Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out

[Benjamin Herrenschmidt]

On Mon, 2012-07-30 at 16:55 +0300, Avi Kivity wrote:
> > The trouble is predicting which guests have drivers and which guests
> > don't.  Having a VGA model that could be enabled universally with good
> > VBE support for guests without drivers would be a very nice default
> > model.
> 
> I agree.  Hopefully it won't be difficult to get the guest to unmap, or
> maybe we can just unregister the direct RAM mapping in qemu.

I don't understand that part... why on earth would the fb has to be
unmapped ?

> > We've never made the switch because WinXP doesn't have VESA support
> > natively.  But we're slowly getting to the point in time where it's
> > acceptable to require a special command line option for running WinXP
> > guests such that we could consider changing the default machine type.
> 
> Yes.
> 
> > 
> >>> It's not clear to me why it doesn't enable VBE but presumably if it did,
> >>> then accelerations could be mapped through VBE.
> >>
> >> I believe the idea is that you don't want to map the framebuffer into
> >> the guest, this allows one-directional communication so you can defer
> >> rendering to the client and not suffer from the latency.  But I may be
> >> mixing things up.
> > 
> > Hrm, that seems like an odd strategy for legacy VGA.  Spice isn't
> > remoting every pixel update, right?  I would assume it's using the same
> > logic as the rest of the VGA cards and doing bulk updates based on the
> > refresh timer.  In that case, exposing the framebuffer shouldn't matter
> > at all.
> 
> I'd assume so too, but we need to make sure the framebuffer is unmapped
> when in accelerated mode, or at least the guest has no expectations of
> using it.

Well, unmapping it is easy but why would you want to do or enforce
that ? 

> The drm drivers for the current model are needed anyway; so moving to
> virtio is extra effort, not an alternative.
> 
> Note virtio doesn't support mapping framebuffers yet, or the entire vga
> compatibility stuff, so the pc-oriented card will have to be a mix of
> virtio and stdvga multiplexed on one pci card (maybe two functions, but
> I'd rather avoid that).

Well what I'm hacking as a proof of concept right now is std-vga with a
BAR for MMIO regs to supplement the legacy VGA IO and an optional virtio
BAR (which is not BAR 0, see below).

So to be compatible with the existing std-vga I made the virtio BAR be
BAR 3 or something like that (trivial patch in virtio-pci to allow that)
but of course that means a hack in the guest to find it which is
sub-optimal.

We had a chat with Rusty and it would be ideal if we could have a PCI
capability indicating where to find the virtio config space. However
this is a bit problematic because either we use the vendor cap which
means limiting outselves to RH vendor ID and hijacking the vendor cap
for it for ever, or we get the SIG to allocate a capability for virtual
IO devices....

The later is ideal but I don't have contacts at the SIG. It could be
done in a way that is usable by many vendors, ie, the cap itself could
contain a vendor ID indicating the virtualization interface owner along
with some additional data (in our case virtio version, BAR index, BAR
offset).

It does generally make sense to be able to have a device expose a
more/less standard or existing HW interface (one of the USB HCIs, AHCI,
VGA stuff, etc...) and also have a virtio channel for paravirt.

Finally as for s390 & co, well... std-vga is still very PCI'ish, so we'd
have to do a bit more work if we are to disconnect that.

Cheers,
Ben.