On 10.12.20 16:20, Bram Hooimeijer wrote:
> Dear Jailhouse community,
> 
> Over the last days I have been trying to get Jailhouse running on real 
> hardware. I ran into quite some issues, but managed to get it running 
> eventually. 
> For some issues, I was able to find a solution somewhere in the mailing 
> archives, but not for all of them. So I thought I'd share my experiences here 
> for future references. 
> There's also some solutions which are not entirely clear. If you have any 
> reference on that it would be welcome, but I understand these might be very 
> system specific as well. 
> 
> ** Installing Jailhouse **
> * Installing Jailhouse on generic Ubuntu (2.10) gives the following error: 
>> ERROR: modpost: "lapic_timer_period" 
>> [/data/ecseqm/jailhouse/510_siemens_jailhouse/driver/jailhouse.ko] undefined!
>> ERROR: modpost: "__get_vm_area_caller" 
>> [/data/ecseqm/jailhouse/510_siemens_jailhouse/driver/jailhouse.ko] undefined!
>> ERROR: modpost: "ioremap_page_range" 
>> [/data/ecseqm/jailhouse/510_siemens_jailhouse/driver/jailhouse.ko] undefined!
> I believe some of the kernel symbols have been renamed in I believe 5.8. As a 
> solution, I switched to 2.04 LTS (Kernel 5.4), where it installed without 
> issues.
> 

That used to work by luck for some kernels via ksymall, but that is
disabled in other kernels for security reasons - and now even removed
from upstream. You need some patches from the github.com/siemens/linux
jailhouse-enabling/5.4 queue (or queues/jailhouse for the head queue,
that's on git.kiszka.org).

> ** Enabling Jailhouse
> * enabling a compiled sysconfig.cell results in:
>> JAILHOUSE_ENABLE: Invalid argument
> with dmesg listing:
>> jailhouse: Not a system configuration
> This issue was already reported on the mailing list, but I'd like to note 
> that it was not a singular case. Switching from GCC-9 to GCC-7 solved the 
> issue for me too. I guess GCC-9 takes the freedom to move the header away 
> from the initial memory location, which results in Jailhouse failing to 
> verify the .cell to be a system configuration description. 
> 

If that isn't solved in current next, we should address it. The proper
fix is moving away from gcc to a different way of compiling, but that's
another story.

> * enabling results in: 
>> FATAL: Unhandled MSR write: c8f
> Ubuntu distributions have CONFIG_X86_CPU_RESCTRL=y kernel config set by 
> default. I do not know how widespread this is. Apparently, this conflicts 
> with jailhouse, as such a Linux kernel tends to write to 0xc8f: 
> IA32_PQR_ASSOC. Disabling rdt over the kernel commandline does not solve the 
> issue. Perhaps it might be useful to extend the hardware check to check for 
> this flag? Rebuilding the kernel without RESCTRL fixed the issue.
> 
> * enabling results in: 
>> FATAL: Invalid MMIO/RAM read, addr: 0x0000000087a6e070 size: 8
>> FATAL: Invalid MMIO/RAM write, addr: 0x0000000087a6e018 size: 0
> These memory accesses are 
>> 86dff000-924fefff : Reserved
>>   89f5b018-89f5b06f : APEI ERST
>>   89f5b070-89f5d017 : APEI ERST
> The APEI ERST are included by jailhouse by default, however the remainder of 
> the reserved region is not. Passing this to jailhouse solves the issue. Does 
> anybody have any idea where this region could be used for? I expect some bios 
> driver? Is there a way to detect which driver is interfering here? 
> 
> * Similarly, a violation was found while destroying a non-root cell: 
>> FATAL: Invalid PIO read, port: 500 size: 2
> Which jailhouse identifies as: 
>> /* Port I/O: 0510-0515 : ACPI CPU throttle */
>> PIO_RANGE(0x510, 0x6),
> Again, passing the port solves the issue. Does anybody have a clue why the 
> CPU throttle is required to destroy a non-root cell? Is it an idea to include 
> these PIO ports by default in the config creation?
> 
> The last issues were described to some extend in Jan's ELCE talk in 2016, 
> "Tutorial: Bootstrapping the Partitioning Hypervisor Jailhouse". I really 
> liked the introduction and think it is an excellent talk to get started with 
> Jailhouse. 
> However, it is not linked in e.g. the readme or the FAQ. This might be 
> beneficial.
> 
> If anyone has any ideas about the PIO/Memory requirements, that would be 
> really welcome. 
> 
> Thanks for all the efforts put in Jailhouse. 
> 

Thanks for this detailed feedback! In general, we are happy to take
contributions also to the README or other docs where you see gaps.
That's best provided by new users as it's too easy for us oversee
details that we know but that aren't sufficiently documented yet.

Jan

-- 
Siemens AG, T RDA IOT
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/200a59b2-8745-099a-4172-a29dcd22c65e%40siemens.com.

Reply via email to