Re: [Qemu-devel] [PATCH] hw/pci: disable pci-bridge's shpc by default

[Eduardo Habkost]

On Thu, Nov 03, 2016 at 06:43:05PM +0200, Marcel Apfelbaum wrote:
> On 11/03/2016 05:24 PM, Laine Stump wrote:
> > On 11/03/2016 07:08 AM, Marcel Apfelbaum wrote:
> > > On 11/02/2016 06:01 PM, Laine Stump wrote:
> > > > On 11/02/2016 11:16 AM, Marcel Apfelbaum wrote:
> > > > > The shpc component is optional while  ACPI hotplug is used
> > > > > for hot-plugging PCI devices into a PCI-PCI bridge.
> > > > > Disabling the shpc by default will make slot 0 usable at boot time
> > > > > and not only for hot-plug, without loosing any functionality.
> > > > > Older machines will have shpc enabled for compatibility reasons.
> > > > 
> > > > From libvirt's POV, changing qemu's default for shpc in qemu only
> > > > serves to confuse; since we have no way to discover what is the
> > > > default setting (especially problematic since it is different for
> > > > different machinetype versions), we now either need to keep a table of
> > > > what the setting is for various machinetypes, or we need to just
> > > > always set it whether it's on or off.
> > > > 
> > > > So for us, the simplest thing is for the default to remain the same
> > > > (since for so long we haven't set this option as we didn't even know
> > > > what it did, or indeed even that it existed), and for libvirt
> > > > to learn about the option, make its default in the config files "on",
> > > > but begin setting it to "off" in all newly defined machines.
> > > > 
> > > 
> > > Hi Laine,
> > > 
> > > Please see my reply to Michael regarding the "why", anyway, can't
> > > libvirt deal with it?
> > > Start use the shpc parameter no matter what QEMU does by default while
> > > keeping it 'on' for machines < 2.8.
> > > (this is only a suggestion, of course...)
> > 
> > 
> > We greatly dislike coding in behavior changes to libvirt
> > based on machinetype/version or qemu version since a version
> > number is a very broad and inaccurate sword. The best
> > behavior changes are those that can be discovered by querying
> > something specific to that behavior, which can't be done in
> > this case, as there is no way to query *anything* specific to
> > a machinetype without instantiating a virtual machine of that
> > machinetype (if it's even queryable then, which is anyway
> > irrelevant to libvirt, since our queries to qemu are done
> > with -machine none).
> > 
> 
> +Eduardo
> 
> Hi Eduardo,
> Can your work can help on this specific case?

In this cases, the needed mechanisms already exist. We just need
to encode that info in the MachineInfo struct, so that it gets
returned by the "query-machines" QMP command. (But making QEMU
maintainers agree on how to encode stuff in QMP is always a
challenge.)

> 
> 
> > libvirt can of course deal with such a change in default behavior by qemu, 
> > but the way it will deal with it is by removing all assumptions about the 
> > default of shpc from the code, and replacing those
> > assumptions with explicit setting of the option in the xml and on the qemu 
> > command line all the time.
> > 
> > In the end, libvirt wouldn't gain anything from this change in qemu's 
> > default behavior - it would be more work than just adding a setting for 
> > shpc to libvirt and having *libvirt* change its default
> > setting (which has the same ultimate results). Of course that's a 
> > relatively selfish (libvirt-centric) view, and I suppose direct users of 
> > the qemu commandline might get some benefit from changing the
> > qemu default, but anyone concerned enough about the exact commandline 
> > contents to be running qemu directly would probably also not have a problem 
> > adding an option to the commandline if they really
> > wanted a 1/32 increase in the number of available slots.
> > 
> 
> As I explained to Michael, this is not only about the extra slot, but
> more about the usage model.
> I do understand the libvirt point of view, on the other hand why
> should we use a default QEMU value that the majority of users don't need?

This is a common problem: sometimes we want to make the default
behavior saner on new machine-types, but changing the default
behavior often doesn't help libvirt (and makes life more
difficult for everybody).

I hope this will become easier over time, once we start making
machine-type info easily discoverable by libvirt.

-- 
Eduardo