On 18.06.19 14:10, Wayne wrote:
Jan/Ralf:
I just meant that my initramfs files get generated by the "dracut" script, which
gets run automatically when executing "make install" in the kernel
distribution. I would be happy to try your x86 initrd binary, it may tell us
something. I haven't been able to install buildroot successfully. Is there any
Sent.
specific reason why you would need it for an x86 poweredge as opposed to the
standard dracut/mkinitramfs for the guest?
The reason is primarily size, a bit convenience: For demo and test purposes, you
want a number of tools and services inside the initramfs that a normal does not
contain (ssh/sshd, various hw diagnostic tools, rt-tests, iperf etc.). Of
course, you can manually define the rules to copy them in via dracut, likely
quite a bit of work, but then the size would not be 8M. Sure, the latter is only
an issue for smaller embedded targets.
Running the "jailhouse hardware check" reports "ok" for all categories except
for the following (which report "optional"):
VT-x (VMX) :
VMX inside SMX missing (optional)
VT-d (IOMMU #0-3) :
39-bit AGAW missing (optional)
(2M pages and 1G pages show as ok)
Wasn't the reason, ok...
Jan
Wayne
On Tue, Jun 18, 2019 at 2:32 AM Jan Kiszka <[email protected]
<mailto:[email protected]>> wrote:
On 17.06.19 21:06, Wayne wrote:
> Hi Jan,
>
> I am still having trouble getting the non-root linux kernel to boot up.
Based
> on your suggestions I tried two scenarios and am using your AMD kernel
config
> you pointed me to above:
>
> 1. Attempted to use the 70MB root linux initramfs (generated through
kernel
> "make install"), but I get this error:
What do you mean with "generated through kernel"?
>
> [ 2.648665] rootfs image is not initramfs (write error); looks like an
initrd
> [ 2.655732] /initrd.image: incomplete write (-28 != 71905893)
> [ 2.672708] Freeing initrd memory: 70224K
>
> Since we suspect possible image corruption by the kernel extracting, I
doubled
> my guest linux memory allocation. Therefore I now have 416MB of memory
reserved
> by the root linux command line for the guest. I can see that the
"MemTotal"
> available in /proc/meminfo went down by approx 416MB accordingly after
updating
> the root command memmap arg. However, if I try to execute the "jailhouse
cell
> linux ..." command with a memory region .size of 400MB (or even 256MB)
then
> jailhouse throws the following error:
>
> Traceback (most recent call last):
> File "./tools/jailhouse-cell-linux", line 824, in <module>
> cell = JailhouseCell(config)
> File "/home/test/jailhouse-next/tools/../pyjailhouse/cell.py", line
36, in
> __init__
> raise e
> File "/home/test/jailhouse-next/tools/../pyjailhouse/cell.py", line
33, in
> __init__
> fcntl.ioctl(self.dev <http://self.dev> <http://self.dev>,
> JailhouseCell.JAILHOUSE_CELL_CREATE, create)
> OSError: [Errno 12] Cannot allocate memory
>
> Any thoughts here?
Nothing obvious in the configs. Well, you have the 0x3a600000 range twice in
the
root cell config. That should not cause the problem, though. Should still be
fixed.
Maybe you are running out of hypervisor memory because your hardware does
not
support large pages and therefore requires larger paging structure. But
that's
also rather unlikely - unless the hardware is 5 years or so old. What all
does
"jailhouse hardware check" report?
>
> 2. If I use my 30MB guest linux 4.19 initramfs instead (generated through
kernel
> "make install"), then it gets passed the extracting phase but falls into
the
> dracut emergency shell. The shell then keeps scrolling repeatedly on the
UART
> (ttyS0):
> :/#
> :/#
> :/#
> ...
> Any thoughts on why this scrolling is occuring? I'm viewing the serial
output on
> another linux machine with "cat /dev/ttyS0".
>
> Any idea why its dropping into the emergency prompt rather than
continuing to
> boot the kernel? The initramfs was just re-generated with "make install"
and
> should match the 4.19 guest.
Given all the problems and variables, I would rather recommend trying a
known-to-work initrd first, ie. the one we generate via buildroot. If it
helps,
I can share a binary for x86 offlist. From there, you can stepwise change
more
variables.
Jan
>
> Note that my root kernel is vanilla 4.16 and my non-root linux guest is
4.19
> jailhouse enabling from siemens. I attached my latest System config and
> non-linux cell config.
>
>
> Thanks for your repeated help,
>
> Wayne
>
> On Thu, Jun 13, 2019 at 2:55 PM Jan Kiszka <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> wrote:
>
> On 13.06.19 20:49, Wayne wrote:
> > I added the "-k 10" to the command and unfortunately it did not
make a
> > difference with the unpacking. If I add "root=/dev/ram0" it
does get
> past the
> > unpacking, but throws the panic for "System is deadlocked on
memory".
> >
> > I have attached my current non-root kernel config. Should I
expect to be
> able
> > to log in to the non-root if I use the same initramfs as the root
linux?
> >
>
> You should at least expect to see no error messages of the kernel,
possibly
> some
> futile probing of devices and then likely a console prompt.
>
> Let's try my kernel config from jailhouse-images first. If that
works, you can
> tune from there towards your needs. I still think there is some
sizing issue or
> so, but I'm not seeing the key difference immediately.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/889c96a9-a7dc-4385-28e5-437fbc4d5008%40siemens.com.
For more options, visit https://groups.google.com/d/optout.
