Re: [Xen-devel] [RFC PATCH v2 3/3] tools, libxl: handle the iomem parameter with the memory_mapping hcall

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On gio, 2014-03-13 at 20:29 +0000, Julien Grall wrote:
> 
> On 13/03/14 18:37, Dario Faggioli wrote:
> > I thought about that too. The reason why this was the taken approach is
> > this xen-devel discussion:
> > http://lists.xen.org/archives/html/xen-devel/2013-06/msg00870.html
> >
> > in particular, this Julien's message:
> > http://lists.xen.org/archives/html/xen-devel/2013-06/msg00902.html
> 
> I was a newbie when I wrote this mail ;).
> 
EhEh... And I by no means wanted to blame you or anyone else... Just
making sure the context is clear enough. :-)

> IMHO, I think we will have to implement a similar solution when the 
> passthrough via device tree will be handled.
> But ... for the "iomem", the best solution seems to let the guest mapped 
> itself the range (see my previous comment on the thread).
> 
Which one (comment)? :-)

Since you say "let the guest", I take it you're talking about the
solution of having the _guest's_ _kernel_ do the mapping?

> > One thing I don't see right now is, in the in-kernel case, what we
> > should do when finding the "iomem=[]" option in a config file.
> 
> Keep the current behavior in libxl. E.g give the permission to map the 
> I/O range.
> 
Ok... What I was asking was, how do we trigger a call to the proper
hypercall (which will be a physmap op, rather than a DOMCTL at that
point) inside the guest kernel?

As you say, right now, we just grant the guest the permission then, in
the x86 HVM case, QEMU will do the mapping later. How do QEMU knows what
to map? I tried to track that, but I did not found much, perhaps I know
too few technical details about PCI passthrough in QEMU.

However, more than figuring out how that happens, I'm interesting in
understanding who you think should inform the guest kernel to map
something, how to do this and what addresses. Because, I think, this is
going to be what Arianna (and Eric? And Viktor?) will need to do...

> > Also, just trying to recap, for Arianna's sake, moving the
> > implementation of the DOMCTL in common code (and implementing the
> > missing bits to make it works properly, of course) is still something we
> > want, right?
> 
> I think yes.
> 
So, again, you're saying we want both the DOMCTL, which no one will be
calling, and the physmap, which the guest kernel will be calling
"somehow", with the "somehow" part not well defined?

I guess the reason for this is that you'll need the DOMCTL at some
point, even for proper PCI passthrough? (yes, you said something about
this above, but I'm not sure I understood it there either)

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

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