Am 06.08.2013 11:32, schrieb Gleb Natapov:
On Tue, Aug 06, 2013 at 12:21:48PM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 11:36:25AM +0300, Gleb Natapov wrote:
On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote:
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
Doesn't work for me.
Bug that should be fixed. With this command line _STA should return zero.
It doesn't have anything to do with _STA: device still appears in QOM.
You said disabled, not removed. So does -global pvpanic,ioport=0 disables the device for you?
It's a QEMU issue, devices that are added with -device are documented in -device help and removed by dropping them from command line. Devices added by default have no way to be dropped from QOM except -nodefaults.
Are you saying that because pvpanic is added automatically QEMU -device help does not print help about it? Why not fix that? What QEMU --help issues has to do with deciding which devices should or should not be present by default?
You misunderstand: -device pvpanic,? will document that there is a numeric port property, which as such is self-documenting. But there's no way for us to document there that port=0 has special meaning of "disable this device in ACPI".
Disabling a device usually requires to not include that device (or in the future to "unrealize" it), which would require some way to suppress having the device created internally by default. As done for floppy, serial, etc. devices in x86 IIUC, which are in the same PIO situation as the pvpanic device, except that they represent physical devices. Adding some -no-pvpanic switch might be an alternative. And if not done already, disabling the pvpanic device should definitely be documented for the man page.
To me this is less a concrete problem with Windows guests but a conceptual question of how we go about enabling/disabling QEMU devices in a hopefully consistent way.
Writing a driver does not solve it fully, you'd still need to actively install that driver, same issue as with virtio. virtio is opt-in, so for customers not using our VM Driver Pack we offer AHCI as driver-less alternative.
I wonder if IPMI might be such an alternative in the future, in which case we should come up with some way to fully disable pvpanic device creation. CC'ing Corey.