qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [SeaBIOS] [PATCH] don't expose pvpanic device in the UI


From: Gleb Natapov
Subject: Re: [Qemu-devel] [SeaBIOS] [PATCH] don't expose pvpanic device in the UI
Date: Tue, 6 Aug 2013 13:44:42 +0300

On Tue, Aug 06, 2013 at 01:19:53PM +0300, Michael S. Tsirkin wrote:
> > > 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?
> 
> No, I'm saying what I said: that there's no way to remove a device
> added by default except -nodefaults, and no way to
> find out what does -nodefaults exclude so you
> can add things you need back selectively.
> 
And what are the rules that govern device exclusion from -nodefaults
list? Why -nodefaults does not create empty machine?

> We wanted to fix the later issue for a long time, it's
> hard to fix - that's why we don't fix that.
> Just using -device for everything is a work-around for now.
> 
That's workaround that makes usability suffer, not a good compromise.

Anyway the thread is started by assertion that the device breaks guests
which it does not, now we moved to documentation realm which should not
have any say about default machine functionality.

> > > > > 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.
> > > 
> > He can disable it, but chances the device will cause aforementioned
> > problems are so much smaller (by design mind you) than PV APIC hotplug
> > device that it makes me wonder why haven't you advocate to make PV APIC
> > hotplug device to be configurable with -device too.
> 
> This might be a good idea for Q35.
> We probably want to keep it as is for PIIX for compatibility.
> Then again, different behaviour for Q35/PIIX might confuse people.
> 
There is nothing more confusing for people than find out that -cdrom is
not usable with Q35. Really, after that nothing can surprise Q35 user
any more :)

--
                        Gleb.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]