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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 22 Nov 2016, Julien Grall wrote:
> On 22/11/16 19:06, Stefano Stabellini wrote:
> > On Mon, 21 Nov 2016, Julien Grall wrote:
> > > On 21/11/2016 21:13, Edgar E. Iglesias wrote:
> > > > On Mon, Nov 21, 2016 at 01:01:15PM -0800, Stefano Stabellini wrote:
> > > > > On Mon, 21 Nov 2016, Edgar E. Iglesias wrote:
> > > > > > On Fri, Nov 18, 2016 at 10:58:42AM -0800, Stefano Stabellini wrote:
> > > > > > > On Thu, 17 Nov 2016, Julien Grall wrote:
> > > > > > > > Hi Stefano,
> > > > > > > > 
> > > > > > > > On 17/11/2016 11:26, Stefano Stabellini wrote:
> > > > > > > > > On Mon, 14 Nov 2016, Julien Grall wrote:
> > > > > > > > > > On 11/11/2016 13:55, Stefano Stabellini wrote:
> > > > > > > > > > > On Fri, 11 Nov 2016, Julien Grall wrote:
> > > > > > > > > > > > On 11/11/2016 02:24, Stefano Stabellini wrote:
> > > > > > > > > > > > > On Thu, 10 Nov 2016, Julien Grall wrote:
> > > > > > > > > > > > > > (CC Stefano and change the title)
> > > > > > > > > > > > > > On 10/11/16 12:13, casionwoo wrote:
> > > > > > > > > > > > > > > I’m pleased about your reply and you have a lot of
> > > > > > > > > > > > > > > code to
> > > > > > > > > > > > > > > clean-up.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > As you mentioned, It’s really huge to digest at
> > > > > > > > > > > > > > > once.
> > > > > > > > > > > > > > > Thank you
> > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > understanding me.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > And that’s why i need a small fix up and todo
> > > > > > > > > > > > > > > list.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I feel familiar with ARM and c language and
> > > > > > > > > > > > > > > there’s no
> > > > > > > > > > > > > > > specific
> > > > > > > > > > > > > > > area
> > > > > > > > > > > > > > > yet.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I think that i can find interesting area with
> > > > > > > > > > > > > > > following up the
> > > > > > > > > > > > > > > codes.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I’m looking forward to being stuck on Xen.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Then it would be easier for me to understand about
> > > > > > > > > > > > > > > Xen
> > > > > > > > > > > > > > > on ARM.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Please let me know the TODO and bug-fix lists.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Stefano, before giving a list of code clean-up, do
> > > > > > > > > > > > > > you
> > > > > > > > > > > > > > have any
> > > > > > > > > > > > > > small
> > > > > > > > > > > > > > TODO
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > ARM in mind?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > A simple task we talked about recently is to enable
> > > > > > > > > > > > > the
> > > > > > > > > > > > > vuart
> > > > > > > > > > > > > (xen/arch/arm/vuart.c) for all guests. At the moment
> > > > > > > > > > > > > it is
> > > > > > > > > > > > > only
> > > > > > > > > > > > > emulated
> > > > > > > > > > > > > for Dom0, but some guests, in particular BareMetal
> > > > > > > > > > > > > guests
> > > > > > > > > > > > > (https://en.wikipedia.org/wiki/BareMetal), would
> > > > > > > > > > > > > benefit
> > > > > > > > > > > > > from it.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > It would be best to introduce an option in libxl to
> > > > > > > > > > > > > explicitly
> > > > > > > > > > > > > enable/disable the vuart for DomUs. Something like
> > > > > > > > > > > > > vuart=1
> > > > > > > > > > > > > in the VM
> > > > > > > > > > > > > config file.
> > > > > > > > > > > > 
> > > > > > > > > > > > The vuart has not been enabled for DomU because it the
> > > > > > > > > > > > UART
> > > > > > > > > > > > region may
> > > > > > > > > > > > clash
> > > > > > > > > > > > with the guest memory layout (which is static).
> > > > > > > > > > > > 
> > > > > > > > > > > > I don't think this option should be available until we
> > > > > > > > > > > > allow
> > > > > > > > > > > > the guest
> > > > > > > > > > > > to
> > > > > > > > > > > > use
> > > > > > > > > > > > the same memory layout as the host (see e820_host
> > > > > > > > > > > > parameter
> > > > > > > > > > > > for x86).
> > > > > > > > > > > 
> > > > > > > > > > > Actually there is no reason for the vuart to use the same
> > > > > > > > > > > address as
> > > > > > > > > > > the physical uart on the platform, is there?
> > > > > > > > > > > In fact it doesn't even
> > > > > > > > > > > have to prentend to be the same uart as the one on the
> > > > > > > > > > > board,
> > > > > > > > > > > right?
> > > > > > > > > > > The vuart MMIO address could be completely configurable
> > > > > > > > > > > and
> > > > > > > > > > > independent
> > > > > > > > > > > from the one of the physical uart.
> > > > > > > > > > 
> > > > > > > > > > There is no reason to use the same information as the
> > > > > > > > > > physical
> > > > > > > > > > UART.
> > > > > > > > > > 
> > > > > > > > > > However, the vuart requires quite a few information (e.g
> > > > > > > > > > base
> > > > > > > > > > address,
> > > > > > > > > > offset
> > > > > > > > > > of different register... see vuart_info structure in
> > > > > > > > > > include/xen/serial.h
> > > > > > > > > > for
> > > > > > > > > > more details) in order to fully work.
> > > > > > > > > > 
> > > > > > > > > > IHMO this is a lot of works for the user to configure. I
> > > > > > > > > > would
> > > > > > > > > > much prefer
> > > > > > > > > > to
> > > > > > > > > > see a PL011 emulated at a specific base address and let the
> > > > > > > > > > user
> > > > > > > > > > select
> > > > > > > > > > whether he wants a UART to debug or not.
> > > > > > > > > 
> > > > > > > > > So you envision the configuration of the MMIO base address to
> > > > > > > > > be
> > > > > > > > > done as
> > > > > > > > > part of a new dynamic guest memory map?
> > > > > > > > 
> > > > > > > > For guest using dynamic memory map, I would expect to expose an
> > > > > > > > uncompleted
> > > > > > > > emulation of the physical UART (e.g it would only be possible to
> > > > > > > > write) at the
> > > > > > > > exact same address as on the host.
> > > > > > > 
> > > > > > > Why? Is this a requirement for baremetal guests?
> > > > > > > 
> > > > > > > I would have actually opted for always emulating a PL011 even for
> > > > > > > guests
> > > > > > > using a dynamic memory map (which of course one way or another
> > > > > > > need to
> > > > > > > be able to choose the address of the UART, the memory and the
> > > > > > > rest).
> > > > > > 
> > > > > > I guess it's not black and white but trying to reduce the gap
> > > > > > towards
> > > > > > being able to run unmodified SW for a given platform as a guest
> > > > > > would
> > > > > > be nice.
> > > > > > 
> > > > > > Some times things are quite relaxed and we can recompile the SW for
> > > > > > Xen,
> > > > > > add new drivers etc. Other times perhaps SW has been certified and
> > > > > > users
> > > > > > may not be able to change anything.
> > > > > > 
> > > > > > For apps where the UARTs are only used for console data, vuarts at
> > > > > > configurable locations would be nice IMO.
> > > > > 
> > > > > All right, so I take that same UART as baremetal is easier than always
> > > > > PL011?
> > > > 
> > > > I think so, yes.
> > > > 
> > > > To comply with the SBSA, depending on the guest, we'll probably need to
> > > > allow for optional emulation of pl011 though...
> > > > 
> > > > Having a flexible setup so that vm.cfgs can instantiate vuarts or
> > > > emulated
> > > > pl011 at specific addresses, that sounds good to me.
> > > 
> > > I am more in favor to have a different approach depending on the memory
> > > layout
> > > (static vs dynamic) of the guest.
> > > 
> > > Exposing the vuart to a guest with static memory layout is overly complex
> > > (you
> > > have a bunch information to configure) and it is much easier to require a
> > > guest using pl011 (implementing a small driver for it is very easy). Note
> > > that
> > > the emulation could just use the vuart for now. But the user would just
> > > have
> > > to say pl011 = true in the vm.cfg.
> > > 
> > > For the emulated pl011, I would not support user configuration (e.g
> > > address)
> > > when using the static memory layout for similar reason as above. Only
> > > dynamic
> > > layout could support an extend configuration. Even though, I am not
> > > convince
> > > of the usefulness of a pl011 for baremetal app (we are supposed to only
> > > emulate the hardware).
> > 
> > I disagree: I think we can provide a simple way to make it configurable
> > without drawbacks. Why stopping half-way?
> > 
> > vuart=["model=pl011,addr=0xf2000000"]
> > 
> > information not provided, default to sensible values. What's so bad
> > about this?
> 
> I am assuming that you expect the toolstack to parse the model and provides
> the correct information to Xen. Correct?

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.

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.


> Furthermore, you are making the example with a simple UART. For instance the
> 8250 also requires a left-shift to apply to the register offsets within the
> UART. This also implies the MMIO size of the UART can change.
> 
> You may also want to present a different value in the status register (see
> vuart.h) even with the same UART model.
> 
> Because of that, the only way to have a stable libxl ABI for the UART is:
> 
> vuart=["addr=0xdeadbeaf,data_off=0x4,status_off=0x10,status=0xa"]

I understand that all these parameters can be configurable, but maybe
they should not be configurable. Certainly it should not be required of
them to be configurable. We should provide flexibility, but without
making our lives too difficult.

BTW your example is of an xl VM config file line, not a libxl API or
hypercall ABI.


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

Does it make sense?

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