On Mon, 16 Feb 2015 13:16:41 +0100
Thomas Huth wrote:
> On s390, we've got to make sure to hold the IPTE lock while accessing
> logical memory. So let's add an ioctl for reading and writing logical
> memory to provide this feature for userspace, too.
>
> Signed-off-by: Thomas Huth
> ---
> Docu
On Thu, 19 Feb 2015 10:47:29 +0100
Cornelia Huck wrote:
> On Mon, 16 Feb 2015 13:16:41 +0100
> Thomas Huth wrote:
>
> > On s390, we've got to make sure to hold the IPTE lock while accessing
> > logical memory. So let's add an ioctl for reading and writing logical
> > memory to provide this feat
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
---
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
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
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.
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
On Wed, Feb 18, 2015 at 05:42:37PM +0100, Paolo Bonzini wrote:
>
>
> On 17/02/2015 12:24, Kashyap Chamarthy wrote:
> > Afraid, I didn't bisect it, but I just wanted to note that the above
> > specific WARN was introduced in the above commit.
> >
> > I'm sure this Kernel (on L0) does not exhibit
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 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 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 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
2015-02-19 13:07+0100, Kashyap Chamarthy:
> Just did two tests with 3.18:
>
> (1) Kernel 3.18 on L0 and 3.20 on L1
>
> Result: Booting L2 guest causes L1 to reboot, and the same[*] stack
> trace on L0 (mentioned on this thread previously).
>
> But, annoyingly enough,
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 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 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: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
>
2015-02-19 16:01+0100, Radim Krčmář:
> 2015-02-19 13:07+0100, Kashyap Chamarthy:
> 5f3d5799974b8 KVM: nVMX: Rework event injection and recovery:
> This concept is based on the rule that a pending vmlaunch/vmresume is
> not canceled. Otherwise, we would risk to lose injected events or leak
> t
2015-02-19 17:02+0100, Radim Krčmář:
> Fixes: e011c663b9c7 ("Check all exceptions for intercept during delivery to
> L2")
Note: I haven't verified that it was introduced by this patch, just
nothing against the hypothesis popped out in a short gravedigging.
--
To unsubscribe from this list: send t
https://bugzilla.kernel.org/show_bug.cgi?id=25332
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
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 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 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 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 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:02:22PM +0100, Radim Krčmář wrote:
> 2015-02-19 16:01+0100, Radim Krčmář:
> > 2015-02-19 13:07+0100, Kashyap Chamarthy:
> > 5f3d5799974b8 KVM: nVMX: Rework event injection and recovery:
> > This concept is based on the rule that a pending vmlaunch/vmresume is
> > not
On Thu, Feb 19, 2015 at 10:10:11PM +0100, Kashyap Chamarthy wrote:
> On Thu, Feb 19, 2015 at 05:02:22PM +0100, Radim Krčmář wrote:
[. . .]
> > Can you try if the following patch works?
>
> Sure, will test a Kernel built with the below patch and report back.
Hmm, I'm stuck with a meta issue.
I
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
28 matches
Mail list logo
