From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423145AbcFMMps (ORCPT ); Mon, 13 Jun 2016 08:45:48 -0400 Received: from smtp.ctxuk.citrix.com ([185.25.65.24]:33242 "EHLO SMTP.EU.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423121AbcFMMpq (ORCPT ); Mon, 13 Jun 2016 08:45:46 -0400 X-IronPort-AV: E=Sophos;i="5.26,466,1459814400"; d="scan'208";a="23987135" From: Paul Durrant To: Julien Grall , "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 Thread-Topic: [Xen-devel] [PATCH] xen: grant-table: Check truncation when giving access to a frame Thread-Index: AQHRxXD/p1iqV6+QMkC69IoQ/qTltJ/nNZaAgAAh7sA= Date: Mon, 13 Jun 2016 12:45:42 +0000 Message-ID: <40a70cd8036747a2801c3ebd1b299d23@AMSPEX02CL03.citrite.net> References: <1465815046-5390-1-git-send-email-julien.grall@arm.com> <575EAA00.10705@arm.com> <575EAA21.4030701@arm.com> In-Reply-To: <575EAA21.4030701@arm.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-DLP: AMS1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u5DCjpqv007657 > -----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 > >>> > >>> --- > >>> 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