[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <575EAA00.10705@arm.com>
Date: Mon, 13 Jun 2016 13:41:36 +0100
From: Julien Grall <julien.grall@....com>
To: Paul Durrant <Paul.Durrant@...rix.com>,
"boris.ostrovsky@...cle.com" <boris.ostrovsky@...cle.com>,
David Vrabel <david.vrabel@...rix.com>,
"jgross@...e.com" <jgross@...e.com>,
"sstabellini@...nel.org" <sstabellini@...nel.org>,
"konrad.wilk@...cle.com" <konrad.wilk@...cle.com>
Cc: Andrew Cooper <Andrew.Cooper3@...rix.com>,
"xen-devel@...ts.xen.org" <xen-devel@...ts.xen.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"JBeulich@...e.com" <JBeulich@...e.com>,
"steve.capper@....com" <steve.capper@....com>
Subject: Re: [Xen-devel] [PATCH] xen: grant-table: Check truncation when
giving access to a frame
Hello Paul,
On 13/06/16 13:12, Paul Durrant wrote:
>> -----Original Message-----
>> From: Xen-devel [mailto:xen-devel-bounces@...ts.xen.org] On Behalf Of
>> Julien Grall
>> Sent: 13 June 2016 11:51
>> To: boris.ostrovsky@...cle.com; David Vrabel; jgross@...e.com;
>> sstabellini@...nel.org; konrad.wilk@...cle.com
>> Cc: steve.capper@....com; Andrew Cooper; linux-kernel@...r.kernel.org;
>> xen-devel@...ts.xen.org; Julien Grall; JBeulich@...e.com
>> Subject: [Xen-devel] [PATCH] xen: grant-table: Check truncation when giving
>> access to a frame
>>
>> The version 1 of the grant-table protocol only supports frame encoded on
>> 32-bit.
>>
>> When the platform is supporting 48-bit physical address, the frame will
>> be encoded on 36-bit which will lead a truncation and give access to
>> the wrong frame.
>>
>> On ARM Xen will always allow the guest to use all the physical address,
>> although today the RAM is always located under 40-bits (see
>> xen/include/public/arch-arm.h).
>>
>> Add a truncation check in gnttab_update_entry_v1 to prevent the guest to
>> give access to the wrong frame.
>>
>> Signed-off-by: Julien Grall <julien.grall@....com>
>>
>> ---
>> This is limiting us to a 44-bit address space whilst ARM can support
>> up to 48-bit today. This number of bit will increase to 52-bit in
>> upcoming processors [1].
>>
>> It might be good to start thinking to extend the version 1 of the
>> protocol to use 64-bit frame number.
>
> ...or simply use version 2 of the protocol.
On another mail [1], you said that "[v2] didn't scale it became
bottle-necked on dom0's grant table size,...".
So it looks like to me that version 2 is the wrong way to go.
The performance should stay the same whether the platform support
40-bit, 44-bit, 48-bit, 52-bit address space.
Regards,
--
Julien Grall
Powered by blists - more mailing lists