On 08.08.2014 14:43, David Vrabel wrote: > On 08/08/14 12:20, Stefan Bader wrote: >> Unfortunately I have not yet figured out why this happens, but can confirm by >> compiling with or without CONFIG_RANDOMIZE_BASE being set that without KASLR >> all >> is ok, but with it enabled there are issues (actually a dom0 does not even >> boot >> as a follow up error). >> >> Details can be seen in [1] but basically this is always some portion of a >> vmalloc allocation failing after hitting a freshly allocated PTE space not >> being >> PTE_NONE (usually from a module load triggered by systemd-udevd). In the >> non-dom0 case this repeats many times but ends in a guest that allows login. >> In >> the dom0 case there is a more fatal error at some point causing a crash. >> >> I have not tried this for a normal PV guest but for dom0 it also does not >> help >> to add "nokaslr" to the kernel command-line. > > Maybe it's overlapping with regions of the virtual address space > reserved for Xen? What the the VA that fails? > > David > Yeah, there is some code to avoid some regions of memory (like initrd). Maybe missing p2m tables? I probably need to add debugging to find the failing VA (iow not sure whether it might be somewhere in the stacktraces in the report).
The kernel-command line does not seem to be looked at. It should put something into dmesg and that never shows up. Also today's random feature is other PV guests crashing after a bit somewhere in the check_for_corruption area... -Stefan
signature.asc
Description: OpenPGP digital signature
