From: Marc Zyngier <marc.zyngier@arm.com>
To: gengdongjiu <gengdongjiu@huawei.com>
Cc: "christoffer.dall\@linaro.org" <christoffer.dall@linaro.org>,
"linux\@armlinux.org.uk" <linux@armlinux.org.uk>,
"james.morse\@arm.com" <james.morse@arm.com>,
"tbaicar\@codeaurora.org" <tbaicar@codeaurora.org>,
"catalin.marinas\@arm.com" <catalin.marinas@arm.com>,
"will.deacon\@arm.com" <will.deacon@arm.com>,
"linux-arm-kernel\@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"kvmarm\@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] KVM: arm/arm64: Fix external abort type matching
Date: Fri, 27 Oct 2017 19:28:32 +0100 [thread overview]
Message-ID: <86a80ca1in.fsf@arm.com> (raw)
In-Reply-To: <0184EA26B2509940AA629AE1405DD7F2016E999C@DGGEMA503-MBS.china.huawei.com> (gengdongjiu@huawei.com's message of "Fri, 27 Oct 2017 15:43:26 +0000")
On Fri, Oct 27 2017 at 3:43:26 pm GMT, gengdongjiu <gengdongjiu@huawei.com> wrote:
>>
>> On Thu, Oct 26 2017 at 6:07:01 pm BST, Dongjiu Geng <gengdongjiu@huawei.com> wrote:
>> > For this matching, current code using the {I,D}FSC range to match
>> > kvm_vcpu_trap_get_fault_type() return value, but
>> > kvm_vcpu_trap_get_fault_type() only return the part {I,D}FSC instead
>> > of whole, so fix this issue
>> >
>> > Value Type
>> > 0x10 FSC_SEA
>> > 0x14 FSC_SEA_TTW0 FSC_SEA_TTW1 FSC_SEA_TTW2 FSC_SEA_TTW3
>> > 0x18 FSC_SECC
>> > 0x1c FSC_SECC_TTW0 FSC_SECC_TTW1 FSC_SECC_TTW2 FSC_SECC_TTW3
>> >
>> > CC: James Morse <james.morse@arm.com>
>> > CC: Tyler Baicar <tbaicar@codeaurora.org>
>> > Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
[...]
>> > diff --git a/arch/arm64/include/asm/kvm_arm.h
>> > b/arch/arm64/include/asm/kvm_arm.h
>> > index 61d694c..c0f1798 100644
>> > --- a/arch/arm64/include/asm/kvm_arm.h
>> > +++ b/arch/arm64/include/asm/kvm_arm.h
>> > @@ -205,15 +205,9 @@
>> > #define FSC_ACCESS ESR_ELx_FSC_ACCESS
>> > #define FSC_PERM ESR_ELx_FSC_PERM
>> > #define FSC_SEA ESR_ELx_FSC_EXTABT
>> > -#define FSC_SEA_TTW0 (0x14)
>> > -#define FSC_SEA_TTW1 (0x15)
>> > -#define FSC_SEA_TTW2 (0x16)
>> > -#define FSC_SEA_TTW3 (0x17)
>> > +#define FSC_SEA_TTW (0x14)
>> > #define FSC_SECC (0x18)
>> > -#define FSC_SECC_TTW0 (0x1c)
>> > -#define FSC_SECC_TTW1 (0x1d)
>> > -#define FSC_SECC_TTW2 (0x1e)
>> > -#define FSC_SECC_TTW3 (0x1f)
>> > +#define FSC_SECC_TTW (0x1c)
>> >
>> > /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
>> > #define HPFAR_MASK (~UL(0xf))
>> > diff --git a/arch/arm64/include/asm/kvm_emulate.h
>> > b/arch/arm64/include/asm/kvm_emulate.h
>> > index e5df3fc..5cde311 100644
>> > --- a/arch/arm64/include/asm/kvm_emulate.h
>> > +++ b/arch/arm64/include/asm/kvm_emulate.h
>> > @@ -239,15 +239,9 @@ static inline bool kvm_vcpu_dabt_isextabt(const
>> > struct kvm_vcpu *vcpu) {
>> > switch (kvm_vcpu_trap_get_fault_type(vcpu)) {
>> > case FSC_SEA:
>> > - case FSC_SEA_TTW0:
>> > - case FSC_SEA_TTW1:
>> > - case FSC_SEA_TTW2:
>> > - case FSC_SEA_TTW3:
>> > + case FSC_SEA_TTW:
>> > case FSC_SECC:
>> > - case FSC_SECC_TTW0:
>> > - case FSC_SECC_TTW1:
>> > - case FSC_SECC_TTW2:
>> > - case FSC_SECC_TTW3:
>> > + case FSC_SECC_TTW:
>> > return true;
>> > default:
>> > return false;
>>
>> What is the bug you're fixing? From what I can tell, you're simply
>> removing valuable symbols from the kernel, and inventing another one
>> that doesn't exist in the architecture.
>
> Marc, I mean the "kvm_vcpu_trap_get_fault_type(vcpu))" return the
> value of fault type which is not the syndrome value {D,I}FSC.
> the case sentence matches the syndrome value instead of fault type.
> So the two are not match, I mean here has issue.
> So the FSC_SECC_TTW1/ FSC_SECC_TTW2/ FSC_SECC_TTW3 and FSC_SECC_TTW1/
> FSC_SECC_TTW2/ FSC_SECC_TTW3 are dead code.
>
> Below value are syndrome {D,I}FSC value, which is not fault type.
> FSC_SECC_TTW0:
> FSC_SECC_TTW1
> FSC_SECC_TTW2:
> FSC_SECC_TTW3:
> FSC_SEA_TTW1:
> FSC_SEA_TTW2
> FSC_SEA_TTW3:
>
> kvm_vcpu_trap_get_fault_type() will clear the low two bits to zero. So
> I use FSC_SEA_TTW represent "Synchronous external abort on translation
> table walk"
I understand that, and I certainly not keen on adding another "fault
type" for this.
> As we can see the Translation fault type "FSC_FAULT", which does not
> define the "FSC_FAULT0" "FSC_FAULT1" "FSC_FAULT2" "FSC_FAULT3".
> Because the fault type " FSC_FAULT " include the four cases.
Indeed, and I'm still not convinced this is the best thing we have in
the code.
> static inline u8 kvm_vcpu_trap_get_fault(const struct kvm_vcpu *vcpu)
> {
> return kvm_vcpu_get_hsr(vcpu) & 0x3f;
> }
Here you go. This should give you a pretty good idea of how to provide a
proper fix.
Thanks,
M.
--
Jazz is not dead. It just smells funny.
next prev parent reply other threads:[~2017-10-27 18:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-27 15:43 [PATCH v2] KVM: arm/arm64: Fix external abort type matching gengdongjiu
2017-10-27 18:28 ` Marc Zyngier [this message]
2017-10-28 5:22 ` gengdongjiu
-- strict thread matches above, loose matches on Subject: below --
2017-10-26 10:07 Dongjiu Geng
2017-10-27 14:55 ` Marc Zyngier
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=86a80ca1in.fsf@arm.com \
--to=marc.zyngier@arm.com \
--cc=catalin.marinas@arm.com \
--cc=christoffer.dall@linaro.org \
--cc=gengdongjiu@huawei.com \
--cc=james.morse@arm.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=tbaicar@codeaurora.org \
--cc=will.deacon@arm.com \
/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).