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

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2663 bytes --]

On gio, 2014-03-13 at 17:32 +0000, Ian Campbell wrote:
> On Thu, 2014-03-13 at 16:47 +0000, Julien Grall wrote:

> > > Sure, but I don't think I see any conflict between this and the approach
> > > Ian proposed above. What am I missing?
> > 
> > I believe, Ian was assuming that the user know the layout because this
> > solution will be used to a very specific case (I think mostly when the
> > device tree won't describe the hardware).
> 
> Right, my assumption was that the kernel was also compiled for the exact
> hardware layout as part of some sort of embedded/appliance situation...
> 
Exactly, that may very well be the case. It may not, in Arianna's case,
but it well can be true for others, or even for her, in future.

Therefore, I keep failing to see why to prevent this to be the case.

> > I'm wondering, if we can let the kernel calling the hypercall. He knows
> > what is the memory layout of the VM.
> 
> This would be somewhat analogous to what happens with an x86 PV guest.
> It would have to be an physmap call or something since this domctl
> wouldn't be accessible by the guest.
> 
> That makes a lot of sense actually since this domctl seems to have been
> intended for use by the x86 HVM device model (qemu).
>
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

Also, Eric and Viktor where asking for/working on something similar, so
there perhaps would be some good in having this...

Eric, Viktor, can you comment why you need this call and how you use, or
want to use it for?
Would it be the same for you to have it in the form of a physmap call,
and invoke it from within the guest kernel?

In Arianna's case, it think it would be more than fine to implement it
that way, and call it from within the OS, isn't this the case, Arianna?

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.

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?

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 #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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