RE: [libvirt] [RFC] Support for CPUID masking v2
From: libvir-list-bounces(a)redhat.com [mailto:libvir-list-
Hi,
This is an attempt to provide similar flexibility to CPU ID masking
without
being x86-specific and unfriendly to users. As suggested by Dan, we need
a
way
to specify both CPU flags and topology to achieve this goal.
Firstly, CPU topology and all (actually all that libvirt knows about)
CPU
features have to be advertised in host capabilities:
<host>
<cpu>
...
<features>
<feature>NAME</feature>
</features>
<topology>
<sockets>NUMBER_OF_SOCKETS</sockets>
<cores>CORES_PER_SOCKET</cores>
<threads>THREADS_PER_CORE</threads>
</topology>
</cpu>
...
</host>
I'm not 100% sure we should represent CPU features as
<feature>NAME</feature>
especially because some features are currently advertised as <NAME/>.
However,
extending XML schema every time a new feature is introduced doesn't look
like
a good idea at all. The problem is we can't get rid of <NAME/>-style
features,
which would result in redundancy:
<features>
<vmx/>
<feature>vmx</feature>
</features>
But I think it's better than changing the schema to add new features.
Secondly, drivers which support detailed CPU specification have to
advertise
it in guest capabilities. In case <features> are meant to be hypervisor
features, than it could look like:
<guest>
...
<features>
<cpu/>
</features>
</guest>
But if they are meant to be CPU features, we need to come up with
something
else:
<guest>
...
<cpu_selection/>
</guest>
I'm not sure how to deal with named CPUs suggested by Dan. Either we
need
to
come up with global set of named CPUs and document what they mean or let
drivers specify their own named CPUs and advertise them through guest
capabilities:
<guest>
...
<cpu model="NAME">
<feature>NAME</feature>
...
</cpu>
</guest>
[IH] you also need to support removing a feature from the base
cpu model,
if it is disabled by bios, like the nx flag).
The former approach would make matching named CPUs with those defined by
a
hypervisor (such as qemu) quite hard. The latter could bring the need
for
hardcoding features provided by specific CPU models or, in case we
decide
not
to provide a list of features for each CPU model, it can complicate
transferring a domain from one hypervisor to another.
And finally, CPU may be configured in domain XML configuration:
<domain>
...
<cpu model="NAME">
<topology>
<sockets>NUMBER_OF_SOCKETS</sockets>
<cores>CORES_PER_SOCKET</cores>
<threads>THREADS_PER_CORE</threads>
</topology>
<feature name="NAME" mode="set|check"
value="on|off"/>
</cpu>
</domain>
Mode 'check' checks physical CPU for the feature and refuses the domain
to
start if it doesn't match. VCPU feature is set to the same value.
Mode
'set'
just sets the VCPU feature.
Final note: <topology> could also be called <cpu_topology> to avoid
confusion
with NUMA <topology>, which is used in host capabilities. However, I
prefer
<cpu><topology>...</topology></cpu> over
<cpu><cpu_topology>...</cpu_topology></cpu>.
Thanks for your comments.
Jirka
--
Libvir-list mailing list
Libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list