|
[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 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? 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 |