xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Shanker Donthineni <shankerd@codeaurora.org>
To: Julien Grall <julien.grall@arm.com>, 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: Wed, 17 Aug 2016 15:08:05 -0500	[thread overview]
Message-ID: <816a2016-07d6-f95f-245c-d1d13f062594@codeaurora.org> (raw)
In-Reply-To: <2dda256a-f2dc-9400-218f-eb2f918f3541@arm.com>



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)';

> Regards,
>

-- 
Shanker Donthineni
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.


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

  reply	other threads:[~2016-08-17 20:08 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 [this message]
2016-08-18 12:02         ` Julien Grall
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=816a2016-07d6-f95f-245c-d1d13f062594@codeaurora.org \
    --to=shankerd@codeaurora.org \
    --cc=andre.przywara@arm.com \
    --cc=julien.grall@arm.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).