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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2014-03-14 at 18:39 +0000, Eric Trudeau wrote:
> 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.

Note that in no case would the guest be able to map arbitrary PA, each
PA still needs to be whitelisted by the tools before it can be mapped to
the guest whether it is the tools or the guest which actually
establishes the mappings.

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

Lack of an IOMMU and the presence of guest DMA means that things are not
going to be completely isolated though.

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

Thanks.

Ian.


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