Re: [Xen Question]

Re: [Xen Question]

[casionwoo]

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.


> 2016. 11. 10. 오후 8:17, Julien Grall <julien.grall@arm.com> 작성:
> 
> On 09/11/16 14:16, 유정우 wrote:
>> Hello, I'm a newbie in Xen. (Actually I have commited once)
> 
> Hello,
> 
> 
> In the future, can you CC xen-devel? So you can get more feedback from the community.
> 
>> I started to study about Xen on ARM.
>> 
>> As i watch the source codes, it's getting difficult.
> 
> I understand, lot of code to digest?
> 
>> 
>> So I thought that if i study with small bug fixs, it would be more
>> easier than just studing without anything.
> 
> Do you have a specific area you would be interested to look at it?
> 
>> I found only todo list about ARM in here
>> (https://wiki.xen.org/wiki/Xen_ARM_TODO)
>> 
>> but it looks like a big problem. So is there any small todo or bug list?
>> about ARM?
> 
> I have a lot of code clean-up in mind, would you be happy with that?
> 
>> --
>> JeungWoo, Yoo
> 
> -- 
> Julien Grall


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

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

[Julien Grall]

(CC Stefano and change the title)

Hello,

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?

Cheers,

>
>
>> 2016. 11. 10. 오후 8:17, Julien Grall <julien.grall@arm.com> 작성:
>>
>> On 09/11/16 14:16, 유정우 wrote:
>>> Hello, I'm a newbie in Xen. (Actually I have commited once)
>>
>> Hello,
>>
>>
>> In the future, can you CC xen-devel? So you can get more feedback from the community.
>>
>>> I started to study about Xen on ARM.
>>>
>>> As i watch the source codes, it's getting difficult.
>>
>> I understand, lot of code to digest?
>>
>>>
>>> So I thought that if i study with small bug fixs, it would be more
>>> easier than just studing without anything.
>>
>> Do you have a specific area you would be interested to look at it?
>>
>>> I found only todo list about ARM in here
>>> (https://wiki.xen.org/wiki/Xen_ARM_TODO)
>>>
>>> but it looks like a big problem. So is there any small todo or bug list?
>>> about ARM?
>>
>> I have a lot of code clean-up in mind, would you be happy with that?
>>
>>> --
>>> JeungWoo, Yoo
>>
>> --
>> Julien Grall
>

-- 
Julien Grall

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

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

[Stefano Stabellini]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1302 bytes --]

On Thu, 10 Nov 2016, Julien Grall wrote:
> (CC Stefano and change the title)
> 
> Hello,
> 
> 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.

BTW we should keep this up to date:

https://wiki.xenproject.org/wiki/Xen_ARM_TODO

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

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

[Julien Grall]

Hi Stefano,

On 11/11/2016 02:24, Stefano Stabellini wrote:
> On Thu, 10 Nov 2016, Julien Grall wrote:
>> (CC Stefano and change the title)
>>
>> Hello,
>>
>> 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).

>
> BTW we should keep this up to date:
>
> https://wiki.xenproject.org/wiki/Xen_ARM_TODO

You are right, although it might be better to use the bug tracker [1] to 
stay aligned with the rest of the hypervisor.

Note that I have got a list of TODO/bugs I track myself but never 
updated the wiki.

Cheers,

[1] https://bugs.xenproject.org/xen/

-- 
Julien Grall

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

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

[Edgar E. Iglesias]

On Fri, Nov 11, 2016 at 09:46:56AM +0000, Julien Grall wrote:
> Hi Stefano,
> 
> On 11/11/2016 02:24, Stefano Stabellini wrote:
> >On Thu, 10 Nov 2016, Julien Grall wrote:
> >>(CC Stefano and change the title)
> >>
> >>Hello,
> >>
> >>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).

Yes, we were thinking to give the mem layout one a try in 4.9 hopefully.

Another task that is not too huge is the one to allow Xen to map in
arbitrary memory regions as Normal Memory into domUs.
We discussed the possibility of having additional arch specific arguments
to the iomem settings.

This is for example useful to give DomU guests direct access to on chip
memories or to specific ranges of DRAM that may be needed to communicate
with devices.


> 
> >
> >BTW we should keep this up to date:
> >
> >https://wiki.xenproject.org/wiki/Xen_ARM_TODO
> 
> You are right, although it might be better to use the bug tracker [1] to
> stay aligned with the rest of the hypervisor.
> 
> Note that I have got a list of TODO/bugs I track myself but never updated
> the wiki.

Good idea, I'll add some stuff into that list!

Best regards,
Edgar



> 
> Cheers,
> 
> [1] https://bugs.xenproject.org/xen/
> 
> -- 
> Julien Grall
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

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

[Stefano Stabellini]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2675 bytes --]

On Fri, 11 Nov 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 11/11/2016 02:24, Stefano Stabellini wrote:
> > On Thu, 10 Nov 2016, Julien Grall wrote:
> > > (CC Stefano and change the title)
> > > 
> > > Hello,
> > > 
> > > 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.


> > BTW we should keep this up to date:
> > 
> > https://wiki.xenproject.org/wiki/Xen_ARM_TODO
> 
> You are right, although it might be better to use the bug tracker [1] to stay
> aligned with the rest of the hypervisor.
> 
> Note that I have got a list of TODO/bugs I track myself but never updated the
> wiki.

I agree that we should all use the same tool, but I didn't realize there
has been a decision on using the bug tracker for this. In fact it
doesn't seem to be much used at the moment.

Maybe we should start a good old bikeshedding thread with other
maintainers on what we should use.

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

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

[유정우]

