From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Mon, 15 Apr 2019 07:56:22 -0700 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C32343092651; Mon, 15 Apr 2019 14:56:20 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-121-136.rdu2.redhat.com [10.10.121.136]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0702419C56; Mon, 15 Apr 2019 14:56:16 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v2 28/31] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn To: devel@edk2.groups.io, anthony.perard@citrix.com Cc: Jordan Justen , Ard Biesheuvel , Julien Grall , xen-devel@lists.xenproject.org References: <20190409110844.14746-1-anthony.perard@citrix.com> <20190409110844.14746-29-anthony.perard@citrix.com> From: "Laszlo Ersek" Message-ID: <7d6adf5d-baca-7e9c-68ef-2f8479bbd902@redhat.com> Date: Mon, 15 Apr 2019 16:56:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190409110844.14746-29-anthony.perard@citrix.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.43]); Mon, 15 Apr 2019 14:56:21 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 04/09/19 13:08, Anthony PERARD wrote: > On a Xen PVH guest, none of the existing serial or console interface > works, so we add a new one, based on XenConsoleSerialPortLib, and > implemeted via SerialDxe. > > That a simple console implementation that can works on both PVH guest (1) ITYM "that *is* a simple console implementation..." > and HVM guests, even if it rarely going to be use on HVM. > > Have PlatformBootManagerLib look for the new console, when running as a > Xen guest. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Anthony PERARD > --- > > Notes: > v2: > - Use MdeModulePkg/Universal/SerialDxe instead of something new. > - Have PlatformInitializeConsole() look for it by using the > known-in-advance device path for the xen console in the > PLATFORM_CONSOLE_CONNECT_ENTRY. > > OvmfPkg/XenOvmf.dsc | 4 ++ > OvmfPkg/XenOvmf.fdf | 1 + > OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf | 4 ++ > OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h | 1 + > OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 10 +++- > OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c | 59 ++++++++++++++++++++ > 6 files changed, 78 insertions(+), 1 deletion(-) > > diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc > index 35af05715b..a26f611058 100644 > --- a/OvmfPkg/XenOvmf.dsc > +++ b/OvmfPkg/XenOvmf.dsc > @@ -599,6 +599,10 @@ [Components] > OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf > OvmfPkg/XenBusDxe/XenBusDxe.inf > OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf > + MdeModulePkg/Universal/SerialDxe/SerialDxe.inf { > + > + SerialPortLib|OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf > + } > MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf > MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf > MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf > diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf > index d614bdce1d..e078c7b405 100644 > --- a/OvmfPkg/XenOvmf.fdf > +++ b/OvmfPkg/XenOvmf.fdf > @@ -298,6 +298,7 @@ [FV.DXEFV] > INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf > INF OvmfPkg/XenBusDxe/XenBusDxe.inf > INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf > +INF MdeModulePkg/Universal/SerialDxe/SerialDxe.inf > > INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf > INF MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf (2) Do you really need all three of: - MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf - IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe/IsaSerialDxe.inf - MdeModulePkg/Universal/SerialDxe/SerialDxe.inf for supporting both HVM and PVH? If possible I'd suggest just the last one, plus a general resolution of SerialPortLib to XenConsoleSerialPortLib. Or would that force HVM users to change their domU configs? (Anyway I don't feel strongly about this question, with regard to the OvmfXen platform.) > diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf > index c41aaeef3f..7dd0683cd2 100644 > --- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf > +++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf > @@ -67,6 +67,10 @@ [Pcd] > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId > gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut > gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile > + gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES > + gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES > + gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity ## CONSUMES > + gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES > > [Pcd.IA32, Pcd.X64] > gEfiMdePkgTokenSpaceGuid.PcdFSBClock (3) If possible, please keep PCDs from the space token space GUID (gEfiMdePkgTokenSpaceGuid) clustered near each other. ("Fully sorted" is optimal, but in many cases the PCD lists we have already aren't sorted, and then I prefer sorting to be a separate patch -- but that's really not necessary here.) > diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h > index 4948ca6518..2ab1a76f6a 100644 > --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h > +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h > @@ -172,6 +172,7 @@ typedef struct { > #define CONSOLE_IN BIT1 > #define STD_ERROR BIT2 > extern PLATFORM_CONSOLE_CONNECT_ENTRY gPlatformConsole[]; > +extern PLATFORM_CONSOLE_CONNECT_ENTRY gXenPlatformConsole[]; > > // > // Platform BDS Functions > diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c > index 1a6d47732e..f186060f34 100644 > --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c > +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c > @@ -85,6 +85,13 @@ InstallDevicePathCallback ( > VOID > ); > > +STATIC > +BOOLEAN > +XenDetected ( > + VOID > + ); > + > + > VOID > PlatformRegisterFvBootOption ( > EFI_GUID *FileGuid, (4) OK, this has convinced me: (4a) please rebase PlatformBootManagerLib to XenPlatformLib first, removing the open-coded XenDetected() function -- this should be a separate patch (4b) once you do that, my concern for "v2 25/31" can also be addressed easily -- you can simply repeat the XenPvhDetected() restriction from XenPlatformPei() in PlatformBootManagerLib too. > @@ -404,7 +411,8 @@ PlatformBootManagerBeforeConsole ( > // > EfiBootManagerDispatchDeferredImages (); > > - PlatformInitializeConsole (gPlatformConsole); > + PlatformInitializeConsole ( > + XenDetected() ? gXenPlatformConsole : gPlatformConsole); > PcdStatus = PcdSet16S (PcdPlatformBootTimeOut, > GetFrontPageTimeoutFromQemu ()); > ASSERT_RETURN_ERROR (PcdStatus); Aha, so my question under (2) does make sense! If you are switching to the Xen console just based on XenDetected(), that includes HVM domUs too, and so you should be able to drop both PciSioSerialDxe and IsaSerialDxe from the OvmfXen platform. > diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c > index 1250a6d351..4179370c81 100644 > --- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c > +++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c > @@ -16,6 +16,11 @@ > #include "BdsPlatform.h" > #include > > +#define SERIAL_DXE_FILE_GUID { \ > + 0xD3987D4B, 0x971A, 0x435F, \ > + { 0x8C, 0xAF, 0x49, 0x67, 0xEB, 0x62, 0x72, 0x41 } \ > + } > + > // > // Debug Agent UART Device Path structure > // Ah cool, now we have *four* separate #define's for this GUID :( - ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c - ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c - CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformConsole.c - OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c This is obviously an omission in MdeModulePkg at this point. (5) Please write a separate patch for "MdeModulePkg.dec" and "MdeModulePkg/Include/Guid/" -- given that the FILE_GUID of "MdeModulePkg/Universal/SerialDxe" has to be placed into device paths by multiple platforms, and SerialDxe calls itself "Universal", MdeModulePkg itself should offer the GUID ready for consumption. Then all three of the above (preexistent) consumers should be updated to take the GUID from that location. I suggest discussing this with the MdeModulePkg maintainers, and if they agree, I recommend implementing this GUID-extraction in an independent series, before spinning v3 of XenPVH. (In v3, the GUID should be consumed like described above.) ... Yes, it's quite arbitrary that I'm asking for the extraction of the GUID at this point, and not earlier. Sorry about that. > @@ -49,6 +54,18 @@ typedef struct { > } VENDOR_RAMFB_DEVICE_PATH; > #pragma pack () > > +// > +// Xen Console Device Path structure > +// > +#pragma pack(1) > +typedef struct { > + VENDOR_DEVICE_PATH VendorHardware; > + UART_DEVICE_PATH Uart; > + VENDOR_DEVICE_PATH TerminalType; > + EFI_DEVICE_PATH_PROTOCOL End; > +} XEN_CONSOLE_DEVICE_PATH; > +#pragma pack() > + > ACPI_HID_DEVICE_PATH gPnpPs2KeyboardDeviceNode = gPnpPs2Keyboard; > ACPI_HID_DEVICE_PATH gPnp16550ComPortDeviceNode = gPnp16550ComPort; > UART_DEVICE_PATH gUartDeviceNode = gUart; (6) Can you please insert a space between "pack" and "(1)"? > @@ -147,6 +164,37 @@ STATIC VENDOR_RAMFB_DEVICE_PATH gQemuRamfbDevicePath = { > gEndEntire > }; > > +STATIC XEN_CONSOLE_DEVICE_PATH gXenConsoleDevicePath = { > + { > + { > + HARDWARE_DEVICE_PATH, > + HW_VENDOR_DP, > + { > + (UINT8) (sizeof (VENDOR_DEVICE_PATH)), > + (UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8) > + } > + }, > + SERIAL_DXE_FILE_GUID > + }, > + { > + { > + MESSAGING_DEVICE_PATH, > + MSG_UART_DP, > + { > + (UINT8) (sizeof (UART_DEVICE_PATH)), > + (UINT8) ((sizeof (UART_DEVICE_PATH)) >> 8) > + } > + }, > + 0, > + FixedPcdGet64 (PcdUartDefaultBaudRate), > + FixedPcdGet8 (PcdUartDefaultDataBits), > + FixedPcdGet8 (PcdUartDefaultParity), > + FixedPcdGet8 (PcdUartDefaultStopBits), > + }, > + gPcAnsiTerminal, > + gEndEntire > +}; > + > // > // Predefined platform default console device path > // > @@ -169,6 +217,17 @@ PLATFORM_CONSOLE_CONNECT_ENTRY gPlatformConsole[] = { > } > }; > > +PLATFORM_CONSOLE_CONNECT_ENTRY gXenPlatformConsole[] = { > + { > + (EFI_DEVICE_PATH_PROTOCOL *)&gXenConsoleDevicePath, > + (CONSOLE_OUT | CONSOLE_IN | STD_ERROR) > + }, > + { > + NULL, > + 0 > + } > +}; > + > // > // Predefined platform connect sequence > // > The rest looks OK to me, although at this point my brain is mush and you could sell me anything. Stopping with the review for today. Thanks, Laszlo