hat the proposed patch in my first mail is incomplete, as
the mod_64 does not work correctly for negative values. A fixed version
is below.
regards Christian
Signed-off-by: Christian Ehrhardt
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 43e9fad..ec7242c 100644
--- a/arch/x86/kvm/la
use the negative
difference unmodified.
regards Christian
Fix lapic time counter read for periodic mode.
Signed-off-by: Christian Ehrhardt
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 43e9fad..eff902d 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
From: Christian Ehrhardt
As requested this is a rebased patch on top of the already applied v3
of the patch series.
*updates to already applied version*
- ensure allocations (might_sleep) are out of atomic context
- centralize consumption of vcpu->request bits
To ensure vcpu's com
From: Christian Ehrhardt
As requested this is a rebased patch on top of the already applied v3
of the patch series.
*updates to already applied version*
- remove dependency to KVM_REQ_MMU_RELOAD in generic code
- remove explicit barrier after test_and_clear_bit as it is implied
- ensure the
From: Christian Ehrhardt
As requested this is a rebased patch on top of the already applied v3
of the patch series.
kvm on s390 formerly ignored vcpu->cpu.
This patch adds set/unset vcpu->cpu in kvm_arch_vcpu_load/put to allow
further architecture unification e.g. let generic code not f
From: Christian Ehrhardt
As requested this is a rebased patch on top of the already applied v3
of the patch series.
*updates to applied version*
- remove dependency to KVM_REQ_MMU_RELOAD in generic code
- remove explicit barrier after test_and_clear_bit as it is implied
- ensure the wait_on_bit
iscussions we might try to
catch up on irc to save this thread a few cycles :-)
--
Grüsse / regards, Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Avi Kivity wrote:
Christian Ehrhardt wrote:
Really need that smp_mb__after_clear_bit ? AFAIK test_and_clear_bit
implies a barrier?
Well I agree that practically test_and_clear_bit has a barrier on
s390, but as far as I read Documentation/atomic_ops.txt at line
339-360 I think the
Marcelo Tosatti wrote:
On Tue, Jun 02, 2009 at 04:26:11PM +0200, ehrha...@linux.vnet.ibm.com wrote:
From: Christian Ehrhardt
[...]
@@ -706,13 +713,19 @@ int kvm_arch_set_memory_region(struct kv
/* request update of sie control block for all available vcpus */
for (i = 0
From: Christian Ehrhardt
This code waants the same number as KVM_MAX_VCPUS but uses a hard coded 64
instead of the constant. This patch changes the field width definitions of
the s390 specific interrupt handling to use the constant.
Signed-off-by: Christian Ehrhardt
---
[diffstat]
kvm_host.h
From: Christian Ehrhardt
As requested this is a rebased patch on top of the already applied v3
of the patch series.
*updates to applied version*
- ensure the wait_on_bit waiter is notified
- ensure dropping vcpu all requests while freeing a vcpu
- kickout only scheduled vcpus (its superfluous
From: Christian Ehrhardt
As requested this is a rebased patch on top of the already applied v3
of the patch series.
kvm on s390 formerly ignored vcpu->cpu.
This patch adds set/unset vcpu->cpu in kvm_arch_vcpu_load/put to allow
further architecture unification e.g. let generic code not f
From: Christian Ehrhardt
As requested this is a rebased patch on top of the already applied v3
of the patch series.
*updates to already applied version*
- ensure the wait_on_bit waiter is notified
- move the reset of requests to kvm_vcpu_release to drop them early
- ensure dropping all vcpu
From: Christian Ehrhardt
As requested this is a rebased patch on top of the already applied v3
of the patch series.
*updates to already applied version*
- ensure allocations (might_sleep) are out of atomic context
- centralize consumption of vcpu->request bits
To ensure vcpu's com
Marcelo Tosatti wrote:
On Sun, May 31, 2009 at 11:22:58AM +0300, Avi Kivity wrote:
ehrha...@linux.vnet.ibm.com wrote:
From: Christian Ehrhardt
*updates in v6*
- ensure the wait_on_bit waiter is notified
- move the reset of requests to kvm_vcpu_release to drop them early
*updates in
From: Christian Ehrhardt
*updates in v6*
- drop the unrelated fix to kvm_host.h from the series to clear it thematically
- ensure the wait_on_bit waiter is notified
- move the reset of requests to kvm_vcpu_release to drop them early
Note: I beg a pardon for the change rate of these series in
From: Christian Ehrhardt
*updates in v3*
- ensure allocations (might_sleep) are out of atomic context
*updates in v2*
instead of a "kick to level" behaviour the patch now implements a kick to the
lowest level. The check there bails out to upper levels if not all outstanding
vcpu->r
From: Christian Ehrhardt
Changing s390 code in kvm_arch_vcpu_load/put come across this header
declarations. They are complete duplicates, not even useful forward
declarations as nothing using it is in between (maybe it was that in
the past).
This patch removes the two dispensable lines.
Signed
From: Christian Ehrhardt
*updates in v2*
merged a small piece of code from patch 1/1 that belongs here themtically
If signal pending is true we exit without updating kvm_run, userspace
currently just does nothing and jumps to kvm_run again.
Since we did not set an exit_reason we might end up
From: Christian Ehrhardt
*updates in v6*
- ensure the wait_on_bit waiter is notified
- move the reset of requests to kvm_vcpu_release to drop them early
*updates in v5*
- ensure dropping vcpu all requests while freeing a vcpu
*updates in v4*
- kickout only scheduled vcpus (its superfluous and
From: Christian Ehrhardt
kvm on s390 formerly ignored vcpu->cpu.
This patch adds set/unset vcpu->cpu in kvm_arch_vcpu_load/put to allow
further architecture unification e.g. let generic code not find -1 on
currently scheduled vcpus.
Signed-off-by: Christian Ehrhardt
---
[diffstat]
kvm-
From: Christian Ehrhardt
*updates in v5*
- ensure dropping all vcpu requests while freeing a vcpu
*updates in v4*
- ensure kick allocations (might_sleep) are out of atomic context
- update vcpu->cpu in kvm-s390 arch handler for load/put
- remove a redundant declaration in kvm_host.h related
From: Christian Ehrhardt
Changing s390 code in kvm_arch_vcpu_load/put come across this header
declarations. They are complete duplicates, not even useful forward
declarations as nothing using it is in between (maybe it was that in
the past).
This patch removes the two dispensable lines.
Signed
From: Christian Ehrhardt
*updates in v5*
- ensure dropping all vcpu requests while freeing a vcpu
*updates in v4*
- kickout only scheduled vcpus (its superfluous and wait might hang forever on
not running vcpus)
*updates in v3*
- handling the mmu reload vcpu request can now be handled inside
From: Christian Ehrhardt
kvm on s390 formerly ignored vcpu->cpu.
This patch adds set/unset vcpu->cpu in kvm_arch_vcpu_load/put to allow
further architecture unification e.g. let generic code not find -1 on
currently scheduled vcpus.
Signed-off-by: Christian Ehrhardt
---
[diffstat]
kvm-
From: Christian Ehrhardt
*updates in v3*
- ensure allocations (might_sleep) are out of atomic context
*updates in v2*
instead of a "kick to level" behaviour the patch now implements a kick to the
lowest level. The check there bails out to upper levels if not all outstanding
vcpu->r
From: Christian Ehrhardt
*updates in v2*
merged a small piece of code from patch 1/1 that belongs here themtically
If signal pending is true we exit without updating kvm_run, userspace
currently just does nothing and jumps to kvm_run again.
Since we did not set an exit_reason we might end up
From: Christian Ehrhardt
*updates in v3*
- ensure kick allocations (might_sleep) are out of atomic context
- replaced "kick to level" behaviour by "kick to low level and bail out"
- updates on running vcpus can now be handled without need to rerun the vcpu
- kvm_arch_set
From: Christian Ehrhardt
*updates in v2*
merged a small piece of code from patch 1/1 that belongs here themtically
If signal pending is true we exit without updating kvm_run, userspace
currently just does nothing and jumps to kvm_run again.
Since we did not set an exit_reason we might end up
From: Christian Ehrhardt
Changing s390 code in kvm_arch_vcpu_load/put come across this header
declarations. They are complete duplicates, not even useful forward
declarations as nothing using it is in between (according to git
blame the s390 and ia64 contributions introducing the first arch
From: Christian Ehrhardt
*updates in v3*
- ensure allocations (might_sleep) are out of atomic context
*updates in v2*
instead of a "kick to level" behaviour the patch now implements a kick to the
lowest level. The check there bails out to upper levels if not all outstanding
vcpu->r
From: Christian Ehrhardt
*updates in v4*
- kickout only scheduled vcpus (its superfluous and wait might hang forever on
not running vcpus)
*updates in v3*
- handling the mmu reload vcpu request can now be handled inside the sigp
handling avoiding an addtional exit
From: Christian Ehrhardt
kvm on s390 formerly ignored vcpu->cpu.
This patch adds set/unset vcpu->cpu in kvm_arch_vcpu_load/put to allow
further architecture unification e.g. let generic code not find -1 on
currently scheduled vcpus.
Signed-off-by: Christian Ehrhardt
---
[diffstat]
kvm-
Avi Kivity wrote:
Christian Ehrhardt wrote:
So you _need_ a mechanism to kick all vcpus out of guest mode?
I have a mechanism to kick a vcpu, and I use it. Due to the fact that
smp_call_* don't work as kick for us the kick is an arch specific
function.
I hop ethat clarified this
Marcelo Tosatti wrote:
On Tue, May 26, 2009 at 10:02:59AM +0200, Christian Ehrhardt wrote:
Marcelo Tosatti wrote:
On Mon, May 25, 2009 at 01:40:49PM +0200, ehrha...@linux.vnet.ibm.com wrote:
From: Christian Ehrhardt
To ensure vcpu's come out of guest context in ce
tee) and I try to come up with
something in the next few days - either a updated patch series or
additional discussion input :-).
--
Grüsse / regards, Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
--
To unsubscribe from this list: send the line "unsubscribe kvm"
Marcelo Tosatti wrote:
On Mon, May 25, 2009 at 01:40:49PM +0200, ehrha...@linux.vnet.ibm.com wrote:
From: Christian Ehrhardt
To ensure vcpu's come out of guest context in certain cases this patch adds a
s390 specific way to kick them out of guest context. Currently it kicks them
o
From: Christian Ehrhardt
*update in v2*
added optimization to skip (addtional) kickout of vcpu's that had the request
already set.
This patch relocates the variables kvm-s390 uses to track guest mem addr/size.
As discussed dropping the variables at struct kvm_arch level allows to use the
c
From: Christian Ehrhardt
To ensure vcpu's come out of guest context in certain cases this patch adds a
s390 specific way to kick them out of guest context. Currently it kicks them
out to rerun the vcpu_run path in the s390 code, but the mechanism itself is
expandable and with a new flag we
From: Christian Ehrhardt
*update in v2*
added optimization to patch 3/3 to skip (addtional) kickout of vcpu's that had
the request already set.
This patch series results from our discussions about handling memslots and vcpu
mmu reloads. It streamlines kvm-s390 a bit by using slots_lock,
From: Christian Ehrhardt
If signal pending is true we exit without updating kvm_run, userspace
currently just does nothing and jumps to kvm_run again.
Since we did not set an exit_reason we might end up with a random one
(whatever was the last exit). Therefore it was possible to e.g. jump to
the
Christian Ehrhardt wrote:
Avi Kivity wrote:
ehrha...@linux.vnet.ibm.com wrote:
From: Christian Ehrhardt
[...]
-/* update sie control blocks, and unlock all vcpus */
+/* request update of sie control block for all available vcpus */
for (i = 0; i < KVM_MAX_VCPUS;
Avi Kivity wrote:
ehrha...@linux.vnet.ibm.com wrote:
From: Christian Ehrhardt
This patch relocates the variables kvm-s390 uses to track guest mem
addr/size.
As discussed dropping the variables at struct kvm_arch level allows
to use the
common vcpu->request based mechanism to reload gu
From: Christian Ehrhardt
To ensure vcpu's come out of guest context in certain cases this patch adds a
s390 specific way to kick them out of guest context. Currently it kicks them
out to rerun the vcpu_run path in the s390 code, but the mechanism itself is
expandable and with a new flag we
From: Christian Ehrhardt
This patch series results from our discussions about handling memslots and vcpu
mmu reloads. It streamlines kvm-s390 a bit by using slots_lock, vcpu-request
(KVM_REQ_MMU_RELOAD) and a kick mechanism to ensure vcpus come out of guest
context to catch the update.
I tested
From: Christian Ehrhardt
This patch relocates the variables kvm-s390 uses to track guest mem addr/size.
As discussed dropping the variables at struct kvm_arch level allows to use the
common vcpu->request based mechanism to reload guest memory if e.g. changes
via set_memory_region.
The k
From: Christian Ehrhardt
If signal pending is true we exit without updating kvm_run, userspace
currently just does nothing and jumps to kvm_run again.
Since we did not set an exit_reason we might end up with a random one
(whatever was the last exit). Therefore it was possible to e.g. jump to
the
Avi Kivity wrote:
Christian Ehrhardt wrote:
The bad thing on vcpu->request in that case is that I don't want
the async behaviour of vcpu->requests in that case, I want the
memory slot updated in all vcpu's when the ioctl is returning.
You mean, the hardware can access the vc
tte
Signed-off-by: Christian Ehrhardt
---
arch/s390/include/asm/kvm_host.h |5 -
arch/s390/kvm/interrupt.c| 33 +++--
arch/s390/kvm/kvm-s390.c |7 +--
arch/s390/kvm/kvm-s390.h |4 +++-
4 files changed, 35 insertions(+),
From: Christian Borntraeger
The floating interrupt lock is only taken in process context. We can
replace all spin_lock_bh with standard spin_lock calls.
Signed-off-by: Christian Borntraeger
Signed-off-by: Christian Ehrhardt
---
arch/s390/kvm/interrupt.c | 20 ++--
arch/s390
From: Carsten Otte
This check verifies that the guest we're trying to run in KVM_RUN
has some memory assigned to it. It enters an endless exception
loop if this is not the case.
Reported-by: Mijo Safradin
Signed-off-by: Carsten Otte
Signed-off-by: Christian Ehrhardt
---
arch/s390/kv
this fix.
Reported-by: Mijo Safradin
Signed-off-by: Carsten Otte
Signed-off-by: Christian Ehrhardt
---
arch/s390/kvm/intercept.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
Index: kvm/arch/s390/kvm/intercept.c
From: Christian Ehrhardt
*updates in v3*
- fix memory slot vs. run uses trylock to avoid a potential livelock
- fix memory slot vs. run checks if it is the first and only memslot registered
*updates in v2*
- hrtimer wakeup use a more accurate calculation
- unlink vcpu uses smb_mb so the pointer
d-off-by: Christian Ehrhardt
---
kvm-s390.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
Index: kvm/arch/s390/kvm/kvm-s390.c
===
--- kvm.orig/arch/s390/kvm/kvm-s390.c
+++ kvm/arch/s390/kvm/kvm-s390.c
@@ -
.
Additionally most of the discussed special conditions for s390 like
only one memslot and no user_alloc are now checked for validity in
kvm_arch_set_memory_region.
Reported-by: Mijo Safradin
Signed-off-by: Carsten Otte
Signed-off-by: Christian Ehrhardt
---
kv
Avi Kivity wrote:
Christian Ehrhardt wrote:
Avi Kivity wrote:
Christian Ehrhardt wrote:
The bad thing on vcpu->request in that case is that I don't want
the async behaviour of vcpu->requests in that case, I want the
memory slot updated in all vcpu's when the ioctl is retur
Avi Kivity wrote:
Christian Ehrhardt wrote:
The bad thing on vcpu->request in that case is that I don't want the
async behaviour of vcpu->requests in that case, I want the memory
slot updated in all vcpu's when the ioctl is returning.
You mean, the hardware can access
Avi Kivity wrote:
Christian Ehrhardt wrote:
I thought about implementing it with slots_lock, vcpu->request, etc
but it really looks like overkill for s390.
We could make (some of) it common code, so it won't look so bad.
There's value in having all kvm ports do things similar
Avi Kivity wrote:
Christian Ehrhardt wrote:
On x86, we use slots_lock to protect memory slots. When we change
the global memory configuration, we set a bit in vcpu->requests, and
send an IPI to all cpus that are currently in guest mode for our
guest. This forces the cpu back to host m
anged the code
using mutex_trylock and in case I can't get the lock I explicitly let
the vcpu exit from guest.
--
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
--
To unsubscribe from this list: send the line "unsubscribe kvm&quo
t;kvm->arch.sca->cpu[vcpu->vcpu_id].sda = 0;
free_page((unsigned long)(vcpu->arch.sie_block));
If this is accessed by hardware on a different cpu, don't you need a
memory barrier here?
Right, will be in v2
--
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technol
From: Carsten Otte
This check verifies that the guest we're trying to run in KVM_RUN
has some memory assigned to it. It enters an endless exception
loop if this is not the case.
Reported-by: Mijo Safradin
Signed-off-by: Carsten Otte
---
arch/s390/kvm/kvm-s390.c |6 ++
1 file changed,
From: Carsten Otte
This patch makes sure we do unlink a vcpu's sie control block
from the system control area in kvm_arch_vcpu_destroy. This
prevents illegal accesses to the sie control block from other
virtual cpus after free.
Reported-by: Mijo Safradin
Signed-off-by: Carsten Otte
---
arch/s
From: Carsten Otte
This patch adds a sanity check for the content of the guest
prefix register content before faulting in the cpu lowcore
that it refers to. The guest might end up in an endless loop
where SIE complains about missing lowcore with incorrect
content of the prefix register without th
From: Christian Borntraeger
This patch reworks the s390 clock comparator wakeup to hrtimer. The clock
comparator is a per-cpu value that is compared against the TOD clock. If
ckc <= TOD an external interrupt 1004 is triggered. Since the clock comparator
and the TOD clock have a much higher resolu
From: Christian Borntraeger
The floating interrupt lock is only taken in process context. We can
replace all spin_lock_bh with standard spin_lock calls.
Signed-off-by: Christian Borntraeger
---
arch/s390/kvm/interrupt.c | 20 ++--
arch/s390/kvm/kvm-s390.c |4 ++--
arch/s
From: Carsten Otte
This patch fixes an incorrectness in the kvm backend for s390.
In case virtual cpus are being created before the corresponding
memory slot is being registered, we need to update the sie
control blocks for the virtual cpus. In order to do that, we
use the vcpu->mutex to lock out
From: Christian Ehrhardt
This is a collection of fixes for kvm-s390 that originate from several tests
made in the last few months. They are now tested a while and should be ready
to be merged.
All six patches are created either by Carsten Otte or Christain Borntraeger.
I'm just th
Andre Przywara wrote:
ehrha...@linux.vnet.ibm.com wrote:
From: Christian Ehrhardt
There is already a variable kvm_cflags which gets the path of the kernel
includes when using --kerneldir. But eventually with newer kernels we
all will
need arch/$arch/include too (my case was a incldue of asm
From: Christian Ehrhardt
There is already a variable kvm_cflags which gets the path of the kernel
includes when using --kerneldir. But eventually with newer kernels we all will
need arch/$arch/include too (my case was a incldue of asm/kvm.h which was not
found anymore). Headers in a full kernel
Anthony Liguori wrote:
ehrha...@linux.vnet.ibm.com wrote:
From: Christian Ehrhardt
The patch applies to upstream qemu as well as kvm-userspace, but
since it is
the qemu configure script I think it should go to upstream qemu
(Anthony)
first and with the next merge to kvm-userspace. On the
From: Christian Ehrhardt
The patch applies to upstream qemu as well as kvm-userspace, but since it is
the qemu configure script I think it should go to upstream qemu (Anthony)
first and with the next merge to kvm-userspace. On the other hand it is the kvm
probe so an ack from Avi in case v3 is
Avi Kivity wrote:
Christian Ehrhardt wrote:
Hi, this patch breaks all non x86 architectures as
libkvm/libkvm-x86.c has the only implementation of the alias
functionality.
Until now only qemu-kvm-x86 has called that functions, but since this
patch the generic qemu-kvm.c calls them which leads
Avi Kivity wrote:
Christian Ehrhardt wrote:
I ran into the issue of a failign KVM Probe of the qemu configure
script three
times this week always needing "set -x", inserting an exit, masking
the cleanup
trap and compiling the c file by hand until I knew what the reason
is. I think
# HG changeset patch
# User Christian Ehrhardt
# Date 1229347014 -3600
# Node ID c754b8806d756a19c57fc3b3e317bbe3c147d5ec
# Parent f7dc67cd9b74c5d7ad322686e58325f879d93468
[PATCH] qemu: report issues causing the kvm probe to fail v2
From: Christian Ehrhardt
*update to v2*
It now reports all
# HG changeset patch
# User Christian Ehrhardt
# Date 1229345133 -3600
# Node ID b48b9d560f80037ab4e12eae128022622c7ccb34
# Parent 4b0ad05490115e4c6f31d2419c0e5b628040f90b
[PATCH] kvm-userspace: ppc: fix compatfd build decision v2
From: Christian Ehrhardt
qemu-kvm.c uses qemu_eventfd
compatfd.c takes
care if CONFIG_signalfd/CONFIG_eventfd are set. Therefore we can savely
remove the makefile guard completely and just always build compatfd.c.
This updated patch works for x86&powerpc with/without --disable-aio in
my tests.
It should appear on the list shortly.
--
Grüsse / rega
# HG changeset patch
# User Christian Ehrhardt
# Date 1229085659 -3600
# Node ID 37967a80a2757505488685aac135681945e6da91
# Parent f0ed33f14658fe91a14ec02501cb42d26e32f01f
[PATCH] kvm-userspace: gdb: fix new gdb function types
From: Christian Ehrhardt
The types changed in the header but not
Hollis Blanchard wrote:
On Thu, 2008-12-11 at 17:05 +0100, Jan Kiszka wrote:
Hollis Blanchard wrote:
On Thu, 2008-12-11 at 13:53 +0100, Christian Ehrhardt wrote:
This is v2 as version one had a type in it occured when splitting patches.
Mercurial somehow lost my changes to the
# HG changeset patch
# User Christian Ehrhardt <[EMAIL PROTECTED]>
# Date 1229005383 -3600
# Node ID d788f32f8f60f3a0d86ab218459089e5186632ca
# Parent f7dc67cd9b74c5d7ad322686e58325f879d93468
[PATCH] qemu: report issues causing the kvm probe to fail
From: Christian Ehrhardt <[EMAIL
# HG changeset patch
# User Christian Ehrhardt <[EMAIL PROTECTED]>
# Date 1228999833 -3600
# Node ID dc1466c9077ab162f4637fffee1869f26be02299
# Parent 4c07fe2a56c7653a9113e05bb08c2de9aec210ce
[PATCH] qemu: ppc: kvm-userspace: KVM PowerPC support for qemu gdbstub
From: Hollis Blanchard &
This is v2 as version one had a type in it occured when splitting patches.
Mercurial somehow lost my changes to the patch description explaining
that, but the patch is right this way.
Christian Ehrhardt wrote:
# HG changeset patch
# User Christian Ehrhardt <[EMAIL PROTECTED]>
# HG changeset patch
# User Christian Ehrhardt <[EMAIL PROTECTED]>
# Date 1228989958 -3600
# Node ID f80fb35de91fe69dae889c70948c9a53212ee444
# Parent 6f228c807ad0b239b7342d2974debfc66418d784
[PATCH] kvm-userspace: fix gdbstub kvm integration
From: Christian Ehrhardt <[EMAIL PROTECTE
# HG changeset patch
# User Christian Ehrhardt <[EMAIL PROTECTED]>
# Date 1228924564 -3600
# Node ID 38846cef16e56c681da1ddc179e248972c8b2ff9
# Parent 705d874ff7a24484eaa15ed75a748c4e1a70c2ef
[PATCH] kvm-userspace: ppc: Add kvm_translate wrapper
From: Hollis Blanchard <[EMAIL PROTECT
# HG changeset patch
# User Christian Ehrhardt <[EMAIL PROTECTED]>
# Date 1228989956 -3600
# Node ID 6f228c807ad0b239b7342d2974debfc66418d784
# Parent 38846cef16e56c681da1ddc179e248972c8b2ff9
[PATCH] qemu: ppc: kvm-userspace: KVM PowerPC support for qemu gdbstub
From: Hollis Blanchard &
This patch series updates the gdbstub support for kvm.
Patch 1&2 introduce basic powerpc support while patch 3 fixes gdbstub generic
code that was broken in a qemu merge.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
# HG changeset patch
# User Christian Ehrhardt <[EMAIL PROTECTED]>
# Date 1228922789 -3600
# Node ID 9a7208ca1afab83913ee14c629bf27632ee6326b
# Parent 5adc6fbbd4a3b82e1bc8acbcb233c60e89715b61
[PATCH] kvm-userspace: ppc: align with upstream qemu - pcibus
From: Christian Ehrhardt <[EMAIL
# HG changeset patch
# User Christian Ehrhardt <[EMAIL PROTECTED]>
# Date 1228922788 -3600
# Node ID f100b1bfa5f3d084d68bd2c66244271db1f5d084
# Parent b41f0d6129f51fb86bf799a5fe7b14a9270eeca4
[PATCH] kvm-userspace: ppc: fix configure enabling kvm for ppc
From: Christian Ehrhardt &
# HG changeset patch
# User Christian Ehrhardt <[EMAIL PROTECTED]>
# Date 1228922788 -3600
# Node ID c032d8555c9494f9812e4d4e0b5b511ae597
# Parent f100b1bfa5f3d084d68bd2c66244271db1f5d084
[PATCH] kvm-userspace: ppc: align with upstream qemu - breakpoint reset
From: Christian Ehrhardt &
# HG changeset patch
# User Christian Ehrhardt <[EMAIL PROTECTED]>
# Date 1228922788 -3600
# Node ID 214485869c303ab81c9da30b6784d641f58585f4
# Parent c032d8555c9494f9812e4d4e0b5b511ae597
[PATCH] kvm-userpace: ppc: align with upstream qemu - 4xxdevs
From: Christian Ehrhardt <[EMAIL
# HG changeset patch
# User Christian Ehrhardt <[EMAIL PROTECTED]>
# Date 1228922789 -3600
# Node ID 5adc6fbbd4a3b82e1bc8acbcb233c60e89715b61
# Parent 214485869c303ab81c9da30b6784d641f58585f4
[PATCH] kvm-userspace: ppc: use virtio-blk header
From: Christian Ehrhardt <[EMAIL
# HG changeset patch
# User Christian Ehrhardt <[EMAIL PROTECTED]>
# Date 1228922788 -3600
# Node ID b41f0d6129f51fb86bf799a5fe7b14a9270eeca4
# Parent 3af3fa5e009e143e1167979e55d547c453661059
[PATCH] kvm-userspace: ppc: fix compatfd build decision
From: Christian Ehrhardt <[EMAIL
en, 0);
#endif
return 0;
--
To unsubscribe from this list: send the line "unsubscribe kvm-commits" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technology Center,
overlooked something and there is an even better or trivial
approach :-)
Since this could be solved several very different ways I think its worth
a discussion.
As I prefer b) I attached a simple patch example how this could look
like :-).
--
Grüsse / regards,
Christian Ehrhardt
IBM
A recent patch in qemu and its merge removed the availability of
kvm_init_new_ap in target-$arch. The helper files now should call
kvm_init_vcpu() directly.
This patch changes that for powerpc.
This should be true for target-ia64/op_helper.c too.
Signed-off-by: Christian Ehrhardt <[EM
sorry - this should actually have some description ...
I'll resend it with one as soon as I find the issue why it is missing
Ehrhardt Christian wrote:
diff --git a/qemu/target-ppc/helper.c b/qemu/target-ppc/helper.c
--- a/qemu/target-ppc/helper.c
+++ b/qemu/target-ppc/helper.c
@@ -29
diff --git a/qemu/target-ppc/helper.c b/qemu/target-ppc/helper.c
--- a/qemu/target-ppc/helper.c
+++ b/qemu/target-ppc/helper.c
@@ -2959,10 +2959,8 @@
env->cpu_model_str = cpu_model;
cpu_ppc_register_internal(env, def);
cpu_ppc_reset(env);
-#ifdef USE_KVM
if (kvm_enabled())
-
From: Christian Ehrhardt <[EMAIL PROTECTED]>
These two patches went in with a conflict:
changeset: 16724:3ce8c651c948
user: Ehrhardt Christian <[EMAIL PROTECTED]>
date:Tue Nov 04 12:10:51 2008 +0200
summary: kvm: qemu: move x86 specific calls introduced by device
This adds powerpc to the unifdef header avi introduced.
I think s390 should work the same way and is needed as they have libkvm already.
Christian/Carsten could you ack that after a quick test if it is working?
Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]>
---
[diffstat]
uni
The device asignment patches added the x86 specific ioperm in qemu-kvm.
This patch moves
qemu-kvm.c:kvm_do_ioperm()
to
qemu-kvm-x86.c:kvm_arch_do_ioperm()
The patch also changes the qemu-kvm header and the includes according to that.
Signed-off-by: Christian Ehrhardt <[EMAIL PROTEC
1 - 100 of 178 matches
Mail list logo
