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

["Edgar E. Iglesias" <edgar.iglesias@gmail.com>]

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.

Cheers,
Edgar

> 
> 
> > For guest using static memory map (i.e the current approach), I would envision
> > to always emulate a PL011 (or at least giving this option) and not the
> > physical UART.
> > 
> > This has a better fit with the support of SBSA/VM Spec compliant guest and
> > still allow a user to do early debugging. Also, by always exposing the same
> > kind of UART, the user does not have to know what is the underlying platform
> > (e.g which UART is used).
> 
> Right

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


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