On 01/12/16 02:07, Stefano Stabellini wrote:
On Fri, 25 Nov 2016, Julien Grall wrote:
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.
Once we start having emulators, it is possible that we'll end up with
more than one. For example, we introduce the PL011 now, then in a couple
of years somebody wants to add ns16550 because it is the only one that
Windows 2019 supports. I am assuming that one way or another they'll run
in a low privilege mode (see other recent threads).
Well, if this Windows is meant to run on SBSA complaint server, it will
have to support either PL011 or SBSA (a subset of PL011).
If we are going to allow more kind of UART? Why don't we have a disk
emulator in Xen? How about a network emulator? Overall Windows 2019 may
not have PV drivers for the network and disk.
I really think we have to draw a line of what we are supporting. The
PL011 is mandatory by a specification. If the guest is not compliant
then it will have to use either PV drivers or having a device assigned.
The addition of a new emulator in upstream would need to be justified. I
don't want to end up bringing QEMU in Xen.
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.
I understand. For clarity, I'll call "PL011 emulator" the one that will
end up being used for DomUs, which might be based on, or different from,
xen/arch/arm/vuart.c. It doesn't exist yet.
The PL011 emulator should have default values for everything. Some of
these values could be configured by libxl, but none should be required
to be configured by libxl. The last thing we want is to disseminate
numbers and addresses in libxl. One of these parameters could be the
MMIO address, but it is just an example, we don't necessarily need to
support changing it. It could be a decent feature to have but I don't
think is important if we'll support configurable memory layouts soon.
This is what I have been suggested from the beginning :).
But in the case of baremetal application, we want to be able to do
logging only (i.e not reading). They will have a driver for the host
UART. It would be pointless and potentially difficult to emulate a full
UART here. This is where vuart come in place (see the use case mentioned
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
exynos, pl011...) in the toolstack. A user would have to pay attention
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.
Unfortunately we have to expect that the number of requests for
emulators will only increase going forward. We need to have a proper low
privilege mode to run them in, to avoid security issues in Xen.
See my answer above.
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
default the layout is static, so what's the point to let the user
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
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
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 ). 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.
I see, I was exactly thinking of iomem as a model :-)
My thinking is that some users might have half-hacked Xen and
half-hacked the guest OS to make their ideas of memory match.
This is very fragile because you cannot control where the memory banks,
gic regions are residing. Hence why I would like to push towards a fully
Naively, I am thinking that the ability to specify the uart address
would help, but maybe I am wrong. I do agree that a fully configurable
memory layout solves most problems.
Xen-devel mailing list