Re: [PATCH v6 3/7] acpi: apei: remove the unused code

Hi gengdongjiu, On 04/09/17 12:43, gengdongjiu wrote: > On 2017/9/1 1:50, James Morse wrote: >> On 28/08/17 11:38, Dongjiu Geng wrote: >>> In current code logic, the two functions ghes_sea_add() and >>> ghes_sea_remove() are only called when CONFIG_ACPI_APEI_SEA >>> is defined. If not, it will

答复: [PATCH v6 4/7] arm64: kvm: support user space to query RAS extension feature

HI James, [...] > > The code to signal memory-failure to user-space doesn't depend on the CPU's > RAS-extensions. I roughly check your answer and agree with your general idea. late I will check it in detail. I have a question, do you sure that if CPU does not support RAS-extensions kernel can

答复: [PATCH v11 5/6] target-arm: kvm64: handle SIGBUS signal for synchronous External Abort

[...] > > > > /* > > * xx > > */ > > void kvm_hwpoison_page_add(ram_addr_t ram_addr); > > It should be in the doc-comment format, which begins "/**" and has some > stylization of how you list parameters and so on. Lots of > examples in the existing headers.

Re: [PATCH v3 4/5] KVM: arm/arm64: Support VGIC dist pend/active changes for mapped IRQs

On 08/09/17 17:05, Christoffer Dall wrote: > On Fri, Sep 8, 2017 at 4:27 PM, Auger Eric wrote: >> Hi Marc, >> >> On 08/09/2017 15:32, Marc Zyngier wrote: >>> On 08/09/17 14:04, Auger Eric wrote: Hi Christoffer, On 06/09/2017 14:26, Christoffer Dall wrote:

Re: [PATCH v11 5/6] target-arm: kvm64: handle SIGBUS signal for synchronous External Abort

On 8 September 2017 at 17:17, gengdongjiu wrote: >> >> This code has all just been copied-and-pasted from target/i386/kvm.c. >> Please instead abstract it out properly into a cpu-independent source file. > > > Yes, it copied from x86. > Do you mean abstracting this code to

Re: [PATCH v11 5/6] target-arm: kvm64: handle SIGBUS signal for synchronous External Abort

Hi peter, Sorry for the late response. > > On 18 August 2017 at 15:23, Dongjiu Geng wrote: > > Add SIGBUS signal handler. In this handler, it checks the exception > > type, translates the host VA which is delivered by host or KVM to > > guest PA, then fills this PA to

Re: [PATCH v3 4/5] KVM: arm/arm64: Support VGIC dist pend/active changes for mapped IRQs

On Fri, Sep 8, 2017 at 4:27 PM, Auger Eric wrote: > Hi Marc, > > On 08/09/2017 15:32, Marc Zyngier wrote: >> On 08/09/17 14:04, Auger Eric wrote: >>> Hi Christoffer, >>> >>> On 06/09/2017 14:26, Christoffer Dall wrote: For mapped IRQs (with the HW bit set in the LR) we

Re: 答复: [PATCH v6 4/7] arm64: kvm: support user space to query RAS extension feature

On 8 September 2017 at 15:34, gengdongjiu wrote: > Hi Peter/ shenglong, >What is your idea about it? We may need to consult with you about it. I agree with what I take to be James' general point that we should be careful to distinguish "KVM supports API A to do a

Re: [PATCH v11 4/6] target-arm: kvm64: detect guest RAS EXTENSION feature

On 8 September 2017 at 15:26, gengdongjiu wrote: >> Shouldn't we need to also tell the kernel that we actually want >> it to expose RAS to the guest? Compare the PMU code in this function, >> where we set a kvm_init_features bit to do this. > In the PMU code, it indeed

[PATCH 2/2] KVM: arm/arm64: Fix vgic_mmio_change_active with PREEMPT_RT

From: Christoffer Dall Getting a per-CPU variable requires a non-preemptible context and we were relying on a normal spinlock to disable preemption as well. This asusmption breaks with PREEMPT_RT and was observed on v4.9 using PREEMPT_RT. This change moves the spinlock

[PATCH 1/2] KVM: arm/arm64: Remove redundant preemptible checks

From: Christoffer Dall The __this_cpu_read() and __this_cpu_write() functions already implement checks for the required preemption levels when using CONFIG_DEBUG_PREEMPT which gives you nice error messages and such. Therefore there is no need to explicitly check this using a

[PATCH 0/2] Fix preemption issues with kvm_arm_get_running_vcpu

From: Christoffer Dall These two patches slightly improves our preemption configuration when accessing the per-CPU variables holding the currently running VCPU by removing a redundant check and rearranging calling code from non-preemptible context on RT systems. I'm not

答复: [PATCH v6 4/7] arm64: kvm: support user space to query RAS extension feature

