qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Cascadelake-Server missing MSR based features ?


From: Daniel P . Berrangé
Subject: Re: [Qemu-devel] Cascadelake-Server missing MSR based features ?
Date: Wed, 20 Mar 2019 13:30:26 +0000
User-agent: Mutt/1.11.3 (2019-02-01)

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 <address@hidden>
> > > >    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.
> 
> 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/address@hidden/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.

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 :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]