On Tue, Nov 04, 2025 at 11:08:23AM +0000, Brendan Jackman wrote:
> On Mon Nov 3, 2025 at 10:50 AM UTC, Mike Rapoport wrote:
> >
> >> >> > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> >> >> > index 1d0585616aa3..73a15cade54a 100644
> >> >> > --- a/include/linux/kvm_host.h
> >> >> > +++ b/include/linux/kvm_host.h
> >> >> > @@ -731,6 +731,12 @@ static inline bool 
> >> >> > kvm_arch_has_private_mem(struct kvm *kvm)
> >> >> >  bool kvm_arch_supports_gmem_mmap(struct kvm *kvm);
> >> >> >  #endif
> >> >> >  
> >> >> > +#ifdef CONFIG_KVM_GUEST_MEMFD
> >> >> > +#ifndef kvm_arch_gmem_supports_no_direct_map
> >> >> > +#define kvm_arch_gmem_supports_no_direct_map can_set_direct_map
> >> >> > +#endif
> >> >> > +#endif /* CONFIG_KVM_GUEST_MEMFD */
> >> >> 
> 
> But this is for CONFIG_ARCH_HAS_DIRECT_MAP? I am reading this as a stub
> to fill in for archs that have set_direct_map_*, but don't have runtime
> disablement like arm64.

You are right.
 
> Whereas my concern is archs that don't have set_direct_map_* at all,
> i.e. where we need to unconditionally fail
> GUEST_MEMFG_FLAG_NO_DIRECT_MAP.
> 
> (Or would we prefer to just not define it at all on those archs? Not
> sure what the norms are there, I guess that's a question for KVM/arch
> maintainers).

It makes sense to define can_set_direct_map to false for arches that don't
support set_direct_map. 

-- 
Sincerely yours,
Mike.

Reply via email to