Re: [PATCH] xen/arm: Implement domain_get_maximum_gpfn

[Tamas K Lengyel <tamas.lengyel@zentific.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2160 bytes --]

On Mon, Sep 8, 2014 at 10:47 PM, Tamas K Lengyel <tamas.lengyel@zentific.com
> wrote:

>
> On Mon, Sep 8, 2014 at 10:43 PM, Julien Grall <julien.grall@linaro.org>
> wrote:
>
>> Hello Tamas,
>>
>> On 03/09/14 02:00, Tamas K Lengyel wrote:
>>
>>>
>>>
>>>
>>> On Wed, Sep 3, 2014 at 10:44 AM, Ian Campbell <Ian.Campbell@citrix.com
>>> <mailto:Ian.Campbell@citrix.com>> 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.
>>>
>>
>> It might be better if you carry this patch on your series.
>>
>> Regards,
>>
>> --
>> Julien Grall
>>
>
> Alright.
>
> Thanks,
> Tamas
>

As a sidenote, if this patch is problematic to merge for some reason, the
current implementation still needs to change to return 0 instead of -ENOSYS
as to conform to the x86 implementation. On the x86 side 0 is used to
indicate failure. See 7ffc9779aa5120c5098d938cb88f69a1dda9a0fe "x86: make
certain memory sub-ops return valid values" for more info.

Tamas

[-- Attachment #1.2: Type: text/html, Size: 3561 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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