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

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 03/13/2014 04:36 PM, Dario Faggioli wrote:
> On gio, 2014-03-13 at 15:34 +0000, Julien Grall wrote:
> 
>>>> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
>>>> index a604cd8..6c206c3 100644
>>>> --- a/tools/libxl/libxl_create.c
>>>> +++ b/tools/libxl/libxl_create.c
>>>> @@ -1099,6 +1099,23 @@ static void domcreate_launch_dm(libxl__egc *egc, 
>>>> libxl__multidev *multidev,
> 
>>>> +        } else {
>>>> +            /*
>>>> +             * NOTE: the following code is still common to both x86
>>>> +             *       and ARM; it also implements a simple 1:1 mapping
>>>> +             *       that could clash with the domU's existing memory
>>>> +             *       layout if the range is already in use in the
>>>> +             *       guest's address space.
>>>
>>> The right thing to do here is to add a guest address field to
>>> libxl_iomem_range and to extend the xl parse to accept
>>>     iomem = [ "MFN,NR@PFN" ] syntax
>>> where @PFN is optional and the default is 1:1.
>>
>> I disagree with this solution, the user doesn't know the guest layout.
>> How is it possible to let him choose the pfn?
>>
> I agree that the user will very much likely not know the guest layout.
> Still, making @PFN optional and defaulting to 1:1, as Ian was
> suggesting, seems the more flexible solution possible, as it does the
> right thing (in combination with "layout passthrough", of course, as you
> say below), but provide enough flexibility for some strange use case we
> can't predict yet.
> 
> What's the downside of that?

There is no need to extend libxl_iomem_range if we have a "layout
passthrough". The user will just have to specify the host MFN.

>> I think, for now the best solution is to expose the same memory layout
>> as the host when iomem is set.
>>
> 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).

I'm wondering, if we can let the kernel calling the hypercall. He knows
what is the memory layout of the VM.

-- 
Julien Grall

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