[-- Attachment #1.1: Type: text/plain, Size: 3261 bytes --]

Thank you for your attention.

>From upper emails, https://bugs.xenproject.org/xen/ this is the small TODO
list, which i follow up right?



2016-11-12 1:59 GMT+09:00 Edgar E. Iglesias <edgar.iglesias@gmail.com>:

> On Fri, Nov 11, 2016 at 09:46:56AM +0000, Julien Grall wrote:
> > Hi Stefano,
> >
> > On 11/11/2016 02:24, Stefano Stabellini wrote:
> > >On Thu, 10 Nov 2016, Julien Grall wrote:
> > >>(CC Stefano and change the title)
> > >>
> > >>Hello,
> > >>
> > >>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).
>
> Yes, we were thinking to give the mem layout one a try in 4.9 hopefully.
>
> Another task that is not too huge is the one to allow Xen to map in
> arbitrary memory regions as Normal Memory into domUs.
> We discussed the possibility of having additional arch specific arguments
> to the iomem settings.
>
> This is for example useful to give DomU guests direct access to on chip
> memories or to specific ranges of DRAM that may be needed to communicate
> with devices.
>
>
> >
> > >
> > >BTW we should keep this up to date:
> > >
> > >https://wiki.xenproject.org/wiki/Xen_ARM_TODO
> >
> > You are right, although it might be better to use the bug tracker [1] to
> > stay aligned with the rest of the hypervisor.
> >
> > Note that I have got a list of TODO/bugs I track myself but never updated
> > the wiki.
>
> Good idea, I'll add some stuff into that list!
>
> Best regards,
> Edgar
>
>
>
> >
> > Cheers,
> >
> > [1] https://bugs.xenproject.org/xen/
> >
> > --
> > Julien Grall
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > https://lists.xen.org/xen-devel
>



-- 
JeungWoo, Yoo

[-- Attachment #1.2: Type: text/html, Size: 4997 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

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

[Julien Grall]

Hi Stefano,

On 11/11/2016 13:55, Stefano Stabellini wrote:
> On Fri, 11 Nov 2016, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 11/11/2016 02:24, Stefano Stabellini wrote:
>>> On Thu, 10 Nov 2016, Julien Grall wrote:
>>>> (CC Stefano and change the title)
>>>>
>>>> Hello,
>>>>
>>>> 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.

This would also be a start to be compliant with the VM System 
Specification (see [1]) that mandates to emulate a PL011.

>
>
>>> BTW we should keep this up to date:
>>>
>>> https://wiki.xenproject.org/wiki/Xen_ARM_TODO
>>
>> You are right, although it might be better to use the bug tracker [1] to stay
>> aligned with the rest of the hypervisor.
>>
>> Note that I have got a list of TODO/bugs I track myself but never updated the
>> wiki.
>
> I agree that we should all use the same tool, but I didn't realize there
> has been a decision on using the bug tracker for this. In fact it
> doesn't seem to be much used at the moment.

The bug tracker might be easier to update the status of feature and keep 
an history of the discussion.

>
> Maybe we should start a good old bikeshedding thread with other
> maintainers on what we should use.

I will let you kick a thread :).

Cheers,

[1] 
http://www.linaro.org/app/resources/WhitePaper/VMSystemSpecificationForARM-v2.0.pdf

-- 
Julien Grall

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

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

[Stefano Stabellini]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3021 bytes --]

On Mon, 14 Nov 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 11/11/2016 13:55, Stefano Stabellini wrote:
> > On Fri, 11 Nov 2016, Julien Grall wrote:
> > > Hi Stefano,
> > > 
> > > On 11/11/2016 02:24, Stefano Stabellini wrote:
> > > > On Thu, 10 Nov 2016, Julien Grall wrote:
> > > > > (CC Stefano and change the title)
> > > > > 
> > > > > Hello,
> > > > > 
> > > > > 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?

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

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

[Julien Grall]

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.

For guest using static memory map (i.e the current approach), I would 
envision to always emulate a PL011 (or at least giving this option) and 
not the physical UART.

This has a better fit with the support of SBSA/VM Spec compliant guest 
and still allow a user to do early debugging. Also, by always exposing 
the same kind of UART, the user does not have to know what is the 
underlying platform (e.g which UART is used).

Regards,

-- 
Julien Grall

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

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

[Stefano Stabellini]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4325 bytes --]

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).


> For guest using static memory map (i.e the current approach), I would envision
> to always emulate a PL011 (or at least giving this option) and not the
> physical UART.
> 
> This has a better fit with the support of SBSA/VM Spec compliant guest and
> still allow a user to do early debugging. Also, by always exposing the same
> kind of UART, the user does not have to know what is the underlying platform
> (e.g which UART is used).

Right

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

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

[Edgar E. Iglesias]

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.

Cheers,
Edgar

> 
> 
> > For guest using static memory map (i.e the current approach), I would envision
> > to always emulate a PL011 (or at least giving this option) and not the
> > physical UART.
> > 
> > This has a better fit with the support of SBSA/VM Spec compliant guest and
> > still allow a user to do early debugging. Also, by always exposing the same
> > kind of UART, the user does not have to know what is the underlying platform
> > (e.g which UART is used).
> 
> Right

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


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

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

[Stefano Stabellini]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4900 bytes --]

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?

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

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

[Edgar E. Iglesias]

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.

Cheers,
Edgar



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

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

[Julien Grall]

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).

Regards,

-- 
Julien Grall

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

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

[Edgar E. Iglesias]

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

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

[Stefano Stabellini]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 7555 bytes --]

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?

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

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

[Julien Grall]

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

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

[Artem Mygaiev]

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

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

[Julien Grall]

Hello Artem,

On 23/11/16 15:10, Artem Mygaiev wrote:
> On 22.11.16 21:36, Julien Grall wrote:
> 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?

There is a couple of usecase where we cannot use PV console:
	- Running unmodified baremetal application as guest. Those applications 
will not have PV driver.
	- Guest compliant with the VM system specification for ARM [1]. A pl011 
is required.

Do you have any concern with this?

Regards,

[1] 
http://www.linaro.org/app/resources/WhitePaper/VMSystemSpecificationForARM-v2.0.pdf

-- 
Julien Grall

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

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

[Artem Mygaiev]

On 23.11.16 17:19, Julien Grall wrote:
> There is a couple of usecase where we cannot use PV console:
>     - Running unmodified baremetal application as guest. Those
> applications will not have PV driver.
Well, I somehow missed that requirement is to run *unmodified*
applications... I think it will be pretty hard to provide all the HW
infrastructure expected and UARTs as I know them have all possible
issues & workarounds.
>     - Guest compliant with the VM system specification for ARM [1]. A
> pl011 is required.
Yes, indeed, a subset of PL011 registers is required, unfortunately I
was not familiar with that spec, thanks.

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

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

[Edgar E. Iglesias]

