[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])
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@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |