Right now sregs is unused on PPC, so we can use it for initialization
of the CPU.
KVM on BookE always virtualizes the host CPU. On Book3s we go a step further
and take the PVR from userspace that tells us what kind of CPU we are supposed
to virtualize, because we support Book3s_32 and Book3s_64
We need to store more information than we currently have for vcpus
when running on Book3s.
So let's extend the internal struct definitions.
Signed-off-by: Alexander Graf ag...@suse.de
---
v3 - v4:
- use context_id instead of mm_context
---
arch/powerpc/include/asm/kvm_host.h | 75
PowerPC code handles dirty logging in the generic parts atm. While this
is great for return -ENOTSUPP, we need to be rather target specific
when actually implementing it.
So let's split it to implementation specific code, so we can implement
it for book3s.
Signed-off-by: Alexander Graf
KVM for PowerPC only supports embedded cores at the moment.
While it makes sense to virtualize on small machines, it's even more fun
to do so on big boxes. So I figured we need KVM for PowerPC64 as well.
This patchset implements KVM support for Book3s_64 hosts and guest support
for Book3s_64 and
We need to intercept interrupt vectors. To do that, let's add a file
we can always include which only activates the intercepts when we have
then configured.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/include/asm/kvm_book3s_64_asm.h | 58 ++
1 files
This adds the book3s specific header file that contains structs that
are only valid on book3s specific code.
Signed-off-by: Alexander Graf ag...@suse.de
---
v3 - v4:
- use context_id instead of mm_alloc
---
arch/powerpc/include/asm/kvm_book3s.h | 136 +
1
Little opcodes behave differently on desktop and embedded PowerPC cores.
In order to reflect those differences, let's add some #ifdef code to emulate.c.
We could probably also handle them in the core specific emulation files, but I
would prefer to reuse as much code as possible.
Signed-off-by:
This is the really low level of guest entry/exit code.
Book3s_64 has an SLB, which stores all ESID - VSID mappings we're
currently aware of.
The segments in the guest differ from the ones on the host, so we need
to switch the SLB to tell the MMU that we're in a new context.
So we store a shadow
This is the of entry / exit code. In order to switch between host and guest
context, we need to switch register state and call the exit code handler on
exit.
This assembly file does exactly that. To finally enter the guest it calls
into book3s_64_slb.S. On exit it gets jumped at from
We need to access some VCPU fields from assembly code. In order to get
the proper offsets, we have to define them in asm-offsets.c.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/kernel/asm-offsets.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff
To be able to keep KVM as module, we need to export the SLB trampoline
addresses to the module, so it knows where to jump to.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/kvm/book3s_64_exports.c | 24
1 files changed, 24 insertions(+), 0 deletions(-)
For KVM we need to allocate a new context id, but don't really care about
all the mm context around it.
So let's split the alloc and destroy functions for the context id, so we can
grab one without allocating an mm context.
Signed-off-by: Alexander Graf ag...@suse.de
---
Getting from host state to the guest is only half the story. We also need
to return to our host context and handle whatever happened to get us out of
the guest.
On PowerPC every guest exit is an interrupt. So all we need to do is trap
the host's interrupt handlers and get into our #VMEXIT code to
For KVM we need to store some information in the PACA, so we
need to extend it.
This patch adds KVM SLB shadow related entries to the PACA and
a field that indicates if we're inside a guest.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/include/asm/paca.h |9 +
1
We designed the Book3S port of KVM as modular as possible. Most
of the code could be easily used on a Book3S_32 host as well.
The main difference between 32 and 64 bit cores is the MMU. To keep
things well separated, we treat the book3s_64 MMU as one possible compile
option.
This patch adds all
Now we have everything in place to be able to build KVM, so let's add it
as config option and in the Makefile.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/kvm/Kconfig | 17 +
arch/powerpc/kvm/Makefile | 27 +++
2 files changed, 40
It looks like the variable pc is defined. At least the current code always
failed on me stating that pc is already defined somewhere else.
Let's use _pc instead, because that doesn't collide.
Is this the right approach? Does it break on 440 too? If not, why not?
Signed-off-by: Alexander Graf
We currently use host endian long types to store information
in the dirty bitmap.
This works reasonably well on Little Endian targets, because the
u32 after the first contains the next 32 bits. On Big Endian this
breaks completely though, forcing us to be inventive here.
So Ben suggested to
With big endian userspace, we can't quite figure out if a pointer
is 32 bit (shifted 32) or 64 bit when we read a 64 bit pointer.
This is what happens with dirty logging. To get the pointer interpreted
correctly, I just make it bounce twice, but admittedly that is not ideal.
I'm open for
On 29.09.2009, at 11:14, Avi Kivity wrote:
On 09/29/2009 10:18 AM, Alexander Graf wrote:
With big endian userspace, we can't quite figure out if a pointer
is 32 bit (shifted 32) or 64 bit when we read a 64 bit pointer.
This is what happens with dirty logging. To get the pointer
Hollis Blanchard 09/29/09 2:00 AM
First, I think there is a real bug here, and the code should read like
this (to match the comment):
/* type has to be known at build time for optimization */
-BUILD_BUG_ON(__builtin_constant_p(type));
+BUILD_BUG_ON(!__builtin_constant_p(type));
On Tue, Sep 29, 2009 at 11:28 AM, Jan Beulich jbeul...@novell.com wrote:
Hollis Blanchard 09/29/09 2:00 AM
First, I think there is a real bug here, and the code should read like
this (to match the comment):
/* type has to be known at build time for optimization */
-
On 09/29/2009 11:17 AM, Alexander Graf wrote:
On 29.09.2009, at 11:14, Avi Kivity wrote:
On 09/29/2009 10:18 AM, Alexander Graf wrote:
With big endian userspace, we can't quite figure out if a pointer
is 32 bit (shifted 32) or 64 bit when we read a 64 bit pointer.
This is what happens with
Am 29.09.2009 um 06:25 schrieb Avi Kivity a...@redhat.com:
On 09/29/2009 11:17 AM, Alexander Graf wrote:
On 29.09.2009, at 11:14, Avi Kivity wrote:
On 09/29/2009 10:18 AM, Alexander Graf wrote:
With big endian userspace, we can't quite figure out if a pointer
is 32 bit (shifted 32) or 64
On 29.09.2009, at 15:25, Avi Kivity wrote:
On 09/29/2009 11:17 AM, Alexander Graf wrote:
On 29.09.2009, at 11:14, Avi Kivity wrote:
On 09/29/2009 10:18 AM, Alexander Graf wrote:
With big endian userspace, we can't quite figure out if a pointer
is 32 bit (shifted 32) or 64 bit when we read
On 09/29/2009 06:29 PM, Alexander Graf wrote:
How about this one? (broken whitespace!)
From c3864a2c5e1fccff7839e47f12c09d9739ca441e Mon Sep 17 00:00:00 2001
From: Alexander Graf ag...@suse.de
Date: Thu, 23 Jul 2009 21:05:57 +0200
Subject: [PATCH] Enable 32bit dirty log pointers on 64bit host
On 29.09.2009, at 18:42, Avi Kivity wrote:
On 09/29/2009 06:29 PM, Alexander Graf wrote:
How about this one? (broken whitespace!)
From c3864a2c5e1fccff7839e47f12c09d9739ca441e Mon Sep 17 00:00:00
2001
From: Alexander Graf ag...@suse.de
Date: Thu, 23 Jul 2009 21:05:57 +0200
Subject:
27 matches
Mail list logo
