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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 1 Dec 2016, Julien Grall wrote:
> On 01/12/16 02:07, Stefano Stabellini wrote:
> > On Fri, 25 Nov 2016, Julien Grall wrote:
> > > Hi Stefano,
> 
> Hi,
> 
> > > 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).

I am not thinking about SBSA compliant OSes, that is the easy case :-)


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

Nobody wants to bring QEMU into Xen. To be pedantic we would be
bringing QEMU into xen.git, not into "Xen", but we don't want that
either.

Of course, any addition would need to be well justified, but at the same
time, I don't think we can rule out any emulator a priori.  We'll have
to evaluate the issue on a case by case basis. As usual, it is going to
be a trade-off between complexity, maintainability and use cases that it
enables. Everybody dislike QEMU on Xen on x86, but it enabled Windows XP
virtual machines back in the day. I might disagree with the way it was
done, but I wonder what would be of the Xen Project today if those
emullators hadn't been added in 2005.

Of course the fewer emulators, the better. I wouldn't accept an IDE
emulator in Xen on ARM today for example. However sometimes they are
unavoidable, that's why it is important to provide a safe execution
environment for them (meaning: not in Xen at EL2).

Today it is pretty much the same thing to add an emulator in the
hypervisor or in QEMU on x86. Somebody has to maintain the code no
matter where it lives and provide security support for it. Every QEMU
vulnerability ends up becoming a Xen vulnerability. In all honesty, it
is better to introduce them in QEMU so that at least the few people that
use stubdoms are less affected. In the future it is going to be similar
to introduce new emulators in xen.git at EL0/1 or in QEMU running
unprivileged in Dom0. This is to say that having emulators out of Xen
(or out of xen.git) is not necessarily an improvement if they are still
able to do exactly the same things, such as mapping any random page in
memory.


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

I was suggesting to kill two birds with one stone and just do PL011 for
DomUs (disabled by default, of course). Instead, you would keep the two
use cases separate? PL011 for VM spec guests and vuart for baremetal
apps? That's an option, but we would still need to feed back the logs
to xenconsoled.

How would you export the vuart in the VM config file? I am asking
because I think it would be simpler to have a single:

pl011=1/0, or uart="pl011"

rather than a vuart option that has a different meaning on different
platforms, because it is supposed to match the physical UART present.

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