Re: [Xen-devel] Xen ARM Dom0less passthrough without IOMMU

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 18 Dec 2019, Julien Grall wrote:
> Hi Stefano,
> 
> On 17/12/2019 18:28, Stefano Stabellini wrote:
> > > Then I tried to passthrough the eMMC, but I got the following
> > > error:
> > > (XEN) DOM1: [    0.879151] sdhci-esdhc-imx 4005d000.usdhc: can't request
> > > region for resource [mem 0x4005d000-0x4005dfff]
> > > (XEN) DOM1: [    0.891137] sdhci-esdhc-imx 4005d000.usdhc:
> > > sdhci_pltfm_init failed -16
> > > (XEN) DOM1: [    0.900249] sdhci-esdhc-imx: probe of 4005d000.usdhc failed
> > > with error -16
> > > 
> > > Where 0x4005d000 is the physical address of the uSDHC(eMMC) node in the
> > > DT.
> > > It seems that the DomU1 kernel does not have access to that memory zone.
> > 
> > It looks like drivers/mmc/host/sdhci-pltfm.c:sdhci_pltfm_init failed,
> > but I cannot see a simple reason why it would. As Julien mentioned the
> > device tree snippet would be useful. Also the domU config and the full
> > device tree would be useful. i.e. did you add "xen,passthrough;" under
> > the related uSDHC node on the host device tree?
> 
> The only purpose of "xen,passthrough" is to mark the device as disabled in
> Dom0 DT. It will not affect how device will be passthrough to a guest.
> 
> In this case, I don't believe the problem is DT related because Linux is able
> to find the regions. If the region were not mapped to the guest, then it would
> be likely result to a data abort later on.
> 
> Looking at Andrei's e-mail again, he doesn't mention anything about the 1:1
> mapping. So I assume, he is still using the guest memory layout. The physical
> address 0x4005d000 which is roughly 372KB into the first RAM bank for the
> guest.
> 
> > > I'm trying to passthrough the eMMC in order to mount DomU1's root
> > > on a SDCard partition, because I couldn't get to DomU1's Linux prompt
> > > when I tried to boot with a ramdisk module. I always get this error:
> > > (XEN) DOM1: [    1.544199] RAMDISK: Couldn't find valid RAM disk image
> > > starting at 0.
> > > 
> > > Could this be because the ramdisk is too big? The smallest I've tried with
> > > Is approximately 60MB in size. What size are the ramdisks that you
> > > are using in your dom0less booting demos?
> > 
> > I don't think so, I could boot with ramdisk 120MB in size or even
> > larger. It is probably an address calculation error: it is easy to make
> > a small mistake in the addresses so that they end up overlapping.
> > Sometimes it is even U-Boot that causes the overlaps.
> > 
> > I would suggest to use ImageBuilder to create the U-Boot boot script to
> > load all the binaries and boot the system. Have a look at
> > uboot-script-gen in particular:
> > 
> > https://gitlab.com/ViryaOS/imagebuilder/blob/master/scripts/uboot-script-gen
> 
> Nice script, but it seems to contain hardcoded value (see offset and memaddr
> override), does not take into account reserved region and assume where
> U-boot/ATF may be loaded. So it may require some work before it can be used on
> NXP board...

Yes, you are right about that. The script doesn't understand
reserved-memory today and it will just start loading binaries at 2MB
after "MEMORY_START" as specified in the config file, assuming that it
is safe to do so.

Andrei, if you end up using it and it doesn't work, please let me know.
I am interested in understanding any failures and might be able to
improve the script or take patches for it.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel