Hi Jan,
On 06/03/17 13:48, Jan Beulich wrote:
On 06.03.17 at 14:21, <julien.gr...@arm.com> wrote:
On 06/03/17 12:41, Jan Beulich wrote:
Furthermore - how does this scale? I.e. what if other devices pop
up wanting to be emulated? Or multiple UARTs?
I think you can appreciate that using QEMU for emulating an UART is
quite overkill.
Sure, but this doesn't answer my questions.
Devices we are planning to emulate are in order to be compliant with the
SBSA. Looking at the spec, it requires:
* SBSA UART
* RTC: It is expected to drive through EFI API but we may want to also
support in non-UEFI case.
* Persistent environment storage: This is only required for the UEFI.
Another device we are expecting to emulate in Xen is the PCI root
complex in order to avoid as much as PV drivers for the guest.
So I think we would need to emulate 3 devices: SBSA UART, RTC and root
complex.
I cannot predict what will happen in the future, but I would expect the
number of devices we require to emulate very limited.
Regarding the multiple UARTs, you have a point here. The code in itself
could handle any number of UARTs easily, but we thought that guest will
usually use only one console.
I was looking at the backend code and see it is using DOMCTL command. I
guess it is considered that the console backend will be tied to a
specific Xen version. Am I correct?
so maybe we can introduce new domctl command for handling vUART. This
would avoid us to commit on an ABI and allow us to extend it if
necessary in the future to support multiple UARTs.
Any opinions?
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
