On 17.06.14 03:02, Paul Mackerras wrote:
On Wed, Jun 11, 2014 at 12:33:50PM +0200, Alexander Graf wrote:
On the exit path from the guest we check what type of interrupt we received
if we received one. This means we're doing hardware access to the XICS interrupt
controller.
However, when
On vcpu schedule, the condition checked for tlb pollution is too loose.
The tlb entries of a vcpu become polluted (vs stale) only when a different
vcpu within the same logical partition runs in-between. Optimize the tlb
invalidation condition taking into account the logical partition id.
With the
On 12.06.14 05:56, Paul Mackerras wrote:
On Tue, Jun 10, 2014 at 07:23:00PM +0200, Alexander Graf wrote:
When we're using PR KVM we must not allow the CPU to take interrupts
in virtual mode, as the SLB does not contain host kernel mappings
when running inside the guest context.
To make sure
On Tue, 2014-06-17 at 11:25 +0200, Alexander Graf wrote:
On 17.06.14 11:22, Benjamin Herrenschmidt wrote:
On Tue, 2014-06-17 at 10:54 +0200, Alexander Graf wrote:
Also, why don't we use twi always or something else that actually is
defined as illegal instruction? I would like to see this
On 17.06.14 11:32, Benjamin Herrenschmidt wrote:
On Tue, 2014-06-17 at 11:25 +0200, Alexander Graf wrote:
On 17.06.14 11:22, Benjamin Herrenschmidt wrote:
On Tue, 2014-06-17 at 10:54 +0200, Alexander Graf wrote:
Also, why don't we use twi always or something else that actually is
defined as
When we're using PR KVM we must not allow the CPU to take interrupts
in virtual mode, as the SLB does not contain host kernel mappings
when running inside the guest context.
To make sure we get good performance for non-KVM tasks but still
properly functioning PR KVM, let's just disable AIL
On Tue, Jun 17, 2014 at 12:03:58PM +0200, Alexander Graf wrote:
When we're using PR KVM we must not allow the CPU to take interrupts
in virtual mode, as the SLB does not contain host kernel mappings
when running inside the guest context.
To make sure we get good performance for non-KVM tasks
On 17.06.14 10:37, Alexander Graf wrote:
On 17.06.14 03:02, Paul Mackerras wrote:
On Wed, Jun 11, 2014 at 12:33:50PM +0200, Alexander Graf wrote:
On the exit path from the guest we check what type of interrupt we
received
if we received one. This means we're doing hardware access to the
On Tuesday 17 June 2014 02:24 PM, Alexander Graf wrote:
On 14.06.14 23:08, Madhavan Srinivasan wrote:
This patch adds kernel side support for software breakpoint.
Design is that, by using an illegal instruction, we trap to hypervisor
via Emulation Assistance interrupt, where we check for the
On 17.06.14 13:07, Madhavan Srinivasan wrote:
On Tuesday 17 June 2014 02:24 PM, Alexander Graf wrote:
On 14.06.14 23:08, Madhavan Srinivasan wrote:
This patch adds kernel side support for software breakpoint.
Design is that, by using an illegal instruction, we trap to hypervisor
via Emulation
On Tuesday 17 June 2014 03:02 PM, Benjamin Herrenschmidt wrote:
On Tue, 2014-06-17 at 11:25 +0200, Alexander Graf wrote:
On 17.06.14 11:22, Benjamin Herrenschmidt wrote:
On Tue, 2014-06-17 at 10:54 +0200, Alexander Graf wrote:
Also, why don't we use twi always or something else that actually
On Tuesday 17 June 2014 03:13 PM, Alexander Graf wrote:
On 17.06.14 11:32, Benjamin Herrenschmidt wrote:
On Tue, 2014-06-17 at 11:25 +0200, Alexander Graf wrote:
On 17.06.14 11:22, Benjamin Herrenschmidt wrote:
On Tue, 2014-06-17 at 10:54 +0200, Alexander Graf wrote:
Also, why don't we use
On Tuesday 17 June 2014 04:38 PM, Alexander Graf wrote:
On 17.06.14 13:07, Madhavan Srinivasan wrote:
On Tuesday 17 June 2014 02:24 PM, Alexander Graf wrote:
On 14.06.14 23:08, Madhavan Srinivasan wrote:
This patch adds kernel side support for software breakpoint.
Design is that, by using
On 17.06.14 13:20, Madhavan Srinivasan wrote:
On Tuesday 17 June 2014 03:13 PM, Alexander Graf wrote:
On 17.06.14 11:32, Benjamin Herrenschmidt wrote:
On Tue, 2014-06-17 at 11:25 +0200, Alexander Graf wrote:
On 17.06.14 11:22, Benjamin Herrenschmidt wrote:
On Tue, 2014-06-17 at 10:54 +0200,
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Tuesday, June 17, 2014 12:09 PM
To: Wood Scott-B07421
Cc: Caraman Mihai Claudiu-B02008; kvm-ppc@vger.kernel.org;
k...@vger.kernel.org; linuxppc-...@lists.ozlabs.org
Subject: Re: [PATCH] KVM: PPC: e500mc: Relax tlb
On Tue, Jun 17, 2014 at 12:22:32PM +0200, Alexander Graf wrote:
Eh, no. What we do is we read (good on BE, byte reversed) into r0. Then we
swab32() from r0 to r3 on LE, mr from r0 to r3 on BE.
r3 gets truncated along the way.
The reason we maintain r0 as wrong-endian is that we write it
On 17.06.14 14:13, Paul Mackerras wrote:
On Tue, Jun 17, 2014 at 12:22:32PM +0200, Alexander Graf wrote:
Eh, no. What we do is we read (good on BE, byte reversed) into r0. Then we
swab32() from r0 to r3 on LE, mr from r0 to r3 on BE.
r3 gets truncated along the way.
The reason we maintain r0
On 17.06.14 13:13, Madhavan Srinivasan wrote:
On Tuesday 17 June 2014 04:38 PM, Alexander Graf wrote:
On 17.06.14 13:07, Madhavan Srinivasan wrote:
On Tuesday 17 June 2014 02:24 PM, Alexander Graf wrote:
On 14.06.14 23:08, Madhavan Srinivasan wrote:
This patch adds kernel side support for
If we're running PR KVM in HV mode, we may get hypervisor doorbell interrupts.
Handle those the same way we treat normal doorbells.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/kvm/book3s_pr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kvm/book3s_pr.c
On 12.06.14 10:16, Anton Blanchard wrote:
To establish addressability quickly, ABIv2 requires the target
address of the function being called to be in r12.
Signed-off-by: Anton Blanchard an...@samba.org
Thanks, applied to kvm-ppc-queue.
Alex
---
Index:
On 12.06.14 10:16, Anton Blanchard wrote:
Both kvmppc_hv_entry_trampoline and kvmppc_entry_trampoline are
assembly functions that are exported to modules and also require
a valid r2.
As such we need to use _GLOBAL_TOC so we provide a global entry
point that establishes the TOC (r2).
We switched to ABIv2 on Little Endian systems now which gets rid of the
dotted function names. Branch to the actual functions when we see such
a system.
Signed-off-by: Alexander Graf ag...@suse.de
diff --git a/arch/powerpc/kvm/book3s_interrupts.S
b/arch/powerpc/kvm/book3s_interrupts.S
index
While sending sparse with endian checks over the code base, it triggered at
some places that were missing casts or had wrong types. Fix them up.
Signed-off-by: Alexander Graf ag...@suse.de
diff --git a/arch/powerpc/kvm/book3s_pr_papr.c
b/arch/powerpc/kvm/book3s_pr_papr.c
index 52a63bf..f7c25c6
So far we've been able to successfully run HV KVM on big endian hosts, but
once you dive into little endian land things start to fall apart.
This patch set enables HV KVM for little endian hosts. This should be the
final piece left missing to get little endian systems fully en par with big
endian
We use ABIv2 on Little Endian systems which gets rid of the dotted function
names. Branch to the actual functions when we see such a system.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 22 ++
1 file changed, 14 insertions(+), 8
Some data structures are always stored in big endian. Among those are the LPPACA
fields as well as the shadow slb. These structures might be shared with a
hypervisor.
So whenever we access those fields, make sure we do so in big endian byte order.
Signed-off-by: Alexander Graf ag...@suse.de
---
From assembly code we might not only have to explicitly BE access 64bit values,
but sometimes also 32bit ones. Add helpers that allow for easy use of lwzx/stwx
in their respective byte-reverse or native form.
Signed-off-by: Alexander Graf ag...@suse.de
CC: Benjamin Herrenschmidt
When running on an LE host all data structures are kept in little endian
byte order. However, the HTAB still needs to be maintained in big endian.
So every time we access any HTAB we need to make sure we do so in the right
byte order. Fix up all accesses to manually byte swap.
Signed-off-by:
Now that we've fixed all the issues that HV KVM code had on little endian
hosts, we can enable it in the kernel configuration for users to play with.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/kvm/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git
On the exit path from the guest we check what type of interrupt we received
if we received one. This means we're doing hardware access to the XICS interrupt
controller.
However, when running on a little endian system, this access is byte reversed.
So let's make sure to swizzle the bytes back
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, June 17, 2014 6:36 PM
To: Caraman Mihai Claudiu-B02008
Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH v2] KVM: PPC: e500mc: Enhance tlb invalidation
condition on vcpu
On Tue, 2014-06-17 at 14:04 -0500, Caraman Mihai Claudiu-B02008 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, June 17, 2014 6:36 PM
To: Caraman Mihai Claudiu-B02008
Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; linuxppc-
d...@lists.ozlabs.org
Subject:
On vcpu schedule, the condition checked for tlb pollution is too loose.
The tlb entries of a vcpu become polluted (vs stale) only when a different
vcpu within the same logical partition runs in-between. Optimize the tlb
invalidation condition keeping last_vcpu_on_cpu per logical partition id.
On Tue, 2014-06-17 at 22:09 +0300, Mihai Caraman wrote:
On vcpu schedule, the condition checked for tlb pollution is too loose.
The tlb entries of a vcpu become polluted (vs stale) only when a different
vcpu within the same logical partition runs in-between. Optimize the tlb
invalidation
-static DEFINE_PER_CPU(struct kvm_vcpu *, last_vcpu_on_cpu);
+static DEFINE_PER_CPU(struct kvm_vcpu * [KVMPPC_NR_LPIDS],
last_vcpu_on_cpu);
Hmm, I didn't know you could express types like that. Is this special
syntax that only works for typeof?
Yes, AFAIK.
No space after *
Checkpatch
On Tue, 2014-06-17 at 14:42 -0500, Caraman Mihai Claudiu-B02008 wrote:
-static DEFINE_PER_CPU(struct kvm_vcpu *, last_vcpu_on_cpu);
+static DEFINE_PER_CPU(struct kvm_vcpu * [KVMPPC_NR_LPIDS],
last_vcpu_on_cpu);
Hmm, I didn't know you could express types like that. Is this special
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, June 17, 2014 10:48 PM
To: Caraman Mihai Claudiu-B02008
Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH v3] KVM: PPC: e500mc: Enhance tlb invalidation
condition on vcpu
On Tue, 2014-06-17 at 15:02 -0500, Caraman Mihai Claudiu-B02008 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, June 17, 2014 10:48 PM
To: Caraman Mihai Claudiu-B02008
Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; linuxppc-
d...@lists.ozlabs.org
Subject:
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, June 17, 2014 11:05 PM
To: Caraman Mihai Claudiu-B02008
Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH v3] KVM: PPC: e500mc: Enhance tlb invalidation
condition on vcpu
On 17.06.14 22:36, mihai.cara...@freescale.com wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, June 17, 2014 11:05 PM
To: Caraman Mihai Claudiu-B02008
Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH v3] KVM: PPC:
40 matches
Mail list logo
