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

[Laszlo Ersek <lersek@xxxxxxxxxx>]

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

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.

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

Cheers,
Laszlo

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