[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YuQjtLK1uk3/bhK/@google.com>
Date: Fri, 29 Jul 2022 18:15:16 +0000
From: Sean Christopherson <seanjc@...gle.com>
To: Kai Huang <kai.huang@...el.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, Michael Roth <michael.roth@....com>,
Tom Lendacky <thomas.lendacky@....com>
Subject: Re: [PATCH 3/4] KVM: SVM: Adjust MMIO masks (for caching) before
doing SEV(-ES) setup
On Fri, Jul 29, 2022, Kai Huang wrote:
> On Thu, 2022-07-28 at 22:17 +0000, Sean Christopherson wrote:
> > Adjust KVM's MMIO masks to account for the C-bit location prior to doing
> > SEV(-ES) setup. A future patch will consume enable_mmio caching during
> > SEV setup as SEV-ES _requires_ MMIO caching, i.e. KVM needs to disallow
> > SEV-ES if MMIO caching is disabled.
> >
> > Cc: stable@...r.kernel.org
> > Signed-off-by: Sean Christopherson <seanjc@...gle.com>
> > ---
> > arch/x86/kvm/svm/svm.c | 9 ++++++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> > index aef63aae922d..62e89db83bc1 100644
> > --- a/arch/x86/kvm/svm/svm.c
> > +++ b/arch/x86/kvm/svm/svm.c
> > @@ -5034,13 +5034,16 @@ static __init int svm_hardware_setup(void)
> > /* Setup shadow_me_value and shadow_me_mask */
> > kvm_mmu_set_me_spte_mask(sme_me_mask, sme_me_mask);
> >
> > - /* Note, SEV setup consumes npt_enabled. */
> > + svm_adjust_mmio_mask();
> > +
> > + /*
> > + * Note, SEV setup consumes npt_enabled and enable_mmio_caching (which
> > + * may be modified by svm_adjust_mmio_mask()).
> > + */
> > sev_hardware_setup();
>
> If I am not seeing mistakenly, the code in latest queue branch doesn't consume
> enable_mmio_caching. It is only added in your later patch.
>
> So perhaps adjust the comment or merge patches together?
Oooh, I see what you're saying. I split the patches so that if this movement turns
out to break something then bisection will point directly here, but that's a pretty
weak argument since both patches are tiny. And taking patch 4 without patch 3,
e.g. in the unlikely event this movement needs to be reverted, is probably worse
than not having patch 4 at all, i.e. having somewhat obvious breakage is better.
So yeah, I'll squash this with patch 4.
Thanks!
Powered by blists - more mailing lists