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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


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