On 11.06.19 23:05, Wayne wrote:
Jan/Ralf,
I was able to get past issues 1 and 3 above by using Jan's kernel config from
this thread:
https://groups.google.com/forum/#!searchin/jailhouse-dev/Re$3A$20Failed$20to$20boot$20jailhouse%7Csort:relevance/jailhouse-dev/M7UO89XFIk0/Qi40DDuMBAAJ";.
You also find a compatible config in
https://github.com/siemens/jailhouse-images/blob/master/recipes-kernel/linux/files/amd64_defconfig_4.19
The DMA issue was resolved by disabling kernel option CONFIG_ISA_DMA_API as
stated in another thread, and reflected in the config file above.
So now I think i've almost got the non-root linux booting. I'm stuck at the
point where its trying to mount a filesystem and since i'm not providing an
initramfs it panics.
Similar to the output below:
[ 1.080178] VFS: Cannot open root device "(null)" or unknown-block(0,0): error
-6
[ 1.087662] Please append a correct "root=" boot option; here are the available
partitions:
[ 1.096013] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
Did you provide an initrd to that Linux? If yes, you may run into issues with
the kernel overwriting parts of it while unpacking. Play with a larger
--kernel-decomp-factor in that case, 8 or higher - though there are also limits
in this regard, and those are defined by the non-root cell RAM size.
I have just a couple more questions:
1. In general, is it true that an inmate will takeover control from the root of
any resource in the following arrays, or are there some cases where they get
"shared" between the root and inmate?
A. ".mem_regions" -> Shared?
You can share memory regions via JAILHOUSE_MEM_ROOTSHARED. The typical example
are shared memory devices that use regions with that flag set.
B. ".irqchips" -> Shared?
Chips can be shared, but individual IRQ lines cannot. So, if you assign a line
to non-root cell, the root cell will lose access.
C. ".pio_bitmap" -> Inmate takes control of these if matching between
inmate and root
No sharing implemented for that.
D. ".pci_devices" -> Inmate takes control?
E. ".pci_caps" -> Inmate takes control?
PCI devices cannot be shared either. One cell need to take ownership and provide
services to another cell via different means (e.g. ivshmem).
2. Along the same lines, going back to my ttyS0 issue mentioned above while
trying to share it:
If I allocate the following to the linux non root cell (and set to -1 in
the root)
.pio_bitmap = {
[0x3f8/8 ... 0x3ff/8] = 0x00 /* serial 2*/
}
Then on the root cell I randomly get a PIO read fault on "0x3FE" when
the non-root is booting, i'm not sure what process is causing this.
Do you mean access violations reported by Jailhouse?
if I leave out the pio mapping in the non-root linux, and alolothat
block in the root cell instead then the non-root linux gets a PIO read fault on
"0x3F9" while booting.
Ralf mentioned that Linux would not try enumerate the device if its set
to -1 ( [0x3f8/8 ... 0x3ff/8] = -1) , but the non-root seems to attempt to do
something with it anyway:
"[ 0.956146]Serial: 8250/16550 driver, 1 ports, IRQ sharing enabled"
"FATAL: Invalid PIO read, port: 3f9: size 1"
Is it possible to map the same pio block in both the root and non-root
with a different mask? Or does the non-root just override it? It seems like
the latter is true.
Nope, see above. If you want to avoid probing, limit the number of UARTs in the
kernel config or command line. The latter is done here:
https://github.com/siemens/jailhouse-images/blob/master/recipes-core/customizations/files/.bash_history-qemu-amd64
BTW, that demo is also configured in a way that the root cell stays away from
ttyS0.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jailhouse-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/fb217470-3561-5891-3214-d3dcd1b7912d%40siemens.com.
For more options, visit https://groups.google.com/d/optout.
