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: > > > > 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.
It doesn't have anything to do with _STA: device still appears in QOM. 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. > > Besides, both -device pvpanic and use of ioport=0 to disable it > > are completely undocumented. > > > Not the only undocumented thing in QEMU command line :) All -device fields are documented with -device help. This was supposed to be the right way to add all new devices. > > BTW pls keep qemu-devel Cc'd. > > > Haven't touched CC list. > > > > We have different definition of "damage" though. > > > > Driver bugs, qemu bugs, OSPM bugs all can cause issues > > like OS crashes, suspend/resume issues, bad > > performance ... What's your definition of damage? > > > None of those cover the case at hand. Sigh. These examples demonstrate why would user want to run QEMU without the pvpanic device. > -- > Gleb. _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios