All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Morse <james.morse@arm.com>
To: gengdongjiu <gengdongjiu@huawei.com>
Cc: mtsirkin@redhat.com, kvm@vger.kernel.org, tbaicar@codeaurora.org,
	qemu-devel@nongnu.org, wangxiongfeng2@huawei.com,
	ben@skyportsystems.com, linux@armlinux.org.uk,
	kvmarm@lists.cs.columbia.edu, huangshaoyu@huawei.com,
	lersek@redhat.com, songwenjun@huawei.com, wuquanming@huawei.com,
	marc.zyngier@arm.com, qemu-arm@nongnu.org, imammedo@redhat.com,
	linux-arm-kernel@lists.infradead.org, ard.biesheuvel@linaro.org,
	pbonzini@redhat.com
Subject: Re: [PATCH v3 2/3] arm64: kvm: inject SError with virtual syndrome
Date: Fri, 12 May 2017 18:24:30 +0100	[thread overview]
Message-ID: <5915EFCE.7070202@arm.com> (raw)
In-Reply-To: <bbceff7a-1ebf-e6de-abc6-e35b71c939f1@huawei.com>

Hi gengdongjiu,

On 05/05/17 14:19, gengdongjiu wrote:
> On 2017/5/2 23:37, James Morse wrote:
> > ... I think you expect an SError to arrive at EL2 and have its ESR recorded in
> > vcpu->arch.fault.vsesr_el2. Some time later KVM decides to inject an SError into
> > the guest, and this ESR is reused...
> > 
> > We shouldn't do this. Qemu/kvmtool may want to inject a virtual-SError that
> > never started as a physical-SError. Qemu/kvmtool may choose to notify the guest
> > of RAS events via another mechanism, or not at all.
> > 
> > KVM should not give the guest an ESR value of its choice. For SError the ESR
> > describes whether the error is corrected, correctable or fatal. Qemu/kvmtool
> > must choose this.

> Below is my previous solution:
> For the SError, CPU will firstly trap to EL3 firmware and records the syndrome to ESR_EL3.
> Before jumping to El2 hypervisors, it will copy the esr_el3 to esr_el2.

(Copying the ESR value won't always be the right thing to do.)


> so in order to pass this syndrome to vsesr_el2, using the esr_el2 value to assign it.

> If Qemu/kvmtool chooses the ESR value and ESR only describes whether the error is corrected/correctable/fatal,
> whether the information is not enough for the guest?

So the API should specify which of these three severities to use? I think this
is too specific. The API should be useful for anything the VSE/VSESR hardware
can do.

VSESR_EL2 is described in the RAS spec: 4.4.12 [0], its a 64 bit register. I
think we should let Qemu/kvmtool specify any 64bit value here, but KVM should
reject values that try to set bits described as RES0.

This would let Qemu/kvmtool specify any SError ISS, either setting ESR_ELx.IDS
and some virtual-machine specific value, or encoding any severity in AET and
choosing the DFSC/EA bits appropriately.


>> > I think we need an API that allows Qemu/kvmtool to inject SError into a guest,
>> > but that isn't quite what you have here.

> KVM provides APIs to inject the SError, Qemu/kvmtool call the API though IOCTL, may be OK?

(just the one API call), yes.


Thanks,

James

[0]
https://static.docs.arm.com/ddi0587/a/RAS%20Extension-release%20candidate_march_29.pdf

WARNING: multiple messages have this Message-ID (diff)
From: James Morse <james.morse@arm.com>
To: gengdongjiu <gengdongjiu@huawei.com>
Cc: mtsirkin@redhat.com, kvm@vger.kernel.org, tbaicar@codeaurora.org,
	qemu-devel@nongnu.org, wangxiongfeng2@huawei.com,
	ben@skyportsystems.com, linux@armlinux.org.uk,
	kvmarm@lists.cs.columbia.edu, huangshaoyu@huawei.com,
	lersek@redhat.com, songwenjun@huawei.com, wuquanming@huawei.com,
	marc.zyngier@arm.com, qemu-arm@nongnu.org, imammedo@redhat.com,
	linux-arm-kernel@lists.infradead.org, ard.biesheuvel@linaro.org,
	pbonzini@redhat.com
Subject: Re: [PATCH v3 2/3] arm64: kvm: inject SError with virtual syndrome
Date: Fri, 12 May 2017 18:24:30 +0100	[thread overview]
Message-ID: <5915EFCE.7070202@arm.com> (raw)
In-Reply-To: <bbceff7a-1ebf-e6de-abc6-e35b71c939f1@huawei.com>

Hi gengdongjiu,

On 05/05/17 14:19, gengdongjiu wrote:
> On 2017/5/2 23:37, James Morse wrote:
> > ... I think you expect an SError to arrive at EL2 and have its ESR recorded in
> > vcpu->arch.fault.vsesr_el2. Some time later KVM decides to inject an SError into
> > the guest, and this ESR is reused...
> > 
> > We shouldn't do this. Qemu/kvmtool may want to inject a virtual-SError that
> > never started as a physical-SError. Qemu/kvmtool may choose to notify the guest
> > of RAS events via another mechanism, or not at all.
> > 
> > KVM should not give the guest an ESR value of its choice. For SError the ESR
> > describes whether the error is corrected, correctable or fatal. Qemu/kvmtool
> > must choose this.

> Below is my previous solution:
> For the SError, CPU will firstly trap to EL3 firmware and records the syndrome to ESR_EL3.
> Before jumping to El2 hypervisors, it will copy the esr_el3 to esr_el2.

(Copying the ESR value won't always be the right thing to do.)


> so in order to pass this syndrome to vsesr_el2, using the esr_el2 value to assign it.

> If Qemu/kvmtool chooses the ESR value and ESR only describes whether the error is corrected/correctable/fatal,
> whether the information is not enough for the guest?

So the API should specify which of these three severities to use? I think this
is too specific. The API should be useful for anything the VSE/VSESR hardware
can do.

VSESR_EL2 is described in the RAS spec: 4.4.12 [0], its a 64 bit register. I
think we should let Qemu/kvmtool specify any 64bit value here, but KVM should
reject values that try to set bits described as RES0.

This would let Qemu/kvmtool specify any SError ISS, either setting ESR_ELx.IDS
and some virtual-machine specific value, or encoding any severity in AET and
choosing the DFSC/EA bits appropriately.


>> > I think we need an API that allows Qemu/kvmtool to inject SError into a guest,
>> > but that isn't quite what you have here.

> KVM provides APIs to inject the SError, Qemu/kvmtool call the API though IOCTL, may be OK?

(just the one API call), yes.


Thanks,

James

[0]
https://static.docs.arm.com/ddi0587/a/RAS%20Extension-release%20candidate_march_29.pdf

_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: james.morse@arm.com (James Morse)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 2/3] arm64: kvm: inject SError with virtual syndrome
Date: Fri, 12 May 2017 18:24:30 +0100	[thread overview]
Message-ID: <5915EFCE.7070202@arm.com> (raw)
In-Reply-To: <bbceff7a-1ebf-e6de-abc6-e35b71c939f1@huawei.com>

Hi gengdongjiu,

On 05/05/17 14:19, gengdongjiu wrote:
> On 2017/5/2 23:37, James Morse wrote:
> > ... I think you expect an SError to arrive at EL2 and have its ESR recorded in
> > vcpu->arch.fault.vsesr_el2. Some time later KVM decides to inject an SError into
> > the guest, and this ESR is reused...
> > 
> > We shouldn't do this. Qemu/kvmtool may want to inject a virtual-SError that
> > never started as a physical-SError. Qemu/kvmtool may choose to notify the guest
> > of RAS events via another mechanism, or not at all.
> > 
> > KVM should not give the guest an ESR value of its choice. For SError the ESR
> > describes whether the error is corrected, correctable or fatal. Qemu/kvmtool
> > must choose this.

> Below is my previous solution:
> For the SError, CPU will firstly trap to EL3 firmware and records the syndrome to ESR_EL3.
> Before jumping to El2 hypervisors, it will copy the esr_el3 to esr_el2.

(Copying the ESR value won't always be the right thing to do.)


> so in order to pass this syndrome to vsesr_el2, using the esr_el2 value to assign it.

> If Qemu/kvmtool chooses the ESR value and ESR only describes whether the error is corrected/correctable/fatal,
> whether the information is not enough for the guest?

So the API should specify which of these three severities to use? I think this
is too specific. The API should be useful for anything the VSE/VSESR hardware
can do.

VSESR_EL2 is described in the RAS spec: 4.4.12 [0], its a 64 bit register. I
think we should let Qemu/kvmtool specify any 64bit value here, but KVM should
reject values that try to set bits described as RES0.

This would let Qemu/kvmtool specify any SError ISS, either setting ESR_ELx.IDS
and some virtual-machine specific value, or encoding any severity in AET and
choosing the DFSC/EA bits appropriately.


>> > I think we need an API that allows Qemu/kvmtool to inject SError into a guest,
>> > but that isn't quite what you have here.

> KVM provides APIs to inject the SError, Qemu/kvmtool call the API though IOCTL, may be OK?

(just the one API call), yes.


Thanks,

James

[0]
https://static.docs.arm.com/ddi0587/a/RAS%20Extension-release%20candidate_march_29.pdf

WARNING: multiple messages have this Message-ID (diff)
From: James Morse <james.morse@arm.com>
To: gengdongjiu <gengdongjiu@huawei.com>
Cc: marc.zyngier@arm.com, christoffer.dall@linaro.org,
	rkrcmar@redhat.com, linux@armlinux.org.uk,
	tbaicar@codeaurora.org, imammedo@redhat.com,
	zhaoshenglong@huawei.com, peter.maydell@linaro.org,
	pbonzini@redhat.com, qemu-devel@nongnu.org, qemu-arm@nongnu.org,
	lersek@redhat.com, ard.biesheuvel@linaro.org,
	mtsirkin@redhat.com, drjones@redhat.com, ben@skyportsystems.com,
	kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, xiexiuqi@huawei.com,
	wangxiongfeng2@huawei.com, songwenjun@huawei.com,
	wuquanming@huawei.com, huangshaoyu@huawei.com
Subject: Re: [Qemu-devel] [PATCH v3 2/3] arm64: kvm: inject SError with virtual syndrome
Date: Fri, 12 May 2017 18:24:30 +0100	[thread overview]
Message-ID: <5915EFCE.7070202@arm.com> (raw)
In-Reply-To: <bbceff7a-1ebf-e6de-abc6-e35b71c939f1@huawei.com>

Hi gengdongjiu,

On 05/05/17 14:19, gengdongjiu wrote:
> On 2017/5/2 23:37, James Morse wrote:
> > ... I think you expect an SError to arrive at EL2 and have its ESR recorded in
> > vcpu->arch.fault.vsesr_el2. Some time later KVM decides to inject an SError into
> > the guest, and this ESR is reused...
> > 
> > We shouldn't do this. Qemu/kvmtool may want to inject a virtual-SError that
> > never started as a physical-SError. Qemu/kvmtool may choose to notify the guest
> > of RAS events via another mechanism, or not at all.
> > 
> > KVM should not give the guest an ESR value of its choice. For SError the ESR
> > describes whether the error is corrected, correctable or fatal. Qemu/kvmtool
> > must choose this.

> Below is my previous solution:
> For the SError, CPU will firstly trap to EL3 firmware and records the syndrome to ESR_EL3.
> Before jumping to El2 hypervisors, it will copy the esr_el3 to esr_el2.

(Copying the ESR value won't always be the right thing to do.)


> so in order to pass this syndrome to vsesr_el2, using the esr_el2 value to assign it.

> If Qemu/kvmtool chooses the ESR value and ESR only describes whether the error is corrected/correctable/fatal,
> whether the information is not enough for the guest?

So the API should specify which of these three severities to use? I think this
is too specific. The API should be useful for anything the VSE/VSESR hardware
can do.

VSESR_EL2 is described in the RAS spec: 4.4.12 [0], its a 64 bit register. I
think we should let Qemu/kvmtool specify any 64bit value here, but KVM should
reject values that try to set bits described as RES0.

This would let Qemu/kvmtool specify any SError ISS, either setting ESR_ELx.IDS
and some virtual-machine specific value, or encoding any severity in AET and
choosing the DFSC/EA bits appropriately.


>> > I think we need an API that allows Qemu/kvmtool to inject SError into a guest,
>> > but that isn't quite what you have here.

> KVM provides APIs to inject the SError, Qemu/kvmtool call the API though IOCTL, may be OK?

(just the one API call), yes.


Thanks,

James

[0]
https://static.docs.arm.com/ddi0587/a/RAS%20Extension-release%20candidate_march_29.pdf

  reply	other threads:[~2017-05-12 17:21 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-30  5:37 [PATCH v3 1/3] arm64: kvm: support kvmtool to detect RAS extension feature Dongjiu Geng
2017-04-30  5:37 ` [Qemu-devel] " Dongjiu Geng
2017-04-30  5:37 ` Dongjiu Geng
2017-04-30  5:37 ` Dongjiu Geng
2017-04-30  5:37 ` Dongjiu Geng
2017-04-30  5:37 ` [PATCH v3 2/3] arm64: kvm: inject SError with virtual syndrome Dongjiu Geng
2017-04-30  5:37   ` [Qemu-devel] " Dongjiu Geng
2017-04-30  5:37   ` Dongjiu Geng
2017-04-30  5:37   ` Dongjiu Geng
2017-04-30  5:37   ` Dongjiu Geng
2017-05-02  8:03   ` Christoffer Dall
2017-05-02  8:03     ` [Qemu-devel] " Christoffer Dall
2017-05-02  8:03     ` Christoffer Dall
2017-05-02  8:03     ` Christoffer Dall
2017-05-02 12:20     ` gengdongjiu
2017-05-02 12:20       ` [Qemu-devel] " gengdongjiu
2017-05-02 12:20       ` gengdongjiu
2017-05-02 12:20       ` gengdongjiu
2017-05-02 12:20       ` [Qemu-arm] " gengdongjiu
2017-05-02 15:37   ` James Morse
2017-05-02 15:37     ` [Qemu-devel] " James Morse
2017-05-02 15:37     ` James Morse
2017-05-05 13:19     ` gengdongjiu
2017-05-05 13:19       ` [Qemu-devel] " gengdongjiu
2017-05-05 13:19       ` gengdongjiu
2017-05-05 13:19       ` [Qemu-arm] " gengdongjiu
2017-05-12 17:24       ` James Morse [this message]
2017-05-12 17:24         ` [Qemu-devel] " James Morse
2017-05-12 17:24         ` James Morse
2017-05-12 17:24         ` James Morse
2017-05-21  9:08         ` gengdongjiu
2017-05-21  9:08           ` [Qemu-devel] " gengdongjiu
2017-05-21  9:08           ` gengdongjiu
2017-05-21  9:08           ` gengdongjiu
2017-04-30  5:37 ` [PATCH v3 3/3] arm/arm64: signal SIBGUS and inject SEA Error Dongjiu Geng
2017-04-30  5:37   ` [Qemu-devel] " Dongjiu Geng
2017-04-30  5:37   ` Dongjiu Geng
2017-04-30  5:37   ` Dongjiu Geng
2017-04-30  5:37   ` Dongjiu Geng
2017-05-02 15:41   ` James Morse
2017-05-02 15:41     ` [Qemu-devel] " James Morse
2017-05-02 15:41     ` James Morse
2017-05-02  7:56 ` [PATCH v3 1/3] arm64: kvm: support kvmtool to detect RAS extension feature Christoffer Dall
2017-05-02  7:56   ` [Qemu-devel] " Christoffer Dall
2017-05-02  7:56   ` Christoffer Dall
2017-05-02 11:05   ` gengdongjiu
2017-05-02 11:05     ` [Qemu-devel] " gengdongjiu
2017-05-02 11:05     ` gengdongjiu
2017-05-02 11:05     ` gengdongjiu
2017-05-02 11:05     ` [Qemu-arm] " gengdongjiu
2017-05-02 12:15   ` gengdongjiu
2017-05-02 12:15     ` [Qemu-devel] " gengdongjiu
2017-05-02 12:15     ` gengdongjiu
2017-05-02 12:15     ` gengdongjiu
2017-05-02 12:15     ` [Qemu-arm] " gengdongjiu
2017-05-02 15:48   ` Paolo Bonzini
2017-05-02 15:48     ` [Qemu-devel] " Paolo Bonzini
2017-05-02 15:48     ` Paolo Bonzini
2017-05-04  8:19     ` James Morse
2017-05-04  8:19       ` [Qemu-devel] " James Morse
2017-05-04  8:19       ` James Morse
2017-05-04  8:19       ` James Morse
2017-05-02 15:29 ` James Morse
2017-05-02 15:29   ` [Qemu-devel] " James Morse
2017-05-02 15:29   ` James Morse
2017-05-02 15:29   ` James Morse
2017-05-04 15:49   ` James Morse
2017-05-04 15:49     ` [Qemu-devel] " James Morse
2017-05-04 15:49     ` James Morse
2017-05-04 15:49     ` James Morse
2017-05-05 12:44     ` gengdongjiu
2017-05-05 12:44       ` [Qemu-devel] " gengdongjiu
2017-05-05 12:44       ` gengdongjiu
2017-05-05 12:44       ` gengdongjiu
2017-06-26  5:22   ` gengdongjiu
2017-06-26  5:22     ` [Qemu-devel] " gengdongjiu
2017-06-26  5:22     ` gengdongjiu
2017-06-26  5:22     ` [Qemu-arm] " gengdongjiu

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=5915EFCE.7070202@arm.com \
    --to=james.morse@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=ben@skyportsystems.com \
    --cc=gengdongjiu@huawei.com \
    --cc=huangshaoyu@huawei.com \
    --cc=imammedo@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=lersek@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=marc.zyngier@arm.com \
    --cc=mtsirkin@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=songwenjun@huawei.com \
    --cc=tbaicar@codeaurora.org \
    --cc=wangxiongfeng2@huawei.com \
    --cc=wuquanming@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.