Re: [PATCH v2 0/6] x86/PVH: Dom0 building adjustments

[Juergen Gross <jgross@xxxxxxxx>]

On 02.09.21 13:42, Jan Beulich wrote:
> On 02.09.2021 10:30, Jan Beulich wrote:
> > The code building PVH Dom0 made use of sequences of P2M changes
> > which are disallowed as of XSA-378. First of all population of the
> > first Mb of memory needs to be redone. Then, largely as a
> > workaround, checking introduced by XSA-378 needs to be slightly
> > relaxed.
> >
> > Note that with these adjustments I get Dom0 to start booting on my
> > development system, but the Dom0 kernel then gets stuck. Since it
> > was the first time for me to try PVH Dom0 in this context (see
> > below for why I was hesitant), I cannot tell yet whether this is
> > due further fallout from the XSA, or some further unrelated
> > problem. Dom0's BSP makes it all the way through to entering the
> > idle loop while all APs are still in VPF_down.
> This last part of the mystery is now solved: By cloning from my PV
> .config, I've inherited the X86_X2APIC=n that I have there. Yet
> ACPI's MADT gets populated with only x2APIC entries when building
> Dom0, which such a kernel would mostly ignore (except for logging).
> IOW in a way this was indeed a missing select, except that what's
> needed wouldn't quite work yet:
>
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -83,6 +83,6 @@ config XEN_PVH
>         bool "Xen PVH guest support"
>         depends on XEN && XEN_PVHVM && ACPI
>         select PVH
> -       def_bool n
> +       select X86_X2APIC if XEN_DOM0
>         help
>           Support for running as a Xen PVH guest.
>
> This is because, as mentioned, XEN_DOM0 gets turned off when XEN_PV
> is off. Whereas x2APIC isn't strictly needed for DomU afaics
> (MADT gets populated with LAPIC entries only), so the "select" also
> shouldn't be unconditional.
Correct.

We should rename XEN_DOM0 to XEN_DOM0_PV, and add a "real" XEN_DOM0.

> While likely no-one will really care, I'd like to note that this
> effectively means a 32-bit Linux PVH Dom0 would be impossible, as
> X86_X2APIC depends on X86_64. This may want reflecting in the
> eventual adjustment to the XEN_DOM0 dependencies.
Indeed.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature