On Wed, 15 Jan 2020, Julien Grall wrote:
> On 14/01/2020 21:39, Jorge Pereira wrote:
> > Hi Guys,
> 
> Hello,
> 
> > 
> > I’m currently using XEN in order to run side-by-side a DOM-0 with a DOM-U
> > guest. My use-case scenario requires in the DOM-U direct access to some
> > dma-capable devices such ethernet and some GPUs.
> > 
> > Since our target platform (i.MX8MM) does not support IOMMU, we can’t assign
> > dma-capable devices to the DOM-U guest because XEN does not create 1:1
> > mapping for that guest in the 2^nd stage MMU. So, guest-virtual addresses
> > are different than the physical ones.
> 
> Bear in mind this setup is going to be insecure unless you have another way to
> prevent your passthrough-ed device to access memory it should not (e.g an
> MPU).
> 
> > Is it possible to have 1:1 mapping for DOM-U guests?

I have a patch that enables 1:1 mapping of memory for dom0-less DomUs,
see attached. It introduces a new option called "direct-map" in the domU
specific device tree section. When direct-map is found, the memory gets
allocated 1:1 for the DomU. direct-map can be used in conjuction with
the existing xen,force-assign-without-iommu parameter to enable device
assignment to domUs without a SMMU.

Note that direct-map is supposed to go under /chosen in the main device
tree, while xen,force-assign-without-iommu is supposed to go under
/passthrough in the partial device tree for device assignment.


The patch is only lightly tested and might not work on your platform.
Also, in addition to the security concerns Julien pointed out, it is
very possible to run into trouble with other static addresses.
Currently, we have a number of resources with fixed addresses in the
DomU address space. Give a look at xen/include/public/arch-arm.h: the
domU GICD is fixed at 0x03001000 for example. If the 1:1 memory
allocation selects a memory region that conflicts with any of those
fixed addresses, you are going to have a problem. I am not even sure
that Xen will be able to detect the error and fail explicitly: it could
just silently fail to boot.



> It is not possible at the moment. There are been various effort to try to do
> it, but I have always push back as this is actively defeating the purposing of
> an hypervisor.
> 
> This would be a different story if we had support for MPU in Xen.

A MPU is a requirement to make 1:1 secure, however, it would be
difficult to add support for it in Xen: on Xilinx platforms, the MPU is
not only for VM/VM protection but also for Cortex-Rs/Cortex-As
protection so it is typically programmed beforehand by somebody with a
system wide view (Xen has only a Cortex-A view of the system.) Xen might
not be the right place to configure the MPU at least on Xilinx boards.

This makes me realize that maybe we need to be able to allow the user to
specify not just that she wants direct mapping (like I did in the
attached patch), but also that she wants a specific range of memory for
each DomU, so that she can go and configure the MPU herself.