Re: [PATCH 00/17 v5] SBSA UART emulation support in Xen

[Julien Grall <julien.grall@arm.com>]

On 05/07/2017 20:43, Julien Grall wrote:
>
>
> On 05/07/2017 20:06, Stefano Stabellini wrote:
>> On Wed, 5 Jul 2017, Julien Grall wrote:
>>> On 07/04/2017 08:31 AM, Bhupinder Thakur wrote:
>>>> Hi Julien,
>>>
>>> Hi Bhupinder,
>>>
>>> Thank you for the summary!
>>>
>>> [...]
>>>>
>>>> Currently, UEFI firmware uses hvc as the console for input/output. Now
>>>> with the support
>>>> of SBSA UART in Xen, it is preferrable that UEFI firmware should be
>>>> able to the uart
>>>> as well.
>>>>
>>>> One option which was discussed was to use pl011 purely as a debug
>>>> port. Currently the debug
>>>> prints are intermixed with the normal console output. Now with uart
>>>> port becoming available
>>>> the debug prints can be redirected to pl011 thus cleaning up the
>>>> console
>>>> output.
>>>>
>>>> Other option is to output everything on both HVC and pl011 both but it
>>>> takes away the advantage
>>>> of separating out the debug and normal console prints. However, pl011
>>>> can be used as debug
>>>> port based on a compile time flag. If this compile-time is off, then
>>>> the output can be sent to both
>>>> HVC and pl011.
>>>>
>>>> Based on this discussion I feel that:
>>>> - the default behaviour should be writing the output to both HVC and
>>>> pl011.
>>>
>>> Hmmm. If I remember correctly this was suggested but ruled out. It was
>>> considered that pl011 and PV console should not be treated equal.
>>> PL011 would
>>> be used for boot diagnostics (i.e imagine an Image with no Xen support).
>>
>> Actually I remember the opposite:
>> afd2e931-706b-6e25-1f0e-feee16e83c88@redhat.com (this was a private
>> reply though).
>
> This was an answer to my question whether a user could select the serial
> by himself. To this reply, you asked whether it was feasible to output
> on all the serials console, but I don't see any yes/no answer.
>
> On the rest of the thread, it has been mentioned it was difficult to
> multiplex to serial console (I forwarded you the thread). Christoffer,
> Laszlo and Ard agreed that PL011 should only be used as boot diagnostics
> and debug (if selected at compile time).

Actually copying here as answer as Laszlo was happy to forward the 
answer on public list: (+CC Christoffer and Ard)

* So, first of all, the debug port must be a super dumb device,
   available to the earliest firmware phases. It basically has to be a
   platform device, whose location and attributes can be figured out
   without hw discovery or enumeration. (Scanning the DTB is fine, albeit
   already quite laborious in the earliest phases.) PCI, virtio, or XenPV
   devices are unsuitable for this.

* In OVMF (x86), we use the QEMU debug port for this purpose
   (hard-coding the accesses to IO port 0x402). For this, we have a
   specialized DebugLib instance, under
   "OvmfPkg/Library/PlatformDebugLibIoPort".

* The serial port ("COM1") is used equivalently with the graphical
   display and the USB and PS/2 keyboard(s), for console purposes. The
   console(s) become available much later during firmware boot (only in
   the BDS phase).

* In order for a device to be usable as a console, the driver stack must
   (recursively) provide the following two "higher level abstractions" on
   top of the device:

   - EfiSimpleTextInProtocol OR EfiSimpleTextInputExProtocol,
   - AND EfiSimpleTextOutProtocol

   If these are provided, then the console splitter / multiplexer
   mentioned by Ard will take care of the rest.

* In OVMF (x86), this is the relevant protocol and driver stack for the
   "COM1" serial port (note that the necessary "high level abstractions"
   I mentioned above are at the bottom):

             MdeModulePkg/Bus/Pci/PciBusDxe
                           ^
                           |
                   [EfiPciIoProtocol]
                           ^
                           |
               PcAtChipsetPkg/IsaAcpiDxe
                           ^
                           |
                 [EfiIsaAcpiProtocol]
                           ^
                           |
       IntelFrameworkModulePkg/Bus/Isa/IsaBusDxe
                           ^
                           |
                  [EfiIsaIoProtocol]
                           ^
                           |
     IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe
                           ^
                           |
                 [EfiSerialIoProtocol]
                           ^
                           |
             Universal/Console/TerminalDxe
                           ^
                           |
              [EfiSimpleTextInProtocol,
               EfiSimpleTextInputExProtocol,
               EfiSimpleTextOutProtocol]

   Most of this stack is platform dependent (up to and including
   IsaSerialDxe, which produces [EfiSerialIoProtocol]). The universal
   part starts only with TerminalDxe, which consumes
   [EfiSerialIoProtocol], and produces the needed higher level
   abstractions on top.

* OVMF can be built (with -D DEBUG_ON_SERIAL_PORT) to ignore the QEMU
   debug port and to direct debug messages to the serial port instead. In
   that case, we use the following library instances, for directing debug
   messages to the serial port:

   - SerialPortLib: PcAtChipsetPkg/Library/SerialIoLib
   - DebugLib: MdePkg/Library/BaseDebugLibSerialPort

   The DebugLib instance uses SerialPortLib interfaces to print
   characters, and the SerialPortLib instance mentioned above hardcodes
   0x3F8 as the "COM1" UART base address.

   This debug-on-serial build works, but once we're in the BDS phase, the
   serial output will be a mixture of console stuff and debug messages,
   because the two separate paths described above dump output to the
   exact same device.

   So the recommended (and default) build is to send DEBUGs to the QEMU
   debug port (redirecting them to a host side file), and to use "COM1"
   only for console purposes.

