lkml.org 
[lkml]   [2016]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [Xen-devel] [PATCH] xen: grant-table: Check truncation when giving access to a frame
Date
> -----Original Message-----
> From: Julien Grall [mailto:julien.grall@arm.com]
> Sent: 13 June 2016 13:42
> To: Paul Durrant; boris.ostrovsky@oracle.com; David Vrabel;
> jgross@suse.com; sstabellini@kernel.org; konrad.wilk@oracle.com
> Cc: Andrew Cooper; xen-devel@lists.xen.org; linux-kernel@vger.kernel.org;
> JBeulich@suse.com; steve.capper@arm.com
> Subject: Re: [Xen-devel] [PATCH] xen: grant-table: Check truncation when
> giving access to a frame
>
>
>
> On 13/06/16 13:41, Julien Grall wrote:
> > 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.
>

No, I meant the guest receive-side copy didn't scale, not grant table v2 itself. Ok the table is bigger with v2, but to do guest receive-side copy required a huge table in dom0 if it was going to scale to 100s of VMs and the perf. benefits were never that great (if they were there at all).

Paul

> I forgot the link.
>
> [1]
> http://lists.xenproject.org/archives/html/xen-devel/2016-06/msg01606.html
>
> --
> Julien Grall
\
 
 \ /
  Last update: 2016-06-13 15:21    [W:1.742 / U:0.772 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site