linux-kernel - Re: [PATCH v3 1/3] arm64: kvm: support kvmtool to detect RAS extension feature

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 10 May 2017 16:53:42 +0800
From:   gengdongjiu <gengdongjiu@...wei.com>
To:     James Morse <james.morse@....com>,
        gengdongjiu <gengdj.1984@...il.com>
CC:     Tyler Baicar <tbaicar@...eaurora.org>,
        Christoffer Dall <christoffer.dall@...aro.org>,
        Marc Zyngier <marc.zyngier@....com>, <pbonzini@...hat.com>,
        <rkrcmar@...hat.com>, <linux@...linux.org.uk>,
        <catalin.marinas@....com>, <will.deacon@....com>,
        <rjw@...ysocki.net>, "Len Brown" <lenb@...nel.org>,
        <matt@...eblueprint.co.uk>, <robert.moore@...el.com>,
        <lv.zheng@...el.com>, <nkaje@...eaurora.org>,
        <zjzhang@...eaurora.org>, <mark.rutland@....com>,
        <akpm@...ux-foundation.org>, <eun.taik.lee@...sung.com>,
        Sandeepa Prabhu <sandeepa.s.prabhu@...il.com>,
        <labbott@...hat.com>, <shijie.huang@....com>,
        <rruigrok@...eaurora.org>, <paul.gortmaker@...driver.com>,
        <tn@...ihalf.com>, Fu Wei <fu.wei@...aro.org>,
        <rostedt@...dmis.org>, <bristot@...hat.com>,
        <linux-arm-kernel@...ts.infradead.org>,
        <kvmarm@...ts.cs.columbia.edu>, <kvm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-acpi@...r.kernel.org>,
        <linux-efi@...r.kernel.org>, <devel@...ica.org>,
        <Suzuki.Poulose@....com>, Punit Agrawal <punit.agrawal@....com>,
        <astone@...hat.com>, <harba@...eaurora.org>,
        "Hanjun Guo" <hanjun.guo@...aro.org>,
        John Garry <john.garry@...wei.com>,
        Shiju Jose <shiju.jose@...wei.com>, <joe@...ches.com>,
        Xiongfeng Wang <wangxiongfeng2@...wei.com>
Subject: Re: [PATCH v3 1/3] arm64: kvm: support kvmtool to detect RAS
 extension feature

Dear, James

On 2017/5/9 1:31, James Morse wrote:
> Hi gengdongjiu,
> 
> On 04/05/17 18:20, gengdongjiu wrote:
>>> On 30/04/17 06:37, Dongjiu Geng wrote:
>>>> Handle kvmtool's detection for RAS extension, because sometimes
>>>> the APP needs to know the CPU's capacity
>>>
>>>> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
>>>> index d9e9697..1004039 100644
>>>> --- a/arch/arm64/kvm/reset.c
>>>> +++ b/arch/arm64/kvm/reset.c
>>>> @@ -64,6 +64,14 @@ static bool cpu_has_32bit_el1(void)
>>>>   return !!(pfr0 & 0x20);
>>>>  }
>>>>
>>>> +static bool kvm_arm_support_ras_extension(void)
>>>> +{
>>>> + u64 pfr0;
>>>> +
>>>> + pfr0 = read_system_reg(SYS_ID_AA64PFR0_EL1);
>>>> + return !!(pfr0 & 0x10000000);
>>>> +}
>>>
>>> Why are we telling user-space that the CPU has RAS extensions? EL0 can't do
>>> anything with this and the guest EL1 can detect it from the id registers.
>>>
>>>
>>> Are you using this to decide whether or not to generate a HEST for the guest?
>>
>> James, yes, it is.  my current user-space qemu EL0 patches indeed will
>> check the RAS  extensions.
>> if has the RAS extensions. for SEA, userspace qemu will generate the
>> CPER and inject the SEA to guest;
>> for SEI,  userspace qemu sets the virtual SEI with the specified
>> Syndrome(set the HCR_EL2.VSE and vsesr_el2 );
>> if not have RAS extensions, Qemu does nothing
> 
> But you can use APEI in a guest on CPUs without the RAS extensions: the host may
> signal memory errors to Qemu for any number of reasons, user-space shouldn't
> care how it knows. Examples are PCI-AER, any APEI event notified by polling or
> one of the flavours of irq.
> 
> I would expect Qemu to generate a HEST based on its abilities, i.e. if it
> supports any mechanism of notifying the guest about errors. Choosing the
> mechanism then depends on the type of error.
> 
> Ideally the Qemu code for HEST/GHES/CPER generation code using some of the irqs
> and polling could be shared with x86, as these should be possible using common
> KVM APIs.
Ok, got it.

> 
> 
>>> If Qemu/kvmtool supports handling memory-failure notifications from signals you
>>> should always generate a HEST. The GHES notification method could be anything
>>> Qemu can deliver to the guest using the KVM APIs. Notifications from Qemu to the
>>> guest don't depend on the RAS extensions. KVM has APIs for IRQ and SEA (you can
>>> use KVM_SET_ONE_REG).
>>
>> I will consider your suggestion to  always generate a CPER instead of
> 
> (generate a HEST, CPER are the runtime records. There are too many acronyms in
> this space!)
  thanks James's correction.

> 
>> relying on the RAS extensions, thanks
> 
> 
> Thanks,
> 
> James
> 
> 
> .
>