Jan/Ralf:

Ok, with the rootfs.cpio you just provided I can see the following on my
serial port:

Welcome to Buildroot
jailhouse login:

So that's progress.  Is there a default user name and password to use to
complete the login?  That would point to the problem being booting against
my initramfs files.

Also, the issue where my serial output scrolled continuously was due to the
capture method.  I switched to minicom and no longer see that occur.

Any further thoughts on why jailhouse fails to load the guest when I set
the memory region greater than 200MB?

Thanks,
Wayne



On Tue, Jun 18, 2019 at 9:08 AM Jan Kiszka <[email protected]> wrote:

> 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/CA%2B%2BKhc2-Cv%3D%3D%2BeJCS8cN-ShK7q%3D%3DQs7UpW-ZfoUcEZ2Tam5c7Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to