Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

2016-05-23 Thread Julien Grall 

Hello Andrii,

On 20/05/16 17:24, Andrii Anisov wrote:

If a malicious user has access to the Android guest (via USB key, wifi,...)
he would be able to crash the platform using the GPU because there is no
SMMU protection.

That's why we are shadowing GPU MMU translation tables in xen heap.
And this is leaded us to need of [PATCH RFC 18/18] arm: Add ability to
allocate Xen heap in lowmem.
Patche for GPU MMU shadowing is not published yet, I still have to
check if it lacks of proprietary information.


I would rather delay any review on patches required (such as patch #18) 
for GPU MMU shadowing until you post the new series.


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

2016-05-23 Thread Julien Grall 

Hello Andrii,

On 20/05/16 18:09, Andrii Anisov wrote:

If I understand correctly, all the initiators but the GPU will be used by
DOM0 which is already direct mapped. The only issue here is allocating
memory enough memory below 4GB.

It's not about memory allocation for domain. It is rather about SDRAM
mapping on the bus. J6 has first 2GB for iomems, starting from
0x8000 2GB of SDRAM mapping plus more SDRAM mapped over 4GB line.
Changing rambase_pfn is painful for J6 release kernel so we just make
it configurable by
 - [PATCH RFC 04/18] libxl: add ability to set rambase_pfn via cfg file.
 - [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn'
setting for kernel Dom0


I am not sure to understand why you need to change the rambase_pfn. Is 
it because the kernel is using hardcoded address rather than using the 
device tree?


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

2016-05-21 Thread Meng Xu 
On Sat, May 21, 2016 at 10:32 AM, Julien Grall  wrote:
> Hello Meng,

Hi Julien,

>
> On 20/05/2016 16:21, Meng Xu wrote:
>>
>> On Thu, May 19, 2016 at 5:53 PM, Andrii Anisov
>>  wrote:
>
> If the board is not supported by Xen, can we say Xen will support the
> board with the warkaround?
>>>
>>>
>>> I would not say boards are supported by XEN (except earlyprintk).
>>> Rather architectures are supported in general, and SoC's are supported
>>> in architecture implementation defined deviations (i.e. SMMU absence).
>>
>>
>> Yes. I searched around for the "Jacinto 6" Automotive processor.[1]
>> It uses Cortex A15 processor...
>> However, I tried the Arndale Octo board two years ago
>> (http://www.arndaleboard.org/wiki/index.php/Main_Page). From my
>> previous experience, the board may not be supported by Xen even though
>> the processor it uses has virtualization extension.. :-(
>
>
> It would like to correct you here.

Thank you very much for the correction! :-)

> Xen (and KVM) can run on any board
> providing virtual extensions, a GIC and an architectural timer are
> available.
>

I see.

> However, some vendor ship boards with a firmware/bootloader that will enter
> the kernel in EL1 rather than EL2 (i.e the hyp mode).

Right! That's exactly what we faced two years ago. :-(

>
> The bootloader is often U-boot and the upstream version may support the
> board. So if the bootloader is entered in a mode that allows to switch to
> HYP mode (either EL3 or secure EL1), then you can recompile U-boot and flash
> your board. Otherwise, the source may be shipped and you can hack around to
> entered Xen to HYP mode.

Yes. Sometimes, the board needs the signature for the uboot, that's
why we couldn't just compile the source without the manufacturer's
signature two years ago...

Thank you very much for clarifying this. It makes the statement more
precisely. :-)

Best Regards,

Meng
---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

2016-05-21 Thread Julien Grall 

Hello Meng,

On 20/05/2016 16:21, Meng Xu wrote:

On Thu, May 19, 2016 at 5:53 PM, Andrii Anisov
 wrote:

If the board is not supported by Xen, can we say Xen will support the
board with the warkaround?


I would not say boards are supported by XEN (except earlyprintk).
Rather architectures are supported in general, and SoC's are supported
in architecture implementation defined deviations (i.e. SMMU absence).


Yes. I searched around for the "Jacinto 6" Automotive processor.[1]
It uses Cortex A15 processor...
However, I tried the Arndale Octo board two years ago
(http://www.arndaleboard.org/wiki/index.php/Main_Page). From my
previous experience, the board may not be supported by Xen even though
the processor it uses has virtualization extension.. :-(


It would like to correct you here. Xen (and KVM) can run on any board 
providing virtual extensions, a GIC and an architectural timer are 
available.


However, some vendor ship boards with a firmware/bootloader that will 
enter the kernel in EL1 rather than EL2 (i.e the hyp mode).


The bootloader is often U-boot and the upstream version may support the 
board. So if the bootloader is entered in a mode that allows to switch 
to HYP mode (either EL3 or secure EL1), then you can recompile U-boot 
and flash your board. Otherwise, the source may be shipped and you can 
hack around to entered Xen to HYP mode.


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

2016-05-20 Thread Meng Xu 
On Fri, May 20, 2016 at 1:23 PM, Andrii Anisov
 wrote:
> Meng,
>
>> From my previous experience, the board may not be supported by Xen even 
>> though
>> the processor it uses has virtualization extension.. :-(
>
> I still insist it depends on SoC ;)

Ah-ha, I totally agree about this...

>
> If you are saying about this case:
>
>> Yes. I searched around for the "Jacinto 6" Automotive processor.[1]
>> It uses Cortex A15 processor...
>> However, I tried the Arndale Octo board two years ago
>> (http://www.arndaleboard.org/wiki/index.php/Main_Page).
>
> Cortex A15 just implements ARMv7 architecture more efficiently then
> A9, while VE are still optional. You should read chip specs more
> careful.
> You remember I wrote:
>>> The most outstanding example is a chip with Cortex A15 MPCore, but
>>> without any VE support at all.
> It was another Samsung's SoC in my experience.

Yes. I just started looking at the ARM now and tried to evaluate the
RTDS scheduler on ARM. That's why I'm very interested in the use case
here and tried to run it. :-)

I will keep an eye on your patches. ;-)

Thanks and Best Regards,

Meng
---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

2016-05-20 Thread Andrii Anisov 
Meng,

> From my previous experience, the board may not be supported by Xen even though
> the processor it uses has virtualization extension.. :-(

I still insist it depends on SoC ;)

If you are saying about this case:

> Yes. I searched around for the "Jacinto 6" Automotive processor.[1]
> It uses Cortex A15 processor...
> However, I tried the Arndale Octo board two years ago
> (http://www.arndaleboard.org/wiki/index.php/Main_Page).

Cortex A15 just implements ARMv7 architecture more efficiently then
A9, while VE are still optional. You should read chip specs more
careful.
You remember I wrote:
>> The most outstanding example is a chip with Cortex A15 MPCore, but
>> without any VE support at all.
It was another Samsung's SoC in my experience.

Andrii Anisov | Associate Manager, Engineering
GlobalLogic
Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1
P +38.044.492.9695x3664  M +380505738852  S andriyanisov
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

2016-05-20 Thread Andrii Anisov 
> If I understand correctly, all the initiators but the GPU will be used by
> DOM0 which is already direct mapped. The only issue here is allocating
> memory enough memory below 4GB.
It's not about memory allocation for domain. It is rather about SDRAM
mapping on the bus. J6 has first 2GB for iomems, starting from
0x8000 2GB of SDRAM mapping plus more SDRAM mapped over 4GB line.
Changing rambase_pfn is painful for J6 release kernel so we just make
it configurable by
- [PATCH RFC 04/18] libxl: add ability to set rambase_pfn via cfg file.
- [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn'
setting for kernel Dom0


> By default Xen will try to allocate as much RAM as possible below 4GB for
> DOM0.

Also we are providing both domains with a piece of non-dma memory for
applications with a patch [PATCH RFC 16/18] xen: Add dom0_mem_high
option & over 4GB memory allocation for Dom0.

> If you are concerned about the amount allocated, you could pre-allocate them 
> before
> hand (such as via the DT as propose in [1]).
I've quickly checked the proposal, looks interesting we would evaluate.

> For the GPU, on another reply you said it was protected by an IPMMU. I
> remembered a series from globallogic to virtualize it in Xen [2]. Can you
> details why this option would not fit in your use case?
> [2]
> http://lists.xenproject.org/archives/html/xen-devel/2014-06/msg03359.html
We have a successor of that patch series. But the GPU MMU is still
32-bit and is not able to address SDRAM mapped over 4GB on the bus.

Andrii Anisov | Associate Manager, Engineering
GlobalLogic
Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1
P +38.044.492.9695x3664  M +380505738852  S andriyanisov
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

2016-05-20 Thread Andrii Anisov 
> If a malicious user has access to the Android guest (via USB key, wifi,...)
> he would be able to crash the platform using the GPU because there is no
> SMMU protection.
That's why we are shadowing GPU MMU translation tables in xen heap.
And this is leaded us to need of [PATCH RFC 18/18] arm: Add ability to
allocate Xen heap in lowmem.
Patche for GPU MMU shadowing is not published yet, I still have to
check if it lacks of proprietary information.

Andrii Anisov | Associate Manager, Engineering
GlobalLogic
Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1
P +38.044.492.9695x3664  M +380505738852  S andriyanisov
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

2016-05-20 Thread Meng Xu 
On Thu, May 19, 2016 at 5:53 PM, Andrii Anisov
 wrote:
> Meng,
>

Hi Andrii,

Thank you very much for your explanation about the use case in previous email!

>>> If the board is not supported by Xen, can we say Xen will support the
>>> board with the warkaround?
>
> I would not say boards are supported by XEN (except earlyprintk).
> Rather architectures are supported in general, and SoC's are supported
> in architecture implementation defined deviations (i.e. SMMU absence).

Yes. I searched around for the "Jacinto 6" Automotive processor.[1]
It uses Cortex A15 processor...
However, I tried the Arndale Octo board two years ago
(http://www.arndaleboard.org/wiki/index.php/Main_Page). From my
previous experience, the board may not be supported by Xen even though
the processor it uses has virtualization extension.. :-(
That's why I asked if the board itself can run Xen. If the board can
run Xen, I would like to buy one and try it out. :-)

[1] http://www.ti.com/lit/ds/symlink/dra746.pdf

Thanks and Best Regards,

Meng
---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

2016-05-20 Thread Julien Grall 

Hello Andrii,

Thank you for sharing details on your use case.

On 19/05/16 22:28, Andrii Anisov wrote:

See the system details I can reveal below:

  * There are two OS in the system Linux(Dom0) and Android(DomU)
  * Android provides almost all infotainment functionality. Linux covers
functionality with higher reliability requirements and backup in
case if Android crashes/glitches.


If a malicious user has access to the Android guest (via USB key, 
wifi,...) he would be able to crash the platform using the GPU because 
there is no SMMU protection.


So can you expand what are your expectations for reliability?


  * Linux (Dom0) handles all HW except GPU.
  * Android (DomD) runs with number of PV drivers, has an exclusive
access to GPU.
  * The system has 2Gb(-16MB due to errata) RAM under 4GB, and a memory
bank mapped over 4GB
  * Due to relatively small amount of dma-able memory both domains
should have assigned RAM both from under 4GB and over 4GB spaces.
  * Several "data flow" mixing scenarios should be provided on Linux
side I.e. controlling Android audio level, Android audio mute,
mixing Android audio stream from stream generated by Linux. Same for
Android displaying, events passing.
  * Domains should share HW codecs.

 >> Similarly, what are the limitations for the Jacinto6 SoC that need to
 >> be workaround?

The main limitation is that Jacinto6 lacks of SMMU. All transaction
initiators can address 32bit only, some initiators have no MMU and do
not support sg-lists (require buffers continuous in maddr).


If I understand correctly, all the initiators but the GPU will be used 
by DOM0 which is already direct mapped. The only issue here is 
allocating memory enough memory below 4GB.


By default Xen will try to allocate as much RAM as possible below 4GB 
for DOM0. If you are concerned about the amount allocated, you could 
pre-allocate them before hand (such as via the DT as propose in [1]).


For the GPU, on another reply you said it was protected by an IPMMU. I 
remembered a series from globallogic to virtualize it in Xen [2]. Can 
you details why this option would not fit in your use case?


Regards,

[1] 
http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg01879.html
[2] 
http://lists.xenproject.org/archives/html/xen-devel/2014-06/msg03359.html


--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

2016-05-19 Thread Andrii Anisov 
Julien,

>>We need to understand the use case and see if it is possible to generalize
>>it for everyone.

Well, the thing I would generalize is an understanding that real chips
(automotive IVI, mobile) have no or has limited SMMU functionality.

For a limited SMMU functionality I would name Renesas RCAR H2 chip -
it has its own IPMMU instead of SMMU. It is claimed that IPMMU
implemets VMSAv7. But no VMSAv7 VE are supported by that IPMMU in
fact.

The most outstanding example is a chip with Cortex A15 MPCore, but
without any VE support at all.

Andrii Anisov | Associate Manager, Engineering
GlobalLogic
Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1
P +38.044.492.9695x3664  M +380505738852  S andriyanisov
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

2016-05-19 Thread Andrii Anisov 
Meng,

>> If the board is not supported by Xen, can we say Xen will support the
>> board with the warkaround?

I would not say boards are supported by XEN (except earlyprintk).
Rather architectures are supported in general, and SoC's are supported
in architecture implementation defined deviations (i.e. SMMU absence).

Andrii Anisov | Associate Manager, Engineering
GlobalLogic
Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1
P +38.044.492.9695x3664  M +380505738852  S andriyanisov
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

2016-05-19 Thread Andrii Anisov 
All,

See the system details I can reveal below:

   - There are two OS in the system Linux(Dom0) and Android(DomU)
   - Android provides almost all infotainment functionality. Linux covers
   functionality with higher reliability requirements and backup in case if
   Android crashes/glitches.
   - Linux (Dom0) handles all HW except GPU.
   - Android (DomD) runs with number of PV drivers, has an exclusive access
   to GPU.
   - The system has 2Gb(-16MB due to errata) RAM under 4GB, and a memory
   bank mapped over 4GB
   - Due to relatively small amount of dma-able memory both domains should
   have assigned RAM both from under 4GB and over 4GB spaces.
   - Several "data flow" mixing scenarios should be provided on Linux side
   I.e. controlling Android audio level, Android audio mute, mixing Android
   audio stream from stream generated by Linux. Same for Android displaying,
   events passing.
   - Domains should share HW codecs.

>> Similarly, what are the limitations for the Jacinto6 SoC that need to
>> be workaround?

The main limitation is that Jacinto6 lacks of SMMU. All transaction
initiators can address 32bit only, some initiators have no MMU and do not
support sg-lists (require buffers continuous in maddr).

Andrii Anisov | Associate Manager, Engineering
GlobalLogic
Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1
P +38.044.492.9695x3664  M +380505738852  S andriyanisov
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt


On Thu, May 19, 2016 at 2:00 PM, Julien Grall  wrote:
> Hello,
>
> On 18/05/16 20:17, Meng Xu wrote:
>>
>> On Wed, May 18, 2016 at 12:32 PM, Andrii Anisov
>>  wrote:
>>>
>>> This series RFC patches from the currently ongoing production project.
>>> This patch series presents changes needed to fit the system into
>>> customer requirements as well as workaround limitations of the
>>> Jacinto6 SoC.
>>
>>
>> IMHO, it will be better, if possible, to describe the exact customer
>> requirements this patch series tries to satisfy. I'm curious at what
>> the requirements are and if the requirements are general enough for
>> many other customers. :-)
>
>
> I agree with Meng here. We need to understand the use case and see if it
is
> possible to generalize it for everyone.
>
> I looked quickly at this patch series and noticed that most of patches
miss
> details on why it is necessary and what you are trying solve. Can you give
> us more details?
>
>> Similarly, what are the limitations for the Jacinto6 SoC that need to
>> be workaround? If the board is not supported by Xen, can we say Xen
>> will support the board with the warkaround?
>
>
> Regards,
>
> --
> Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

2016-05-19 Thread Julien Grall 

Hello,

On 18/05/16 20:17, Meng Xu wrote:

On Wed, May 18, 2016 at 12:32 PM, Andrii Anisov
 wrote:

This series RFC patches from the currently ongoing production project.
This patch series presents changes needed to fit the system into
customer requirements as well as workaround limitations of the
Jacinto6 SoC.


IMHO, it will be better, if possible, to describe the exact customer
requirements this patch series tries to satisfy. I'm curious at what
the requirements are and if the requirements are general enough for
many other customers. :-)


I agree with Meng here. We need to understand the use case and see if it 
is possible to generalize it for everyone.


I looked quickly at this patch series and noticed that most of patches 
miss details on why it is necessary and what you are trying solve. Can 
you give us more details?



Similarly, what are the limitations for the Jacinto6 SoC that need to
be workaround? If the board is not supported by Xen, can we say Xen
will support the board with the warkaround?


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

2016-05-18 Thread Meng Xu 
Hi Andrii,

On Wed, May 18, 2016 at 12:32 PM, Andrii Anisov
 wrote:
> This series RFC patches from the currently ongoing production project.
> This patch series presents changes needed to fit the system into
> customer requirements as well as workaround limitations of the
> Jacinto6 SoC.

IMHO, it will be better, if possible, to describe the exact customer
requirements this patch series tries to satisfy. I'm curious at what
the requirements are and if the requirements are general enough for
many other customers. :-)

Similarly, what are the limitations for the Jacinto6 SoC that need to
be workaround? If the board is not supported by Xen, can we say Xen
will support the board with the warkaround?


Thanks and Best Regards,

Meng
---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel