Re: [Xen-devel] [PATCH 02/11] xen/arm: vpl011: Add new hvm params in Xen for ring buffer/event setup

[Julien Grall <julien.grall@xxxxxxx>]

Hi Jan,

On 06/03/17 13:48, Jan Beulich wrote:
> > > > On 06.03.17 at 14:21, <julien.grall@xxxxxxx> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel