On Tue, Aug 06, 2013 at 01:23:26PM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 01:14:14PM +0300, Gleb Natapov wrote:
On Tue, Aug 06, 2013 at 01:13:17PM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2013 at 12:29:27PM +0300, Gleb Natapov wrote:
On Tue, Aug 06, 2013 at 05:26:46PM +0800, Hu Tao 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: > > 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.
The internal pvpanic can be disabled by -global pvpanic.ioport=0. -device pvpanic,ioport=0 just adds another pvpanic device.
Yeah, good point.
I tried this, this doesn't remove the device - merely sets the port to 0.
That's the point. And _STA will report it as disabled.
In ACPI? Why have it at all?
You can put whatever you want into ACPI as long as _STA returns disabled status. What's the problem?
You asked if the device can be enable/disable above, not removed. It can.
I really meant QOM/QMP. _STA is only seen by OSPM.
Then you should have said "removed". No you cannot, this is not the only such device. I do not see why would you want to though.
-- Gleb.