[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: [libvirt] [RFC] Support for CPUID masking v2



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]