On Wed, Nov 23, 2016 at 06:26:06PM +0200, Artem Mygaiev wrote:
> On 23.11.16 17:19, Julien Grall wrote:
> > There is a couple of usecase where we cannot use PV console:
> >     - Running unmodified baremetal application as guest. Those
> > applications will not have PV driver.
> Well, I somehow missed that requirement is to run *unmodified*
> applications... I think it will be pretty hard to provide all the HW
> infrastructure expected and UARTs as I know them have all possible
> issues & workarounds.

Hi Artem,

The way I see this is not for Xen to provide support for any HW for any
platform on all platforms.

The way I see it is that on a given platform, for example the ZynqMP.
You can run Xen as a partitioning Hypervisor essentially using device
passthrough to assign various real HW devices to each VM.

The various guests can run unmodified because they each see a subset
of the platform.

It is useful to have vuarts that go are shared into a single one.

Cheers,
Edgar



> >     - Guest compliant with the VM system specification for ARM [1]. A
> > pl011 is required.
> Yes, indeed, a subset of PL011 registers is required, unfortunately I
> was not familiar with that spec, thanks.

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

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

[Julien Grall]

Hi Edgar,

On 23/11/16 16:38, Edgar E. Iglesias wrote:
> On Wed, Nov 23, 2016 at 06:26:06PM +0200, Artem Mygaiev wrote:
>> On 23.11.16 17:19, Julien Grall wrote:
>>> There is a couple of usecase where we cannot use PV console:
>>>     - Running unmodified baremetal application as guest. Those
>>> applications will not have PV driver.
>> Well, I somehow missed that requirement is to run *unmodified*
>> applications... I think it will be pretty hard to provide all the HW
>> infrastructure expected and UARTs as I know them have all possible
>> issues & workarounds.
>
> Hi Artem,
>
> The way I see this is not for Xen to provide support for any HW for any
> platform on all platforms.
>
> The way I see it is that on a given platform, for example the ZynqMP.
> You can run Xen as a partitioning Hypervisor essentially using device
> passthrough to assign various real HW devices to each VM.
>
> The various guests can run unmodified because they each see a subset
> of the platform.
>
> It is useful to have vuarts that go are shared into a single one.

To expand on the vuart, this is a small emulator to handle write from a 
guest. This was originally designed to handle DOM0 early console that is 
hardcoded on ARM32.

As mentioned by Artem, read would be more complex as it will mean 
per-UART emulator. IIRC, this would not be a problem for you, right?

Regards,

-- 
Julien Grall

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

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

[Stefano Stabellini]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 11587 bytes --]

On Tue, 22 Nov 2016, 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?

Actually I am thinking that the default values should be in the
emulators themselves. After all they are the part of the code that knows
more about vuarts.

So the toolstack would pass down all the info provided by the users to
Xen. Xen would start the appropriate emulator, initializing anything not
specifically configured by libxl to default values. No need for long
lists of defaults in libxl.


> 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.

It is up to the maintainers to decide how many and which vuart should be
configurable. libxl would have the capability of listing supported models
of vuarts. Today libxl already does that for nics and vgas.


> 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"]

I understand that all these parameters can be configurable, but maybe
they should not be configurable. Certainly it should not be required of
them to be configurable. We should provide flexibility, but without
making our lives too difficult.

BTW your example is of an xl VM config file line, not a libxl API or
hypercall ABI.


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

This is my reasoning: people that request a vuart explicitly in the VM
config file are people that are configuring an embedded system with
non-Linux OSes because all others should be able to use the PV console
effectively.

In that case, to setup the system with the minimum amount of
configuration and efforts, they might want to emulate one of the UARTs
supported by their non-Linux OSes. The PL011 is pretty widespread, so it
could be a good choice.

Additionally they know the memory layout of all their VMs, so they can
easily pick an unused address and configure it both in the VM config
file and in their non-Linux OS.

Does it make sense?

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

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

[Edgar E. Iglesias]

On Wed, Nov 23, 2016 at 06:32:41PM +0000, Julien Grall wrote:
> Hi Edgar,
> 
> On 23/11/16 16:38, Edgar E. Iglesias wrote:
> >On Wed, Nov 23, 2016 at 06:26:06PM +0200, Artem Mygaiev wrote:
> >>On 23.11.16 17:19, Julien Grall wrote:
> >>>There is a couple of usecase where we cannot use PV console:
> >>>    - Running unmodified baremetal application as guest. Those
> >>>applications will not have PV driver.
> >>Well, I somehow missed that requirement is to run *unmodified*
> >>applications... I think it will be pretty hard to provide all the HW
> >>infrastructure expected and UARTs as I know them have all possible
> >>issues & workarounds.
> >
> >Hi Artem,
> >
> >The way I see this is not for Xen to provide support for any HW for any
> >platform on all platforms.
> >
> >The way I see it is that on a given platform, for example the ZynqMP.
> >You can run Xen as a partitioning Hypervisor essentially using device
> >passthrough to assign various real HW devices to each VM.
> >
> >The various guests can run unmodified because they each see a subset
> >of the platform.
> >
> >It is useful to have vuarts that go are shared into a single one.
> 
> To expand on the vuart, this is a small emulator to handle write from a
> guest. This was originally designed to handle DOM0 early console that is
> hardcoded on ARM32.
> 
> As mentioned by Artem, read would be more complex as it will mean per-UART
> emulator. IIRC, this would not be a problem for you, right?

Hi Julien,

Right, we wouldn't want to use vuarts for reading.

In our case, I was thinking that guests that need input from serial ports
or that require specific BAUD rates will have to be assigned one of the
UARTs.

For guests that just want to output informative log messages onto the
UART, we can use vuarts.

Best regards,
Edgar

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

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

[Julien Grall]

Hi Stefano,

On 23/11/16 19:55, Stefano Stabellini wrote:
> Actually I am thinking that the default values should be in the
> emulators themselves. After all they are the part of the code that knows
> more about vuarts.

Can you expand what you mean by emulator? I was never expecting to have 
a fully emulated UART exposed to the guest (i.e read/write character 
support) except for a PL011.

The current vuart (see xen/arch/arm/vuart.c) is very simple but require 
someone to configure it. For DOM0, this is configured by the serial 
driver. For guest we need someone doing the same.

