Re: [Xen-devel] [PATCH] xen: grant-table: Check truncation when giving access to a frame

[Julien Grall]

Hello Paul,

On 13/06/16 13:12, Paul Durrant wrote:
> > -----Original Message-----
> > From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of
> > Julien Grall
> > Sent: 13 June 2016 11:51
> > To: boris.ostrovsky@xxxxxxxxxx; David Vrabel; jgross@xxxxxxxx;
> > sstabellini@xxxxxxxxxx; konrad.wilk@xxxxxxxxxx
> > Cc: steve.capper@xxxxxxx; Andrew Cooper; linux-kernel@xxxxxxxxxxxxxxx;
> > xen-devel@xxxxxxxxxxxxx; Julien Grall; JBeulich@xxxxxxxx
> > 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@xxxxxxx>
> >
> > ---
> >      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