From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] libxc: introduce a per architecture scratch pfn for temporary grant mapping Date: Wed, 14 Jan 2015 13:23:54 +0000 Message-ID: <54B66DEA.4010105@citrix.com> References: <1421179848-31833-1-git-send-email-julien.grall@linaro.org> <54B66805.4080902@citrix.com> <54B66D29.6050001@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YBNvT-00042E-Jc for xen-devel@lists.xenproject.org; Wed, 14 Jan 2015 13:23:59 +0000 In-Reply-To: <54B66D29.6050001@linaro.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Julien Grall , 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 13:20, Julien Grall wrote: > 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. That is what x86 does. I assumed (clearly incorrectly) that ARM was similar. > > 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. Do you mean to say that there is a grant table range baked into the ABI occupying guest physical address space? ~Andrew