[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <AM0PR04MB4481C44313C450F8994AF4BC88A20@AM0PR04MB4481.eurprd04.prod.outlook.com>
Date: Thu, 29 Aug 2019 02:46:19 +0000
From: Peng Fan <peng.fan@....com>
To: Stefano Stabellini <sstabellini@...nel.org>
CC: Robin Murphy <robin.murphy@....com>,
"linux@...linux.org.uk" <linux@...linux.org.uk>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
dl-linux-imx <linux-imx@....com>,
"van.freenix@...il.com" <van.freenix@...il.com>,
"xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
Hi Stefano,
> Subject: RE: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
>
> On Wed, 28 Aug 2019, Peng Fan wrote:
> > Hi Robin,
> >
> > > Subject: Re: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
> > >
> > > On 09/07/2019 09:22, Peng Fan wrote:
> > > > arm64 shares some code under arch/arm/xen, including mm.c.
> > > > However ZONE_DMA is removed by commit
> > > > ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
> > > > So to ARM64, need use __GFP_DMA32.
>
> Hi Peng,
>
> Sorry for being so late in replying, this email got lost in the noise.
>
>
> > > > Signed-off-by: Peng Fan <peng.fan@....com>
> > > > ---
> > > > arch/arm/xen/mm.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index
> > > > e1d44b903dfc..a95e76d18bf9 100644
> > > > --- a/arch/arm/xen/mm.c
> > > > +++ b/arch/arm/xen/mm.c
> > > > @@ -27,7 +27,7 @@ unsigned long
> > > > xen_get_swiotlb_free_pages(unsigned
> > > > int order)
> > > >
> > > > for_each_memblock(memory, reg) {
> > > > if (reg->base < (phys_addr_t)0xffffffff) {
> > > > - flags |= __GFP_DMA;
> > > > + flags |= __GFP_DMA | __GFP_DMA32;
> > >
> > > Given the definition of GFP_ZONE_BAD, I'm not sure this combination
> > > of flags is strictly valid, but rather is implicitly reliant on only
> > > one of those zones ever actually existing. As such, it seems liable
> > > to blow up if the plans to add ZONE_DMA to arm64[1] go ahead.
> >
> > How about this, or do you have any suggestions?
> > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index
> > d33b77e9add3..f61c29a4430f 100644
> > --- a/arch/arm/xen/mm.c
> > +++ b/arch/arm/xen/mm.c
> > @@ -28,7 +28,11 @@ unsigned long xen_get_swiotlb_free_pages(unsigned
> > int order)
> >
> > for_each_memblock(memory, reg) {
> > if (reg->base < (phys_addr_t)0xffffffff) {
> > +#ifdef CONFIG_ARM64
> > + flags |= __GFP_DMA32; #else
> > flags |= __GFP_DMA;
> > +#endif
> > break;
> > }
> > }
>
> Yes I think this is the way to go, but we are trying not to add any #ifdef
> CONFIG_ARM64 under arch/arm. Maybe you could introduce a static inline
> function to set GFP_DMA:
>
> static inline void xen_set_gfp_dma(gfp_t *flags)
>
> it could be implemented under arch/arm/include/asm/xen/page.h for arm
> and under arch/arm64/include/asm/xen/page.h for arm64 using __GFP_DMA
> for the former and __GFP_DMA32 for the latter.
Thanks for your suggestion. I'll use this in V2.
Thanks,
Peng.
Powered by blists - more mailing lists