On 2017-03-27 15:36, Ralf Ramsauer wrote:
> Hi,
>
> a while ago, we (almost) entirely decoupled hypervisor code from inmate
> code. While there were several reasons for decoupling code, many of asm
> headers could still be shared.
>
> Currently, the buildsystem of jailhouse already allows us to include
> hypervisor's asm headers from inmates, we do that e.g. on ARM for
> sysregs.h, which is a typical candidate for such kind of shared headers.
>
> I just noticed that there are many more duplicated macros or register
> definitions:
> - ARM: GICv2/3 registers are redundantly redefined in inmate and
> hypervisor
> - Accessors for MMIO (mmio{8,16,32}_{read/write})
> - Memory Barrier Macros, cpu_relax
> - typedefs for basic types, including bool
>
> So my question is if it would make sense if we introduce a separate
> directory for inmate/hypervisor shared header files and header files
> only. Let's call it /headers. In my opinion, this would be prettier
> than including hypervisor headers in inmates, and avoid redefinition of
> hypervisor/inmate independent definitions which we currently do and
> which tends to be error-prone.
>
> I'm asking this because I have some local patches that implement PSCI
> support for inmates. I'm already able to boot secondary CPUs on
> bare-metal inmates, but I don't want to mainline this code, as it
> introduces yet more duplicated definitions for PSCI commands. I tried
> to share those definitions, which ended up in a mess, as hypervisor's
> asm/psci.h implements more than naming things, so this requires further
> modification.
>
> And before I start fixing things at one location only I thought it could
> be worth to spend a minute on thinking about a common header directory.
I would throw in two thoughts here:
- any inmate usage of hypervisor header should be "free of
interference" for the latter, not excluding simple, "harmless"
exceptions
- if we can continue to use common headers or even expand on this
depends on how we continue with the inmates
- as a library, possibly with a different license?
- as a tool for internal purposes (testing, demos etc.)?
I don't have an answer for the latter yet, but the former should hold as
long as we practice that reuse.
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.
