[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ebd69ba1-fc06-3cc7-348e-3cb0004c2a34@oracle.com>
Date: Tue, 22 Sep 2020 11:24:20 -0400
From: boris.ostrovsky@...cle.com
To: Christoph Hellwig <hch@....de>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
Juergen Gross <jgross@...e.com>,
Stefano Stabellini <sstabellini@...nel.org>,
Jani Nikula <jani.nikula@...ux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@...el.com>,
Minchan Kim <minchan@...nel.org>,
Nitin Gupta <ngupta@...are.org>, x86@...nel.org,
xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org,
intel-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
linux-mm@...ck.org
Subject: Re: [PATCH 6/6] x86/xen: open code alloc_vm_area in
arch_gnttab_valloc
On 9/22/20 10:58 AM, Christoph Hellwig wrote:
> On Mon, Sep 21, 2020 at 04:44:10PM -0400, boris.ostrovsky@...cle.com wrote:
>> This will end up incrementing area->ptes pointer. So perhaps something like
>>
>>
>> pte_t **ptes = area->ptes;
>>
>> if (apply_to_page_range(&init_mm, (unsigned long)area->area->addr,
>> PAGE_SIZE * nr_frames, gnttab_apply, &ptes)) {
>>
>> ...
> Yeah. What do you think of this version?
Oh yes, this is way better. This now can actually be read without trying to mentally unwind triple pointers. (You probably want to initialize idx to zero before calling apply_to_page_range(), I am not sure it's guaranteed to be zero).
> I think it is a little
> cleaner and matches what xenbus does. At this point it probably should
> be split into a Xen and a alloc_vm_area removal patch, though.
Right.
-boris
Powered by blists - more mailing lists