Andreas Färber <afaer...@suse.de> writes: > Am 06.08.2013 10:36, schrieb Gleb Natapov: >> 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: >>>>> 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 >>> >>> Doesn't work for me. >> Bug that should be fixed. With this command line _STA should return >> zero. >> >>> Besides, both -device pvpanic and use of ioport=0 to disable it >>> are completely undocumented. >>> >> Not the only undocumented thing in QEMU command line :) > [snip] > > I disagree: -device adds a device, not removes one. It will still be > present. > > I am neutral as to whether qemu-system-x86_64 should have it enabled by > default or not.
Me too. > But if we want to suppress it, then -nodefaults should > disable it. ACK: that's how we do optional devices that are there by default. ioport=0 affecting _STA is *not* "removing" the device, it's changing how the device is exposed to the guest. No opinion on whether it's a good idea or not. > Since libvirt uses that though, it would mean libvirt would > need to add it back, whether via user's XML domain config or by libvirt > itself based on some version/etc. heuristics. Doubt that'll be a problem for libvirt.
