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

[Eric Trudeau <etrudeau@xxxxxxxxxxxx>]

> -----Original Message-----
> From: Dario Faggioli [mailto:dario.faggioli@xxxxxxxxxx]
> Sent: Thursday, March 13, 2014 2:38 PM
> To: Ian Campbell
> Cc: Julien Grall; Arianna Avanzini; paolo.valente@xxxxxxxxxx; Keir Fraser;
> stefano.stabellini@xxxxxxxxxxxxx; Tim Deegan; Ian.Jackson@xxxxxxxxxxxxx; xen-
> devel@xxxxxxxxxxxxx; julien.grall@xxxxxxxxxx; Eric Trudeau; Jan Beulich;
> viktor.kleinik@xxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [RFC PATCH v2 3/3] tools, libxl: handle the iomem
> parameter with the memory_mapping hcall
> 
> 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 our target scenarios, we are relying on the Virtualization Extensions in ARM 
for
security as well as for segregating Linux "machines" in order to share CPU 
resources
more effectively.
Therefore, we do not want the guest domain to decide the IPA->PA mapping, Dom0
is in charge of this through hypercalls to Xen.  We like the iomem in the 
config file,
and we use the irq parameter as well to route IRQs to guests, because it allows
Dom0 only to control how the physical devices are assigned to the DomU's. This
also keeps the guest OS drivers from having to change when they are running in a
virtual machine.

In our use cases, we want primarily 1:1 mapping for most memory because we have
no IOMMU and each DomU can do DMA and needs 1:1 contiguous memory for that.

In our development port of Xen, we do not have the DomU devices in the DT given
to Xen at boot.  Therefore, Dom0 does not see these devices and the Dom0 Linux
probe does not try to init the devices.  Our near-future plans are to add the 
devices
targeted for DomU into the Xen DT, but with status property set to disabled.  
Dom0
will use some domain plan to create DTs for the DomUs by assigning the 
appropriate
devices to each and enabling the devices that were disabled in Dom0's DT.

This is probably more information that you wanted, but it may help in a better
understanding of our usage of Xen.

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

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