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

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

On Mon, Nov 21, 2016 at 09:24:27PM +0000, 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.

I see your points. I'll admit I was focusing on the dynamic case.


> 
> 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).
> 
> Regards,
> 
> -- 
> Julien Grall

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