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:43 +0000, Jan Beulich wrote:
> >>> On 13.03.14 at 16:27, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > On Mon, 2014-03-10 at 09:25 +0100, Arianna Avanzini wrote:
> >> NOTE: the added 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.
> > 
> > In that case you need to CC the x86 maintainers (Jan, Keir, Tim) here.
> > It doesn't seem to me that this is going to be the correct thing to do
> > for either x86 PV or x86 HVM guests.
> > 
> > My gut feeling is that this should be ifdef'd or otherwise made
> > conditional.
> 
> At the very least - it really looks more like a temporary hack than
> a long term solution to me. Why would we ever want, for other
> than experimental purposes, a 1:1 address relationship baked
> into anything?
> 
We discussed a bit about this during v1's submission of this series.
Some pointers here:

http://lists.xenproject.org/archives/html/xen-devel/2014-03/msg00036.html
http://lists.xenproject.org/archives/html/xen-devel/2014-03/msg00054.html

Summarizing, the idea is allowing for some kind of "raw device
passthrough" for the cases where:
 - there is no IOMMU in the hw
 - the OS does not support DT or ACPI

Which is the case of Arianna's port and, I believe, it may be something
other people wanting to port small and special purpose/embedded OSes on
Xen would face too (perhaps Eric and Viktor can add something about
their own use case).

AFAIUI, once you settle on allowing it and bypassing DT parsing, then
the point becomes _where_ to put the mapping. 1:1 looked more the only
than the best option, although it is of course at risk of clashes with
other stuff put there by Xen.

For this reason, we decided that having both 1:1 mapping, and an
equivalent of x86's e820_host for ARM would be a good enough solution.
Of course, it's responsibility to the user/sysadmin to provide the
appropriate set of options... or get to keep the pieces, if they
don't. :-)

The agreement was that Arianna would keep on implementing this, with the
1:1 mapping. A follow-up work (from either her or someone else, e.g.,
Julien said he could be up for it at some point) would add the e820-ish
part.

Personally, I think I agree with Ian about still defaulting to 1:1, but
also allowing for a bit more of flexibility, should mapping at a
specific PFN ever become a thing. Especially, I don't see much harm in
this (either the flexible or the unflexible variant), except for people
abusing this possibility, but again, that's up to them (I guess it's the
good old "should we allow users to shoot in their foot?" thing.)

Hope this clarified things a bit...

Do you happen to see any alternative solution, in absence of proper
DT/ACPI support in the guest OS? If no, what would be the best solution
to keep this out of x86 way? Is #ifdef, as Ian's suggesting, fine?

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