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