On Tue, Aug 06, 2013 at 03:08:32PM +0300, Michael S. Tsirkin wrote:
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.
Qemu is so far from able to do so that I do not consider it such.