Messages in this thread | | | Subject | Re: [Xen-devel] [PATCH] xen: grant-table: Check truncation when giving access to a frame | From | Julien Grall <> | Date | Mon, 13 Jun 2016 13:41:36 +0100 |
| |
Hello Paul,
On 13/06/16 13:12, Paul Durrant wrote: >> -----Original Message----- >> From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of >> Julien Grall >> Sent: 13 June 2016 11:51 >> To: boris.ostrovsky@oracle.com; David Vrabel; jgross@suse.com; >> sstabellini@kernel.org; konrad.wilk@oracle.com >> Cc: steve.capper@arm.com; Andrew Cooper; linux-kernel@vger.kernel.org; >> xen-devel@lists.xen.org; Julien Grall; JBeulich@suse.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@arm.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
| |