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

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

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