From: Rusty Russell <rusty@rustcorp.com.au>
To: Christoph Hellwig <hch@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
virtualization <virtualization@lists.linux-foundation.org>,
Jeff Garzik <jeff@garzik.org>
Subject: Re: [PATCH 2/5] lguest guest feedback tidyups
Date: Fri, 11 May 2007 17:31:06 +1000 [thread overview]
Message-ID: <1178868666.23513.49.camel@localhost.localdomain> (raw)
In-Reply-To: <20070511065613.GB25182@infradead.org>
On Fri, 2007-05-11 at 07:56 +0100, Christoph Hellwig wrote:
> On Fri, May 11, 2007 at 11:21:30AM +1000, Rusty Russell wrote:
> > 1) send-dma and bind-dma hypercall wrappers for drivers to use,
> > 2) formalization of the convention that devices can use the irq
> > corresponding to their index on the lguest_bus.
> > 3) ___force to shut up sparse: guests *can* use ioremap as virtual mem.
>
> No, they can't. Even if in your case the underlying address spaces
> happen to be the same anything returned by ioremap must use the proper
> accessors. That's the whole point of having this separation, otherwise
> you wouldn't need to use ioremap at all.
Hi Christoph!
Well, without ioremap, the memory wouldn't normally be mapped. Is
there something better to use?
> So instead of sprinkling cast
> around add lguest_read*/lguest_write* accessors that do the __force cast
> once and make sure the ioremap return value is always accessed using those.
And that's nothing to do with iremap. They're required because guest
"physical" == host virtual, and casting a long to a "__user void *"
seems to require a __force.
I enjoy a good Hellwigging as much as anyone, but your aim is off.
Cheers,
Rusty.
next prev parent reply other threads:[~2007-05-11 7:31 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-11 1:17 [PATCH 0/5] lguest feedback tidyups Rusty Russell
2007-05-11 1:19 ` [PATCH 1/5] lguest host " Rusty Russell
2007-05-11 1:21 ` [PATCH 2/5] lguest guest " Rusty Russell
2007-05-11 1:22 ` [PATCH 3/5] lguest network driver " Rusty Russell
2007-05-11 1:23 ` [PATCH 4/5] lguest block " Rusty Russell
2007-05-11 1:24 ` [PATCH 5/5] lguest console " Rusty Russell
2007-05-13 4:08 ` [PATCH 4/5] lguest block " Rusty Russell
2007-05-13 3:52 ` [PATCH 3/5] lguest network " Rusty Russell
2007-05-13 4:12 ` Rusty Russell
2007-05-11 6:56 ` [PATCH 2/5] lguest guest " Christoph Hellwig
2007-05-11 7:31 ` Rusty Russell [this message]
2007-05-11 7:40 ` Christoph Hellwig
2007-05-13 1:00 ` Rusty Russell
2007-05-13 3:48 ` Rusty Russell
2007-05-13 18:43 ` Al Viro
2007-05-14 7:11 ` Rusty Russell
2007-05-13 4:07 ` [PATCH 1/5] lguest host " Rusty Russell
2007-05-13 18:47 ` Al Viro
2007-05-14 1:30 ` Rusty Russell
2007-05-13 18:39 ` Al Viro
2007-05-14 1:44 ` Rusty Russell
2007-05-14 5:38 ` Rusty Russell
2007-05-11 6:53 ` [PATCH 0/5] lguest " Christoph Hellwig
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=1178868666.23513.49.camel@localhost.localdomain \
--to=rusty@rustcorp.com.au \
--cc=akpm@linux-foundation.org \
--cc=hch@infradead.org \
--cc=jeff@garzik.org \
--cc=linux-kernel@vger.kernel.org \
--cc=virtualization@lists.linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox