[<prev] [next>] [day] [month] [year] [list]
Message-ID: <87v9zjg16g.fsf@vitty.brq.redhat.com>
Date: Fri, 12 Apr 2019 08:58:15 +0200
From: Vitaly Kuznetsov <vkuznets@...hat.com>
To: Michael Kelley <mikelley@...rosoft.com>,
"m.maya.nakamura" <m.maya.nakamura@...il.com>
Cc: "x86\@kernel.org" <x86@...nel.org>,
"linux-hyperv\@vger.kernel.org" <linux-hyperv@...r.kernel.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
KY Srinivasan <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Stephen Hemminger <sthemmin@...rosoft.com>,
"sashal\@kernel.org" <sashal@...nel.org>
Subject: RE: [PATCH 4/6] x86: hv: mmu.c: Replace page definitions with Hyper-V specific ones
Michael Kelley <mikelley@...rosoft.com> writes:
> From: Vitaly Kuznetsov <vkuznets@...hat.com> 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
Powered by blists - more mailing lists