From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tamas K Lengyel Subject: Re: [PATCH] xen/arm: Implement domain_get_maximum_gpfn Date: Wed, 3 Sep 2014 11:00:30 +0200 Message-ID: References: <1404226666-7949-1-git-send-email-julien.grall@linaro.org> <53BD29CD.4020204@linaro.org> <1405526542.1087.50.camel@kazak.uk.xensource.com> <5404E5D3.4010302@linaro.org> <1409733899.24834.2.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5171215483990397299==" Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XP6Qb-0004Fm-Vo for xen-devel@lists.xenproject.org; Wed, 03 Sep 2014 09:00:34 +0000 Received: by mail-qg0-f50.google.com with SMTP id q108so7740943qgd.23 for ; Wed, 03 Sep 2014 02:00:30 -0700 (PDT) In-Reply-To: <1409733899.24834.2.camel@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: Ian Campbell Cc: "xen-devel@lists.xenproject.org" , Julien Grall , Tim Deegan , Stefano Stabellini , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org --===============5171215483990397299== Content-Type: multipart/alternative; boundary=001a11c30406cfabc2050225772b --001a11c30406cfabc2050225772b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 3, 2014 at 10:44 AM, Ian Campbell wrote: > On Mon, 2014-09-01 at 17:32 -0400, Julien Grall wrote: > > Hi Ian, > > > > On 16/07/14 12:02, Ian Campbell wrote: > > > I'd much prefer to just have the fix to xc_dom_gnttab_hvm_seed for ARM > > > and continue to punt on this interface until it is actually needed by > > > something unavoidable on the guest side (and simultaneously hope that > > > day never comes...). > > > > This patch is a requirement to make Xen Memory access working on ARM. > > Could you reconsider the possibility to apply this patch on Xen? > > Needs more rationale as to why it is required for Xen Memory (do you > mean xenaccess?). I assume I'll find that in the relevant thread once I > get to it? > > It's used in a non-critical sanity check for performance reasons, as seen here: https://github.com/tklengyel/xen/blob/arm_memaccess3/xen/common/mem_access.c#L75. Without the sanity check we might attempt to set mem_access permissions on gpfn's that don't exist for the guest. It wouldn't break anything to do that but if we know beforehand that the gpfn is outside the scope of what the guest has we can skip the entire thing. > > For the main concern of this thread (i.e the buggy scratch pfn with > > xc_dom_gnttab_hvm_seed), I wrote a patch to let the architecture decided > > which scrach pfn should be used. I will send the patch next week. > > OK. > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > --001a11c30406cfabc2050225772b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Sep 3, 2014 at 10:44 AM, Ian Campbell <= ;Ian.Campbell@= citrix.com> wrote:
On Mon, 2= 014-09-01 at 17:32 -0400, Julien Grall wrote:
> Hi Ian,
>
> On 16/07/14 12:02, Ian Campbell wrote:
> > I'd much prefer to just have the fix to xc_dom_gnttab_hvm_see= d for ARM
> > and continue to punt on this interface until it is actually neede= d by
> > something unavoidable on the guest side (and simultaneously hope = that
> > day never comes...).
>
> This patch is a requirement to make Xen Memory access working on ARM.<= br> > Could you reconsider the possibility to apply this patch on Xen?

Needs more rationale as to why it is required for Xen Memory (do you<= br> mean xenaccess?). I assume I'll find that in the relevant thread once I=
get to it?


It's used in= a non-critical sanity check for performance reasons, as seen here: https://github.com/tklengyel/xen/blob/arm_memaccess3/xen/common/= mem_access.c#L75. Without the sanity check we might attempt to set mem_= access permissions on gpfn's that don't exist for the guest. It wou= ldn't break anything to do that but if we know beforehand that the gpfn= is outside the scope of what the guest has we can skip the entire thing.
=A0
> For the main concern of this thread (i.e the buggy scratch pfn with > xc_dom_gnttab_hvm_seed), I wrote a patch to let the architecture decid= ed
> which scrach pfn should be used. I will send the patch next week.

OK.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.x= en.org/xen-devel

--001a11c30406cfabc2050225772b-- --===============5171215483990397299== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5171215483990397299==--