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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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