[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Benjamin Herrenschmidt
Subject: Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out
Date: Tue, 31 Jul 2012 13:26:32 +1000

On Mon, 2012-07-30 at 19:17 -0500, Anthony Liguori wrote:

> This is a detail of how Spice/QXL works.  It is not a framebuffer
> protocol.
> Spice sends a series of rendering commands.  It not rendering to a flat
> framebuffer but rather to window-like objects.  It maintains a list of
> these commands and objects and even maintain a tree to understand
> z-ordering.

So it's GDI on the wire roughly :-)

> It remotes these commands over the network and the client does all the
> magic that your compositing manager/window manager/X server would
> normally do.  This is why it's so complicated, it's doing an awful lot.

So akin to a rootless X server ? 

> Normally, the framebuffer that the guest sees (it must exist, it's VGA
> after all) is never updated.  If the guest attempts to read the
> framebuffer (it normally doesn't), Spice/QXL will render the entire
> queue all at once to produce the framebuffer result.  This is a slow
> path because it doesn't happen normally.
> Unmapping is probably the wrong word.  Quiescing is probably a better
> term.

I'd say we keep the fb around, whether it's actually actively updated or
not indeed depends on the active driver in the guest. That way we can
switch back to dumb fb easily for oopses or kernel text console.

I'll dig a bit more later see if I can figure out more of the innards of
spice/qxl. Note also that the .br folks are working on a qxl over
virtio, I'll catch up with them this week to make sure we coordinate our

> >> > 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 ? 
> Because Spice depends on keeping the framebuffer inconsistent.

That's ok, we don't need to unmap the object for that. We can "switch"
to "GDI mode" in which case it goes back to not triggering updates, it
can still be written to, this just has no visible effect. That way the
kernel can trivially switch it back on with a single command of some
sort for things like emergency oops display, switch to text consoles,
you name it ....

> >> 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.
> Why does it need to be compatible?  I don't think there's anything in
> VESA that mandates the framebuffer be in BAR 0.  In fact, I don't think
> VESA even mandates PCI.
> VBE is strictly a BIOS interface.  So you could move the framebuffer to
> BAR 1 by just modifying SeaBIOS.

Well, I didn't want to diverge too much from the existing one bcs things
like openbios know about it but I'm starting to think that this is a
stupid idea. See my other email on that subject.

> > 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.
> Typically, PCI capabilities point to the PCI config space.  But the
> virtio config space is not part of the PCI config space.  It's in BAR0.
> So this doesn't make a lot of sense to me.

No the idea was to have a PCI cap akin to the MSI-X cap that indicates
that the device supports virtio, which version of it, and indicates
which BAR has the virtio config space (just like an MSI-X cap tells you
which BAR has the MSI-X config table).

But I'm not thinking I'll just do a proper virtio with BAR 0, it's
cleaner to do that and fix the various firmwares to look for BAR 2 for
the fb instead and those FW aren't very hard to fix (tho I might ask for
a hand with the x86 asm in vbe bios). Also that way I get a clean break
so I can use a proper vendor ID (btw. BAR 2 rather than BAR 1 so it can
be a BAR pair in 64-bit space in the future).

> >From a virtio perspective, if there was an API to "map area of memory
> from host", virtio-pci could use a transport feature flag to indicate
> that such an area existed.  It would be a fully compatible change to
> virtio-pci.
> >From a VGA perspective, as long as we set the class code correctly and
> handle legacy VGA access, it should all be fine.  We would need to
> implement VBE in terms of virtio commands but that shouldn't be a
> problem.
> I think the best approach is to have some basic commands for managing
> things like resolution setting, 2d accelerations, etc.  A feature flag
> could be used to say "this device speaks Spice too."

Yup, that's where I'm headed. One remaining question is whether I keep
an MMIO programming interface for mode setting, which might be easier
for firmwares/BIOSen so they don't have to deal with DMA. There is the
legacy ports but those can be hard to reach on some platforms.

My current thinking is thus:

- BAR 0 -> virtio
- BAR 1 -> MMIO image of the legacy ports
- BAR 2/3 -> fb (2 initially, 2+3 64-bit BAR in the future)

Additionally, the virtio transport will provide commands to access the
mode setting/VGA registers as well so a guest driver doesn't have to
access BAR 1. It also makes it easier to have a non-PCI variant.

This is all pretty easy so far so I'll give that a shot and come back
when I have actual patches, we can discuss further from that point.

It might be a good idea to implement VBE 3 with blits as well btw
provided Windows can make use of it (can it ?)


> Regards,
> Anthony Liguori
> > 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]