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 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.
--
Gleb.
