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
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
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
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
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
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
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
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
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
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
59,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())
- kvm_init_new_ap(env->cpu_index, env);
-#endif
+ kvm_init_vcpu(env);
return env;
}
--
Grüsse / regards,
Christi
c :-)
I know you started with the arch-platform-os-compiler after our discussion,
but I like the $PROCESSOR solution for our *powerpc* Makefiles too.
And a good catch with that AR usage in patch 7.
(full series)
Acked-by: Christian Ehrhardt <[EMAIL PROTECTED]>
--
Grüsse / regards,
Chri
nchard <[EMAIL PROTECTED]>
This patch adds a better error reporting for powerpc testcases.
It prints the bytes read in load_file so far until an error occured.
Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]>
---
[dif
single patch I just
submitted while cleaning our userspace repo to get the missing things
upstream.
Avi, let me know if I confused you and I'll send them once again with
some time in between to order them easier.
[EMAIL PROTECTED] wrote:
From: Christian Ehrhardt <[EMAIL PROTECTED]>
malc wrote:
On Tue, 30 Sep 2008, [EMAIL PROTECTED] wrote:
From: Christian Ehrhardt <[EMAIL PROTECTED]>
*update*
further debugging according to some requests revealed that
ARCH_CFLAGS does
not contain all CFLAGS that might be needed, especially those
supplied via
extra-cflags. The
gt;
> > By the way, I will be on vacation for a few weeks starting Monday, but
> > Christian Ehrhardt should be able to take care of any technical issues.
>
> Applied all; thanks. I prefer to only merge bug fixes at this time for
> 2.6.27. As far as I can tell, patch 2 is independ
be
working fine.
> >
> > The net is that we don't need to flush the TLB on privilege
> > switches, but we do on guest context switches (which are far
> > more infrequent). Guest boot time performance improvement: about 30%.
> >
--
Grüsse / regards,
Christi
could do things like
- initialize i with 0 and let the whole block until the for loop run in
"if !defined(__s390__)"
That way you would additionally stop modifying the tss_ext variable
which is not used in the s390 case anyway.
[...]
--
Grüsse / regards,
Christian Ehrha
On Monday 07 July 2008 17:34:13 Jun Koi wrote:
> On Mon, Jul 7, 2008 at 11:07 PM, Christian Ehrhardt
>
> <[EMAIL PROTECTED]> wrote:
> > Jun Koi wrote:
> >> Hi,
> >>
> >> Could anybody explain a bit about kvmtrace? I cannot find any doc on
> &
Hollis Blanchard wrote:
On Mon, 2008-07-07 at 15:56 +0200, [EMAIL PROTECTED] wrote:
From: Christian Ehrhardt <[EMAIL PROTECTED]>
The current implementation of kvmtrace uses always a 64 bit cycle variable,
but get_cycles() which is used to fill it is "unsigned long" which
Hollis Blanchard wrote:
On Mon, 2008-07-07 at 15:56 +0200, [EMAIL PROTECTED] wrote:
From: Christian Ehrhardt <[EMAIL PROTECTED]>
The current implementation of kvmtrace uses always a 64 bit cycle variable,
but get_cycles() which is used to fill it is "unsigned long" which
age to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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
[PATCH] kvmppc: kvmtrace: fix "Remove use of bit fields in kvm trace
structure"
From: Christian Ehrhardt <[EMAIL PROTECTED]>
The current patch kvm_trace_nobitfields.diff in the kvmppc.hg-dev repo
doesn't compile and has some minor flaws.
This patch is known to the kvm
56 matches
Mail list logo