Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device

[Eduardo Habkost]

On Tue, Oct 10, 2017 at 12:44:26AM +0300, Michael S. Tsirkin wrote:
> On Mon, Oct 09, 2017 at 02:02:18PM +0100, Daniel P. Berrange wrote:
> > On Mon, Oct 09, 2017 at 02:43:44PM +0200, Igor Mammedov wrote:
> > > On Mon, 9 Oct 2017 12:03:36 +0100
> > > "Daniel P. Berrange" <address@hidden> wrote:
> > > 
> > > > On Mon, Sep 11, 2017 at 06:59:24PM +0200, Marc-André Lureau wrote:
> > > > > See docs/specs/vmcoreinfo.txt for details.
> > > > > 
> > > > > "etc/vmcoreinfo" fw_cfg entry is added when using "-device 
> > > > > vmcoreinfo".  
> > > > 
> > > > I'm wondering if you considered just adding the entry to fw_cfg by
> > > > default, without requiring any -device arg ? Unless I'm 
> > > > misunderstanding,
> > > > this doesn't feel like a device to me - its just a well known bucket
> > > > in fw_cfg IIUC ?  Obviously its existance would need to be tied to
> > > > the latest machine type for ABI reasons though. The benefit of this
> > > > is that it would "just work" without us having to plumb it through to
> > > > all the downstream applications that use QEMU for mgmt guest (OpenStack,
> > > > oVirt, GNOME Boxes, virt-manager, and countless other mgmt apps).
> > > it follows model set by pvpanic device, it's easier to manage from 
> > > migration
> > > POV, one could use it even for old machine types with new qemu (just by 
> > > adding
> > > device, it makes instance not backwards migratable to old qemu but should 
> > > work
> > > for forward migration) and if user doesn't need it, device could be just 
> > > omitted
> > > from CLI.
> > 
> > Sure but it means that in effect no one will have this functionality enabled
> > for several years. pvpanic has been around a long time and I rarely see it
> > present in configured guests :-(
> > 
> > 
> > Regards,
> > Daniel
> 
> libvirt runs with -nodefaults, right? I'd argue pretty strongly -nodefaults
> shouldn't add optional devices anyway.

Does it mean every time we make a PC device configurable, we
should make it be disabled by -nodefaults, and require libvirt to
adapt?

I don't think that would be a good idea.  Imagine the hassle the
"pc: make .* configurable" patches[1] would generate for libvirt.

> 
> So it's up to you guys, you can add it to VMs by default if you want to.

To be honest, I think "no defaults" is a misleading name for an
option.  If it really meant "create no optional device at all",
it would eventually become a synonym for "-machine none", and I
don't think that's its goal.

I expect PC to always have a set of devices/features that are
disabled by -nodefaults, and a set of devices/features that are
not disabled by -nodefaults.  We need good judgement to decide on
which set the device will be, and I believe Daniel exposed good
arguments to put vmcoreinfo in the second set.

[1] https://www.mail-archive.com/address@hidden/msg393493.html
    Subject: [RFC PATCH v2 00/12] Guest startup time optimization

-- 
Eduardo