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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 5 Dec 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 01/12/16 21:33, Stefano Stabellini wrote:
> > 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.
> 
> We have to factor in our decision that QEMU is been used by many people, which
> mean the code should be more exercised. In the case of Xen, some emulator may
> be used by very few people (think about TEE or a specific UART).

That's true, although not all parts of QEMUs are used as much as others.
For example I am pretty sure there is no security support for ARM
platforms and devices in QEMU today.


> I would require more unit tests (maybe in XTF) when a new emulator is added.
> Allowing us to check if the emulator is still functional.

Definitely true. It would be nice to have fuzzy testing too.


> > > > > 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?
> 
> We have to keep those use cases separated. We already went in lengthly
> discussion and you agreed on it. Anyway, I will summarize here.

Ops, sorry, after reading the rest of your email I realize that there
was a misunderstanding. Let me explain. I agree that keeping full PL011
emulation and small vuart emulation separate can be a good thing. I also
agree that those are two different use cases.

But I didn't realize that the vuart feature and the expose memory layout
feature were tightly connected for you. I would keep them independent.
In fact, vuart or PL011, I would make a new virtual uart option
available to any guests including the ones without host memory layout,
using an iomem style option. The new uart could be advertised as PL011
on device tree, while in fact only emulating part of it via vuart.c (of
course the fact that doesn't completely emulate a PL011 should be
clearly documented).

On the other hand, you would basically embedded the vuart option into the
host memory layout option and expose it as the same uart as the one on
the host, which of course changes from platform to platform.

Although I like the approach I suggested because I believe it gives
users more flexibility and is less unexpected, because the type of the
uart is well defined, I don't think this is an important decision. The
host memory layout feature is the important one to have and guests that
need a virtual uart will still be able to get one with full PL011
emulation one day. The end results are very similar. So I would leave it
to the contributor or, if you feel strongly about it, I'll leave it up
to you.


> You cannot assume if there will be a space in the layout for the
> PL011. Further, this guest will have a driver for the host UART and
> not the PL011.

I think these are reasonable expectations. If they are not, then you'd
be right.

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