> -----Original Message----- > From: Julien Grall [mailto:[email protected]] > Sent: 13 June 2016 13:42 > To: Paul Durrant; [email protected]; David Vrabel; > [email protected]; [email protected]; [email protected] > Cc: Andrew Cooper; [email protected]; [email protected]; > [email protected]; [email protected] > 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:[email protected]] On Behalf > Of > >>> Julien Grall > >>> Sent: 13 June 2016 11:51 > >>> To: [email protected]; David Vrabel; [email protected]; > >>> [email protected]; [email protected] > >>> Cc: [email protected]; Andrew Cooper; linux- > [email protected]; > >>> [email protected]; Julien Grall; [email protected] > >>> 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 <[email protected]> > >>> > >>> --- > >>> 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
