On Fri, Aug 25, 2023, Zeng Guang wrote:
>
> On 8/18/2023 9:53 PM, Sean Christopherson wrote:
> > On Fri, Aug 18, 2023, Binbin Wu wrote:
> > > On 8/17/2023 5:17 PM, Binbin Wu wrote:
> > > > On 8/17/2023 6:25 AM, Sean Christopherson wrote:
> > > > > On Wed, Jul 19, 2023, Binbin Wu wrote:
> > > > > For the next version, can you (or Zeng) send a single series for LAM
> > > > > and LASS? They're both pretty much ready to go, i.e. I don't expect
> > > > > one to hold up the other at this point, and posting a single series
> > > > > will reduce the probability of me screwing up a conflict resolution
> > > > > or missing a dependency when applying.
> > > > >
> > > Hi Sean,
> > > Do you still prefer a single series for LAM and LASS for the next version
> > > when we don't need to rush for v6.6?
> > Yes, if it's not too much trouble on your end. Since the two have overlapping
> > prep work and concepts, and both series are in good shape, my strong preference
> > is to grab them at the same time. I would much rather apply what you've tested
> > and reduce the probability of messing up any conflicts.
> >
> >
> >
> Hi Sean,
> One more concern, KVM LASS patch has an extra dependency on kernel LASS
> series in which enumerates lass feature bit (X86_FEATURE_LASS/X86_CR4_LASS).
> So far kernel lass patch is still under review, as alternative we may extract
> relevant patch part along with kvm lass patch set for a single series in case
> kernel lass cannot be merged before v6.7. Do you think it OK in that way?
Hmm, since getting LASS support in KVM isn't urgent, I think it makes sense to
wait for kernel support, no reason to complicate things.
To avoid delaying LAM, just put all the LAM patches first, it's trivally easy for
me to grab a partial series.
Speaking of kernel support, one thing we should explicit discuss is whether or
not KVM should require kernel support for LASS, i.e. if KVM should support LASS
if it's present in hardware, even if it's not enabled in the host.
Looking at the kernel patches, LASS will be disabled if vsyscall is in emulate
mode. Ah, digging deeper, that's an incredibly esoteric and deprecated mode.
bf00745e7791 ("x86/vsyscall: Remove CONFIG_LEGACY_VSYSCALL_EMULATE").
So scratch that, let's again keep things simple. Might be worth a call out in
the changelog that adds F(LASS), though.