> So the toolstack would pass down all the info provided by the users to
> Xen. Xen would start the appropriate emulator, initializing anything not
> specifically configured by libxl to default values. No need for long
> lists of defaults in libxl.
>
>
>> 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.
>
> It is up to the maintainers to decide how many and which vuart should be
> configurable. libxl would have the capability of listing supported models
> of vuarts. Today libxl already does that for nics and vgas.

As we discussed recently, the goal of exposing the vuart is to let the 
guest write data not read without having to bring a full PV drivers.

Supporting multiple fully emulated UARTs would be very similarly to 
incorporate piece of QEMU code within Xen. I think we both well know 
what it means in term of security.

We have to emulate a PL011 because this is part of the VM spec. If you 
think that more kind of UART have to be emulated, then I would like to 
see real use case as nobody stepped up for that on the ML so far.

>> 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?
>
> This is my reasoning: people that request a vuart explicitly in the VM
> config file are people that are configuring an embedded system with
> non-Linux OSes because all others should be able to use the PV console
> effectively.
>
> In that case, to setup the system with the minimum amount of
> configuration and efforts, they might want to emulate one of the UARTs
> supported by their non-Linux OSes. The PL011 is pretty widespread, so it
> could be a good choice.
> Additionally they know the memory layout of all their VMs, so they can
> easily pick an unused address and configure it both in the VM config
> file and in their non-Linux OS.

Their non-Linux OSes will already need to be aware of the guest memory 
layout because it is fully static. They will use either device-tree/acpi 
or hardcoded the layout.

In both case, could you explain why they would want to configure the 
base address of the UART? It looks like to me it is more burden to chose 
the address. They would be fine to use the one in the static memory layout.

If they want a dynamic memory layout (host or custom [1]). Then it needs 
to be fully defined separately. I am not in favor of having a layout 
that can be half-static, half-dynamic as you are currently suggesting.

Note that I know this is currently the case for iomem parameters, but I 
found this ugly and there was no better solution. Let's not continue 
that way.

Regards,

[1] I can detail more on this if someone is interested.

-- 
Julien Grall

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

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

[Stefano Stabellini]

On Fri, 25 Nov 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 23/11/16 19:55, Stefano Stabellini wrote:
> > Actually I am thinking that the default values should be in the
> > emulators themselves. After all they are the part of the code that knows
> > more about vuarts.
> 
> Can you expand what you mean by emulator? I was never expecting to have a
> fully emulated UART exposed to the guest (i.e read/write character support)
> except for a PL011.

Once we start having emulators, it is possible that we'll end up with
more than one. For example, we introduce the PL011 now, then in a couple
of years somebody wants to add ns16550 because it is the only one that
Windows 2019 supports. I am assuming that one way or another they'll run
in a low privilege mode (see other recent threads).


> The current vuart (see xen/arch/arm/vuart.c) is very simple but require
> someone to configure it. For DOM0, this is configured by the serial driver.
> For guest we need someone doing the same.

I understand. For clarity, I'll call "PL011 emulator" the one that will
end up being used for DomUs, which might be based on, or different from,
xen/arch/arm/vuart.c. It doesn't exist yet.

The PL011 emulator should have default values for everything. Some of
these values could be configured by libxl, but none should be required
to be configured by libxl. The last thing we want is to disseminate
numbers and addresses in libxl. One of these parameters could be the
MMIO address, but it is just an example, we don't necessarily need to
support changing it. It could be a decent feature to have but I don't
think is important if we'll support configurable memory layouts soon.


> > So the toolstack would pass down all the info provided by the users to
> > Xen. Xen would start the appropriate emulator, initializing anything not
> > specifically configured by libxl to default values. No need for long
> > lists of defaults in libxl.
> > 
> > 
> > > 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.
> > 
> > It is up to the maintainers to decide how many and which vuart should be
> > configurable. libxl would have the capability of listing supported models
> > of vuarts. Today libxl already does that for nics and vgas.
> 
> As we discussed recently, the goal of exposing the vuart is to let the guest
> write data not read without having to bring a full PV drivers.
> 
> Supporting multiple fully emulated UARTs would be very similarly to
> incorporate piece of QEMU code within Xen. I think we both well know what it
> means in term of security.
> 
> We have to emulate a PL011 because this is part of the VM spec. If you think
> that more kind of UART have to be emulated, then I would like to see real use
> case as nobody stepped up for that on the ML so far.

Unfortunately we have to expect that the number of requests for
emulators will only increase going forward. We need to have a proper low
privilege mode to run them in, to avoid security issues in Xen.


> > > 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?
> > 
> > This is my reasoning: people that request a vuart explicitly in the VM
> > config file are people that are configuring an embedded system with
> > non-Linux OSes because all others should be able to use the PV console
> > effectively.
> > 
> > In that case, to setup the system with the minimum amount of
> > configuration and efforts, they might want to emulate one of the UARTs
> > supported by their non-Linux OSes. The PL011 is pretty widespread, so it
> > could be a good choice.
> > Additionally they know the memory layout of all their VMs, so they can
> > easily pick an unused address and configure it both in the VM config
> > file and in their non-Linux OS.
> 
> Their non-Linux OSes will already need to be aware of the guest memory layout
> because it is fully static. They will use either device-tree/acpi or hardcoded
> the layout.
> 
> In both case, could you explain why they would want to configure the base
> address of the UART? It looks like to me it is more burden to chose the
> address. They would be fine to use the one in the static memory layout.
> 
> If they want a dynamic memory layout (host or custom [1]). Then it needs to be
> fully defined separately. I am not in favor of having a layout that can be
> half-static, half-dynamic as you are currently suggesting.
> 
> Note that I know this is currently the case for iomem parameters, but I found
> this ugly and there was no better solution. Let's not continue that way.

I see, I was exactly thinking of iomem as a model :-)

My thinking is that some users might have half-hacked Xen and
half-hacked the guest OS to make their ideas of memory match.

Naively, I am thinking that the ability to specify the uart address
would help, but maybe I am wrong. I do agree that a fully configurable
memory layout solves most problems.

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

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

[Julien Grall]

On 01/12/16 02:07, Stefano Stabellini wrote:
> On Fri, 25 Nov 2016, Julien Grall wrote:
>> Hi Stefano,

Hi,

