Michael Kelley <[email protected]> writes: > From: Vitaly Kuznetsov <[email protected]> Sent: Friday, April 5, 2019 > 4:11 AM >> > >> > @@ -32,15 +32,15 @@ static inline int fill_gva_list(u64 gva_list[], int >> > offset, >> > do { >> > diff = end > cur ? end - cur : 0; >> > >> > - gva_list[gva_n] = cur & PAGE_MASK; >> > + gva_list[gva_n] = cur & HV_HYP_PAGE_MASK; >> >> I'm not sure this is correct: here we're expressing guest virtual >> addresses in need of flushing, this should be unrelated to the >> hypervisor page size. >> > > I talked to the Hyper-V guys about this. They have not implemented > the HvFlushVirtualAddressList hypercalls for ARM64 yet. But when they > do, they expect the GVA list will need to be in terms of the Hyper-V > page size. They don't want to have to figure out the guest page size > and adjust their arithmetic on a per-guest basis.
Understood, thanks! However, what I wanted to say is that this code is x86-specific (arch/x86/hyperv/mmu.c) and the implementation is hard-wired to the spec, namely we use lower 12 bits (there's even a comment in the code about this which the patch doesn't change) to encode the number of pages to flush. We can speculate that when these hypercalls are implemented on ARM they'll have similar requirements but I'd suggest we leave it as-is for now and fix this when (and, actually, if) we decide to move this to arch-independent part. We may need to do additional adjustments - and we don't know about them yet because there's no spec published. -- Vitaly
