[libvirt] [RFC PATCH 0/2] nodeinfo: PPC64: Fix topology and siblings info on capabilities and nodeinfo
Daniel P. Berrange
berrange at redhat.com
Thu Jul 21 16:18:13 UTC 2016
On Thu, Jul 21, 2016 at 05:52:11PM +0200, Andrea Bolognani wrote:
> On Wed, 2016-07-20 at 13:49 +0100, Daniel P. Berrange wrote:
> > > Additionally, this doesn't tell us anything about whether any
> > > host CPU can run a guest CPU: given the above configuration,
> > > on ppc64, we know that CPU 1 can run guest threads even though
> > > it's offline because CPU 0 is online, but the same isn't true
> > > on x86.
> > >
> > > So we would end up needing three new boolean properties:
> > >
> > > - online - whether the CPU is online
> > > - can_run_vcpus - whether the CPU can run vCPUs
> > > - can_pin_vcpus - whether vCPUs can be pinned to the CPU
> >
> > These two can*vcpus props aren't telling the whole story
> > because they are assuming use of KVM - TCG or LXC guests
> > would not follow the same rules for runability here.
> >
> > This is why I think the host capabilities XML should focus
> > on describing what hardware actually exists and its state,
> > and not say anything about guest runnability.
> >
> > Historically we've let apps figure out the runnability
> > of pCPUs vs guest vCPUs, but even on x86 it isn't as simple
> > as you/we make it out to be.
> >
> > For example, nothing here reflects the fact that the host
> > OS could have /sys/fs/cgroups/cpuset/cpuset.cpus configured
> > to a subset of CPUs. So already today on x86, just because
> > a CPU is listed in the capabilities XML, does not imply that
> > you can run a guest on it.
> >
> > So I think there's a gap for exposing information about
> > runability of guests vs host CPUs, that does not really
> > fit in the host capabilities. Possibly it could be in the
> > guest capabilities, but more likely it would need to be
> > a new API entirely.
>
> Why wouldn't domcapabilities be a good place? We already
> have some related information (the <vcpu> tag).
Just depends whether we have all the info we need available
in the domcapabilities API. eg I was wondering whether we
would need info about the guest CPU topology (sockets, core,
threads) too. If we don't, then great, it can be in the
domcapabilities.
> In any case, regardless of whether or not it will ultimately
> be part of domcapabilities, I guess a good starting point is
> to sketch out how the xml would look like. I'm thinking of
> something like
>
> <cpu id='0' runnable='yes' pinnable='yes' run_group='0-3'/>
> <cpu id='1' runnable='yes' pinnable='no' run_group='0-3'/>
> <cpu id='2' runnable='yes' pinnable='no' run_group='0-3'/>
> <cpu id='3' runnable='yes' pinnable='no' run_group='0-3'/>
>
> where 'runnable' tells you whether the CPU can run vCPUs,
> 'pinnable' whether vCPUs can be pinned, and 'run_group' tells
> you what CPUs the pinned vCPUs will actually run on? On x86
What's the relationship to guest CPUs and their topology
here ? Is this trying to say that all vCPUs placed in a
run_group must be in the same virtual socket ?
If so is the pinnable attribute trying to imply that when
you change pinning for a vCPU on the first pCPU in a run
group, that it will automatically change pinning of the
other vCPUs on that same pCPU run group ?
> it would look simpler:
>
> <cpu id='0' runnable='yes' pinnable='yes' run_group='0'/>
> <cpu id='1' runnable='yes' pinnable='yes' run_group='1'/>
>
> I think we don't need to add information that can already be
> obtained from existing capabilities, such as the siblings
> list.
Yep, it'd be nice to avoid duplicating info already exposed in
the host capabilities, such as host topology.
It feels like 'run_group' is however rather duplicating the
info. eg, isn't 'run_group' just directly saying which
cores are part of the same socket.
For sake of clarity can you just back up again & explain exactly
what the rules are wrt PPC & pCPU / vCPU topology and plaement.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
More information about the libvir-list
mailing list