I've been testing the patch few days, the bolloon OOM notifier patch
seems to
do a good jobs freeing memory before OOM killer is about to kill a process.
Although on few ocassions it wasn't enough.
But if you're memory target is anywhere within some range of freeram, and
it's hard to say how much
On Thu, Feb 19, 2015 at 12:23:15PM -0600, Rob Herring wrote:
> On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar
> wrote:
> > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned
> > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page
> > size
> On 19 feb. 2015, at 17:55, Andrew Jones wrote:
>
>> On Thu, Feb 19, 2015 at 05:19:35PM +, Ard Biesheuvel wrote:
>>> On 19 February 2015 at 16:57, Andrew Jones wrote:
On Thu, Feb 19, 2015 at 10:54:43AM +, Ard Biesheuvel wrote:
This is a 0th order approximation of how we could
On Thu, Feb 19, 2015 at 05:19:35PM +, Ard Biesheuvel wrote:
> On 19 February 2015 at 16:57, Andrew Jones wrote:
> > On Thu, Feb 19, 2015 at 10:54:43AM +, Ard Biesheuvel wrote:
> >> This is a 0th order approximation of how we could potentially force the
> >> guest
> >> to avoid uncached ma
On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar
wrote:
> In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned
> in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page
> size due to size alignment checking in vgic driver for VCPU Control and
> V
On 19/02/2015 18:55, Andrew Jones wrote:
>> > > (I don't have an exact number for how many times it went to EL1 because
>> > > access_mair() doesn't have a trace point.)
>> > > (I got the 62873 number by testing a 3rd kernel build that only had patch
>> > > 3/3 applied to the base, and counting
On 19 February 2015 at 16:57, Andrew Jones wrote:
> On Thu, Feb 19, 2015 at 10:54:43AM +, Ard Biesheuvel wrote:
>> This is a 0th order approximation of how we could potentially force the guest
>> to avoid uncached mappings, at least from the moment the MMU is on. (Before
>> that, all of memory
On Thu, Feb 19, 2015 at 10:54:43AM +, Ard Biesheuvel wrote:
> This is a 0th order approximation of how we could potentially force the guest
> to avoid uncached mappings, at least from the moment the MMU is on. (Before
> that, all of memory is implicitly classified as Device-nGnRnE)
>
> The ide
On Tue, Jan 27, 2015 at 12:33:26PM +0530, Pranavkumar Sawargaonkar wrote:
> In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned
> in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page
> size due to size alignment checking in vgic driver for VCPU Control
On 19 February 2015 at 15:27, Alexander Graf wrote:
>
>
> On 19.02.15 15:56, Ard Biesheuvel wrote:
>> On 19 February 2015 at 14:50, Alexander Graf wrote:
>>>
>>>
>>> On 19.02.15 11:54, Ard Biesheuvel wrote:
This is a 0th order approximation of how we could potentially force the
guest
>
On 19.02.15 15:56, Ard Biesheuvel wrote:
> On 19 February 2015 at 14:50, Alexander Graf wrote:
>>
>>
>> On 19.02.15 11:54, Ard Biesheuvel wrote:
>>> This is a 0th order approximation of how we could potentially force the
>>> guest
>>> to avoid uncached mappings, at least from the moment the MMU
On 19 February 2015 at 15:19, Marc Zyngier wrote:
> On 19/02/15 13:44, Ard Biesheuvel wrote:
>> On 19 February 2015 at 13:40, Marc Zyngier wrote:
>>> On 19/02/15 10:54, Ard Biesheuvel wrote:
---
arch/arm/kvm/mmu.c | 2 +-
arch/arm64/include/asm/kvm_arm.h | 2 +-
On 19/02/15 13:44, Ard Biesheuvel wrote:
> On 19 February 2015 at 13:40, Marc Zyngier wrote:
>> On 19/02/15 10:54, Ard Biesheuvel wrote:
>>> ---
>>> arch/arm/kvm/mmu.c | 2 +-
>>> arch/arm64/include/asm/kvm_arm.h | 2 +-
>>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> d
On 19 February 2015 at 14:50, Alexander Graf wrote:
>
>
> On 19.02.15 11:54, Ard Biesheuvel wrote:
>> This is a 0th order approximation of how we could potentially force the guest
>> to avoid uncached mappings, at least from the moment the MMU is on. (Before
>> that, all of memory is implicitly cl
On 19.02.15 11:54, Ard Biesheuvel wrote:
> This is a 0th order approximation of how we could potentially force the guest
> to avoid uncached mappings, at least from the moment the MMU is on. (Before
> that, all of memory is implicitly classified as Device-nGnRnE)
>
> The idea (patch #2) is to tr
On 19 February 2015 at 13:40, Marc Zyngier wrote:
> On 19/02/15 10:54, Ard Biesheuvel wrote:
>> ---
>> arch/arm/kvm/mmu.c | 2 +-
>> arch/arm64/include/asm/kvm_arm.h | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.
On 19/02/15 10:54, Ard Biesheuvel wrote:
> ---
> arch/arm/kvm/mmu.c | 2 +-
> arch/arm64/include/asm/kvm_arm.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index 136662547ca6..fa8ec55220ea 100644
> --- a/arch/a
On 02/13/2015 05:39 AM, Andre Przywara wrote:
> Hi,
>
> as I found it increasingly inconvenient to use kvmtool[1] as part of a
> Linux repository, I decided to give it a go and make it a stand-alone
> project. So I filtered all the respective commits, adjusted the paths in
> there (while keeping a
Mangle the memory attribute register values at each write to MAIR_EL1
so that regions that the guest intends to map as device or uncached are
in fact mapped as cached instead. This avoids incoherency issues when
the guest bypassed the caches to access memory that the host has mapped
as cached.
Sig
---
arch/arm/kvm/mmu.c | 2 +-
arch/arm64/include/asm/kvm_arm.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 136662547ca6..fa8ec55220ea 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -1530,7 +1530,7
This is a 0th order approximation of how we could potentially force the guest
to avoid uncached mappings, at least from the moment the MMU is on. (Before
that, all of memory is implicitly classified as Device-nGnRnE)
The idea (patch #2) is to trap writes to MAIR_EL1, and replace uncached mappings
This adds handling to el1_trap() to perform some sysreg writes directly
in EL2, without performing the full world switch to the host and back
again. This is mainly for doing writes that don't need special handling,
but where the register is part of the group that we need to trap for
other reasons.
22 matches
Mail list logo
