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

[Gerd Hoffmann]

  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