>> On 23/11/16 19:55, Stefano Stabellini wrote:
>>> Actually I am thinking that the default values should be in the
>>> emulators themselves. After all they are the part of the code that knows
>>> more about vuarts.
>>
>> Can you expand what you mean by emulator? I was never expecting to have a
>> fully emulated UART exposed to the guest (i.e read/write character support)
>> except for a PL011.
>
> Once we start having emulators, it is possible that we'll end up with
> more than one. For example, we introduce the PL011 now, then in a couple
> of years somebody wants to add ns16550 because it is the only one that
> Windows 2019 supports. I am assuming that one way or another they'll run
> in a low privilege mode (see other recent threads).

Well, if this Windows is meant to run on SBSA complaint server, it will 
have to support either PL011 or SBSA (a subset of PL011).

If we are going to allow more kind of UART? Why don't we have a disk 
emulator in Xen? How about a network emulator? Overall Windows 2019 may 
not have PV drivers for the network and disk.

I really think we have to draw a line of what we are supporting. The 
PL011 is mandatory by a specification. If the guest is not compliant 
then it will have to use either PV drivers or having a device assigned.

The addition of a new emulator in upstream would need to be justified. I 
don't want to end up bringing QEMU in Xen.

>> The current vuart (see xen/arch/arm/vuart.c) is very simple but require
>> someone to configure it. For DOM0, this is configured by the serial driver.
>> For guest we need someone doing the same.
>
> I understand. For clarity, I'll call "PL011 emulator" the one that will
> end up being used for DomUs, which might be based on, or different from,
> xen/arch/arm/vuart.c. It doesn't exist yet.
>
> The PL011 emulator should have default values for everything. Some of
> these values could be configured by libxl, but none should be required
> to be configured by libxl. The last thing we want is to disseminate
> numbers and addresses in libxl. One of these parameters could be the
> MMIO address, but it is just an example, we don't necessarily need to
> support changing it. It could be a decent feature to have but I don't
> think is important if we'll support configurable memory layouts soon.

This is what I have been suggested from the beginning :).

But in the case of baremetal application, we want to be able to do 
logging only (i.e not reading). They will have a driver for the host 
UART. It would be pointless and potentially difficult to emulate a full 
UART here. This is where vuart come in place (see the use case mentioned 
by Edgar).

>>> So the toolstack would pass down all the info provided by the users to
>>> Xen. Xen would start the appropriate emulator, initializing anything not
>>> specifically configured by libxl to default values. No need for long
>>> lists of defaults in libxl.
>>>
>>>
>>>> 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.
>>>
>>> It is up to the maintainers to decide how many and which vuart should be
>>> configurable. libxl would have the capability of listing supported models
>>> of vuarts. Today libxl already does that for nics and vgas.
>>
>> As we discussed recently, the goal of exposing the vuart is to let the guest
>> write data not read without having to bring a full PV drivers.
>>
>> Supporting multiple fully emulated UARTs would be very similarly to
>> incorporate piece of QEMU code within Xen. I think we both well know what it
>> means in term of security.
>>
>> We have to emulate a PL011 because this is part of the VM spec. If you think
>> that more kind of UART have to be emulated, then I would like to see real use
>> case as nobody stepped up for that on the ML so far.
>
> Unfortunately we have to expect that the number of requests for
> emulators will only increase going forward. We need to have a proper low
> privilege mode to run them in, to avoid security issues in Xen.

See my answer above.

>
>
>>>> 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?
>>>
>>> This is my reasoning: people that request a vuart explicitly in the VM
>>> config file are people that are configuring an embedded system with
>>> non-Linux OSes because all others should be able to use the PV console
>>> effectively.
>>>
>>> In that case, to setup the system with the minimum amount of
>>> configuration and efforts, they might want to emulate one of the UARTs
>>> supported by their non-Linux OSes. The PL011 is pretty widespread, so it
>>> could be a good choice.
>>> Additionally they know the memory layout of all their VMs, so they can
>>> easily pick an unused address and configure it both in the VM config
>>> file and in their non-Linux OS.
>>
>> Their non-Linux OSes will already need to be aware of the guest memory layout
>> because it is fully static. They will use either device-tree/acpi or hardcoded
>> the layout.
>>
>> In both case, could you explain why they would want to configure the base
>> address of the UART? It looks like to me it is more burden to chose the
>> address. They would be fine to use the one in the static memory layout.
>>
>> If they want a dynamic memory layout (host or custom [1]). Then it needs to be
>> fully defined separately. I am not in favor of having a layout that can be
>> half-static, half-dynamic as you are currently suggesting.
>>
>> Note that I know this is currently the case for iomem parameters, but I found
>> this ugly and there was no better solution. Let's not continue that way.
>
> I see, I was exactly thinking of iomem as a model :-)
>
> My thinking is that some users might have half-hacked Xen and
> half-hacked the guest OS to make their ideas of memory match.

This is very fragile because you cannot control where the memory banks, 
gic regions are residing. Hence why I would like to push towards a fully 
dynamic layout.

>
> Naively, I am thinking that the ability to specify the uart address
> would help, but maybe I am wrong. I do agree that a fully configurable
> memory layout solves most problems.

Regards,

-- 
Julien Grall

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

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

[Stefano Stabellini]

On Thu, 1 Dec 2016, Julien Grall wrote:
> On 01/12/16 02:07, Stefano Stabellini wrote:
> > On Fri, 25 Nov 2016, Julien Grall wrote:
> > > Hi Stefano,
> 
> Hi,
> 
> > > On 23/11/16 19:55, Stefano Stabellini wrote:
> > > > Actually I am thinking that the default values should be in the
> > > > emulators themselves. After all they are the part of the code that knows
> > > > more about vuarts.
> > > 
> > > Can you expand what you mean by emulator? I was never expecting to have a
> > > fully emulated UART exposed to the guest (i.e read/write character
> > > support)
> > > except for a PL011.
> > 
> > Once we start having emulators, it is possible that we'll end up with
> > more than one. For example, we introduce the PL011 now, then in a couple
> > of years somebody wants to add ns16550 because it is the only one that
> > Windows 2019 supports. I am assuming that one way or another they'll run
> > in a low privilege mode (see other recent threads).
> 
> Well, if this Windows is meant to run on SBSA complaint server, it will have
> to support either PL011 or SBSA (a subset of PL011).

I am not thinking about SBSA compliant OSes, that is the easy case :-)


