From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
Jan Beulich <JBeulich@suse.com>,
xen-devel <xen-devel@lists.xen.org>
Subject: Re: [RFC PATCH 3/16]: PVH xen: Add PHYSDEVOP_map_iomem
Date: Mon, 28 Jan 2013 11:43:38 -0500 [thread overview]
Message-ID: <20130128164337.GD7223@konrad-lan.dumpdata.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1301281513230.10432@kaball.uk.xensource.com>
On Mon, Jan 28, 2013 at 03:13:48PM +0000, Stefano Stabellini wrote:
> On Sat, 26 Jan 2013, Mukesh Rathor wrote:
> > On Fri, 25 Jan 2013 18:23:49 -0800
> > Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> >
> > > On Fri, 25 Jan 2013 08:05:40 +0000
> > > "Jan Beulich" <JBeulich@suse.com> wrote:
> > >
> > > > >>> On 25.01.13 at 02:53, Mukesh Rathor <mukesh.rathor@oracle.com>
> > > > >>> wrote:
> > > > > Since this happens once during boot, I am ok either way. Staying
> > > > > with what I've keeps linux code clean and also provides flexibily
> > > > > for future in case. But if you feel strongly, I can special case
> > > > > dom0 in linux to assume xen has it all mapped, and generate a
> > > > > patch there. Please lmk.
> > > >
> > > > Hmm, special casing Dom0 isn't what I'm after. I want this to be
> > > > transparent to the kernel in all cases (keeps the Linux code even
> > > > cleaner).
> > >
> > > Ok. I am looking into it. Stefano, Ian, any comments? You guys OK with
> > > that approach? I probably won't need PHYSDEVOP_map_iomem then.
> >
> > Forgot to cc stefano and Ian. Resending CCing them.
>
> Yeah, it looks like a reasonable approach.
That would mean that the PVH domU with PCI devices would have do this
as well. Usually this is done in the toolstack - so would this mean that
the PHYSDEVOP_map_iomem would be used there? Or would it be just part
of the XEN_DOMCTL_iomem_permission?
next prev parent reply other threads:[~2013-01-28 16:43 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-12 1:32 [RFC PATCH 3/16]: PVH xen: Add PHYSDEVOP_map_iomem Mukesh Rathor
2013-01-14 11:23 ` Jan Beulich
2013-01-15 23:35 ` Mukesh Rathor
2013-01-16 9:45 ` Jan Beulich
2013-01-24 2:12 ` Mukesh Rathor
2013-01-24 9:23 ` Jan Beulich
2013-01-25 1:53 ` Mukesh Rathor
2013-01-25 8:05 ` Jan Beulich
2013-01-26 2:23 ` Mukesh Rathor
2013-01-26 3:04 ` Mukesh Rathor
2013-01-28 15:13 ` Stefano Stabellini
2013-01-28 16:43 ` Konrad Rzeszutek Wilk [this message]
2013-01-28 16:47 ` Jan Beulich
2013-01-28 16:50 ` Ian Campbell
2013-01-28 10:55 ` Ian Campbell
2013-01-24 15:06 ` Tim Deegan
2013-01-25 1:03 ` Mukesh Rathor
2013-01-28 16:39 ` Konrad Rzeszutek Wilk
2013-01-28 16:47 ` Jan Beulich
2013-01-30 21:24 ` Konrad Rzeszutek Wilk
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=20130128164337.GD7223@konrad-lan.dumpdata.com \
--to=konrad@kernel.org \
--cc=Ian.Campbell@citrix.com \
--cc=JBeulich@suse.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xen.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.