Re: Question about xen and Rasp 4B

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 4 Feb 2021, Jukka Kaartinen wrote:
> We really need direct HW access so PVFB is not really an option. And at this
> point. We can trust the VMs.
> 
> 
> Any idea what am I missing something here is this the way to give domu access
> to the memory?
> 
> # from dom0: cat /proc/iomem
> # fe104000-fe104027 : fe104000.rng rng@7e104000
> 
> # to hide the above rng from the dom0 I added these to device-tree and above
> line from /proc/iomem dissapiered.
> boot2.scr:
> fdt set /soc/rng@7e104000 xen,passthrough <0x1>
> fdt set /soc/rng@7e104000 status disabled

Leave status to enabled or okay, just set xen,passthrough to 0x1.

 
> domu.cfg:
> iomem = [ 'fe104,1' ]
> 
> domu start but I cannot see that address in the domu iomem range.
> Also the device-tree from the domu is quite empty.
> 
> Do I need something like:
> device_tree = "rng.dtb"
> 
> like here:
> https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg02618.html
> 
> 
> I tried to add
> dtdev = [ "/soc/rng@7e104000" ]

Yes you need both dtdev and device_tree, see
https://xenbits.xenproject.org/docs/unstable/misc/arm/passthrough.txt

iomem is to remap memory regions
irqs is to remap interrupts
device_tree is to populate the DomU device tree
dtdev is to setup the IOMMU, linking to the original device in the host DT


> but this gives be error:
> "libxl: error: libxl_create.c:1107:libxl__domain_config_setdefault:
> passthrough not supported on this platform"
> 
> Will this happen if generate the rng.dtb?

This usually happens because there is no IOMMU on the board, or the
IOMMU is disabled. Indeed, the Raspberry Pi 4 doesn't seem to have one.

Now this is going to make things more difficult: without the IOMMU there
can be no protection. In addition, we have a problem with address
translations: when the domU programs a device to do DMA, it uses its
"fake" pseudo-physical addresses. When the device starts the DMA
transaction with the "fake" address, the IOMMU translates it back to a
real physical address.

For this reason, there is no way to assign a device to a domU without
IOMMU on upstream Xen. However, I sent out a patch series a while back
to allow to create domUs with memory 1:1 mapped (pseudo-physical ==
physical). With those patches applied, there is no issue with address
translations anymore and you can assign a device to a domU even without
IOMMU. However, keep in mind that there is going to be no protection.
The series only works for dom0less domUs for now, but it shouldn't be
hard to make it work for any other domUs.

You can find the series here in the Xilinx Xen branch:
https://github.com/Xilinx/xen/tree/xilinx/release-2020.2

and specifically the relevant patches start here:
https://github.com/Xilinx/xen/commit/b8953d357aa095d1027156cf386ad37bd8a34da5

up until:
https://github.com/Xilinx/xen/commit/a7b332c420da40aa3192a8b77c65bcdb1935b5ab