Hi Peter，
Sorry for the late response.
>
> > diff --git a/include/linux/sched.h b/include/linux/sched.h index
> > 93ecd930efd3..edb622c40a90 100644
> > --- a/include/linux/sched.h
> > +++ b/include/linux/sched.h
> > @@ -1324,6 +1324,13 @@ struct task_struct {
> > /* CPU-specific state of
>
> On Thu, 10 Jan 2019 at 12:09, gengdongjiu wrote:
> > Peter, I summarize James's main idea, James think QEMU does not
> > needs to check *something* if Qemu support firmware-first.
> > What do we do for your comments?
>
> Unless I'm missing somethin
gengdongjiu 将撤回邮件“[RFC RESEND PATCH] kvm: arm64: export memory error recovery
capability to user space”。
>
> On Thu, 10 Jan 2019 at 12:09, gengdongjiu wrote:
> > Peter, I summarize James's main idea, James think QEMU does not needs
> > to check *something* if Qemu support firmware-first.
> > What do we do for your comments?
>
> Unless I'm missing somethin
Hi James/Peter,
thanks for this discussion, and sorry for my late response due to vacation.
On 2018/12/22 2:17, James Morse wrote:
> Hi Peter,
>
> On 19/12/2018 19:02, Peter Maydell wrote:
>> On Mon, 17 Dec 2018 at 15:56, James Morse wrote:
>>> I don't think this really matters. Its only the
>
> On Fri, 14 Dec 2018 at 13:56, James Morse wrote:
> >
> > Hi Dongjiu Geng,
> >
> > On 14/12/2018 10:15, Dongjiu Geng wrote:
> > > When user space do memory recovery, it will check whether KVM and
> > > guest support the error recovery, only when both of them support,
> > > user space will do
gengdongjiu 将撤回邮件“[RFC RESEND PATCH] kvm: arm64: export memory error recovery
capability to user space”。
>
> On Fri, 14 Dec 2018 at 13:56, James Morse wrote:
> >
> > Hi Dongjiu Geng,
> >
> > On 14/12/2018 10:15, Dongjiu Geng wrote:
> > > When user space do memory recovery, it will check whether KVM and
> > > guest support the error recovery, only when both of them support,
> > > user space will do t
HI James,
Thanks for the mail and comments, I will reply to you in the next mail.
2018-12-14 21:55 GMT+08:00, James Morse :
> Hi Dongjiu Geng,
>
> On 14/12/2018 10:15, Dongjiu Geng wrote:
>> When user space do memory recovery, it will check whether KVM and
>> guest support the error recover
Loop RT kernel Mailing lists.
On 2018/12/10 1:04, zhang jianwei wrote:
> hi Thomas and Mike??
> i say you disabled the RT_GROUP_SCHED in RT kernel because of strange cpu
> stall was observed. currently, in my projects, I need
> enable?0?2RT_GROUP_SCHED in RT kernel. I??d like to know how to rep
Hi James,
Thanks for the mail.
On 2018/11/20 2:05, James Morse wrote:
> Hi gengdongjiu,
>
> On 17/11/2018 15:41, gengdongjiu wrote:
>> In the current kernel, it only handles three kinds of error, which is
>> memory error, PCIE device and ARM process. But now the SMMU a
Hi robin/will/James
In the current kernel, it only handles three kinds of error, which is
memory error, PCIE device and ARM process. But now the SMMU already
support the RAS, how to handle the SMMU RAS error in the kernel?
I check the UEFI_SPEC_2.7, the ACPI's CPER have the IOMMU type, but it
se
Hi Suzuki
On 2018/10/10 1:22, Suzuki K Poulose wrote:
>
>
> On 08/10/18 13:34, Dongjiu Geng wrote:
>> The commit 539aee0edb9f ("KVM: arm64: Share the parts of
>> get/set events useful to 32bit") shares the get/set events
>> helper for arm64 and arm32, it is better also share the check
>> for vcp
Hi christoffer/marc,
Could you review this simple patch to enable the 32 bit KVM vcpu event
supports? Because below user space patch depended on it. thanks
https://patchwork.kernel.org/patch/10617601/
> subject: [PATCH 2/2] arm/arm64: KVM: share the check for vcpu events
> capability
>
2018-08-10 5:05 GMT+08:00 Tyler Baicar :
> On Thu, Aug 9, 2018 at 8:32 AM, gengdongjiu wrote:
>>
>> 2018-08-08 0:26 GMT+08:00 Dongjiu Geng :
>> > In order to remove the additional check before calling the
>> > ghes_notify_sea(), make stub definition when !CONF
CC Borislav
2018-08-08 0:26 GMT+08:00 Dongjiu Geng :
> In order to remove the additional check before calling the
> ghes_notify_sea(), make stub definition when !CONFIG_ACPI_APEI_SEA.
>
> After this cleanup, we can simply call the ghes_notify_sea() to let
> APEI driver handle the SEA notification
On 2018/8/6 22:26, Will Deacon wrote:
>> Will,
>> This patch will be applied, right? thanks
> I haven't queued it in the arm64 tree, since it touches include/acpi/ghes.h
> and you don't have an ack from the acpi folks. I acked it so that you could
> route it via the acpi tree without me hol
2018-07-27 18:06 GMT+08:00 Will Deacon :
> On Thu, Jul 26, 2018 at 05:01:47PM -0400, Dongjiu Geng wrote:
>> In order to remove the additional check before calling the
>> ghes_notify_sea(), make stub definition when !CONFIG_ACPI_APEI_SEA.
>>
>> Signed-off-by: Dongjiu Geng
>> ---
>
> Acked-by: Will
Hi Sebastian ,
Thanks for the answer.
On 2018/7/2 18:14, Sebastian Andrzej Siewior wrote:
> On 2018-07-02 17:34:34 [+0800], gengdongjiu wrote:
>> The Linux kernel version is v4.1.46, and the preempt_rt patch is
>> patch-4.1.46-rt52.patch.
>
> the 4.1 series is no long
Hi Thomas/Anna/John,
Recently I found that the hrtimer become inaccurate when there is a RT
process runs on the same cpu core, and the kernel has applied preempt_rt
patch.
The Linux kernel version is v4.1.46, and the preempt_rt patch is
patch-4.1.46-rt52.patch.
I know that in the preempt_rt
Hi James,
On 2018/6/29 23:58, James Morse wrote:
> Hi Dongjiu Geng,
>
> This patch doesn't apply on v4.18-rc2.
>
> Documentation/virtual/kvm/api.txt already has a 8.18 section. I guess you
> based
> this on v4.17.
Yes, indeed I based on v4.17.
>
> For posting patches, please use the latest '
> On 12/06/18 15:50, gengdongjiu wrote:
> > On 2018/6/11 21:36, James Morse wrote:
> >> On 08/06/18 20:48, Dongjiu Geng wrote:
> >>> For the migrating VMs, user space may need to know the exception
> >>> state. For example, in the machine A, KVM make an SE
Hi James,
thanks for the review.
On 2018/6/11 21:36, James Morse wrote:
> Hi Dongjiu Geng,
>
> Please only put 'RESEND' in the subject if the patch content is identical.
> This patch is not the same as v4.
Yes, it should
>
> On 08/06/18 20:48, Dongjiu Geng wrote:
>> For the migrating VMs, us
Hi Marc
thanks for the review.
On 2018/6/9 20:40, Marc Zyngier wrote:
> On Fri, 08 Jun 2018 20:48:40 +0100,
> Dongjiu Geng wrote:
>>
>> For the migrating VMs, user space may need to know the exception
>> state. For example, in the machine A, KVM make an SError pending,
>> when migrate to B, KVM
Christoffer,
Thanks for the review.
On 2018/6/9 19:17, Christoffer Dall wrote:
> On Sat, Jun 09, 2018 at 03:48:40AM +0800, Dongjiu Geng wrote:
>> For the migrating VMs, user space may need to know the exception
>> state. For example, in the machine A, KVM make an SError pending,
>> when migrate
Hi Mathias,
This patch is ready to apply, It is great that this patch can be applied to
4.18. thanks a lot.
On 2018/6/6 22:36, Dongjiu Geng wrote:
> Initialize the 'err' variate to remove the build warning,
> the warning is shown as below:
>
> drivers/usb/host/xhci-tegra.c: In function 'tegra
On 2018/6/5 16:40, Greg KH wrote:
> On Wed, Jun 06, 2018 at 12:35:00AM +0800, Dongjiu Geng wrote:
>> Initialize the 'err' variate to remove the build warning,
>> the warning is shown as below:
>>
>> drivers/usb/host/xhci-tegra.c: In function ‘tegra_xusb_mbox_thread’:
>> drivers/usb/host/xhci-teg
Hi Mark,
Thanks for the comments.
On 2018/5/31 18:52, Mark Rutland wrote:
> On Thu, May 31, 2018 at 08:41:45PM +0800, Dongjiu Geng wrote:
>> +#ifdef CONFIG_ACPI_APEI_SEI
>> +static LIST_HEAD(ghes_sei);
>> +
>> +/*
>> + * Return 0 only if one of the SEI error sources successfully reported an
>>
Hi Mark, James,
Thanks the review.
On 2018/6/1 0:51, James Morse wrote:
> Hi Mark, Dongjiu Geng,
>
> On 31/05/18 12:01, Mark Rutland wrote:
>> In do_serror() we already handle nmi_{enter,exit}(), so there's no need
>> for that here.
>
> Even better: nmi_enter() has a BUG_ON(in_nmi()).
There
James,
>
>> I do not know when it is merge-window. About the apply version, it does not
>> have limited.
>
> 'git fetch' Linus' tree and look at the tags. 'v4.16' lost its '-rc' suffixes,
> and there isn't a 'v4.17-rc1' yet, so we are still in the merge window.
>
> Linus sends a message to LKM
James,
Thanks for this mail.
On 2018/4/13 0:14, James Morse wrote:
> Hi gengdongjiu,
>
> On 12/04/18 06:00, gengdongjiu wrote:
>> 2018-02-16 1:55 GMT+08:00 James Morse :
>>> On 05/02/18 11:24, gengdongjiu wrote:
>>>>> Is the emulated SError
Hi James,
Thanks for the comments.
2018-04-10 22:15 GMT+08:00, James Morse :
> Hi Dongjiu Geng,
>
> On 09/04/18 22:36, Dongjiu Geng wrote:
>> This new IOCTL exports user-invisible states related to SError.
>> Together with appropriate user space changes, it can inject
>> SError with specified sy
HI James,
Thanks for the review.
2018-04-10 22:15 GMT+08:00, James Morse :
> Hi Dongjiu Geng,
>
> On 09/04/18 22:36, Dongjiu Geng wrote:
>> Before user space injects a SError, it needs to know whether it can
>> specify the guest Exception Syndrome, so KVM should tell user space
>> whether it ha
Hi James，
thanks for this mail.
On 2018/4/10 22:15, James Morse wrote:
> Hi Dongjiu Geng,
>
> On 09/04/18 22:36, Dongjiu Geng wrote:
>> 1. Detect whether KVM can set set guest SError syndrome
>> 2. Support to Set VSESR_EL2 and inject SError by user space.
>> 3. Support live migration to keep S
Dear James,
Thanks for this mail and sorry for my late response.
2018-02-16 1:55 GMT+08:00 James Morse :
> Hi gengdongjiu, liu jun
>
> On 05/02/18 11:24, gengdongjiu wrote:
[]
>>
>>> Is the emulated SError routed following the routing rules for HCR_EL2.{AMO,
Hi Shiju,
The configuration "CONFIG_ACPI_APEI_SEA" is needed to manually enable?
In the "drivers/acpi/apei/Kconfig" file, the default value of ACPI_APEI_SEA is
"y"
config ACPI_APEI_SEA
bool "APEI Synchronous External Abort logging/recovering support"
depends on ARM64 && ACPI_AP
Hi James,
Thanks for your time to review and give comments.
[...]
> > +
> > +8.14 KVM_CAP_ARM_SET_SERROR_ESR
> > +
> > +Architectures: arm, arm64
> > +
> > +This capability indicates that userspace can specify syndrome value
> > +reported to guest OS when guest takes a virtual SError interrupt
Hi James,
Thanks for your review and good suggestion.
>
> Hi Dongjiu Geng,
>
> On 03/03/18 16:09, Dongjiu Geng wrote:
> > RAS Extension provides VSESR_EL2 register to specify virtual SError
> > syndrome value, this patch adds a new IOCTL to export user-invisible
> > states related to SError e
Hi James,
>
> Hi Dongjiu Geng,
>
> On 03/03/18 16:09, Dongjiu Geng wrote:
> > Export one API to specify virtual SEI syndrome value for guest, and
> > add a helper to get the VSESR_EL2 value.
>
> This patch adds two helpers that nothing calls... its not big, please merge
> it with the patch tha
Hi James,
> Hi gengdongjiu,
>
> On 26/02/18 16:13, gengdongjiu wrote:
> > 2018-02-24 1:58 GMT+08:00 James Morse :
> >> On 22/02/18 18:02, Dongjiu Geng wrote:
> >>> The RAS SError Syndrome can be Implementation-Defined,
> >>> arm64_is_ras_serror(
Hi James,
Thank you very much for this mail and your time to review this patch.
Appreciate that.
I will check it and reply.
On 2018/3/16 4:37, James Morse wrote:
> Hi Dongjiu Geng,
>
> On 03/03/18 16:09, Dongjiu Geng wrote:
>> Export one API to specify virtual SEI syndrome value
>> for guest
Hi James,
sorry for my late response due to chines new year.
2018-02-16 1:55 GMT+08:00 James Morse :
> Hi gengdongjiu,
>
> On 12/02/18 10:19, gengdongjiu wrote:
>> On 2018/2/10 1:44, James Morse wrote:
>>> The point? We can't know what a CPU without the RAS
Hi James,
Thanks a lot for your review.
2018-02-24 1:58 GMT+08:00 James Morse :
> Hi Dongjiu Geng,
>
> On 22/02/18 18:02, Dongjiu Geng wrote:
>> The RAS SError Syndrome can be Implementation-Defined,
>> arm64_is_ras_serror() is used to judge whether it is RAS SError,
>> but arm64_is_ras_serror(
Hi James,
Thanks for the mail.
On 2018/2/10 1:44, James Morse wrote:
[...]
>
>> its ESR is 0, can not control the virtual SError's syndrom value, it does
>> not have
>> such registers to control that.
>
> My point was its more nuanced than this: the ARM-ARM's
> TakeVirtualSErrorException() pse
On 2018/2/8 3:03, James Morse wrote:
> Hi Xie XiuQi,
>
> On 30/01/18 19:19, James Morse wrote:
>> On 26/01/18 12:31, Xie XiuQi wrote:
>>> With ARM v8.2 RAS Extension, SEA are usually triggered when memory errors
>>> are consumed. According to the existing process, errors occurred in the
>>> kern
[...]
>
> > Yes, I know you are dong that. Your serial's patch will consider all above
> things, right?
>
> Assuming I got it right, yes. It currently makes the race Xie XiuQi spotted
> worse,
> which I want to fix too. (details on the cover letter)
Ok.
>
>
> > If your patch can be consider
James,
Thank you for your time to reply me.
On 2018/1/31 3:21, James Morse wrote:
> Hi gengdongjiu,
>
> On 24/01/18 20:06, gengdongjiu wrote:
>>> On 06/01/18 16:02, Dongjiu Geng wrote:
>>>> The ARM64 RAS SError Interrupt(SEI) syndrome value is specific to the
>
Hi James,
thanks for the review.
On 2018/1/24 3:07, James Morse wrote:
> Hi Dongjiu Geng,
>
> On 06/01/18 16:02, Dongjiu Geng wrote:
>> RAS Extension add a VSESR_EL2 register which can provide
>> the syndrome value reported to software on taking a virtual
>> SError interrupt exception. This pat
Hi James,
Thanks a lot for your review and comments.
>
> Hi Dongjiu Geng,
>
> On 06/01/18 16:02, Dongjiu Geng wrote:
> > The ARM64 RAS SError Interrupt(SEI) syndrome value is specific to the
> > guest and user space needs a way to tell KVM this value. So we add a
> > new ioctl. Before user sp
sorry fix a typo.
On 2018/1/23 17:23, gengdongjiu wrote:
>> There are problems with doing this:
>>
>> Oct. 18, 2017, 10:26 a.m. James Morse wrote:
>> | How do SEA and SEI interact?
>> |
>> | As far as I can see they can both interrupt each other, which isn&#x
Hi James,
On 2018/1/23 3:39, James Morse wrote:
> Hi Dongjiu Geng,
>
> (versions of patches 1,2 and 4 have been queued by Catalin)
>
> (Nit 'ACPI / APEI:' is the normal subject prefix for ghes.c, this helps the
> maintainers know which patches they need to pay attention to when you are
> touchin
2018-01-15 16:33 GMT+08:00 Christoffer Dall :
> On Fri, Jan 12, 2018 at 06:05:23PM +, James Morse wrote:
>> On 15/12/17 03:30, gengdongjiu wrote:
>> > On 2017/12/7 14:37, gengdongjiu wrote:
>
> [...]
>
>>
>> (I recall someone saying migration is needed
2018-01-13 2:05 GMT+08:00 James Morse :
> Hi gengdongjiu,
>
> On 16/12/17 04:47, gengdongjiu wrote:
>> [...]
>>>
>>>> + case ESR_ELx_AET_UER: /* The error has not been propagated */
>>>> + /*
>>>> + * Usersp
Hi James,
Sorry for my late response due to out of office recently.
2018-01-13 2:05 GMT+08:00 James Morse :
> Hi gengdongjiu,
>
> On 15/12/17 03:30, gengdongjiu wrote:
>> On 2017/12/7 14:37, gengdongjiu wrote:
>>>> We need to tackle (1) and (3) separately. Fo
Hi James,
thanks very much for your mail and reply, I will check it ASAP. Due to
recently busy with other thing, so reply may be late.
On 2018/1/13 2:05, James Morse wrote:
> Hi gengdongjiu,
>
> On 16/12/17 04:47, gengdongjiu wrote:
>> [...]
>>>
>>>> +
Hi Christoffer
On 2018/1/15 16:33, Christoffer Dall wrote:
> On Fri, Jan 12, 2018 at 06:05:23PM +, James Morse wrote:
>> On 15/12/17 03:30, gengdongjiu wrote:
>>> On 2017/12/7 14:37, gengdongjiu wrote:
>
> [...]
>
>>
>> (I recall someone saying
On 2018/1/11 22:17, Adrian Hunter wrote:
>> (e.g., via 'perf inject --itrace'), are also not supported
>>
>> - technically both cs-etm and spe can be used simultaneously, however
>> disabled for simplicity in this release
>>
>> Signed-off-by: Kim Phillips
> For what is there now, it looks fine
> > > New features should not be going into 4.15-rc, that should be a
> > > 4.16-rc1 thing, right?
> >
> > It is also great if it can be applied to 4.16-rc1. Thanks a lot!
>
> I will queue it for 4.16-rc1.
Thanks very much to Catalin.
>
> --
> Catalin
On 2018/1/5 15:57, Greg KH wrote:
> On Fri, Jan 05, 2018 at 09:22:54AM +0800, gengdongjiu wrote:
>> Hi will/catalin
>>
>> On 2017/12/13 18:09, Suzuki K Poulose wrote:
>>> On 13/12/17 10:13, Dongjiu Geng wrote:
>>>> ARM v8.4 extensions add new neon instruc
Hi will/catalin
On 2017/12/13 18:09, Suzuki K Poulose wrote:
> On 13/12/17 10:13, Dongjiu Geng wrote:
>> ARM v8.4 extensions add new neon instructions for performing a
>> multiplication of each FP16 element of one vector with the corresponding
>> FP16 element of a second vector, and to add or subt
On 2017/12/16 3:35, Matthew Wilcox wrote:
>> It's going to be complicated to do, I don't think its worth the effort.
> We can find a bit in struct page that we guarantee will only be set if
> this is allocated as a pagetable. Bit 1 of the third union is currently
> available (compound_head is a po
[...]
>
>> + case ESR_ELx_AET_UER: /* The error has not been propagated */
>> + /*
>> + * Userspace only handle the guest SError Interrupt(SEI) if the
>> + * error has not been propagated
>> + */
>> + run->exit_reason = KVM_EXIT_E
Hi James,
On 2017/12/16 2:52, James Morse wrote:
>> signal, it will record the CPER and trigger a IRQ to notify guest, as shown
>> below:
>>
>> SIGBUS_MCEERR_AR trigger Synchronous External Abort.
>> SIGBUS_MCEERR_AO trigger GPIO IRQ.
>>
>> For the SIGBUS_MCEERR_AO and SIGBUS_MCEERR_AR, we have a
Hi James,
On 2017/12/7 14:37, gengdongjiu wrote:
>> We need to tackle (1) and (3) separately. For (3) we need some API that lets
>> Qemu _trigger_ an SError in the guest, with a specified ESR. But, we don't
>> have
>> a way of migrating pending SError yet... wh
change the mail title and resend.
Hi James/All,
If the user space application happen page table RAS error,Memory error
handler(memory_failure()) will do nothing except making a poisoned page flag,
and fault handler in arch/arm64/mm/fault.c
will deliver a signal to kill this application. when t
Hi James/All,
If the user space application happen page table RAS error,Memory error
handler(memory_failure()) will do nothing except making a poisoned page flag,
and fault handler in arch/arm64/mm/fault.c
will deliver a signal to kill this application. when this application exits, it
will ca
On 2017/12/13 18:09, Suzuki K Poulose wrote:
>> Reviewed-by: Dave Martin
>
> Looks good to me.
>
> Reviewed-by: Suzuki K Poulose
Thanks a lot to Suzuki's review.
> Reviewed-by: James Morse
>
>
> Nit: Your 'RESEND V2' and 'V2' are not the same patch.
> 'RESEND' is to indicate you're reposting exactly the same patch, usually with
> a
> fixed CC list. Anyone who receives both can ignore one as you've said they are
> the same.
James,
Thanks for the remin
On 2017/12/12 22:53, Dave Martin wrote:
>> +HWCAP_FHM
> This needs to match the name of the #define in hwcap.h.
Thanks for the comments, have changed it.
>
> With that change, Reviewed-by: Dave Martin
Dave, appreciate for the review
>
> Cheers
> ---Dave
>
>
On 2017/12/12 11:31, Xie XiuQi wrote:
>> +return 0;
> It looks good to me. do_sea() has done all necessary action for SEA, so it
> should always return 0,
> no matter ghes_notify_sea() return true or false.
yes, it is.
>
> Reviewed-by: Xie XiuQi
Thanks XiuQi's review and comments.
>
>>
On 2017/12/12 2:58, Suzuki K Poulose wrote:
> Hi gengdongjiu
>
> Sorry for the late response. I have a similar patch to add the support for
> "FHM", which I was about to post it this week.
Suzuki, you are welcome.
May be you can not post again to avoid the duplicate revie
On 2017/12/11 21:29, Dave Martin wrote:
>> Thanks for the point out.
>> In fact, this feature only adds two instructions:
>> FP16 * FP16 + FP32
>> FP16 * FP16 - FP32
>>
>> The spec call this bit to ID_AA64ISAR0_EL1.FHM, I do not know why it
>> will call "FHM", I think call it "FMLXL" may be bette
Hi James,
Thanks for your review and suggestion.
> Hi gengdongjiu,
>
> On 08/12/17 04:43, gengdongjiu wrote:
> > by the way, I think also change the info.si_code to "BUS_MCEERR_AR" is
> > better, as shown [1].
> > BUS_MCEERR_AR can tell user space
On 2017/12/11 19:59, Dave P Martin wrote:
> On Sat, Dec 09, 2017 at 03:28:42PM +, Dongjiu Geng wrote:
>> ARM v8.4 extensions include support for new floating point
>> multiplication variant instructions to the AArch64 SIMD
>
> Do we have any human-readable description of what the new instruct
Hi James, Will
On 2017/12/7 22:32, James Morse wrote:
> Hi gengdongjiu, Will,
>
> On 07/12/17 05:55, gengdongjiu wrote:
>> On 2017/12/7 0:15, Will Deacon wrote:
>>>> --- a/arch/arm64/mm/fault.c
>>>> +++ b/arch/arm64/mm/fault.c
>>>> @@ -5
Hi James,
On 2017/12/7 3:04, James Morse wrote:
> Hi gengdongjiu,
>
> On 06/12/17 10:26, gengdongjiu wrote:
>> On 2017/11/15 0:00, James Morse wrote:
>>>> + * error has not been propagated
>>>> + */
>>>> + run->
On 2017/12/7 0:15, Will Deacon wrote:
>> --- a/arch/arm64/mm/fault.c
>> +++ b/arch/arm64/mm/fault.c
>> @@ -570,7 +570,6 @@ static int do_sea(unsigned long addr, unsigned int esr,
>> struct pt_regs *regs)
>> {
>> struct siginfo info;
>> const struct fault_info *inf;
>> -int ret = 0;
On 2017/11/15 0:00, James Morse wrote:
>> + * error has not been propagated
>> + */
>> +run->exit_reason = KVM_EXIT_EXCEPTION;
>> +run->ex.exception = ESR_ELx_EC_SERROR;
>> +run->ex.error_code = KVM_SEI_SEV_RECOVERABLE;
>> +re
change the mail subject and resend the mail
On 2017/12/6 16:56, gengdongjiu wrote:
>
> On 2017/12/6 0:57, Andi Kleen wrote:
> x86 doesn't handle it.
>
> There are lots of memory types that are not handled by MCE recovery
> because it is just too difficult. In general
On 2017/12/6 0:57, Andi Kleen wrote:
> x86 doesn't handle it.
>
> There are lots of memory types that are not handled by MCE recovery
> because it is just too difficult. In general MCE recovery focuses on
> memory types that use up significant percent of total memory. Page tables
> are normally
gengdongjiu :
> Hi all,
>Sorry to disturb you. Now the ARM64 has supported the RAS, when enabling
> this feature, we encounter a issue. If the user space application happen page
> table RAS error,
> Memory error handler(memory_failure()) will do nothing except make a poisoned
&
Hi all,
Sorry to disturb you. Now the ARM64 has supported the RAS, when enabling
this feature, we encounter a issue. If the user space application happen page
table RAS error,
Memory error handler(memory_failure()) will do nothing except make a poisoned
page flag, and fault handler in arch/ar
>
> Well, if the feature is not going to be upstream, the change may not be
> accepted.
> You could always add your custom code for "matching" the capability, like for
> e.g,
> ARM64_HAS_VIRT_HOST_EXTN.
Ok, Suzuki, thanks for your suggestion and answer.
>
> Cheers
> Suzuki
>
> .
>
On 2017/11/28 19:40, Suzuki K Poulose wrote:
> Cc: linux-arm-kernel
>
> On 28/11/17 11:17, gengdongjiu wrote:
>> Hi,suzuki/mark,
>
> Hello!
>
> Please Cc linux-arm-kernel mailing list in the future for any arm/arm64 kernel
> related queries.
Thanks a lot for t
Hi,suzuki/mark,
very sorry to disturb you, I have a question that want to consult with you.
For the CPU feature detection,
why we use extract 4 bits width for the feature match instead of the actual
bits number[1]? may be the actual hardware feature bit more than 4 bits.
thanks!
static inlin
Hi James,
Thanks a lot for the review.
On 2017/11/15 0:00, James Morse wrote:
> Hi Dongjiu Geng,
>
> On 10/11/17 19:54, Dongjiu Geng wrote:
>> If it is not RAS SError, directly inject virtual SError,
>> which will keep the old way. If it is RAS SError, firstly
>> let host ACPI module to handl
Hi James,
Thank you very much for your comments and review.
On 2017/11/15 0:00, James Morse wrote:
> Hi Dongjiu Geng,
>
> On 10/11/17 19:54, Dongjiu Geng wrote:
>> This series patches mainly do below things:
>>
>> 1. Trap RAS ERR* registers Accesses to EL2 from Non-secure EL1,
>>KVM will w
Hi James,
>
> Can I take that as a 'Tested-by:'?
>
> These tags also let us record who has a system that can test changes to this
> driver.
sure.
Thanks for the fixing.
Qiang Zheng who is my colleague have tested it.
CC Qiang.
Tested-by: Qiang Zheng
>
>
> Thanks,
>
> James
>
>
>
>
On 2017/11/1 22:16, Mark Rutland wrote:
>> it will report Error.
> Alternatives cannot be nested. You need to define a cap like:
>
> ARM64_HAS_RAS_NOT_IESB
>
> ... which is set when ARM64_HAS_RAS_EXTN && !ARM64_HAS_IESB.
>
> Then you can do:
>
> alternative_if ARM64_HAS_RAS_NOT_IESB
>
>
> On 01/11/17 12:54, gengdongjiu wrote:
> > Hi Robin,
> >
> > On 2017/11/1 19:24, Robin Murphy wrote:
> >>> + esb
> >>> +alternative_else_nop_endif
> >>> +1:
> >>> + .endm
> >> Having a branch in here is prett
Hi Robin,
On 2017/11/1 19:24, Robin Murphy wrote:
>> +esb
>> +alternative_else_nop_endif
>> +1:
>> +.endm
> Having a branch in here is pretty horrible, and furthermore using label
> number 1 has a pretty high chance of subtly breaking code where this
> macro is inserted.
>
> Can we not so
On 2017/11/1 19:32, James Morse wrote:
>> RAS&IESB for firmware first support". In Huawei's platform, we do not
>> support IESB, so software needs to insert that.
> Surely you don't implement it because your CPU doesn't need it. Can
> unrecoverable errors really cross an exception without becoming
On 2017/10/31 23:38, James Morse wrote:
> CC'd people I've seen posting CPER log fragments, could you give this a
> test on your platforms?
Thanks for the fixing, not found obviously issue.
On 2017/10/29 9:12, Marc Zyngier wrote:
> I'm sorry, but I can't manage to parse this commit message. How about
> something like this?
>
> "kvm_vcpu_dabt_isextabt() tries to match a full fault syndrome, but
> calls kvm_vcpu_trap_get_fault_type() that only returns the fault class,
> thus reducin
On 2017/10/28 2:28, Marc Zyngier wrote:
>> 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.
Ok,
>
> On Thu, Oct 26 2017 at 6:07:01 pm BST, Dongjiu Geng
> 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
>
Hi Naoya,
very sorry to disturb you, I want to consult you about the handing to error
page type in memory_failure().
If the error page is the current task's page table, will the memory_failure not
handling that?
>From my test, I found the memory_failure() consider the error page table
>physic
On 2017/10/22 17:38, Rafael J. Wysocki wrote:
> On Sun, Oct 22, 2017 at 8:54 AM, Dongjiu Geng wrote:
>> For the SEA notification, the two functions ghes_sea_add() and
>> ghes_sea_remove() are only called when CONFIG_ACPI_APEI_SEA
>> is defined. If not, it will return errors in the ghes_probe()
>
On 2017/10/22 17:38, Rafael J. Wysocki wrote:
>> Tested-by: Tyler Baicar
>> Reviewed-by: Borislav Petkov
> I applied one of the previous iterations.
>
> Do I need to replace it with this version?
>
Thanks a lot Rafael's applying.
Both for me is OK.
If Borislav agreed, may be not.
I will pay att
On 2017/10/21 20:15, Borislav Petkov wrote:
>> Signed-off-by: Dongjiu Geng
>> Tested-by: Tyler Baicar
>> Signed-off-by: Borislav Petkov
> I gave you Reviewed-by, not Signed-off-by.
>
> Before you send more patches, read this:
>
> Documentation/process/submitting-patches.rst
>
> You can read
1 - 100 of 229 matches
Mail list logo
