On 14.12.2016 00:57, John Ferlan wrote: > > > On 11/24/2016 04:55 AM, Nitesh Konkar wrote: >> Currently when the vcpu placement is static >> and cpuset is not specified, CPU Affinity >> under virsh vcpupin shows 0..CPUMAX. This >> patchset will result in display of only >> online CPU's under CPU Affinity on linux. >> >> Signed-off-by: Nitesh Konkar <nitkon12@xxxxxxxxxxxxxxxxxx> >> --- >> src/conf/domain_conf.c | 6 ++++++ >> 1 file changed, 6 insertions(+) >> > > It seems there are some similarities to Viktor's series: > > http://www.redhat.com/archives/libvir-list/2016-November/msg01320.html > > at least with respect to creating an accessor function (in patch 1) > virHostCPUHasBitmap that will hide that virHostCPUGetOnlineBitmap call > and the ugly #ifdef __linux__ in the domain_conf.c file. > > Using virHostCPUHasBitmap will hide the need for the #ifdef... > > Secondary, should there be a fallback in the event that a NULL is > returned from virHostCPUGetOnlineBitmap? > > Finally, does there need to be a similar call to like what Viktor did > w/r/t virProcessGetAffinity and making sure the bitmaps are equal? > The intention of this series is (iiuc) to reflect the live situation inflicted by the host's current online cpu map. In order to do that, one would have to distinguish between running and a defined only domains. The code as proposed would currently only reflect the 'defined' situation. For a running domain, virProcessGetAffinity would return the equivalent cpu mask. Which, btw. would have to be used even if the domain is carrying a cpumask. Otherwise the live state wouldn't be reflected properly. The question is probably whether the vcpu pin info is supposed to reflect the real or the intended state. The current implementation treats it as the intended state. Personally, I'd find the following behavior most logical: Invoked with VIR_DOMAIN_AFFECT_LIVE: Get/set the process current cpu affinity. Don't touch the definition. This would reflect the real live state. Invoked with VIR_DOMAIN_AFFECT_CONFIG: Get/set the values in the persistent domain configuration only. This would reflect the intended state. I don't think however that this intended state should depend on the current online host cpus. This would still not reveal whether the vcpus are pinned or not. I am wondering whether we just might need a new API telling us whether a domain is pinned or not (if we don't want to client to parse the domain XML)? [...] -- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
