All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@arm.com>
To: shankerd@codeaurora.org, xen-devel@lists.xen.org
Cc: andre.przywara@arm.com, sstabellini@kernel.org,
	steve.capper@arm.com, wei.chen@linaro.org
Subject: Re: [PATCH v2 5/6] xen/arm: traps: Avoid unnecessary VA -> IPA translation in abort handlers
Date: Thu, 18 Aug 2016 13:02:24 +0100	[thread overview]
Message-ID: <1265e274-e31b-38a2-fe07-12af3ddd9f52@arm.com> (raw)
In-Reply-To: <816a2016-07d6-f95f-245c-d1d13f062594@codeaurora.org>



On 17/08/16 21:08, Shanker Donthineni wrote:
>
>
> On 08/17/2016 06:11 AM, Julien Grall wrote:
>> On 17/08/16 03:19, Shanker Donthineni wrote:
>>> Hi Julien,
>>
>> Hello Shanker,
>>
>>> On 07/27/2016 12:09 PM, Julien Grall wrote:
>>>> Translating a VA to a IPA is expensive. Currently, Xen is assuming that
>>>> HPFAR_EL2 is only valid when the stage-2 data/instruction abort
>>>> happened
>>>> during a translation table walk of a first stage translation (i.e S1PTW
>>>> is set).
>>>>
>>>> However, based on the ARM ARM (D7.2.34 in DDI 0487A.j), the register is
>>>> also valid when the data/instruction abort occured for a translation
>>>> fault.
>>>>
>>>> With this change, the VA -> IPA translation will only happen for
>>>> permission faults that are not related to a translation table of a
>>>> first stage translation.
>>>>
>>>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>>>>
>>>> ---
>>>>      Changes in v2:
>>>>          - Use fsc in the switch in do_trap_data_abort_guest
>>>> ---
>>>>   xen/arch/arm/traps.c | 24 ++++++++++++++++++++----
>>>>   1 file changed, 20 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
>>>> index ea105f2..83a30fa 100644
>>>> --- a/xen/arch/arm/traps.c
>>>> +++ b/xen/arch/arm/traps.c
>>>> @@ -2382,13 +2382,28 @@ static inline paddr_t get_faulting_ipa(vaddr_t
>>>> gva)
>>>>       return ipa;
>>>>   }
>>>>
>>>> +static inline bool hpfar_is_valid(bool s1ptw, uint8_t fsc)
>>>> +{
>>>> +    /*
>>>> +     * HPFAR is valid if one of the following cases are true:
>>>> +     *  1. the stage 2 fault happen during a stage 1 page table walk
>>>> +     *  (the bit ESR_EL2.S1PTW is set)
>>>> +     *  2. the fault was due to a translation fault
>>>> +     *
>>>> +     * Note that technically HPFAR is valid for other cases, but they
>>>> +     * are currently not supported by Xen.
>>>> +     */
>>>> +    return s1ptw || (fsc == FSC_FLT_TRANS);
>>>
>>> Yes, XEN is not supporting the stage 2 access flag but we should handle
>>> a stage 2 address size fault.
>>
>> The function hpfar_is_valid indicates whether the register HPFAR is
>> valid. If the function returns false, Xen will use the hardware do the
>> translation.
>>
>> It will only lead to a waste of cycle but this is fine as the address
>> size fault is not a hot path for now.
>>
>>> I think we should do some thing like to below to match ARM ARM.
>>>
>>> return s1ptw || (fsc != FSC_FLT_PERM);
>>
>> This does not match the ARM ARM, with this check you consider that
>> HPFAR will be valid for all the fault but permission ones which is not
>> true.
>>
>> I purposefully choose a white list because it is safer to use the
>> hardware to do the translation more often than the invert.
>>
>> So I don't see why we should handle stage 2 access flag with the
>> current Xen. If you still disagree, please explain why with a concrete
>> example.
>>
>
> Agree with you, I have suggested the above change because I saw the same
> check in Linux KVM.
> As per ARM ARM, it should be 'return s1ptw || (fsc == FSC_FLT_TRANS) ||
> (fsc == FSC_FLT_ACCESS) || (fsc == 0x00)';

Feel free to send a patch for this explaining why we would need to have 
the full check. But I don't think it is worth to test every case and 
therefore increasing the number of cycles of this function for faults we 
don't care so far.

Regards,

-- 
Julien Grall

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

  reply	other threads:[~2016-08-18 12:02 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-27 17:09 [PATCH v2 0/6] xen/arm: Simplify do_trap_*_abort_guest Julien Grall
2016-07-27 17:09 ` [PATCH v2 1/6] xen/arm: traps: Simplify the switch in do_trap_*_abort_guest Julien Grall
2016-07-28 19:41   ` Stefano Stabellini
2016-07-27 17:09 ` [PATCH v2 2/6] xen/arm: Provide macros to help creating workaround helpers Julien Grall
2016-07-28 19:42   ` Stefano Stabellini
2016-07-27 17:09 ` [PATCH v2 3/6] xen/arm: Use check_workaround to handle the erratum 766422 Julien Grall
2016-07-28 19:43   ` Stefano Stabellini
2016-07-27 17:09 ` [PATCH v2 4/6] xen/arm: traps: MMIO should only be emulated for fault translation Julien Grall
2016-07-27 17:09 ` [PATCH v2 5/6] xen/arm: traps: Avoid unnecessary VA -> IPA translation in abort handlers Julien Grall
2016-07-27 17:28   ` Sergej Proskurin
2016-07-27 17:40     ` Julien Grall
2016-08-17  2:19   ` Shanker Donthineni
2016-08-17 11:11     ` Julien Grall
2016-08-17 20:08       ` Shanker Donthineni
2016-08-18 12:02         ` Julien Grall [this message]
2016-07-27 17:09 ` [PATCH v2 6/6] xen/arm: arm64: Add Cortex-A57 erratum 834220 workaround Julien Grall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1265e274-e31b-38a2-fe07-12af3ddd9f52@arm.com \
    --to=julien.grall@arm.com \
    --cc=andre.przywara@arm.com \
    --cc=shankerd@codeaurora.org \
    --cc=sstabellini@kernel.org \
    --cc=steve.capper@arm.com \
    --cc=wei.chen@linaro.org \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.