On Tue, Aug 06, 2013 at 02:00:35PM +0300, Gleb Natapov wrote:
On Tue, Aug 06, 2013 at 12:35:10PM +0200, Andreas Färber wrote:
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
Yes, this is how I found it.
way for us to document there that port=0 has special meaning of "disable this device in ACPI".
Adding capability to describe a property should solve that and is a good idea regardless, no? "pvpanic.ioport=uint16" is not very descriptive.
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.
We should not add -no-pvpanic! If there is a legitimate use for -no-pvpanic we should go with MST suggestion and do not create it by default. The question is why would anyone use -no-pvpanic? Legit reason, not just "to remove pvpanic".
To be able to emulate a real hardware system without any PV devices. I think it's a reasonable requirement.
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.
Agree. Now I see that some devises always present (even with -nodefualts) and some do not. The logic is not clear, but seams to be: if there is not legit reason to disable device or for stable topology device placemen need to be controlled, disable it with -nodefualts. In that case I do not see why pvpanic would not be always present.
The reason this whole thread started with is non issue.
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.
There is no functionality loss without a driver. User is not required to install drivers.
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.
IPMI was considered, to complicated for what was needed.