> -----Original Message----- > From: Julien Grall [mailto:julien.gr...@arm.com] > Sent: 13 June 2016 13:42 > To: Paul Durrant; boris.ostrov...@oracle.com; David Vrabel; > jgr...@suse.com; sstabell...@kernel.org; konrad.w...@oracle.com > Cc: Andrew Cooper; xen-devel@lists.xen.org; linux-ker...@vger.kernel.org; > jbeul...@suse.com; steve.cap...@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-boun...@lists.xen.org] On Behalf > Of > >>> Julien Grall > >>> Sent: 13 June 2016 11:51 > >>> To: boris.ostrov...@oracle.com; David Vrabel; jgr...@suse.com; > >>> sstabell...@kernel.org; konrad.w...@oracle.com > >>> Cc: steve.cap...@arm.com; Andrew Cooper; linux- > ker...@vger.kernel.org; > >>> xen-devel@lists.xen.org; Julien Grall; jbeul...@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.gr...@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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
