[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8fd63619-811b-b8ca-1655-513acb3f90c2@suse.com>
Date: Thu, 23 Sep 2021 16:03:52 +0200
From: Juergen Gross <jgross@...e.com>
To: Jan Beulich <jbeulich@...e.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>
Cc: Stefano Stabellini <sstabellini@...nel.org>,
lkml <linux-kernel@...r.kernel.org>,
"xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
Konrad Wilk <konrad.wilk@...cle.com>
Subject: Re: [PATCH 2/9] xen/x86: allow PVH Dom0 without XEN_PV=y
On 07.09.21 12:08, Jan Beulich wrote:
> Decouple XEN_DOM0 from XEN_PV, converting some existing uses of XEN_DOM0
> to a new XEN_PV_DOM0. (I'm not convinced all are really / should really
> be PV-specific, but for starters I've tried to be conservative.)
>
> For PVH Dom0 the hypervisor populates MADT with only x2APIC entries, so
> without x2APIC support enabled in the kernel things aren't going to work
> very well. (As opposed, DomU-s would only ever see LAPIC entries in MADT
> as of now.) Note that this then requires PVH Dom0 to be 64-bit, as
> X86_X2APIC depends on X86_64.
>
> In the course of this xen_running_on_version_or_later() needs to be
> available more broadly. Move it from a PV-specific to a generic file,
> considering that what it does isn't really PV-specific at all anyway.
>
> Note that xen/interface/version.h cannot be included on its own; in
> enlighten.c, which uses SCHEDOP_* anyway, include xen/interface/sched.h
> first to resolve the apparently sole missing type (xen_ulong_t).
>
> Signed-off-by: Jan Beulich <jbeulich@...e.com>
Reviewed-by: Juergen Gross <jgross@...e.com>
Juergen
Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3092 bytes)
Download attachment "OpenPGP_signature" of type "application/pgp-signature" (496 bytes)
Powered by blists - more mailing lists