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