All of lore.kernel.org
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] ARM: mm: Fix stage-2 device memory attributes
Date: Mon, 27 Jan 2014 17:21:16 +0000	[thread overview]
Message-ID: <20140127172116.GD8358@arm.com> (raw)
In-Reply-To: <52E69121.8050500@arm.com>

On Mon, Jan 27, 2014 at 05:02:25PM +0000, Marc Zyngier wrote:
> On 27/01/14 16:57, Catalin Marinas wrote:
> > On Mon, Jan 27, 2014 at 11:16:57AM +0000, Marc Zyngier wrote:
> >> On 24/01/14 23:37, Christoffer Dall wrote:
> >>> On Sat, Jan 04, 2014 at 08:27:23AM -0800, Christoffer Dall wrote:
> >>>> --- a/arch/arm/include/asm/pgtable-3level.h
> >>>> +++ b/arch/arm/include/asm/pgtable-3level.h
> >>>> @@ -120,13 +120,19 @@
> >>>>  /*
> >>>>   * 2nd stage PTE definitions for LPAE.
> >>>>   */
> >>>> -#define L_PTE_S2_MT_UNCACHED	 (_AT(pteval_t, 0x5) << 2) /* MemAttr[3:0] */
> >>>> -#define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* MemAttr[3:0] */
> >>>> -#define L_PTE_S2_MT_WRITEBACK	 (_AT(pteval_t, 0xf) << 2) /* MemAttr[3:0] */
> >>>> -#define L_PTE_S2_RDONLY		 (_AT(pteval_t, 1) << 6)   /* HAP[1]   */
> >>>> -#define L_PTE_S2_RDWR		 (_AT(pteval_t, 3) << 6)   /* HAP[2:1] */
> >>>> -
> >>>> -#define L_PMD_S2_RDWR		 (_AT(pmdval_t, 3) << 6)   /* HAP[2:1] */
> >>>> +#define L_PTE_S2_MT_UNCACHED		(_AT(pteval_t, 0x0) << 2) /* strongly ordered */
> >>>> +#define L_PTE_S2_MT_WRITETHROUGH	(_AT(pteval_t, 0xa) << 2) /* normal inner write-through */
> >>>> +#define L_PTE_S2_MT_WRITEBACK		(_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
> >>>> +#define L_PTE_S2_MT_DEV_SHARED		(_AT(pteval_t, 0x1) << 2) /* device */
> >>>> +#define L_PTE_S2_MT_DEV_NONSHARED	(_AT(pteval_t, 0x1) << 2) /* device */
> >>>> +#define L_PTE_S2_MT_DEV_WC		(_AT(pteval_t, 0x5) << 2) /* normal non-cacheable */
> >>>> +#define L_PTE_S2_MT_DEV_CACHED		(_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
> >>>> +#define L_PTE_S2_MT_MASK		(_AT(pteval_t, 0xf) << 2)
> >>>> +
> >>>> +#define L_PTE_S2_RDONLY			(_AT(pteval_t, 1) << 6)   /* HAP[1]   */
> >>>> +#define L_PTE_S2_RDWR			(_AT(pteval_t, 3) << 6)   /* HAP[2:1] */
> >>>> +
> >>>> +#define L_PMD_S2_RDWR			(_AT(pmdval_t, 3) << 6)   /* HAP[2:1] */
> >>>>  
> >>>>  /*
> >>>>   * Hyp-mode PL2 PTE definitions for LPAE.
> >>
> >> The change makes sense to me. arm64 uses a slightly different approach,
> >> by using a PTE_S2_MEMATTR macro, but I'm not sure that would work for ARM.
> >>
> >> Russell, Catalin: could you please have a look at this?
> > 
> > Do we actually need more than Normal Cacheable and Device for stage 2?
> 
> Not so far. As long as these two memory types are enforced as a minimum,
> we're quite happy to let the guest use whatever it decides.
> 
> I suppose Christoffer introduces them all here as a matter of
> completeness, but I don't see them as being useful anytime soon.

That would be useful on arm if you want cachepolicy= argument to force
the cacheability of guest Normal memory type.

On arm64, the stage 1 memory type is decided via MAIR and that's how we
handle cachepolicy for Normal memory. But for stage 2 this won't work,
the type is explicitly set in the MemAttr encoding. But I don't think we
need host cachepolicy enforced onto guest.

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"patches@linaro.org" <patches@linaro.org>,
	Russell King <linux@arm.linux.org.uk>
Subject: Re: [PATCH v2] ARM: mm: Fix stage-2 device memory attributes
Date: Mon, 27 Jan 2014 17:21:16 +0000	[thread overview]
Message-ID: <20140127172116.GD8358@arm.com> (raw)
In-Reply-To: <52E69121.8050500@arm.com>

On Mon, Jan 27, 2014 at 05:02:25PM +0000, Marc Zyngier wrote:
> On 27/01/14 16:57, Catalin Marinas wrote:
> > On Mon, Jan 27, 2014 at 11:16:57AM +0000, Marc Zyngier wrote:
> >> On 24/01/14 23:37, Christoffer Dall wrote:
> >>> On Sat, Jan 04, 2014 at 08:27:23AM -0800, Christoffer Dall wrote:
> >>>> --- a/arch/arm/include/asm/pgtable-3level.h
> >>>> +++ b/arch/arm/include/asm/pgtable-3level.h
> >>>> @@ -120,13 +120,19 @@
> >>>>  /*
> >>>>   * 2nd stage PTE definitions for LPAE.
> >>>>   */
> >>>> -#define L_PTE_S2_MT_UNCACHED	 (_AT(pteval_t, 0x5) << 2) /* MemAttr[3:0] */
> >>>> -#define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* MemAttr[3:0] */
> >>>> -#define L_PTE_S2_MT_WRITEBACK	 (_AT(pteval_t, 0xf) << 2) /* MemAttr[3:0] */
> >>>> -#define L_PTE_S2_RDONLY		 (_AT(pteval_t, 1) << 6)   /* HAP[1]   */
> >>>> -#define L_PTE_S2_RDWR		 (_AT(pteval_t, 3) << 6)   /* HAP[2:1] */
> >>>> -
> >>>> -#define L_PMD_S2_RDWR		 (_AT(pmdval_t, 3) << 6)   /* HAP[2:1] */
> >>>> +#define L_PTE_S2_MT_UNCACHED		(_AT(pteval_t, 0x0) << 2) /* strongly ordered */
> >>>> +#define L_PTE_S2_MT_WRITETHROUGH	(_AT(pteval_t, 0xa) << 2) /* normal inner write-through */
> >>>> +#define L_PTE_S2_MT_WRITEBACK		(_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
> >>>> +#define L_PTE_S2_MT_DEV_SHARED		(_AT(pteval_t, 0x1) << 2) /* device */
> >>>> +#define L_PTE_S2_MT_DEV_NONSHARED	(_AT(pteval_t, 0x1) << 2) /* device */
> >>>> +#define L_PTE_S2_MT_DEV_WC		(_AT(pteval_t, 0x5) << 2) /* normal non-cacheable */
> >>>> +#define L_PTE_S2_MT_DEV_CACHED		(_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
> >>>> +#define L_PTE_S2_MT_MASK		(_AT(pteval_t, 0xf) << 2)
> >>>> +
> >>>> +#define L_PTE_S2_RDONLY			(_AT(pteval_t, 1) << 6)   /* HAP[1]   */
> >>>> +#define L_PTE_S2_RDWR			(_AT(pteval_t, 3) << 6)   /* HAP[2:1] */
> >>>> +
> >>>> +#define L_PMD_S2_RDWR			(_AT(pmdval_t, 3) << 6)   /* HAP[2:1] */
> >>>>  
> >>>>  /*
> >>>>   * Hyp-mode PL2 PTE definitions for LPAE.
> >>
> >> The change makes sense to me. arm64 uses a slightly different approach,
> >> by using a PTE_S2_MEMATTR macro, but I'm not sure that would work for ARM.
> >>
> >> Russell, Catalin: could you please have a look at this?
> > 
> > Do we actually need more than Normal Cacheable and Device for stage 2?
> 
> Not so far. As long as these two memory types are enforced as a minimum,
> we're quite happy to let the guest use whatever it decides.
> 
> I suppose Christoffer introduces them all here as a matter of
> completeness, but I don't see them as being useful anytime soon.

That would be useful on arm if you want cachepolicy= argument to force
the cacheability of guest Normal memory type.

On arm64, the stage 1 memory type is decided via MAIR and that's how we
handle cachepolicy for Normal memory. But for stage 2 this won't work,
the type is explicitly set in the MemAttr encoding. But I don't think we
need host cachepolicy enforced onto guest.

-- 
Catalin

  reply	other threads:[~2014-01-27 17:21 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-04  6:14 [PATCH] ARM: mm: Fix stage-2 device memory attributes Christoffer Dall
2014-01-04  6:14 ` Christoffer Dall
2014-01-04 16:27 ` [PATCH v2] " Christoffer Dall
2014-01-04 16:27   ` Christoffer Dall
2014-01-24 23:37   ` Christoffer Dall
2014-01-24 23:37     ` Christoffer Dall
2014-01-27 11:16     ` Marc Zyngier
2014-01-27 11:16       ` Marc Zyngier
2014-01-27 16:57       ` Catalin Marinas
2014-01-27 16:57         ` Catalin Marinas
2014-01-27 17:02         ` Marc Zyngier
2014-01-27 17:02           ` Marc Zyngier
2014-01-27 17:21           ` Catalin Marinas [this message]
2014-01-27 17:21             ` Catalin Marinas
2014-01-28 21:24             ` Christoffer Dall
2014-01-28 21:24               ` Christoffer Dall
  -- strict thread matches above, loose matches on Subject: below --
2014-01-28 21:24 Christoffer Dall
2014-01-29 10:39 ` Marc Zyngier
2014-01-29 15:44   ` Christoffer Dall
2014-01-30 11:41 ` Catalin Marinas

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=20140127172116.GD8358@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.