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 kvm_f
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 failures I got.
>> It's much better than 3.
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
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 pat
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 :
http://lkml.kernel.org/
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 much ruled out from
>>> being the minimum version based
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 w
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 loc
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.
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 wrote:
>>> My main motivation for keep on using gcc-4.1 is th
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 compi
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
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 inject
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
>> causes clang to raise
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.
>>
>> What I'm trying to find
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
> >> using xN registe
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
>
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
>>> > not
>>> > do it.I guess most people us
On Mon, 24 Apr 2017, Arnd Bergmann wrote:
> I later tried all mips defconfigs with linux-4.3 and they all failed
> with gcc-4.1.3
> but built fine with gcc-4.9. I've now tried decstation_defconfig in 4.8-rc11,
> and this is what I see for gcc-4.1.3
>
> make O=build/mips/decstation_defconfig/ -skj
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 th
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 ma
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 wrote:
> > >> Many inlin
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.
>>>
>
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
+++ b/arch/arm64/include/asm/cputype.h
@@
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
> occurence
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
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
---
Documentation/arm64/silicon-errata.txt | 1 +
a
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
> >>> st
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 that doesn't have this p
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 from linux/compil
30 matches
Mail list logo