On Monday 02 Aug 2021 at 16:52:31 (+0200), Fuad Tabba wrote: > Hi Quentin. > > On Thu, Jul 29, 2021 at 3:28 PM Quentin Perret <qper...@google.com> wrote: > > > > Introduce a helper usable in nVHE protected mode to check whether a > > physical address is in a RAM region or not. > > > > Signed-off-by: Quentin Perret <qper...@google.com> > > --- > > arch/arm64/kvm/hyp/include/nvhe/mem_protect.h | 1 + > > arch/arm64/kvm/hyp/nvhe/mem_protect.c | 7 +++++++ > > 2 files changed, 8 insertions(+) > > > > diff --git a/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h > > b/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h > > index cc86598654b9..5968fbbb3514 100644 > > --- a/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h > > +++ b/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h > > @@ -51,6 +51,7 @@ extern const u8 pkvm_hyp_id; > > int __pkvm_prot_finalize(void); > > int __pkvm_mark_hyp(phys_addr_t start, phys_addr_t end); > > > > +bool addr_is_memory(phys_addr_t phys); > > I'm just wondering about the naming of the function. I understand what > you're trying to achieve with it, but an address without a unit that > conveys size or type seems to be missing something. Would
Well it does have a type no? I was hopping this would make it clear what it actually does. > memregion_addr_is_memory or something like that be a better > description, since it is what find_mem_range finds? I think the callers shouldn't need to care about the implementation details though. This just replies to the question 'is this physical address in RAM range or not?'. And I could actually imagine that we would change the implementation some day to avoid the binary search, but the users probably don't need to care. Thanks, Quentin _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
