[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Fri, 25 Nov 2016, Julien Grall wrote:
> 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.

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


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


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

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.


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

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.

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
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.