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

[Gerd Hoffmann <kraxel@redhat.com>]

   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.

>>   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 ;)

>> 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.  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?  If so: does qemu emulate this 
correctly?

> 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.

>> 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.  I also don't see the point in plugging a display like mad.

Can we care about the *real* problems please?

thanks,
   Gerd