On Wed, Mar 20, 2019 at 01:30:26PM +0000, Daniel P. Berrangé wrote: > On Tue, Mar 19, 2019 at 02:20:01PM -0300, Eduardo Habkost wrote: > > On Tue, Mar 19, 2019 at 04:16:14PM +0000, Daniel P. Berrangé wrote: > > > 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 ? > > > > > > > Making it migratable and usable in named CPU models is the easy > > part. This series is probably enough: > > > > http://lists.nongnu.org/archive/html/qemu-devel/2019-01/msg06701.html > > ("[PATCH 0/2] i386: arch_capabilities fixes + migratability") > > > > I have just realized that I have left my own series fall through > > the cracks. At least patch 1/2 is a bug fix, so I will merge it > > for -rc1.
I've decided to queue both patches for -rc1. > > > > The hard part is enabling the flag by default on existing CPU > > models. We probably need to implement CPU model versioning in > > QEMU 4.1 to do that properly. See discussion at: > > > > https://www.mail-archive.com/qemu-devel@nongnu.org/msg603291.html > > ("Re: [Qemu-devel] [PATCH 2/2] i386: Add some MSR based features > > on Cascadelake-Server CPU model") > > Ok, so once the migration problem is fixed, IIUC the main blocker is > that we want to be able to support use of Cascadelake-Server CPU model > on older kernels that lacked the ARCH_CAPABILITIES support in KVM. > We don't have a nice way to achieve that right now, but the versioned > CPU models concept would allow for a solution. > > IOW, once migration is fixed, it is fine for mgmt apps to enable the > use of the MSR features by turning them on manually for Cascadelake-Server > if they know they don't care about older kernels. After we let management software enable arch_capabilities and set individual bits, the main challenge would be dealing with RSBA safely. In theory we shouldn't let a VM with RSBA=off run on a host with RSBA=on. But we have been allowing this to happen for a few QEMU releases, and it would be difficult to change this behavior without breaking existing configurations. -- Eduardo
