Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])

[Julien Grall <julien.grall@xxxxxxx>]

Hi Stefano,

On 23/11/16 19:55, Stefano Stabellini wrote:
> Actually I am thinking that the default values should be in the
> emulators themselves. After all they are the part of the code that knows
> more about vuarts.
Can you expand what you mean by emulator? I was never expecting to have 
a fully emulated UART exposed to the guest (i.e read/write character 
support) except for a PL011.
The current vuart (see xen/arch/arm/vuart.c) is very simple but require 
someone to configure it. For DOM0, this is configured by the serial 
driver. For guest we need someone doing the same.
> So the toolstack would pass down all the info provided by the users to
> Xen. Xen would start the appropriate emulator, initializing anything not
> specifically configured by libxl to default values. No need for long
> lists of defaults in libxl.
>
>
> > If so, you will end up people asking to implement each of their UART (8250,
> > exynos, pl011...) in the toolstack. A user would have to pay attention whether
> > this model is supported or not by their toolstack.
> It is up to the maintainers to decide how many and which vuart should be
> configurable. libxl would have the capability of listing supported models
> of vuarts. Today libxl already does that for nics and vgas.
As we discussed recently, the goal of exposing the vuart is to let the 
guest write data not read without having to bring a full PV drivers.
Supporting multiple fully emulated UARTs would be very similarly to 
incorporate piece of QEMU code within Xen. I think we both well know 
what it means in term of security.
We have to emulate a PL011 because this is part of the VM spec. If you 
think that more kind of UART have to be emulated, then I would like to 
see real use case as nobody stepped up for that on the ML so far.
> > Lastly, the pl011 emulation needs to be easily enabled by any user without
> > requiring a knowledge on the guest memory layout (which is not stable BTW). By
> > default the layout is static, so what's the point to let the user configuring
> > it?
> This is my reasoning: people that request a vuart explicitly in the VM
> config file are people that are configuring an embedded system with
> non-Linux OSes because all others should be able to use the PV console
> effectively.
>
> In that case, to setup the system with the minimum amount of
> configuration and efforts, they might want to emulate one of the UARTs
> supported by their non-Linux OSes. The PL011 is pretty widespread, so it
> could be a good choice.
> Additionally they know the memory layout of all their VMs, so they can
> easily pick an unused address and configure it both in the VM config
> file and in their non-Linux OS.
Their non-Linux OSes will already need to be aware of the guest memory 
layout because it is fully static. They will use either device-tree/acpi 
or hardcoded the layout.
In both case, could you explain why they would want to configure the 
base address of the UART? It looks like to me it is more burden to chose 
the address. They would be fine to use the one in the static memory layout.
If they want a dynamic memory layout (host or custom [1]). Then it needs 
to be fully defined separately. I am not in favor of having a layout 
that can be half-static, half-dynamic as you are currently suggesting.
Note that I know this is currently the case for iomem parameters, but I 
found this ugly and there was no better solution. Let's not continue 
that way.
Regards,

[1] I can detail more on this if someone is interested.

--
Julien Grall

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