Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

On Mon, Apr 24, 2017 at 1:30 PM, Arnd Bergmann wrote: > How about this approach then: > > - To keep it simple, we update the README.rst to say that a minimum > gcc-4.3 is required, while recommending gcc-4.9 for all architectures > - Support for gcc-4.0 and earlier gets removed

Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

On Mon, Apr 24, 2017 at 8:30 PM, Maciej W. Rozycki wrote: > On Mon, 24 Apr 2017, Arnd Bergmann wrote: > >> >> So it still fails, but only because of one compiler error that I can avoid by >> disabling that driver, and you probably use a slightly patched compiler >> version

Re: [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request

On Mon, Apr 24, 2017 at 08:14:54PM +0100, Marc Zyngier wrote: > On 24/04/17 19:59, Daniel Lezcano wrote: > > On Mon, Apr 24, 2017 at 07:46:43PM +0100, Marc Zyngier wrote: > >> On 24/04/17 15:01, Daniel Lezcano wrote: > >>> In the next changes, we track when the interrupts occur in order to > >>>

Re: [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request

On Mon, Apr 24, 2017 at 04:01:31PM +0200, Daniel Lezcano wrote: > In the next changes, we track when the interrupts occur in order to > statistically compute when is supposed to happen the next interrupt. > > In all the interruptions, it does not make sense to store the timer interrupt >

[PATCH 0/2] arm64: Workaround for Thunder KVM hang issues.

We have discovered in rare circumstances, guest execution may result in host not receiving one or more interrupts. This does not otherwise affect guest or host execution and/or isolation. David Daney (2): arm64: Add MIDR values for Cavium cn83XX SoCs arm64: Add workaround for Cavium Thunder

[PATCH 2/2] arm64: Add workaround for Cavium Thunder erratum 30115

Some Cavium Thunder CPUs suffer a problem where a KVM guest may inadvertently cause the host kernel to quit receiving interrupts. The workaround is to toggle the group-1 interrupt enable on each exit from the guest. Signed-off-by: David Daney ---

[PATCH 1/2] arm64: Add MIDR values for Cavium cn83XX SoCs

Signed-off-by: David Daney --- arch/arm64/include/asm/cputype.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h index 0984d1b..235e77d 100644 --- a/arch/arm64/include/asm/cputype.h +++

Re: [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request

On 24/04/17 19:59, Daniel Lezcano wrote: > On Mon, Apr 24, 2017 at 07:46:43PM +0100, Marc Zyngier wrote: >> On 24/04/17 15:01, Daniel Lezcano wrote: >>> In the next changes, we track when the interrupts occur in order to >>> statistically compute when is supposed to happen the next interrupt. >>>

Re: [PATCH] arm64: Add ASM modifier for xN register operands

Hi, El Mon, Apr 24, 2017 at 06:34:14PM +0100 Will Deacon ha dit: > On Mon, Apr 24, 2017 at 06:22:51PM +0100, Ard Biesheuvel wrote: > > On 24 April 2017 at 18:00, Will Deacon wrote: > > > Hi Matthias, > > > > > > On Thu, Apr 20, 2017 at 11:30:53AM -0700, Matthias Kaehlcke

Re: [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request

On Mon, Apr 24, 2017 at 07:46:43PM +0100, Marc Zyngier wrote: > On 24/04/17 15:01, Daniel Lezcano wrote: > > In the next changes, we track when the interrupts occur in order to > > statistically compute when is supposed to happen the next interrupt. > > > > In all the interruptions, it does not

Re: [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request

On 24/04/17 15:01, Daniel Lezcano wrote: > In the next changes, we track when the interrupts occur in order to > statistically compute when is supposed to happen the next interrupt. > > In all the interruptions, it does not make sense to store the timer interrupt > occurences and try to predict

Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

Hi Arnd, On Mon, Apr 24, 2017 at 7:29 PM, Arnd Bergmann wrote: > On Mon, Apr 24, 2017 at 6:53 PM, Maciej W. Rozycki > wrote: >> On Mon, 24 Apr 2017, Arnd Bergmann wrote: >>> > If there's no real good reason (brokenness) to deprecate gcc-4.1, I would >>> >

Re: [PATCH V15 04/11] efi: parse ARM processor error

On Fri, Apr 21, 2017 at 12:22:09PM -0600, Baicar, Tyler wrote: > I guess it's not really needed. It just may be useful considering there can > be numerous error info structures, numerous context info structures, and a > variable length vendor information section. I can move this print to only in >

Re: [PATCH] arm64: Add ASM modifier for xN register operands

On Mon, Apr 24, 2017 at 06:22:51PM +0100, Ard Biesheuvel wrote: > On 24 April 2017 at 18:00, Will Deacon wrote: > > Hi Matthias, > > > > On Thu, Apr 20, 2017 at 11:30:53AM -0700, Matthias Kaehlcke wrote: > >> Many inline assembly statements don't include the 'x' modifier when

Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

On Mon, Apr 24, 2017 at 6:53 PM, Maciej W. Rozycki wrote: > On Mon, 24 Apr 2017, Arnd Bergmann wrote: > >> > If there's no real good reason (brokenness) to deprecate gcc-4.1, I would >> > not >> > do it.I guess most people using old compilers know what they're doing. >> >>

Re: [PATCH] arm64: Add ASM modifier for xN register operands

On 24 April 2017 at 18:00, Will Deacon wrote: > Hi Matthias, > > On Thu, Apr 20, 2017 at 11:30:53AM -0700, Matthias Kaehlcke wrote: >> Many inline assembly statements don't include the 'x' modifier when >> using xN registers as operands. This is perfectly valid, however it >>

Re: [PATCH v3 7/8] arm64: exception: handle asynchronous SError interrupt

Hi Wang Xiongfeng, On 21/04/17 12:33, Xiongfeng Wang wrote: > On 2017/4/20 16:52, James Morse wrote: >> On 19/04/17 03:37, Xiongfeng Wang wrote: >>> On 2017/4/18 18:51, James Morse wrote: The host expects to receive physical SError Interrupts. The ARM-ARM doesn't describe a way to

Re: [PATCH] arm64: Add ASM modifier for xN register operands

Hi Matthias, On Thu, Apr 20, 2017 at 11:30:53AM -0700, Matthias Kaehlcke wrote: > Many inline assembly statements don't include the 'x' modifier when > using xN registers as operands. This is perfectly valid, however it > causes clang to raise warnings like this: > > warning: value size does not

Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

On Mon, 24 Apr 2017, Arnd Bergmann wrote: > > If there's no real good reason (brokenness) to deprecate gcc-4.1, I would > > not > > do it.I guess most people using old compilers know what they're doing. > > What I'm trying to find out first is whether "people regularly using 10+ > year old

Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

On Mon, Apr 24, 2017 at 12:17 PM, Geert Uytterhoeven wrote: > On Mon, Apr 24, 2017 at 11:44 AM, Arnd Bergmann wrote: >> On Sun, Apr 23, 2017 at 10:13 PM, Geert Uytterhoeven >> wrote: >>> On Sat, Apr 22, 2017 at 5:30 PM, Arnd Bergmann

[PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request

In the next changes, we track when the interrupts occur in order to statistically compute when is supposed to happen the next interrupt. In all the interruptions, it does not make sense to store the timer interrupt occurences and try to predict the next interrupt as when know the expiration time.

Re: [PATCH 2/2] kvm: arm/arm64: Fix race in resetting stage2 PGD

On Mon, Apr 24, 2017 at 11:10:24AM +0100, Suzuki K Poulose wrote: > In kvm_free_stage2_pgd() we check the stage2 PGD before holding > the lock and proceed to take the lock if it is valid. And we unmap > the page tables, followed by releasing the lock. We reset the PGD > only after dropping this

Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS

On 04/21/17 15:27, gengdongjiu wrote: > Hi all/Laszlo, > > sorry, I have a question to consult with you. > > > On 2017/4/7 2:55, Laszlo Ersek wrote: >> On 04/06/17 14:35, gengdongjiu wrote: >>> Dear, Laszlo >>>Thanks for your detailed explanation. >>> >>> On 2017/3/29 19:58, Laszlo Ersek

Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

Hi Arnd, On Mon, Apr 24, 2017 at 11:44 AM, Arnd Bergmann wrote: > On Sun, Apr 23, 2017 at 10:13 PM, Geert Uytterhoeven > wrote: >> On Sat, Apr 22, 2017 at 5:30 PM, Arnd Bergmann wrote: >>> Based on what I found so far, gcc-4 can be pretty

[PATCH 0/2] kvm: Fixes for race conditions

The two patches here fixes race conditions in the KVM hypervisor code dealing with the shadow MMU. The first one applies to core KVM code where mmu_notifier->ops.release() could be called twice with one instance possibily accessing a free'd KVM instance. Reported here :

[PATCH 1/2] kvm: Fix mmu_notifier release race

The KVM uses mmu_notifier (wherever available) to keep track of the changes to the mm of the guest. The guest shadow page tables are released when the VM exits via mmu_notifier->ops.release(). There is a rare chance that the mmu_notifier->release could be called more than once via two different

[PATCH 2/2] kvm: arm/arm64: Fix race in resetting stage2 PGD

In kvm_free_stage2_pgd() we check the stage2 PGD before holding the lock and proceed to take the lock if it is valid. And we unmap the page tables, followed by releasing the lock. We reset the PGD only after dropping this lock, which could cause a race condition where another thread waiting on the

Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

On Sun, Apr 23, 2017 at 10:13 PM, Geert Uytterhoeven wrote: > Hi Arnd, > > On Sat, Apr 22, 2017 at 5:30 PM, Arnd Bergmann wrote: >> Based on what I found so far, gcc-4 can be pretty much ruled out from >> being the minimum version based on the number of

Re: [PATCH v3] kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd

On Sat, Apr 22, 2017 at 02:28:44AM +0200, Alexander Graf wrote: > > > On 04.04.17 12:35, Suzuki K Poulose wrote: > > Hi Christoffer, > > > > On 04/04/17 11:13, Christoffer Dall wrote: > > > Hi Suzuki, > > > > > > On Mon, Apr 03, 2017 at 03:12:43PM +0100, Suzuki K Poulose wrote: > > > > In