On Tue, Mar 19, 2019 at 10:35:33PM +0800, Tao Xu wrote: > On 3/19/2019 8:16 PM, Daniel P. Berrangé wrote: > > The Cascadelake-Server CPU was added last year in > > > > commit c7a88b52f62b30c04158eeb07f73e3f72221b6a8 > > Author: Tao Xu <tao3...@intel.com> > > Date: Wed Sep 19 11:11:22 2018 +0800 > > > > i386: Add new model of Cascadelake-Server > > > > The commit message says that MSR based features are initially > > omitted from its definition: > > > > [quote] > > On Cascadelake, some capabilities (RDCL_NO, IBRS_ALL, RSBA, > > SKIP_L1DFL_VMENTRY and SSB_NO) are enumerated by MSR. > > These features rely on MSR based feature support patch. > > Will be added later after that patch's in. > > http://lists.nongnu.org/archive/html/qemu-devel/2018-09/msg00074.html > > [/quote]
[snip] > > Can anyone shed light on what the status is wrt exposing the MSR based > > features in Cascadelake-Server ? > > Hi, I sent the patch to add the MSR based features with the Update stepping > patch together last year, and we discussed a lot about it: > > [1] https://patchwork.kernel.org/patch/10743427/ Ahh, I see, so none of the MSR based feature stuff is migratable. If migration isn't needed, then they can use "-cpu host" which gets all features automatically. If migration is needed, then the app is using a named CPU model, and no MSR based features should ever be used. Also means that libvirt must be careful to *not* enable MSR based features with "host-model" as this is supposde to be a migratable version of "host-passthrough" Is there any ETA on fixing things so that the MSR features can be used with named models ? Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
