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:26:53 +0000 Message-ID: <54B66E9D.9030009@linaro.org> References: <1421179848-31833-1-git-send-email-julien.grall@linaro.org> <54B66805.4080902@citrix.com> <54B66D29.6050001@linaro.org> <54B66DEA.4010105@citrix.com> 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 1YBNym-0004Bk-DW for xen-devel@lists.xenproject.org; Wed, 14 Jan 2015 13:27:24 +0000 Received: by mail-we0-f181.google.com with SMTP id q58so8767459wes.12 for ; Wed, 14 Jan 2015 05:27:22 -0800 (PST) In-Reply-To: <54B66DEA.4010105@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 13:23, Andrew Cooper wrote: > 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. Are you sure? With xc_domain_maximum_gpfn() + 1 we should not shoot a RAM page. At least most of the time. >> >> 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? Yes. Regards, -- Julien Grall