From: Rusty Russell <rusty@rustcorp.com.au>
To: Will Deacon <will.deacon@arm.com>
Cc: Marc Zyngier <Marc.Zyngier@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
lf-virt <virtualization@lists.linux-foundation.org>,
Eric Van Hensbergen <ericvh@gmail.com>,
Sasha Levin <levinsasha928@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] virtio: 9p: correctly pass physical address to userspace for high pages
Date: Fri, 19 Oct 2012 10:09:51 +1030 [thread overview]
Message-ID: <87wqynpcxk.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20121018094247.GA17296@mudshark.cambridge.arm.com>
Will Deacon <will.deacon@arm.com> writes:
> On Thu, Oct 18, 2012 at 03:19:06AM +0100, Rusty Russell wrote:
>> We do have an alternate solution: masking out __GFP_HIGHMEM from the
>> kmalloc of desc. If it fails, we will fall back to laying out the
>> virtio request directly inside the ring; if it doesn't fit, we'll wait
>> for the device to consume more buffers.
>
> Hmm, that will probably work for the vring but the zero-copy code for 9p may
> just give us an address from userspace if I'm understanding it correctly. In
> that case, we really have to do the translation as below (which is actually
> much cleaner because everything is page-aligned).
>
>> > @@ -325,7 +326,7 @@ static int p9_get_mapped_pages(struct virtio_chan *chan,
>> > int count = nr_pages;
>> > while (nr_pages) {
>> > s = rest_of_page(data);
>> > - pages[index++] = virt_to_page(data);
>> > + pages[index++] = kmap_to_page(data);
>> > data += s;
>> > nr_pages--;
>> > }
>
> So what do you reckon? How about I leave this hunk as a separate patch and
> have a play masking out __GFP_HIGHMEM for the vring descriptor?
Yes, I think so. A scathing comment would be nice, too...
Thanks,
Rusty.
WARNING: multiple messages have this Message-ID (diff)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Will Deacon <will.deacon@arm.com>
Cc: "linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Sasha Levin <levinsasha928@gmail.com>,
Marc Zyngier <Marc.Zyngier@arm.com>,
lf-virt <virtualization@lists.linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Eric Van Hensbergen <ericvh@gmail.com>
Subject: Re: [PATCH] virtio: 9p: correctly pass physical address to userspace for high pages
Date: Fri, 19 Oct 2012 10:09:51 +1030 [thread overview]
Message-ID: <87wqynpcxk.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20121018094247.GA17296@mudshark.cambridge.arm.com>
Will Deacon <will.deacon@arm.com> writes:
> On Thu, Oct 18, 2012 at 03:19:06AM +0100, Rusty Russell wrote:
>> We do have an alternate solution: masking out __GFP_HIGHMEM from the
>> kmalloc of desc. If it fails, we will fall back to laying out the
>> virtio request directly inside the ring; if it doesn't fit, we'll wait
>> for the device to consume more buffers.
>
> Hmm, that will probably work for the vring but the zero-copy code for 9p may
> just give us an address from userspace if I'm understanding it correctly. In
> that case, we really have to do the translation as below (which is actually
> much cleaner because everything is page-aligned).
>
>> > @@ -325,7 +326,7 @@ static int p9_get_mapped_pages(struct virtio_chan *chan,
>> > int count = nr_pages;
>> > while (nr_pages) {
>> > s = rest_of_page(data);
>> > - pages[index++] = virt_to_page(data);
>> > + pages[index++] = kmap_to_page(data);
>> > data += s;
>> > nr_pages--;
>> > }
>
> So what do you reckon? How about I leave this hunk as a separate patch and
> have a play masking out __GFP_HIGHMEM for the vring descriptor?
Yes, I think so. A scathing comment would be nice, too...
Thanks,
Rusty.
next prev parent reply other threads:[~2012-10-18 23:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-17 10:14 [PATCH] virtio: 9p: correctly pass physical address to userspace for high pages Will Deacon
2012-10-17 16:05 ` Sasha Levin
2012-10-17 16:17 ` Will Deacon
2012-10-18 2:19 ` Rusty Russell
2012-10-18 2:19 ` Rusty Russell
2012-10-18 9:42 ` Will Deacon
2012-10-18 23:39 ` Rusty Russell [this message]
2012-10-18 23:39 ` Rusty Russell
2012-10-18 9:42 ` Will Deacon
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=87wqynpcxk.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=Marc.Zyngier@arm.com \
--cc=akpm@linux-foundation.org \
--cc=ericvh@gmail.com \
--cc=levinsasha928@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=will.deacon@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.