Re: [PATCH kernel 1/3] x86/amd/dr_addr_mask: Cache values in percpu variables

[Alexey Kardashevskiy]

On 7/12/22 04:07, Sean Christopherson wrote:
> On Tue, Dec 06, 2022, Alexey Kardashevskiy wrote:
> > On 2/12/22 03:58, Sean Christopherson wrote:
> > > On Thu, Dec 01, 2022, Alexey Kardashevskiy wrote:
> > > > diff --git a/arch/x86/include/asm/debugreg.h b/arch/x86/include/asm/debugreg.h
> > > > index cfdf307ddc01..c4324d0205b5 100644
> > > > --- a/arch/x86/include/asm/debugreg.h
> > > > +++ b/arch/x86/include/asm/debugreg.h
> > > > @@ -127,6 +127,7 @@ static __always_inline void local_db_restore(unsigned long dr7)
> > > >    #ifdef CONFIG_CPU_SUP_AMD
> > > >    extern void set_dr_addr_mask(unsigned long mask, int dr);
> > > > +extern unsigned long get_dr_addr_mask(int dr);
> > > >    #else
> > > >    static inline void set_dr_addr_mask(unsigned long mask, int dr) { }
> > >
> > > KVM_AMD doesn't depend on CPU_SUP_AMD, i.e. this needs a stub.  Or we need to add
> > > a dependency.
> >
> > The new symbol is under CONFIG_CPU_SUP_AMD and so is its only user
> > arch/x86/kernel/cpu/amd.c:
> >
> > arch/x86/kernel/cpu/Makefile:
> > obj-$(CONFIG_CPU_SUP_AMD)               += amd.o
> >
> >
> > Is this enough dependency or we need something else? (if enough, I'll put it
> > into the next commit log).
>
> No, it's actually the opposite, the issue is precisely that the symbol is buried
> under CPU_SUP_AMD.  KVM_AMD doesn't currently depend on CPU_SUP_AMD, and so the
> usage in sev_es_prepare_switch_to_guest() fails to compile if CPU_SUP_AMD=n and
> KVM_AMD={Y,M}.

Ouch, you are one step ahead, 2/3 fails, not this one. My bad. I'll add 
a stub anyway.

btw I want to do "s/int dr/unsigned int dr/" since I am using an array 
now. Does it have to be patch#1 "fix set_dr_addr_mask" and then patch#2 
"add get_dr_addr_mask" or one patch will do? Thanks,


>    config KVM_AMD
> 	tristate "KVM for AMD processors support"
> 	depends on KVM
>
> I actually just submitted a patch[*] to "fix" that since KVM requires the CPU vendor
> to be AMD or Hygon at runtime.

>  Although that patch is buried in the middle of a
> large series, it doesn't have any dependencies.  So, if this series is routed through
> the KVM tree, it should be straightforward to just pull that patch into this series,
> and whichever series lands first gets the honor of applying that patch.
>
> If this series is routed through the tip tree, the best option may be to just add
> a stub to avoid potential conflicts, and then we can rip the stub out later.
>
> [*] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2F20221201232655.290720-12-seanjc%40google.com&data=05%7C01%7CAlexey.Kardashevskiy%40amd.com%7C6ee92cb78f8f446b887908dad7ac6fca%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638059432896741545%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=25f18IS6z9HEf0Qtt%2BFDxZdtbTVPg%2FVulsFGhWLH0Rg%3D&reserved=0

--
Alexey