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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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?

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