[libvirt] [RFC] Support for CPUID masking v2

[Jiri Denemark <jdenemar@xxxxxxxxxx>]

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>

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