* qemu-system-aarch64 has no "debug port", so in ArmVirtQemu we have
   something that can be compared to the (sub-optimal) "-D
   DEBUG_ON_SERIAL_PORT" build of OVMF. Namely, debug messages and
   console output are intermixed.

* In particular, for the DEBUG messages, we use the following library
   instances:

   - PL011UartLib: ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.inf

   - SerialPortLib [1]:
     ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.inf
     (in early firmware phases with no writeable RAM)

   - SerialPortLib [2]:
     ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.inf
     (later firmware phases with writeable RAM)

   - DebugLib: MdePkg/Library/BaseDebugLibSerialPort

   The DebugLib instance is the same as in OVMF's -D DEBUG_ON_SERIAL_PORT
   build, but the serial port APIs are filled in by different library
   instances.

   For the early firmware phases, we use EarlyFdtPL011SerialPortLib,
   which parses the PL011 location from the DTB on every single serial
   port API invocation. In later firmware phases, we use
   FdtPL011SerialPortLib, which can cache the parsed location in static
   variables.

   Finally, both SerialPortLib instances ask the same PL011UartLib to
   perform the actual PL011 accesses.

* Now that we got the DEBUG message printing for ArmVirtQemu out of the
   way, let's look at how PL011 is used for console purposes. (Again,
   sharing the same PL011 between console and DEBUG messages is not
   optimal, but there is no separate debug port for the aarch64 target.)

            MdeModulePkg/Universal/SerialDxe
                           ^
                           |
                 [EfiSerialIoProtocol]
                           ^
                           |
             Universal/Console/TerminalDxe
                           ^
                           |
              [EfiSimpleTextInProtocol,
               EfiSimpleTextInputExProtocol,
               EfiSimpleTextOutProtocol]

   All the drivers in this stack are universal, and SerialDxe produces
   exactly one [EfiSerialIoProtocol] instance without consuming other
   protocol instances. The trick is that it delegates the actual work to
   the platform's SerialPortLib instance (which is linked into the
   SerialDxe executable).

   In ArmVirtQemu's case, this instance is the one marked above as
   "SerialPortLib [2]", which in turn pulls in PL011UartLib as well.

* Considering the ArmVirtXen case. Both paths (DEBUG messages and
   console IO) are identical to those in ArmVirtQemu, except we use the
   following serial port library instance:

   - SerialPortLib: OvmfPkg/Library/XenConsoleSerialPortLib

   You might notice that we don't have two SerialPortLib instances here,
   one for "early" (RAM-less) phases and another for "late" (RAM-ful)
   phases, like we have in ArmVirtQemu. As far as I understand, the
   reason is that Xen guests lack the "early" (RAM-less) phases totally,
   and so we can get away with just a SerialPortLib instance that
   requires writeable RAM.

   This library instance performs Xen hypercalls. But, that makes no
   difference that the same SerialPortLib instance is used for *both*
   paths, namely console IO and DEBUG messages.

* Now, assuming Xen gets another serial port, i.e. it'll have both
   emulated PL011 and the paravirt console device. Based on my experience
   with OVMF (where DEBUGs and console IO use different devices), I'd
   recommend to dedicate one device to DEBUG messages, and another to
   console IO. I would *not* recommend multiplexing UEFI console IO to
   both PL011 and the XenPV console -- simply because separating DEBUGs
   from console IO is much more important than that. So if you gain
   another, primitive enough serial port-like device, definitely dedicate
   it to this separation, IMHO!

   Whether you assign PL011 to DEBUGs and keep UEFI console IO (including
   grub2 IO, for example) on XenPV, or assign them the other way around,
   is a matter of taste (or standards), I guess.

   - For keeping the UEFI console IO on XenPV, and moving the DEBUG
     messages to the new PL011: implement a new DebugLib instance that
     grabs the PL011 location in a manner that is specific to Xen guests
     (my guess: simply open-code it?) and then delegates the transmit
     work to PL011UartLib. That's all.

   - For the inverse: add a new DebugLib instance that embeds
     XenConsoleSerialPortLib's functionality, and add a SerialPortLib
     instace -- a variant of FdtPL011SerialPortLib.inf -- that grabs the
     PL011 location in a Xen-specific way, and delegates the transmit
     work to PL011UartLib.

   Both of these involve the introduction of a DebugLib instance that
   does *not* depend on the SerialPortLib class.

* Off the top of my head, I can't say how (and *whether*) this division
   of log devices in UEFI should be mirrored to the Linux guest OS as
   well. Earlier I made an effort to understand how Linux handled DBG2
   versus SPCR versus... whatever, but I've forgotten all that by now.

* If you *absolutely* want to multiplex both debug messages and console
   IO to both PL011 and the XenPV console, then a new DXE driver will be
   necessary that produces another EfiSerialIoProtocol instance, without
   going through the SerialPortLib class.

   This driver could be a clone of SerialDxe, but instead of consuming
   SerialPortLib (which we resolve to XenConsoleSerialPortLib in
   ArmVirtXen), it could be modified to:

   - grab the PL011 location in a Xen-specific way,

   - talk to PL011UartLib directly.

   Again, I do not recommend this; it would just duplicate the number of
   devices on which you'd get a mixture of DEBUGs and console IO. If Xen
   is gaining another serial port, use that opportunity to separate
   DEBUGs from console IO, like OVMF does. Which device is going to be
   used for which role is a matter of taste, or maybe it can be deduced
   from the relevant specs (ARM VM spec or maybe the SBBR).

Thanks,
Laszlo
PS: pls feel free to fwd this to some public list so that others can
comment should they want to.

-- 
Julien Grall

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