[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Embedded-pv-devel] [Xen-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
    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

_______________________________________________
Embedded-pv-devel mailing list
Embedded-pv-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/embedded-pv-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.