Hi James, Thanks a lot for your detailed comments. CC Peter. Peter is Qemu expert. Let us see his suggestion. > > Hi gengdongjiu, > > On 05/09/17 08:18, gengdongjiu wrote: > > On 2017/9/1 2:04, James Morse wrote: > >> On 28/08/17 11:38, Dongjiu Geng wrote: > >>> Userspace will want to check

Re: [PATCH v11 4/6] target-arm: kvm64: detect guest RAS EXTENSION feature

Hi Peter, Sorry for my late response. > > On 18 August 2017 at 15:23, Dongjiu Geng wrote: > > check if kvm supports guest RAS EXTENSION. if so, set corresponding > > feature bit for vcpu. > > > > Signed-off-by: Dongjiu Geng > > --- > >

Re: [PATCH v3 4/5] KVM: arm/arm64: Support VGIC dist pend/active changes for mapped IRQs

Hi Marc, On 08/09/2017 15:32, Marc Zyngier wrote: > On 08/09/17 14:04, Auger Eric wrote: >> Hi Christoffer, >> >> On 06/09/2017 14:26, Christoffer Dall wrote: >>> For mapped IRQs (with the HW bit set in the LR) we have to follow some >>> rules of the architecture. One of these rules is that VM

Re: [PATCH] arm64: KVM: VHE: reset PSTATE.UAO when switch to host

Hi Marc, > > On 08/09/17 10:05, gengdongjiu wrote: > > Marc, > >Thanks for reply. > > > > On 2017/9/8 16:21, Marc Zyngier wrote: > >>> Marc, > >>> > >>> sorry I have another question for the PAN. [...] > There cannot be any userspace mapping at EL2 when non-VHE, so there cannot be > any

Re: [PATCH v3 4/5] KVM: arm/arm64: Support VGIC dist pend/active changes for mapped IRQs

On 08/09/17 14:04, Auger Eric wrote: > Hi Christoffer, > > On 06/09/2017 14:26, Christoffer Dall wrote: >> For mapped IRQs (with the HW bit set in the LR) we have to follow some >> rules of the architecture. One of these rules is that VM must not be >> allowed to deactivate a virtual interrupt

Re: [PATCH v2 19/28] arm64/sve: ptrace and ELF coredump support

On Thu, Sep 07, 2017 at 05:11:45AM +, Okamoto, Takayuki wrote: > Hi Dave, > > Thank you for your reply. > > > Your fix looks correct and seems to work. For stylistic reasons, I may > > write it like this instead, but the effect should be the same: > > > > header->max_vl = sve_max_vl; >

Re: [PATCH v3 4/5] KVM: arm/arm64: Support VGIC dist pend/active changes for mapped IRQs

Hi Christoffer, On 06/09/2017 14:26, Christoffer Dall wrote: > For mapped IRQs (with the HW bit set in the LR) we have to follow some > rules of the architecture. One of these rules is that VM must not be > allowed to deactivate a virtual interrupt with the HW bit set unless the > physical

Re: [PATCH] arm64: KVM: VHE: reset PSTATE.UAO when switch to host

On 08/09/17 10:05, gengdongjiu wrote: > Marc, >Thanks for reply. > > On 2017/9/8 16:21, Marc Zyngier wrote: >>> Marc, >>> >>> sorry I have another question for the PAN. >>> >>> In the non-VHE mode, The host kernel is running in the EL1. Before >>> host kernel enter guest, host OS will call

Re: [PATCH] arm64: KVM: VHE: reset PSTATE.UAO when switch to host

Marc, Thanks for reply. On 2017/9/8 16:21, Marc Zyngier wrote: >> Marc, >> >> sorry I have another question for the PAN. >> >> In the non-VHE mode, The host kernel is running in the EL1. Before >> host kernel enter guest, host OS will call 'HVC' instruction to do >> the world-switch, and the

Re: [PATCH] arm64: KVM: VHE: reset PSTATE.UAO when switch to host

On Fri, 8 Sep 2017 15:19:21 +0800 gengdongjiu wrote: > On 2017/9/7 23:23, Marc Zyngier wrote: > > On 07/09/17 16:03, gengdongjiu wrote: > >>> On 07/09/17 12:49, gengdongjiu wrote: > > [...] > > > > > I really cannot think of a good reason why we'd want to do

Re: [PATCH] arm64: KVM: VHE: reset PSTATE.UAO when switch to host

On 2017/9/7 23:23, Marc Zyngier wrote: > On 07/09/17 16:03, gengdongjiu wrote: >>> On 07/09/17 12:49, gengdongjiu wrote: [...] > > I really cannot think of a good reason why we'd want to do that. Playing > with set_fs() is almost universally wrong, and I'm certainly going to > oppose to