Re: [Xen-devel] [RFC PATCH 3/16]: PVH xen: Add PHYSDEVOP_map_iomem

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2013-01-28 at 16:47 +0000, Jan Beulich wrote:
> >>> On 28.01.13 at 17:43, Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx> wrote:
> > 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@xxxxxxxxxx> wrote:
> >> > 
> >> > > On Fri, 25 Jan 2013 08:05:40 +0000
> >> > > "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> >> > > 
> >> > > > >>> On 25.01.13 at 02:53, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
> >> > > > >>> 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?
> 
> I'd expect the latter - completely transparent to the guest.

That's what I would have said too.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel