On Mon, Aug 05, 2013 at 09:26:28PM +0300, Michael S. Tsirkin wrote:
On Mon, Aug 05, 2013 at 06:46:06PM +0200, Paolo Bonzini wrote:
On 08/05/2013 06:18 PM, Michael S. Tsirkin wrote:
Depending on the management, "management" could just be the user. Most of the time the user simply says to use virtio in the XML.
If it had to be specified manually every time, pvpanic would be just another knob that nobody uses.
Management tools already set XML appropriately depending on the guest. If users are happy to leave the device alone, we are also happy.
What if the guest is upgraded? How does the user know they have to add a magic device?
Device is useless without a driver anyway.
Who cares? It doesn't eat valuable resources. (20 bytes in the DSDT are not valuable, a PCI slot is).
IO ports are a bit more valuable.
But I was responding to what you said "how does the user know they have to add a magic device" - in the same way that they know they need a driver.
They see yellow exclamation mark in a gui.
How does user know there's need to install a driver?
Apparently that was not a problem in Vista and later, when Microsoft stopped bugging users with the wizard by default. And it's never been a problem in Linux.
But they don't need to know that, since probably no one will write a driver for pvpanic that runs on Windows XP (6 months before EOL) or 2003 (18 months before EOL).
So let's add -device pvpanic to QEMU, same as any device, if you think everyone absolutely wants this device explain this to libvirt guys and they'll add it by default, they are much closer to real users and can treat this appropriately.
It will be exactly the same problem, just thrown further from where you can find a real solution---which is not QEMU and is not libvirt, it is in the firmware.
Really, all guests handle the missing driver without asking the user.
Did you really check them all?
All those that have a GUI that runs by default, and manage drivers in said GUI...
What does GUI have to do with it? Guests can log errors or fail in a variety of ways. GUI is not required.
This is pure speculations. Why OS would fail if it finds HW it does not have driver for if said HW is not needed for the OS to function?
At some point MSFT even issued a hotfix to disable the pesky Found New Hardware wizard. Let's treat it as a guest bug, hide the device altogether with _OSI (detecting Vista or 2008 or Linux), and declare that Windows 2000/XP/2003 lack support for pvpanic.
Sounds like you merely mean all windows guests.
... which means all Windows guests, yes.
Which are the ones where we noticed there's a problem.
What is problematic about guest telling a user that it has HW without a driver? I is just OS doing what OS should do.
But there could be other guests which are problematic.
If you see a mouse in a room, how likely is it that there's a single mouse there?
This is a PV technology which to me looks like it was rushed through and not only set on by default, but without a way to disable it - apparently on the assumption there's 0 chance it can cause any damage. Now that we do know the chance it's not there, why not go back to the standard interface, and why not give users a chance to enable/disable it?
You should be able to disable it with: -device pvpanic,ioport=0 We have different definition of "damage" though.
In other words, let's do the standard thing, and make the new device available with -device pvpanic. And in BIOS, let's just obey what QEMU tells us to do, and not create the device if it's not there.
SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios