LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: gengdongjiu <email@example.com> To: James Morse <firstname.lastname@example.org> Cc: "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, Huangshaoyu <email@example.com> Subject: Re: [PATCH v9 5/7] arm64: kvm: Introduce KVM_ARM_SET_SERROR_ESR ioctl Date: Mon, 12 Feb 2018 18:19:24 +0800 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <5A7DDDEE.email@example.com> 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() pseudo-code lets virtual-SError have an > implementation defined syndrome. I've never seen Juno generate anything other > than '0', but it might do something different on a thursday. I checked the "aarch64/exceptions/asynch/AArch64.TakeVirtualSErrorException", you are right, the virtual SError's syndrome value can be 0 or implementation defined value, not always 0, which is decided by the "exception.syndrome<24>". thanks for the clarification. > > The point? We can't know what a CPU without the RAS extensions puts in there. > > Why Does this matter? When migrating a pending SError we have to know the > difference between 'use this 64bit value', and 'the CPU will generate it'. > If I make an SError pending with ESR=0 on a CPU with VSESR, I can't migrated to > a system that generates an impdef SError-ESR, because I can't know it will be 0. Yes, But it will have a issue, For the target system, before taking the SError, no one can know whether its syndrome value is IMPLEMENTATION DEFINED or architecturally defined. when the virtual SError is taken, the ESR_ELx.IDS will be updated, then we can know whether the ESR value is impdef or architecturally defined. It seems migration is only allowed only when target system and source system all support RAS extension, because we do not know whether its syndrome is IMPLEMENTATION DEFINED or architecturally defined. > > >> Does Juno not have RAS Extension? > > It's two types of v8.0 CPU, no RAS extensions. > > >> if yes, I think we can only inject an SError, but can not change its ESR value, >> because it does not have vsesr_el2. > > I agree, this means we need to be able to tell the difference between 'pending' > and 'pending with this ESR'. > > >>> Just because we can't control the ESR doesn't mean injecting an SError isn't >>> something user-space may want to do. > >> yes, we may need to support user-space injects an SError even through CPU does not have RAS Extension. >> >>> If we tackle migration of pending-SError first, I think that will give us the >>> API to create a new pending SError with/without an ESR as appropriate. >> >> sure, we should. Last week, I checked the KVM_GET/SET_VCPU_EVENTS IOCTL, it should meet our >> migration requirements > > Great! > > > Thanks, > > James > >
next prev parent reply other threads:[~2018-02-12 10:21 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-01-24 20:06 [PATCH v9 5/7] arm64: kvm: Introduce KVM_ARM_SET_SERROR_ESR ioctl gengdongjiu 2018-01-30 19:21 ` James Morse 2018-02-05 6:19 ` gengdongjiu 2018-02-09 17:44 ` James Morse 2018-02-12 10:19 ` gengdongjiu [this message] 2018-02-15 17:55 ` James Morse 2018-03-08 6:18 ` gengdongjiu 2018-03-15 20:46 ` James Morse -- strict thread matches above, loose matches on Subject: below -- 2018-01-06 16:02 [PATCH v9 0/7] Handle guest RAS Error in KVM and kernel Dongjiu Geng 2018-01-06 16:02 ` [PATCH v9 5/7] arm64: kvm: Introduce KVM_ARM_SET_SERROR_ESR ioctl Dongjiu Geng 2018-01-23 19:06 ` James Morse
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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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: linkBe 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).