> If we are going to allow more kind of UART? Why don't we have a disk emulator
> in Xen? How about a network emulator? Overall Windows 2019 may not have PV
> drivers for the network and disk.
> 
> I really think we have to draw a line of what we are supporting. The PL011 is
> mandatory by a specification. If the guest is not compliant then it will have
> to use either PV drivers or having a device assigned.
> 
> The addition of a new emulator in upstream would need to be justified. I don't
> want to end up bringing QEMU in Xen.

Nobody wants to bring QEMU into Xen. To be pedantic we would be
bringing QEMU into xen.git, not into "Xen", but we don't want that
either.

Of course, any addition would need to be well justified, but at the same
time, I don't think we can rule out any emulator a priori.  We'll have
to evaluate the issue on a case by case basis. As usual, it is going to
be a trade-off between complexity, maintainability and use cases that it
enables. Everybody dislike QEMU on Xen on x86, but it enabled Windows XP
virtual machines back in the day. I might disagree with the way it was
done, but I wonder what would be of the Xen Project today if those
emullators hadn't been added in 2005.

Of course the fewer emulators, the better. I wouldn't accept an IDE
emulator in Xen on ARM today for example. However sometimes they are
unavoidable, that's why it is important to provide a safe execution
environment for them (meaning: not in Xen at EL2).

Today it is pretty much the same thing to add an emulator in the
hypervisor or in QEMU on x86. Somebody has to maintain the code no
matter where it lives and provide security support for it. Every QEMU
vulnerability ends up becoming a Xen vulnerability. In all honesty, it
is better to introduce them in QEMU so that at least the few people that
use stubdoms are less affected. In the future it is going to be similar
to introduce new emulators in xen.git at EL0/1 or in QEMU running
unprivileged in Dom0. This is to say that having emulators out of Xen
(or out of xen.git) is not necessarily an improvement if they are still
able to do exactly the same things, such as mapping any random page in
memory.


> > > The current vuart (see xen/arch/arm/vuart.c) is very simple but require
> > > someone to configure it. For DOM0, this is configured by the serial
> > > driver.
> > > For guest we need someone doing the same.
> > 
> > I understand. For clarity, I'll call "PL011 emulator" the one that will
> > end up being used for DomUs, which might be based on, or different from,
> > xen/arch/arm/vuart.c. It doesn't exist yet.
> > 
> > The PL011 emulator should have default values for everything. Some of
> > these values could be configured by libxl, but none should be required
> > to be configured by libxl. The last thing we want is to disseminate
> > numbers and addresses in libxl. One of these parameters could be the
> > MMIO address, but it is just an example, we don't necessarily need to
> > support changing it. It could be a decent feature to have but I don't
> > think is important if we'll support configurable memory layouts soon.
> 
> This is what I have been suggested from the beginning :).
> 
> But in the case of baremetal application, we want to be able to do logging
> only (i.e not reading). They will have a driver for the host UART. It would be
> pointless and potentially difficult to emulate a full UART here. This is where
> vuart come in place (see the use case mentioned by Edgar).

I was suggesting to kill two birds with one stone and just do PL011 for
DomUs (disabled by default, of course). Instead, you would keep the two
use cases separate? PL011 for VM spec guests and vuart for baremetal
apps? That's an option, but we would still need to feed back the logs
to xenconsoled.

How would you export the vuart in the VM config file? I am asking
because I think it would be simpler to have a single:

pl011=1/0, or uart="pl011"

rather than a vuart option that has a different meaning on different
platforms, because it is supposed to match the physical UART present.

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

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

[Julien Grall]

Hi Stefano,

On 01/12/16 21:33, Stefano Stabellini wrote:
> On Thu, 1 Dec 2016, Julien Grall wrote:
>> On 01/12/16 02:07, Stefano Stabellini wrote:
>>> On Fri, 25 Nov 2016, Julien Grall wrote:
>>>> Hi Stefano,
>>
>> Hi,
>>
>>>> On 23/11/16 19:55, Stefano Stabellini wrote:
>>>>> Actually I am thinking that the default values should be in the
>>>>> emulators themselves. After all they are the part of the code that knows
>>>>> more about vuarts.
>>>>
>>>> Can you expand what you mean by emulator? I was never expecting to have a
>>>> fully emulated UART exposed to the guest (i.e read/write character
>>>> support)
>>>> except for a PL011.
>>>
>>> Once we start having emulators, it is possible that we'll end up with
>>> more than one. For example, we introduce the PL011 now, then in a couple
>>> of years somebody wants to add ns16550 because it is the only one that
>>> Windows 2019 supports. I am assuming that one way or another they'll run
>>> in a low privilege mode (see other recent threads).
>>
>> Well, if this Windows is meant to run on SBSA complaint server, it will have
>> to support either PL011 or SBSA (a subset of PL011).
>
> I am not thinking about SBSA compliant OSes, that is the easy case :-)
>> If we are going to allow more kind of UART? Why don't we have a disk emulator
>> in Xen? How about a network emulator? Overall Windows 2019 may not have PV
>> drivers for the network and disk.
>>
>> I really think we have to draw a line of what we are supporting. The PL011 is
>> mandatory by a specification. If the guest is not compliant then it will have
>> to use either PV drivers or having a device assigned.
>>
>> The addition of a new emulator in upstream would need to be justified. I don't
>> want to end up bringing QEMU in Xen.
>
> Nobody wants to bring QEMU into Xen. To be pedantic we would be
> bringing QEMU into xen.git, not into "Xen", but we don't want that
> either.
>
> Of course, any addition would need to be well justified, but at the same
> time, I don't think we can rule out any emulator a priori.  We'll have
> to evaluate the issue on a case by case basis. As usual, it is going to
> be a trade-off between complexity, maintainability and use cases that it
> enables. Everybody dislike QEMU on Xen on x86, but it enabled Windows XP
> virtual machines back in the day. I might disagree with the way it was
> done, but I wonder what would be of the Xen Project today if those
> emullators hadn't been added in 2005.
>
> Of course the fewer emulators, the better. I wouldn't accept an IDE
> emulator in Xen on ARM today for example. However sometimes they are
> unavoidable, that's why it is important to provide a safe execution
> environment for them (meaning: not in Xen at EL2).
>
> Today it is pretty much the same thing to add an emulator in the
> hypervisor or in QEMU on x86. Somebody has to maintain the code no
> matter where it lives and provide security support for it. Every QEMU
> vulnerability ends up becoming a Xen vulnerability. In all honesty, it
> is better to introduce them in QEMU so that at least the few people that
> use stubdoms are less affected. In the future it is going to be similar
> to introduce new emulators in xen.git at EL0/1 or in QEMU running
> unprivileged in Dom0. This is to say that having emulators out of Xen
> (or out of xen.git) is not necessarily an improvement if they are still
> able to do exactly the same things, such as mapping any random page in
> memory.

