All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] ARM/arm64: KVM: test properly for a PTE's uncachedness
Date: Mon, 9 Nov 2015 17:59:42 +0100	[thread overview]
Message-ID: <CAKv+Gu_agkv7aDqj7fgdoWU+9k=eJ-0YU7WrDKm1_wtr_xYQ6g@mail.gmail.com> (raw)
In-Reply-To: <20151109163519.GB12968@cbox>

On 9 November 2015 at 17:35, Christoffer Dall
<christoffer.dall@linaro.org> wrote:
> On Mon, Nov 09, 2015 at 05:27:40PM +0100, Ard Biesheuvel wrote:
>> On 9 November 2015 at 17:21, Christoffer Dall
>> <christoffer.dall@linaro.org> wrote:
>> > On Fri, Nov 06, 2015 at 12:43:08PM +0100, Ard Biesheuvel wrote:
>> >> The open coded tests for checking whether a PTE maps a page as
>> >> uncached use a flawed 'pte_val(xxx) & CONST != CONST' pattern,
>> >> which is not guaranteed to work since the type of a mapping is an
>> >> index into the MAIR table, not a set of mutually exclusive bits.
>> >>
>> >> Considering that, on arm64, the S2 type definitions use the following
>> >> MAIR indexes
>> >>
>> >>     #define MT_S2_NORMAL            0xf
>> >>     #define MT_S2_DEVICE_nGnRE      0x1
>> >>
>> >> we have been getting lucky merely because the S2 device mappings also
>> >> have the PTE_UXN bit set, which means that a device PTE still does not
>> >> equal a normal PTE after masking with the former type.
>> >>
>> >> Instead, implement proper checking against the MAIR indexes that are
>> >> known to define uncached memory attributes.
>> >>
>> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> >> ---
>> >>  arch/arm/include/asm/kvm_mmu.h   | 11 +++++++++++
>> >>  arch/arm/kvm/mmu.c               |  5 ++---
>> >>  arch/arm64/include/asm/kvm_mmu.h | 12 ++++++++++++
>> >>  3 files changed, 25 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
>> >> index 405aa1883307..422973835d41 100644
>> >> --- a/arch/arm/include/asm/kvm_mmu.h
>> >> +++ b/arch/arm/include/asm/kvm_mmu.h
>> >> @@ -279,6 +279,17 @@ static inline void __kvm_extend_hypmap(pgd_t *boot_hyp_pgd,
>> >>                                      pgd_t *merged_hyp_pgd,
>> >>                                      unsigned long hyp_idmap_start) { }
>> >>
>> >> +static inline bool __kvm_pte_is_uncached(pte_t pte)
>> >> +{
>> >> +     switch (pte_val(pte) & L_PTE_MT_MASK) {
>> >> +     case L_PTE_MT_UNCACHED:
>> >> +     case L_PTE_MT_BUFFERABLE:
>> >> +     case L_PTE_MT_DEV_SHARED:
>> >> +             return true;
>> >> +     }
>> >
>> > so PTEs created by setting PAGE_S2_DEVICE will end up hitting in one of
>> > these because L_PTE_S2_MT_DEV_SHARED is the same as L_PTE_MT_BUFFERABLE
>> > for stage-2 mappings and PAGE_HYP_DEVICE end up using
>> > L_PTE_MT_DEV_SHARED.
>> >
>> > Totally obvious.
>> >
>>
>> Hmm, perhaps not. Would you prefer all aliases of the L_PTE_MT_xx
>> constants that map to device permissions to be listed here?
>>
>
> Meh, there's no great solution and this code is all the kind of code
> that you just need to take the time to understand.  We could add a
> comment I suppose, if I got the above correct, I can throw something in?
>

Actually, I think the patch is wrong, and so is the commit message.

I got confused between HYP mappings and stage 2 mappings. HYP mappings
use an index into the MAIR (which HYP inherits from the kernel) but
the stage 2 mappings have a bit fiield describing the type.

So for one, I think that means that __kvm_pte_is_uncached() cannot be
used for both HYP and stage-2 PTE's, or we'd need to add a parameter
to distinguish between them.

For HYP mappings, we need to compare the MAIR index to values that are
known to refer to device or uncached mappings (as the patch does)
For S2 mappings, we need to mask the MemAttr[5:2] field, and interpret
it according to the description in the ARM ARM, i.e., MemAttr[3:2] ==
0b00 indicates device, MemAttr[3:0] == 0b0101 is uncached memory,
anything else requires cache maintenance.

-- 
Ard.

WARNING: multiple messages have this Message-ID (diff)
From: ard.biesheuvel@linaro.org (Ard Biesheuvel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM/arm64: KVM: test properly for a PTE's uncachedness
Date: Mon, 9 Nov 2015 17:59:42 +0100	[thread overview]
Message-ID: <CAKv+Gu_agkv7aDqj7fgdoWU+9k=eJ-0YU7WrDKm1_wtr_xYQ6g@mail.gmail.com> (raw)
In-Reply-To: <20151109163519.GB12968@cbox>

On 9 November 2015 at 17:35, Christoffer Dall
<christoffer.dall@linaro.org> wrote:
> On Mon, Nov 09, 2015 at 05:27:40PM +0100, Ard Biesheuvel wrote:
>> On 9 November 2015 at 17:21, Christoffer Dall
>> <christoffer.dall@linaro.org> wrote:
>> > On Fri, Nov 06, 2015 at 12:43:08PM +0100, Ard Biesheuvel wrote:
>> >> The open coded tests for checking whether a PTE maps a page as
>> >> uncached use a flawed 'pte_val(xxx) & CONST != CONST' pattern,
>> >> which is not guaranteed to work since the type of a mapping is an
>> >> index into the MAIR table, not a set of mutually exclusive bits.
>> >>
>> >> Considering that, on arm64, the S2 type definitions use the following
>> >> MAIR indexes
>> >>
>> >>     #define MT_S2_NORMAL            0xf
>> >>     #define MT_S2_DEVICE_nGnRE      0x1
>> >>
>> >> we have been getting lucky merely because the S2 device mappings also
>> >> have the PTE_UXN bit set, which means that a device PTE still does not
>> >> equal a normal PTE after masking with the former type.
>> >>
>> >> Instead, implement proper checking against the MAIR indexes that are
>> >> known to define uncached memory attributes.
>> >>
>> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> >> ---
>> >>  arch/arm/include/asm/kvm_mmu.h   | 11 +++++++++++
>> >>  arch/arm/kvm/mmu.c               |  5 ++---
>> >>  arch/arm64/include/asm/kvm_mmu.h | 12 ++++++++++++
>> >>  3 files changed, 25 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
>> >> index 405aa1883307..422973835d41 100644
>> >> --- a/arch/arm/include/asm/kvm_mmu.h
>> >> +++ b/arch/arm/include/asm/kvm_mmu.h
>> >> @@ -279,6 +279,17 @@ static inline void __kvm_extend_hypmap(pgd_t *boot_hyp_pgd,
>> >>                                      pgd_t *merged_hyp_pgd,
>> >>                                      unsigned long hyp_idmap_start) { }
>> >>
>> >> +static inline bool __kvm_pte_is_uncached(pte_t pte)
>> >> +{
>> >> +     switch (pte_val(pte) & L_PTE_MT_MASK) {
>> >> +     case L_PTE_MT_UNCACHED:
>> >> +     case L_PTE_MT_BUFFERABLE:
>> >> +     case L_PTE_MT_DEV_SHARED:
>> >> +             return true;
>> >> +     }
>> >
>> > so PTEs created by setting PAGE_S2_DEVICE will end up hitting in one of
>> > these because L_PTE_S2_MT_DEV_SHARED is the same as L_PTE_MT_BUFFERABLE
>> > for stage-2 mappings and PAGE_HYP_DEVICE end up using
>> > L_PTE_MT_DEV_SHARED.
>> >
>> > Totally obvious.
>> >
>>
>> Hmm, perhaps not. Would you prefer all aliases of the L_PTE_MT_xx
>> constants that map to device permissions to be listed here?
>>
>
> Meh, there's no great solution and this code is all the kind of code
> that you just need to take the time to understand.  We could add a
> comment I suppose, if I got the above correct, I can throw something in?
>

Actually, I think the patch is wrong, and so is the commit message.

I got confused between HYP mappings and stage 2 mappings. HYP mappings
use an index into the MAIR (which HYP inherits from the kernel) but
the stage 2 mappings have a bit fiield describing the type.

So for one, I think that means that __kvm_pte_is_uncached() cannot be
used for both HYP and stage-2 PTE's, or we'd need to add a parameter
to distinguish between them.

For HYP mappings, we need to compare the MAIR index to values that are
known to refer to device or uncached mappings (as the patch does)
For S2 mappings, we need to mask the MemAttr[5:2] field, and interpret
it according to the description in the ARM ARM, i.e., MemAttr[3:2] ==
0b00 indicates device, MemAttr[3:0] == 0b0101 is uncached memory,
anything else requires cache maintenance.

-- 
Ard.

  reply	other threads:[~2015-11-09 16:59 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-06 11:43 [PATCH] ARM/arm64: KVM: test properly for a PTE's uncachedness Ard Biesheuvel
2015-11-06 11:43 ` Ard Biesheuvel
2015-11-09  7:24 ` Pavel Fedin
2015-11-09  7:24   ` Pavel Fedin
2015-11-09  8:17 ` Marc Zyngier
2015-11-09  8:17   ` Marc Zyngier
2015-11-09 16:21 ` Christoffer Dall
2015-11-09 16:21   ` Christoffer Dall
2015-11-09 16:27   ` Ard Biesheuvel
2015-11-09 16:27     ` Ard Biesheuvel
2015-11-09 16:35     ` Christoffer Dall
2015-11-09 16:35       ` Christoffer Dall
2015-11-09 16:59       ` Ard Biesheuvel [this message]
2015-11-09 16:59         ` Ard Biesheuvel
     [not found]         ` <1447148737-15363-1-git-send-email-ard.biesheuvel@linaro.org>
2015-11-10  9:47           ` [PATCH v2] " Ard Biesheuvel
2015-11-10 10:27             ` Pavel Fedin
     [not found]           ` <20151110122203.GD12968@cbox>
2015-11-10 13:15             ` Ard Biesheuvel
2015-11-10 13:40               ` Christoffer Dall
2015-11-10 13:48                 ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKv+Gu_agkv7aDqj7fgdoWU+9k=eJ-0YU7WrDKm1_wtr_xYQ6g@mail.gmail.com' \
    --to=ard.biesheuvel@linaro.org \
    --cc=christoffer.dall@linaro.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=marc.zyngier@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.