Re: [Xen-devel] [PATCH] build: convert CONFIG_COMPAT to Kconfig

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Mon, 2015-12-21 at 04:32 -0700, Jan Beulich wrote:
> > > > On 18.12.15 at 23:09, <andrew.cooper3@xxxxxxxxxx> wrote:
> > On 18/12/2015 21:49, Doug Goldstein wrote:
> > > On 12/18/15 3:35 PM, Andrew Cooper wrote:
> > > > On 18/12/2015 20:06, Doug Goldstein wrote:
> > > > > Use the Kconfig generated CONFIG_COMPAT defines in the code base.
> > > > > 
> > > > > CC: Keir Fraser <keir@xxxxxxx>
> > > > > CC: Jan Beulich <jbeulich@xxxxxxxx>
> > > > > CC: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> > > > > Signed-off-by: Doug Goldstein <cardoe@xxxxxxxxxx>
> > > > Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, although I
> > > > have
> > > > a slight quibble.
> > > > 
> > > > > ---
> > > > > This was previously Acked-by: Jan Beulich <jbeulich@xxxxxxxx> but
> > > > > then
> > > > > there was a request to change it to xen/common/Kconfig from
> > > > > xen/arch/x86/Kconfig. Unfortunately a small typo ('def_bool y'
> > > > > instead of
> > > > > 'bool') caused it to break on ARM. This resolves the issue and
> > > > > should be
> > > > > ready to merge.
> > > > > ---
> > > > > Âconfig/x86_64.mkÂÂÂÂÂ| 1 -
> > > > > Âxen/arch/x86/Kconfig | 1 +
> > > > > Âxen/common/KconfigÂÂÂ| 7 +++++++
> > > > > Â3 files changed, 8 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/config/x86_64.mk b/config/x86_64.mk
> > > > > index f12d549..85fa27c 100644
> > > > > --- a/config/x86_64.mk
> > > > > +++ b/config/x86_64.mk
> > > > > @@ -2,7 +2,6 @@ CONFIG_X86 := y
> > > > > ÂCONFIG_X86_64 := y
> > > > > ÂCONFIG_X86_$(XEN_OS) := y
> > > > > Â
> > > > > -CONFIG_COMPAT := y
> > > > > ÂCONFIG_MIGRATE := y
> > > > > ÂCONFIG_XCUTILS := y
> > > > > Â
> > > > > diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> > > > > index 07e366d..7d2ed96 100644
> > > > > --- a/xen/arch/x86/Kconfig
> > > > > +++ b/xen/arch/x86/Kconfig
> > > > > @@ -3,6 +3,7 @@ config X86_64
> > > > > Â
> > > > > Âconfig X86
> > > > > Â     def_bool y
> > > > > +     select COMPAT
> > > > > Â     select HAS_ACPI
> > > > > Â     select HAS_CPUFREQ
> > > > > Â     select HAS_EHCI
> > > > > diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> > > > > index 7d0e9a9..046e257 100644
> > > > > --- a/xen/common/Kconfig
> > > > > +++ b/xen/common/Kconfig
> > > > > @@ -1,6 +1,13 @@
> > > > > Â
> > > > > Âmenu "Common Features"
> > > > > Â
> > > > > +config COMPAT
> > > > > +     bool
> > > > > +     help
> > > > > +     ÂÂ32-bit interface support on 64-bit Xen which is used
> > > > > for both
> > > > > +     ÂÂHVM and PV guests. HVMLoader makes 32-bit hypercalls
> > > > > irrespective
> > > > > +     ÂÂof the destination runmode of the guest.
> > > > As this is now common, probably want to specify x86 HVM and PV
> > > > guests. 
> > > > Arm guests are technically HVM, although the term is rather less
> > > > common
> > > > on their side.
> > > > 
> > > > ~Andrew
> > > > 
> > > How about:
> > > 
> > > 32-bit interface support on 64-bit Xen which is used by x86 HVM and
> > > PV
> > > guests and ARM HVM guests. The reason this is used for HVM guests is
> > > that HVMLoader makes 32-bit hypercalls irrespective of the
> > > destination
> > > run mode of the guest.
> > > 
> > 
> > The complication here is that arm doesn't yet support compat.ÂÂThere is
> > a hope to (which is, I guess, why Jan asked for it to be common), but
> > it
> > shouldn't give any implication that it is available on ARM yet.
> 
> I don't think ARM is meant to ever use this layer - its interface was
> made 32-bit clean from the beginning.

Correct. We went to some lengths to avoid the need for a compat layer for
supporting 32 bit guests on a 64 bit Xen ARM.

I also want to clarify that ARM guests are neither PV nor HVM(*), they are
something in between and we try to avoid the PV/HVM terminology when
speaking about ARM, they are just "guests" as there is only one kind. (Some
of the PV/HVM terminology has leaked into the implementation, due to not
fully refactoring some stuff or shaving various yaks by renaming stuff, but
that's irrelevant to the bigger picture IMHO).

Eventually we may end up with a thing like x86's HVM (i.e. pretending to be
real h/w) at which point we will need to retcon on a name for the existing
guest type.

(*) They are somewhat more like a PVH or dm-lite guest, but even that isn't
Âquite right.

>  The reason for wanting this
> option to be common is an abstract one (i.e. considering just possible
> future architectures).

I would hope that most future arches would try very hard to follow ARM's
lead here and not have a compat layer at all, but that doesn't conflict
with your abstract point IMHO.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel