Re: [PATCH v4 00/21] SError rework + RAS for firmware first support

Hi james, On 2017/11/16 2:25, James Morse wrote: > What about 32bit? The register names and sizes are different. User-space would > need a separate implementation to drive this. This is easier for the kernel > to do I agree with you that using different register names and sizes, such as 32 bit.

Re: [PATCH v4 00/21] SError rework + RAS for firmware first support

On Tue, Nov 14, 2017 at 04:03:01PM +, James Morse wrote: > Hi Christoffer, > > On 13/11/17 11:29, Christoffer Dall wrote: > > On Thu, Nov 09, 2017 at 06:14:56PM +, James Morse wrote: > >> On 19/10/17 15:57, James Morse wrote: > >>> Known issues: > >> [...] > >>> * KVM-Migration:

Re: [PATCH v4 00/21] SError rework + RAS for firmware first support

On Mon, Nov 13, 2017 at 01:05:19PM +, Peter Maydell wrote: > On 13 November 2017 at 11:29, Christoffer Dall wrote: > > I'm thinking this is analogous to migrating a VM that uses an irqchip in > > userspace and has set the IRQ or FIQ lines using KVM_IRQ_LINE. My > > feeling

Re: [PATCH v4 00/21] SError rework + RAS for firmware first support

Hi gengdongjiu, On 15/11/17 09:15, gengdongjiu wrote: > On 2017/11/15 0:03, James Morse wrote: >>> Hope this helps? >> Yes, I'll go looking for a way to expose VSESR_EL2 to user-space. > > what is the purpose to expose VSESR_EL2? > do you mean set its value after migration? Yes. Ideally Qemu

Re: [PATCH v4 00/21] SError rework + RAS for firmware first support

> > (While VSESR_EL2 is 64bit[0], the value gets written into the ESR, which is > 32bit, so I doubt the top 32bits can be used, currently they are all > reserved.) In fact the valid bits for vsesr_el2 is 25bit, which will set to ESR.ISS, bits [24:0]. ESR.IL and ESR.EC are not set by vsesr_el2.

Re: [PATCH v4 00/21] SError rework + RAS for firmware first support

Hi james, On 2017/11/15 0:03, James Morse wrote: >> Hope this helps? > Yes, I'll go looking for a way to expose VSESR_EL2 to user-space. what is the purpose to expose VSESR_EL2? do you mean set its value after migration? May be we can use similar below Mechanism

Re: [PATCH v4 00/21] SError rework + RAS for firmware first support

Hi Drew, On 13/11/17 16:14, Andrew Jones wrote: > On Mon, Nov 13, 2017 at 12:29:46PM +0100, Christoffer Dall wrote: >> On Thu, Nov 09, 2017 at 06:14:56PM +, James Morse wrote: >>> On 19/10/17 15:57, James Morse wrote: Known issues: * KVM-Migration: VDISR_EL2 is exposed to userspace

Re: [PATCH v4 00/21] SError rework + RAS for firmware first support

Hi Christoffer, On 13/11/17 11:29, Christoffer Dall wrote: > On Thu, Nov 09, 2017 at 06:14:56PM +, James Morse wrote: >> On 19/10/17 15:57, James Morse wrote: >>> Known issues: >> [...] >>> * KVM-Migration: VDISR_EL2 is exposed to userspace as DISR_EL1, but how >>> should >>>HCR_EL2.VSE

Re: [PATCH v4 00/21] SError rework + RAS for firmware first support

On 13 November 2017 at 16:14, Andrew Jones wrote: > On Mon, Nov 13, 2017 at 12:29:46PM +0100, Christoffer Dall wrote: >> I'm thinking this is analogous to migrating a VM that uses an irqchip in >> userspace and has set the IRQ or FIQ lines using KVM_IRQ_LINE. My >> feeling is

Re: [PATCH v4 00/21] SError rework + RAS for firmware first support

On Mon, Nov 13, 2017 at 12:29:46PM +0100, Christoffer Dall wrote: > On Thu, Nov 09, 2017 at 06:14:56PM +, James Morse wrote: > > Hi guys, > > > > On 19/10/17 15:57, James Morse wrote: > > > Known issues: > > [...] > > > * KVM-Migration: VDISR_EL2 is exposed to userspace as DISR_EL1, but how

Re: [PATCH v4 00/21] SError rework + RAS for firmware first support

On 13 November 2017 at 11:29, Christoffer Dall wrote: > I'm thinking this is analogous to migrating a VM that uses an irqchip in > userspace and has set the IRQ or FIQ lines using KVM_IRQ_LINE. My > feeling is that this is also not supported today. Oops, yes, we completely

Re: [PATCH v4 00/21] SError rework + RAS for firmware first support

On Thu, Nov 09, 2017 at 06:14:56PM +, James Morse wrote: > Hi guys, > > On 19/10/17 15:57, James Morse wrote: > > Known issues: > [...] > > * KVM-Migration: VDISR_EL2 is exposed to userspace as DISR_EL1, but how > > should > >HCR_EL2.VSE or VSESR_EL2 be migrated when the guest has an

Re: [PATCH v4 00/21] SError rework + RAS for firmware first support

Hi guys, On 19/10/17 15:57, James Morse wrote: > Known issues: [...] > * KVM-Migration: VDISR_EL2 is exposed to userspace as DISR_EL1, but how > should >HCR_EL2.VSE or VSESR_EL2 be migrated when the guest has an SError pending > but >hasn't taken it yet...? I've been trying to work

Re: [PATCH v4 00/21] SError rework + RAS for firmware first support

On Wed, Nov 01, 2017 at 03:23:50PM +, James Morse wrote: > Hi guys, > > On 31/10/17 10:08, Will Deacon wrote: > > On Tue, Oct 31, 2017 at 07:35:35AM +0100, Christoffer Dall wrote: > >> On Thu, Oct 19, 2017 at 03:57:46PM +0100, James Morse wrote: > >>> The aim of this series is to enable IESB

Re: [PATCH v4 00/21] SError rework + RAS for firmware first support

Hi guys, On 31/10/17 10:08, Will Deacon wrote: > On Tue, Oct 31, 2017 at 07:35:35AM +0100, Christoffer Dall wrote: >> On Thu, Oct 19, 2017 at 03:57:46PM +0100, James Morse wrote: >>> The aim of this series is to enable IESB and add ESB-instructions to let us >>> kick any pending RAS errors into

Re: [PATCH v4 00/21] SError rework + RAS for firmware first support

On Tue, Oct 31, 2017 at 07:35:35AM +0100, Christoffer Dall wrote: > Hi James, Catalin, and Will, > > On Thu, Oct 19, 2017 at 03:57:46PM +0100, James Morse wrote: > > Hello, > > > > The aim of this series is to enable IESB and add ESB-instructions to let us > > kick any pending RAS errors into

Re: [PATCH v4 00/21] SError rework + RAS for firmware first support

Hi James, Catalin, and Will, On Thu, Oct 19, 2017 at 03:57:46PM +0100, James Morse wrote: > Hello, > > The aim of this series is to enable IESB and add ESB-instructions to let us > kick any pending RAS errors into firmware to be handled by firmware-first. > > Not all systems will have this

[PATCH v4 00/21] SError rework + RAS for firmware first support

Hello, The aim of this series is to enable IESB and add ESB-instructions to let us kick any pending RAS errors into firmware to be handled by firmware-first. Not all systems will have this firmware, so these RAS errors will become pending SErrors. We should take these as quickly as possible and