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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list