* Jan Kiszka <[email protected]> [2017-06-20 18:39:09 +0200]:
> On 2017-06-20 18:18, Gustavo Lima Chaves wrote:
> >
> > [...]
> >
> >>>
> >>> And now things become even easier to use:
> >>>
> >>> jailhouse cell linux config.cell bzImage -i initrd -c \
> >>> "console=... memmap=1M@0 memmap=... pmtmr=0x..."
> >>>
> >>> The memmap and pmtmr arguments should be overcome via ACPI tables in the
> >>> future. Then no redundant tunable will be left.
> >>
> >> ACPI turned out to be only of limited use as it made the kernel expect
> >> resources that are mandatory according to the spec. So I went for
> >> passing the parameters via the structures the kernel gets from the
> >> bootloader. Memory regions were also included as E820 list, the PM timer
> >> and now also the number of CPUs and their IDs come via a custom data
> >> structure that the Jailhouse bits in Linux process.
> >>
> >> Result: no more special command line parameters, and even SMP works now.
> >> See usual branches.
> >
> > Resurrecting an old thread here trying to figure some things out. So the
> > reason for not giving access to the ACPI tables to Linux inmates is that
> > we'd have to slice it, removing what is not meant to fall into its
> > partition, and the spec (and the parser) do not expect a "sliced up" ACPI
> > table, right?
>
> Yes, basically. ACPI, or at least how it is used by typical OSes, is not
> complete /wrt description of the hardware resources and their
> availability. And its executable elements make it horribly complex.
>
> I've learned about other hypervisors building such sliced configs. They
Can you name then? :)
> told me that would be "inevitable" due to the need to describe CPU power
> management - I'm not yet convinced, but I also didn't look into all
You mean TODO-list entry
- power management [v1.0]
- block
- allow per cell (managing inter-core/inter-cell impacts)?
> nasty details. However, they also emulate a more complete guest
> platform, something that we do not want to.
I understand it might be a lot of code to get there, but the end goal
is nice as well. I guess we can live with the way it is, though.
>
> >
> > Now, what parts of the jh branch on Linux are meant to be proposed
> > upstream? None? The one introducing config JAILHOUSE_GUEST?
>
> Eventually, all from queues/jailhouse (I suppose that is what you refer
> to), but surely not in the given form. For x86 guest, those tagged with
> "x86" are essential.
OK, cool.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA ITP 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].
> For more options, visit https://groups.google.com/d/optout.
--
Gustavo Lima Chaves
Intel - Open Source Technology Center
--
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].
For more options, visit https://groups.google.com/d/optout.
