Re: [PATCH v1 14/21] Ovmf/Xen: allow non-PCI usage of XenBusDxe

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 26 January 2015 at 14:10, Laszlo Ersek <lersek@redhat.com> wrote:
> On 01/26/15 14:52, Ard Biesheuvel wrote:
>
>> Well, the problem is that the XenConsoleSerialPortLib implementation
>> also needs to issue Xen hypercalls, and needs to do so very early.
>
> In general virtual serial consoles, be they Xen or virtio, are a huge
> "impedance mismatch" (is that the right term?) for UEFI / edk2. For UEFI
> / edk2, the serial port library is one of the lowest level libraries,
> because it must be able to give you debug output as early as SEC. Fixed
> addresses, minimal state, minimal setup.
>
> However, the virtual serial ports are very stateful and require
> elaborate device setup. That matches the DXE phase alright, but nothing
> before.
>
>> We
>> could still make XENIO_PROTOCOL take its implementations of those
>> hypercalls form XenHypercallLib, as XenConsoleSerialPortLib does, but
>> I don't think it makes the code more understandable in that case. In
>> particular, we would have two different ways of issuing hypercalls
>> from code that is Xen-specific, one directly and one through the IO
>> protocol.
>
> Agreed. The root cause of that is that the virtual (Xen) serial port is
> unsuitable for the original purpose of SerialPortLib -- be super
> low-level, available as soon as in SEC, without any kind of discovery,
> and just have minimal state. It's a debug device on which everything
> else relies on.
>
> (The same is true of virtio-serial, obviously.)
>

In fact, this is working fine for the Xen console. My SerialPortLib
implementation has a constructor that issues 2 hypercalls through
XenHypercallLib to initialize the console, and the PrePi SEC
implementation calls the SerialPortLib constructor explicitly. For
ARM, this is essential as there is no other console. For x86, this
wouldn't work as its XenHypercallLib depends on the hyperpage HOB to
be available, but then, it doesn't need the Xen console anyway.

> For QEMU ARM guests, we use the emulated (PL011) serial port, which is
> easy to program. But you do remember the sad hoops you had jump through
> with the DTB because you wanted to make the base address dynamic.
>

Yes. But one of the primary issues is that the emulated NOR flash
breaks global variables, making it difficult to retain the state
created by a constructor.

>>> But I guess the following also makes sense:
>>>
>>>                     XenBusDxe
>>>                    /         \
>>>                XenIo          ARM vs. Intel hypercall Lib Instance
>>>                  |
>>>             PCI vs. DTB
>>>
>>> The second architecture would keep XenIo much thinner, and it's
>>> certainly sufficient to have only one hypercall method built into the
>>> entire firmware -- you could decide that question at build time with a
>>> "global" library class resolution.
>>>
>>
>> Yes, I think this is the pragmatic choice, and I happen to be feeling
>> very pragmatic at the moment :-)
>
> "At the moment"? :) No doubt. :)
>

-- 
Ard.