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

[Julien Grall <julien.grall@arm.com>]

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@lists.xen.org
https://lists.xen.org/xen-devel