[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 2 Sep 2021 13:42:09 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xXFVZSaYK4b8AaJ5+/aIrMW00hZGanLVCMXLN49C26c=; b=jheRC3phtRpE6pRTliRKpNp2eiLqNm+qEh/9spIiBXkVfdh5oyawuFdOf/y5aPdKzFORt7zzlqL73zoF/aET9nZ2RusvotCakhJFgTYUAJbuU8Mn+fwW0I9kC9AwErNnzztaaxvebrX7beKuxvYI1B1sZqqwarCNy8opF+0dCNL81XMaYazkNuaLtTIEpNNm7LHLrBVZkbU3Gi/PHpUc1cCatdoLzOvD0+KTt8cuEOxsvep+OiqTGLpOIf+2UtEvOBZWwmpDbcgKJNCv7gvVTn1ghxr33GOzMFcgIosKZWaFzOmRZRB9117vTjqV/elGb0vI8WI3ml+yvOiWYz4C/A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=edCBtRt22ezlv7rHVOgEMFSMVN86J+T7rDIgTPuWyB/1evYcATdlzTB+jNmy874LwZ8DgOYw1nPYb4iF5byKwdNjQosP+vnfk3MOHKXODRayJtUnIU/jCdnM/t/hZ5a3UeZZB6GuLVpGJKzetaXwownOfcWyt35Bgf6m/nnifKZ/fqwM5X33AhK7HdPS15vjIMLZYxUwSGZuMRo1PzClKviPd7KlRJo4cohVwkafeLwSZNp0aCLHjZXlh4rbLBAiNIH8Qg3sFjb0Dp0CMuS2TirbUzTR238W10lbPBCXs7bljh6YdC/KtHRn+kZzkQIMIwsyQnig9sRu3ZRdcnLRVw==
  • Authentication-results: citrix.com; dkim=none (message not signed) header.d=none;citrix.com; dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Thu, 02 Sep 2021 11:42:24 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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
          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.

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.

Btw, I've meanwhile also checked timers: They're active and get
updated while Dom0 is in this funny idle state.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.