From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH] libxc: introduce a per architecture scratch pfn for temporary grant mapping Date: Wed, 14 Jan 2015 13:20:41 +0000 Message-ID: <54B66D29.6050001@linaro.org> References: <1421179848-31833-1-git-send-email-julien.grall@linaro.org> <54B66805.4080902@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YBNsk-0003Vo-Rl for xen-devel@lists.xenproject.org; Wed, 14 Jan 2015 13:21:10 +0000 Received: by mail-we0-f171.google.com with SMTP id u56so8738032wes.2 for ; Wed, 14 Jan 2015 05:21:09 -0800 (PST) In-Reply-To: <54B66805.4080902@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper , xen-devel@lists.xenproject.org Cc: Wei Liu , Ian Campbell , Stefano Stabellini , Ian Jackson , Jan Beulich , =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= List-Id: xen-devel@lists.xenproject.org On 14/01/15 12:58, Andrew Cooper wrote: > On 13/01/15 20:10, Julien Grall wrote: >> The code to initialize the grant table in libxc uses >> xc_domain_maximum_gpfn() + 1 to get a guest pfn for mapping the grant >> frame and to initialize it. >> >> This solution has two major issues: >> - The check of the return of xc_domain_maximum_gpfn is buggy because >> xen_pfn_t is unsigned and in case of an error -ERRNO is returned. >> Which is never catch with ( pfn <= 0 ). > > Wow - xc_domain_maximum_gpfn() will currently truncate long to int on > 64bit systems. That is unhelpful of it. > >> - The guest memory layout maybe filled up to the end, i.e >> xc_domain_maximum_gpfn() + 1 gives either 0 or an invalid PFN due to >> hardware limitation. > > I realise I am throwing a spanner in the works here, but if you are > looking to fix it, lets fix this properly rather than hacking around the > problem further. > > There is currently no way for the toolstack to map something on behalf > of a guest which is not in the guest physmap. As a workaround, the code > here shoots a guest ram page, adds a non-ram page to the physmap, maps, > edits, unmaps and replaces the ram. Hmmm... why do you talk about shooting a guest RAM page? Neither the current code, nor the suggested solution for ARM does a such things. ARM is defining a grant table range which is out of the RAM and not mapped at that time. So we can reuse it with any possible issue. Regards, -- Julien Grall