|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])
On 22.11.16 21:36, 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? > > 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. > > 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"] > > 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? I'm just curious - is it really have to be UART? can it be a PV TTY device(s)? Wouldn't it be better to avoid unneeded HW emulation and just provide "serial" function? _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |