[ARM] Handling CMA pool device nodes in Dom0

[ARM] Handling CMA pool device nodes in Dom0

[Iurii Mykhalskyi]

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

Hello!

I'm working under Renesas Gen3 H3 board with 4GB RAM (Salvator-X) support
in Xen mainline.

Salvator-X has several  CMA pool nodes, for example:

1:
adsp_reserved: linux,adsp {
compatible = "shared-dma-pool";
reusable;
reg = <0x00000000 0x57000000 0x0 0x01000000>;
};

2:
linux,cma {
compatible = "shared-dma-pool";
reusable;
reg = <0x00000000 0x58000000 0x0 0x18000000>;
linux,cma-default;
};

During Dom0 allocation, we can't guarantee, that allocated memory will
contain mentioned regions.
In second сase, we can actually hardcode mapped region by using separate
DTS for Dom0 with changed memory regions.
But for first one, this in not an option - this pool is used for audio DSP
and its firmware relies on this addresses.

What is the correct way to solve this situation?
Does Xen has some mechanism to handle such cases?

Thank you.

-- 

Iurii Mykhalskyi | Senior Software Engineer
GlobalLogic
P +38.044.492.9695x3664  M +38.096.311.5467  S mad-nemoi
www.globallogic.com
<http://www.globallogic.com/>
http://www.globallogic.com/email_disclaimer.txt

[-- Attachment #1.2: Type: text/html, Size: 4519 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: [ARM] Handling CMA pool device nodes in Dom0

[Julien Grall]

(CC Stefano)

On 25/11/16 12:19, Iurii Mykhalskyi wrote:
> Hello!

Hi Iurii,

>
> I'm working under Renesas Gen3 H3 board with 4GB RAM (Salvator-X)
> support in Xen mainline.
>
> Salvator-X has several  CMA pool nodes, for example:
>
> 1:
> adsp_reserved: linux,adsp {
> compatible = "shared-dma-pool";
> reusable;
> reg = <0x00000000 0x57000000 0x0 0x01000000>;
> };
>
> 2:
> linux,cma {
> compatible = "shared-dma-pool";
> reusable;
> reg = <0x00000000 0x58000000 0x0 0x18000000>;
> linux,cma-default;
> };
>
> During Dom0 allocation, we can't guarantee, that allocated memory will
> contain mentioned regions.
> In second сase, we can actually hardcode mapped region by using separate
> DTS for Dom0 with changed memory regions.
> But for first one, this in not an option - this pool is used for audio
> DSP and its firmware relies on this addresses.
>
> What is the correct way to solve this situation?
> Does Xen has some mechanism to handle such cases?

 From my understanding all the nodes you mentioned are living under the 
node /reserved-memory, right? Currently Xen is not parsing this node.

Before answering about possible implementation in Xen, I would like to 
understand what are the constraints on these reserved memory regions.

I understand that when "reg" property is specified, it is a static 
allocation and we need to be able to map those regions at the same 
address in DOM0.

However, do these regions need to be included in memory node?

Regards,

-- 
Julien Grall

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

Re: [ARM] Handling CMA pool device nodes in Dom0

[Stefano Stabellini]

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

On Tue, 29 Nov 2016, Julien Grall wrote:
> (CC Stefano)
> 
> On 25/11/16 12:19, Iurii Mykhalskyi wrote:
> > Hello!
> 
> Hi Iurii,
> 
> > 
> > I'm working under Renesas Gen3 H3 board with 4GB RAM (Salvator-X)
> > support in Xen mainline.
> > 
> > Salvator-X has several  CMA pool nodes, for example:
> > 
> > 1:
> > adsp_reserved: linux,adsp {
> > compatible = "shared-dma-pool";
> > reusable;
> > reg = <0x00000000 0x57000000 0x0 0x01000000>;
> > };
> > 
> > 2:
> > linux,cma {
> > compatible = "shared-dma-pool";
> > reusable;
> > reg = <0x00000000 0x58000000 0x0 0x18000000>;
> > linux,cma-default;
> > };
> > 
> > During Dom0 allocation, we can't guarantee, that allocated memory will
> > contain mentioned regions.
> > In second сase, we can actually hardcode mapped region by using separate
> > DTS for Dom0 with changed memory regions.
> > But for first one, this in not an option - this pool is used for audio
> > DSP and its firmware relies on this addresses.
> > 
> > What is the correct way to solve this situation?
> > Does Xen has some mechanism to handle such cases?
> 
> From my understanding all the nodes you mentioned are living under the node
> /reserved-memory, right? Currently Xen is not parsing this node.
> 
> Before answering about possible implementation in Xen, I would like to
> understand what are the constraints on these reserved memory regions.
> 
> I understand that when "reg" property is specified, it is a static allocation
> and we need to be able to map those regions at the same address in DOM0.
> 
> However, do these regions need to be included in memory node?

Another question: what caching attributes do they need in the stage2 mapping?

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

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

Re: [ARM] Handling CMA pool device nodes in Dom0

[Peng Fan]

On Tue, Nov 29, 2016 at 01:49:51PM +0000, Julien Grall wrote:
>(CC Stefano)
>
>On 25/11/16 12:19, Iurii Mykhalskyi wrote:
>>Hello!
>
>Hi Iurii,
>
>>
>>I'm working under Renesas Gen3 H3 board with 4GB RAM (Salvator-X)
>>support in Xen mainline.
>>
>>Salvator-X has several  CMA pool nodes, for example:
>>
>>1:
>>adsp_reserved: linux,adsp {
>>compatible = "shared-dma-pool";
>>reusable;
>>reg = <0x00000000 0x57000000 0x0 0x01000000>;
>>};
>>
>>2:
>>linux,cma {
>>compatible = "shared-dma-pool";
>>reusable;
>>reg = <0x00000000 0x58000000 0x0 0x18000000>;
>>linux,cma-default;
>>};
>>
>>During Dom0 allocation, we can't guarantee, that allocated memory will
>>contain mentioned regions.
>>In second сase, we can actually hardcode mapped region by using separate
>>DTS for Dom0 with changed memory regions.
>>But for first one, this in not an option - this pool is used for audio
>>DSP and its firmware relies on this addresses.
>>
>>What is the correct way to solve this situation?
>>Does Xen has some mechanism to handle such cases?

How about using "alloc-ranges"?

Regards,
Peng.

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

Reserved-memory node handling in XEN ( WAS Re: [ARM] Handling CMA pool device nodes in Dom0)

[Andrii Anisov]

Dear All,


I would like to revive this thread within the R-Car Gen3 support nits 
cleanup work.


On 01.12.16 02:12, Stefano Stabellini wrote:
>> Before answering about possible implementation in Xen, I would like to
>> understand what are the constraints on these reserved memory regions.
>>
>> I understand that when "reg" property is specified, it is a static allocation
>> and we need to be able to map those regions at the same address in DOM0.
Yes, this should be like that.

>> However, do these regions need to be included in memory node?
I guess this regions should be included into the memory node. But from 
this point of view, it is not clear if the size of the reserved region 
should be accounted during RAM space allocation for the domain.

> Another question: what caching attributes do they need in the stage2 mapping?
I guess Write-Back Cacheable should be sufficient.

-- 

*Andrii Anisov*



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

Re: Reserved-memory node handling in XEN ( WAS Re: [ARM] Handling CMA pool device nodes in Dom0)

[Julien Grall]

On 26/07/17 16:04, Andrii Anisov wrote:
> Dear All,

Hi,

>
> I would like to revive this thread within the R-Car Gen3 support nits
> cleanup work.
>
>
> On 01.12.16 02:12, Stefano Stabellini wrote:
>>> Before answering about possible implementation in Xen, I would like to
>>> understand what are the constraints on these reserved memory regions.
>>>
>>> I understand that when "reg" property is specified, it is a static
>>> allocation
>>> and we need to be able to map those regions at the same address in DOM0.
> Yes, this should be like that.
>
>>> However, do these regions need to be included in memory node?
> I guess this regions should be included into the memory node. But from
> this point of view, it is not clear if the size of the reserved region
> should be accounted during RAM space allocation for the domain.

If you use the memory allocator for those reserved region, then they 
should be accounted in the domain memory. If not, then they are entirely 
separated and then no need to account them. Just add a separate memory 
node for it.

>
>> Another question: what caching attributes do they need in the stage2
>> mapping?
> I guess Write-Back Cacheable should be sufficient.

write-back cacheable is quite weak attribute for stage-2. Is that safe?

Cheers,

-- 
Julien Grall

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

Re: Reserved-memory node handling in XEN ( WAS Re: [ARM] Handling CMA pool device nodes in Dom0)

[Andrii Anisov]

Hello Julien,

On 26.07.17 20:06, Julien Grall wrote:
> If you use the memory allocator for those reserved region, then they 
> should be accounted in the domain memory. If not, then they are 
> entirely separated and then no need to account them. Just add a 
> separate memory node for it.
I've got your point.

> write-back cacheable is quite weak attribute for stage-2. Is that safe?
I guess the domain should drive the resultant cacheability because it 
knows how that memory region will be used. So the weakest write-back 
cacheability is the right choice. Is my understanding correct?

-- 

*Andrii Anisov*



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

Re: Reserved-memory node handling in XEN ( WAS Re: [ARM] Handling CMA pool device nodes in Dom0)

[Julien Grall]

On 27/07/17 10:24, Andrii Anisov wrote:
> Hello Julien,

Hi,

> On 26.07.17 20:06, Julien Grall wrote:
>> If you use the memory allocator for those reserved region, then they
>> should be accounted in the domain memory. If not, then they are
>> entirely separated and then no need to account them. Just add a
>> separate memory node for it.
> I've got your point.
>
>> write-back cacheable is quite weak attribute for stage-2. Is that safe?
> I guess the domain should drive the resultant cacheability because it
> knows how that memory region will be used. So the weakest write-back
> cacheability is the right choice. Is my understanding correct?

It really depends on the security impact here. If the reserved memory is 
shared with other device, what would be the impact of a domain using the 
wrong memory attribute?

Furthermore, using the weakest one would imply cache maintenance when 
the region is assigned/deassigned to/from a domain to prevent leaking data.

Cheers,

-- 
Julien Grall

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

Re: Reserved-memory node handling in XEN ( WAS Re: [ARM] Handling CMA pool device nodes in Dom0)

[Andrii Anisov]

Dear Julien,


On 27.07.17 12:55, Julien Grall wrote:
> It really depends on the security impact here. If the reserved memory 
> is shared with other device, what would be the impact of a domain 
> using the wrong memory attribute?
I'm sorry, I did not get the point.
Could you please provide an example of a security impact?

> Furthermore, using the weakest one would imply cache maintenance when 
> the region is assigned/deassigned to/from a domain to prevent leaking 
> data.
Could you please provide an example scenario for data leakage?

-- 

*Andrii Anisov*



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

Re: Reserved-memory node handling in XEN ( WAS Re: [ARM] Handling CMA pool device nodes in Dom0)

[Julien Grall]

On 27/07/17 11:36, Andrii Anisov wrote:
> Dear Julien,
>
>
> On 27.07.17 12:55, Julien Grall wrote:
>> It really depends on the security impact here. If the reserved memory
>> is shared with other device, what would be the impact of a domain
>> using the wrong memory attribute?
> I'm sorry, I did not get the point.
> Could you please provide an example of a security impact?

Let's rephrase it differently. Is the reserved memory always RAM or 
could it be other things?

>
>> Furthermore, using the weakest one would imply cache maintenance when
>> the region is assigned/deassigned to/from a domain to prevent leaking
>> data.
> Could you please provide an example scenario for data leakage?

Well, if your region is cacheable it might be possible to have some data 
left in the cache after the domain destruction.

If you start a domain afterwards, it may be able to read data that 
belonged to the previous domain. Hence data leak.

All region of page allocated by the memory allocator in Xen will be 
clean and invalidate to prevent such leak. This will not be the case for 
reserved memory as this will not be managed by the memory allocator.

Cheers,

-- 
Julien Grall

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

Re: Reserved-memory node handling in XEN ( WAS Re: [ARM] Handling CMA pool device nodes in Dom0)

[Andrii Anisov]

On 27.07.17 13:56, Julien Grall wrote:
> Let's rephrase it differently. Is the reserved memory always RAM or 
> could it be other things?
I think this have to be checked with the DT spec to have an answer.

> Well, if your region is cacheable it might be possible to have some 
> data left in the cache after the domain destruction.
>
> If you start a domain afterwards, it may be able to read data that 
> belonged to the previous domain. Hence data leak.
>
> All region of page allocated by the memory allocator in Xen will be 
> clean and invalidate to prevent such leak. This will not be the case 
> for reserved memory as this will not be managed by the memory allocator.
So that is the question to the reserved-memory support design. And 
should be considered during the choosing the approach (manage it with 
existing allocator, or implement something aside)

-- 

*Andrii Anisov*


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