We have to factor in our decision that QEMU is been used by many people, 
which mean the code should be more exercised. In the case of Xen, some 
emulator may be used by very few people (think about TEE or a specific 
UART).

I would require more unit tests (maybe in XTF) when a new emulator is 
added. Allowing us to check if the emulator is still functional.

>
>
>>>> The current vuart (see xen/arch/arm/vuart.c) is very simple but require
>>>> someone to configure it. For DOM0, this is configured by the serial
>>>> driver.
>>>> For guest we need someone doing the same.
>>>
>>> I understand. For clarity, I'll call "PL011 emulator" the one that will
>>> end up being used for DomUs, which might be based on, or different from,
>>> xen/arch/arm/vuart.c. It doesn't exist yet.
>>>
>>> The PL011 emulator should have default values for everything. Some of
>>> these values could be configured by libxl, but none should be required
>>> to be configured by libxl. The last thing we want is to disseminate
>>> numbers and addresses in libxl. One of these parameters could be the
>>> MMIO address, but it is just an example, we don't necessarily need to
>>> support changing it. It could be a decent feature to have but I don't
>>> think is important if we'll support configurable memory layouts soon.
>>
>> This is what I have been suggested from the beginning :).
>>
>> But in the case of baremetal application, we want to be able to do logging
>> only (i.e not reading). They will have a driver for the host UART. It would be
>> pointless and potentially difficult to emulate a full UART here. This is where
>> vuart come in place (see the use case mentioned by Edgar).
>
> I was suggesting to kill two birds with one stone and just do PL011 for
> DomUs (disabled by default, of course). Instead, you would keep the two
> use cases separate? PL011 for VM spec guests and vuart for baremetal
> apps?

We have to keep those use cases separated. We already went in lengthly 
discussion and you agreed on it. Anyway, I will summarize here.

In the case of bare metal application, the guest will use the host 
memory layout as the hypervisor would be used as an abstraction. You 
cannot assume if there will be a space in the layout for the PL011. 
Further, this guest will have a driver for the host UART and not the 
PL011. I expect the guest will mainly use the UART for logging, and this 
is very easy to expose the vuart without much change.

> That's an option, but we would still need to feed back the logs
> to xenconsoled.

Agreed.

>
> How would you export the vuart in the VM config file? I am asking
> because I think it would be simpler to have a single:
>
> pl011=1/0, or uart="pl011"
>
> rather than a vuart option that has a different meaning on different
> platforms, because it is supposed to match the physical UART present.

I would expect the vuart to be automatically exposed when use the host 
memory layout. So pl011=1/0 would be fine by me.

Regards,

-- 
Julien Grall

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

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

[Stefano Stabellini]

On Mon, 5 Dec 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 01/12/16 21:33, Stefano Stabellini wrote:
> > On Thu, 1 Dec 2016, Julien Grall wrote:
> > > On 01/12/16 02:07, Stefano Stabellini wrote:
> > > > On Fri, 25 Nov 2016, Julien Grall wrote:
> > > > > Hi Stefano,
> > > 
> > > Hi,
> > > 
> > > > > On 23/11/16 19:55, Stefano Stabellini wrote:
> > > > > > Actually I am thinking that the default values should be in the
> > > > > > emulators themselves. After all they are the part of the code that
> > > > > > knows
> > > > > > more about vuarts.
> > > > > 
> > > > > Can you expand what you mean by emulator? I was never expecting to
> > > > > have a
> > > > > fully emulated UART exposed to the guest (i.e read/write character
> > > > > support)
> > > > > except for a PL011.
> > > > 
> > > > Once we start having emulators, it is possible that we'll end up with
> > > > more than one. For example, we introduce the PL011 now, then in a couple
> > > > of years somebody wants to add ns16550 because it is the only one that
> > > > Windows 2019 supports. I am assuming that one way or another they'll run
> > > > in a low privilege mode (see other recent threads).
> > > 
> > > Well, if this Windows is meant to run on SBSA complaint server, it will
> > > have
> > > to support either PL011 or SBSA (a subset of PL011).
> > 
> > I am not thinking about SBSA compliant OSes, that is the easy case :-)
> > > If we are going to allow more kind of UART? Why don't we have a disk
> > > emulator
> > > in Xen? How about a network emulator? Overall Windows 2019 may not have PV
> > > drivers for the network and disk.
> > > 
> > > I really think we have to draw a line of what we are supporting. The PL011
> > > is
> > > mandatory by a specification. If the guest is not compliant then it will
> > > have
> > > to use either PV drivers or having a device assigned.
> > > 
> > > The addition of a new emulator in upstream would need to be justified. I
> > > don't
> > > want to end up bringing QEMU in Xen.
> > 
> > Nobody wants to bring QEMU into Xen. To be pedantic we would be
> > bringing QEMU into xen.git, not into "Xen", but we don't want that
> > either.
> > 
> > Of course, any addition would need to be well justified, but at the same
> > time, I don't think we can rule out any emulator a priori.  We'll have
> > to evaluate the issue on a case by case basis. As usual, it is going to
> > be a trade-off between complexity, maintainability and use cases that it
> > enables. Everybody dislike QEMU on Xen on x86, but it enabled Windows XP
> > virtual machines back in the day. I might disagree with the way it was
> > done, but I wonder what would be of the Xen Project today if those
> > emullators hadn't been added in 2005.
> > 
> > Of course the fewer emulators, the better. I wouldn't accept an IDE
> > emulator in Xen on ARM today for example. However sometimes they are
> > unavoidable, that's why it is important to provide a safe execution
> > environment for them (meaning: not in Xen at EL2).
> > 
> > Today it is pretty much the same thing to add an emulator in the
> > hypervisor or in QEMU on x86. Somebody has to maintain the code no
> > matter where it lives and provide security support for it. Every QEMU
> > vulnerability ends up becoming a Xen vulnerability. In all honesty, it
> > is better to introduce them in QEMU so that at least the few people that
> > use stubdoms are less affected. In the future it is going to be similar
> > to introduce new emulators in xen.git at EL0/1 or in QEMU running
> > unprivileged in Dom0. This is to say that having emulators out of Xen
> > (or out of xen.git) is not necessarily an improvement if they are still
> > able to do exactly the same things, such as mapping any random page in
> > memory.
> 
> We have to factor in our decision that QEMU is been used by many people, which
> mean the code should be more exercised. In the case of Xen, some emulator may
> be used by very few people (think about TEE or a specific UART).

