[Qemu-devel] Re: [PATCH] spice: add qxl device

[Michael S. Tsirkin]

On Wed, Nov 17, 2010 at 04:20:45PM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> >>>>+        qxl0 = qxl;
> >>>
> >>>What happens when this device is then removed?
> >>
> >>Better don't try ...
> >
> >Better prevent it then?
> 
> How can I do that?
> 
> >>The primary vga can't be hot-unplugged in qemu.  Not only because
> >>the qxl0 pointer would point into nowhere in this case, but also
> >>because you can't unregister the graphic console.
> >
> >But do we really have to make this part of qxl design, with global
> >vars and stuff? Even if we have a limitation in qemu, qxl should be able
> >to keep all its data in device state I think ...
> 
> It isn't part of the qxl design.  It is just that
> register_displaychangelistener() doesn't provide a way to pass
> through a device state pointer, so these callbacks use qxl0 instead.

I see. Fair enough, we'd have to fix that API first.

> >>  Also having non-pci ressources (legacy vga I/O ports) is a problem.
> >
> >I'm not sure why is this a problem. It shouldn't be.
> 
> Because it has ressources not visible in the pci config space?
> But you know the pci specs better than me.  If you think it would
> work you are probably right ;)

Devices report using these legacy resources by declaring special values
in the programming interface register. See appendix D in the spec
if you are curious. VGA is 03.

> >>Because the first one actually *is* different. It is the only one
> >>which is vga compatible.  It serves as primary display.  You'll see
> >>the boot messages there.
> >
> >I thought it's up to the guest where to send boot messages.
> >Modern BIOSes have options to control this behaviour.
> 
> It isn't.  For one qemu has no multihead support.  You'll see
> non-primary displays only when connecting via spice because of that.
> 
> I also doubt seabios supports this.

Not now. But that's guest stuff.

>  How does this work btw?  Only
> one vga adapter can drive the legacy vga ports, right?  Is there
> some way to enable/disable this per vga device?

Yes, just disable IO memory.

>  If so: does qemu
> emulate this correctly?

It mostly does.

> >I think it's a mistake to make things such as device class
> >depend on the order devices are created in.
> >It would be better to make it a separate property, or give it a
> >different name.
> 
> Having qxl-vga and qxl devices would certainly be an option.  Works
> probably better than some qdev property usability-wise.

Sounds good.

> >>I doubt you'll see it wrap in any real world scenario.  Even with one
> >>hotplug + unplug cycle per second you'll need a bunch of years to
> >>see it wrap.  Beside that at least in windows the device can't be
> >>unplugged in the first place, windows will veto the unplug request.
> >
> >Yes but we are splitting the unplug part from the guest eject, so user
> >will in the future be able to perform surprise removal just like with
> >real hardware. And with this in place, it need not take even a
> >millisecond to unplug a device.
> 
> If you do that your guest will likely be quite upset and you'll have
> much bigger problems than the counter wrapping after millions of
> hotplugs.

In the guest. Maybe. Although WHQL includes surprise removal tests
for some cards, so it might work better than you think.

But the counter wrapping will at least in theory crash qemu,
this is an even bigger problem than a guest crash.

>  I also don't see the point in plugging a display like
> mad.

Just to see if you can exploit some memory corruption maybe?

> Can we care about the *real* problems please?
> 
> thanks,
>   Gerd