That's true, although not all parts of QEMUs are used as much as others.
For example I am pretty sure there is no security support for ARM
platforms and devices in QEMU today.


> I would require more unit tests (maybe in XTF) when a new emulator is added.
> Allowing us to check if the emulator is still functional.

Definitely true. It would be nice to have fuzzy testing too.


> > > > > The current vuart (see xen/arch/arm/vuart.c) is very simple but
> > > > > require
> > > > > someone to configure it. For DOM0, this is configured by the serial
> > > > > driver.
> > > > > For guest we need someone doing the same.
> > > > 
> > > > I understand. For clarity, I'll call "PL011 emulator" the one that will
> > > > end up being used for DomUs, which might be based on, or different from,
> > > > xen/arch/arm/vuart.c. It doesn't exist yet.
> > > > 
> > > > The PL011 emulator should have default values for everything. Some of
> > > > these values could be configured by libxl, but none should be required
> > > > to be configured by libxl. The last thing we want is to disseminate
> > > > numbers and addresses in libxl. One of these parameters could be the
> > > > MMIO address, but it is just an example, we don't necessarily need to
> > > > support changing it. It could be a decent feature to have but I don't
> > > > think is important if we'll support configurable memory layouts soon.
> > > 
> > > This is what I have been suggested from the beginning :).
> > > 
> > > But in the case of baremetal application, we want to be able to do logging
> > > only (i.e not reading). They will have a driver for the host UART. It
> > > would be
> > > pointless and potentially difficult to emulate a full UART here. This is
> > > where
> > > vuart come in place (see the use case mentioned by Edgar).
> > 
> > I was suggesting to kill two birds with one stone and just do PL011 for
> > DomUs (disabled by default, of course). Instead, you would keep the two
> > use cases separate? PL011 for VM spec guests and vuart for baremetal
> > apps?
> 
> We have to keep those use cases separated. We already went in lengthly
> discussion and you agreed on it. Anyway, I will summarize here.

Ops, sorry, after reading the rest of your email I realize that there
was a misunderstanding. Let me explain. I agree that keeping full PL011
emulation and small vuart emulation separate can be a good thing. I also
agree that those are two different use cases.

But I didn't realize that the vuart feature and the expose memory layout
feature were tightly connected for you. I would keep them independent.
In fact, vuart or PL011, I would make a new virtual uart option
available to any guests including the ones without host memory layout,
using an iomem style option. The new uart could be advertised as PL011
on device tree, while in fact only emulating part of it via vuart.c (of
course the fact that doesn't completely emulate a PL011 should be
clearly documented).

On the other hand, you would basically embedded the vuart option into the
host memory layout option and expose it as the same uart as the one on
the host, which of course changes from platform to platform.

Although I like the approach I suggested because I believe it gives
users more flexibility and is less unexpected, because the type of the
uart is well defined, I don't think this is an important decision. The
host memory layout feature is the important one to have and guests that
need a virtual uart will still be able to get one with full PL011
emulation one day. The end results are very similar. So I would leave it
to the contributor or, if you feel strongly about it, I'll leave it up
to you.


> You cannot assume if there will be a space in the layout for the
> PL011. Further, this guest will have a driver for the host UART and
> not the PL011.

I think these are reasonable expectations. If they are not, then you'd
be right.

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

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

[Julien Grall]

Hi Stefano,

On 05/12/16 20:25, Stefano Stabellini wrote:
> On Mon, 5 Dec 2016, Julien Grall wrote:

[...]

>>>> But in the case of baremetal application, we want to be able to do logging
>>>> only (i.e not reading). They will have a driver for the host UART. It
>>>> would be
>>>> pointless and potentially difficult to emulate a full UART here. This is
>>>> where
>>>> vuart come in place (see the use case mentioned by Edgar).
>>>
>>> I was suggesting to kill two birds with one stone and just do PL011 for
>>> DomUs (disabled by default, of course). Instead, you would keep the two
>>> use cases separate? PL011 for VM spec guests and vuart for baremetal
>>> apps?
>>
>> We have to keep those use cases separated. We already went in lengthly
>> discussion and you agreed on it. Anyway, I will summarize here.
>
> Ops, sorry, after reading the rest of your email I realize that there
> was a misunderstanding. Let me explain. I agree that keeping full PL011
> emulation and small vuart emulation separate can be a good thing. I also
> agree that those are two different use cases.
>
> But I didn't realize that the vuart feature and the expose memory layout
> feature were tightly connected for you. I would keep them independent.
> In fact, vuart or PL011, I would make a new virtual uart option
> available to any guests including the ones without host memory layout,
> using an iomem style option. The new uart could be advertised as PL011
> on device tree, while in fact only emulating part of it via vuart.c (of
> course the fact that doesn't completely emulate a PL011 should be
> clearly documented).
>
> On the other hand, you would basically embedded the vuart option into the
> host memory layout option and expose it as the same uart as the one on
> the host, which of course changes from platform to platform.
>
> Although I like the approach I suggested because I believe it gives
> users more flexibility and is less unexpected, because the type of the
> uart is well defined, I don't think this is an important decision. The
> host memory layout feature is the important one to have and guests that
> need a virtual uart will still be able to get one with full PL011
> emulation one day. The end results are very similar. So I would leave it
> to the contributor or, if you feel strongly about it, I'll leave it up
> to you.

After reading what you suggest, I am fine with that. I thought you 
wanted to only support PL011, hence why I was arguing back.

Cheers,


-- 
Julien Grall

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