Avi:
Time to time, I see this error message, any typo exist?
thx,eddie
slab error in kmem_cache_destroy(): cache `kvm_rmap_desc': Can't free
all objects
Call Trace:
[8027c0fe] kmem_cache_destroy+0x93/0xdc
[88009125] :kvm:kvm_mmu_module_exit+0x23/0x37
I was curious if anyone thinks that it may be possible to get a
KVM-patched QEMU to use a real video card? For example, let's say I had
a second video card. Is QEMU/kvm a codebase which would support hacking
in the ability to utilize this second video card (one not utilized by
the host Linux)?
Dong, Eddie wrote:
Avi:
Time to time, I see this error message, any typo exist?
thx,eddie
slab error in kmem_cache_destroy(): cache `kvm_rmap_desc': Can't free
all objects
Call Trace:
[8027c0fe] kmem_cache_destroy+0x93/0xdc
[88009125]
On Wed, Oct 10, 2007 at 07:38:55PM +0200, Oliver Kowalke wrote:
Will this patch be included into the new kvm version (46)?
No. Hopefully it will be included in a near future version of kvm.
hmm - Iget an error:
patch -p1 ./qemu.patch
patching file qemu/hw/pc.c
patch: malformed
Anthony de Almeida Lopes wrote:
I was curious if anyone thinks that it may be possible to get a
KVM-patched QEMU to use a real video card? For example, let's say I had
a second video card. Is QEMU/kvm a codebase which would support hacking
in the ability to utilize this second video card
Laurent Vivier wrote:
Anthony de Almeida Lopes wrote:
I was curious if anyone thinks that it may be possible to get a
KVM-patched QEMU to use a real video card? For example, let's say I had
a second video card. Is QEMU/kvm a codebase which would support hacking
in the ability to utilize
Cam Macdonell wrote:
Izik Eidus wrote:
Cam Macdonell wrote:
Hi,
sorry, but patch for that feature was already wrote by someone.
but you are more than welcome to try/ask about something else.
Ah, I should've searched the list. Is there another project of similar
scope that would be
Dor Laor wrote:
Laurent Vivier wrote:
Anthony de Almeida Lopes wrote:
I was curious if anyone thinks that it may be possible to get a
KVM-patched QEMU to use a real video card? For example, let's say I had
a second video card. Is QEMU/kvm a codebase which would support hacking
in the
Jim Paris wrote:
If I stop KVM in the monitor with stop, wait a minute, and do
cont, a Linux guest gives me a BUG: soft lockup detected on CPU#0.
Is that expected behavior?
We have the same behavior on s390 when running in a virtual
environment. The issue is, that the guest physical cpu may
Hi all,
Per our privious discussions about source layout, I just worked out
these patches to support new CPU archs for KVM.
Firslty, we just move all files to its final position in source
structure as we discussed before. In the drivers/kvm directory
I add an x86 directory to hold x86 specific
From cdbc4c54cf65e46e5545fe44c9a31ae457385ee0 Mon Sep 17 00:00:00 2001
From: Zhang xiantao [EMAIL PROTECTED]
Date: Thu, 11 Oct 2007 16:42:46 +0800
In order to adapt different architectures, we have to change it to an
neutral name. kvm_ops maybe not the best name, but shouldn't introduce
different
To give a statement from other architectures I wanted to say that this patch is
fine for the power port.
From my view it is the small and easy-to-review flavor of the big patch series
I once sent to the list.
And because Carsten and I sit in the same office these patches are usually
From 70477d03b238ca76c76d51a1b03f6cee8bb0965c Mon Sep 17 00:00:00 2001
From: Zhang xiantao [EMAIL PROTECTED]
Date: Thu, 11 Oct 2007 16:40:56 +0800
Move files to its final postion in source structure. No code logic
changed!
0003-This-patch-is-the-main-work-to-to-support-differnt-a.patch.tar
Zhang, Xiantao wrote:
These patches are based on commit
7060e1c92b504ac725e2ffbc91053c1dc684e685(last commit of Oct 8).
They don't apply on top of git head anymore, could you please rebase?
Any comments are welcome!
I do appreciate your work towards portability. Could you also please
post
[EMAIL PROTECTED] wrote:
Jim Paris wrote:
If I stop KVM in the monitor with stop, wait a minute, and do
cont, a Linux guest gives me a BUG: soft lockup detected on
CPU#0. Is that expected behavior?
We have the same behavior on s390 when running in a virtual
environment. The issue is, that
Change to inline style for easy review.
From cdbc4c54cf65e46e5545fe44c9a31ae457385ee0 Mon Sep 17 00:00:00 2001
From: Zhang xiantao [EMAIL PROTECTED]
Date: Thu, 11 Oct 2007 16:42:46 +0800
Subject: [PATCH] Change kvm_x86_ops to kvm_ops, and make room for
structure kvm_arch_ops.
---
From 70477d03b238ca76c76d51a1b03f6cee8bb0965c Mon Sep 17 00:00:00 2001
From: Zhang xiantao [EMAIL PROTECTED]
Date: Thu, 11 Oct 2007 16:40:56 +0800
Move files to its final postion in source structure. No code logic
changed!
---
drivers/kvm/i8259.c | 450 --
Carsten Otte wrote:
Zhang, Xiantao wrote:
These patches are based on commit
7060e1c92b504ac725e2ffbc91053c1dc684e685(last commit of Oct 8).
They don't apply on top of git head anymore, could you please rebase?
Any comments are welcome!
I do appreciate your work towards portability. Could
On Thu, Oct 11, 2007 at 10:40:47AM +0200, Laurent Vivier wrote:
There is work in progress for pci pass through capability. Besides
PCI it also required to have pv dma or 1-1 mapping between the
guest and the host. Both will be released in the following
month. NIC pass through works but
Dong, Eddie wrote:
[EMAIL PROTECTED] wrote:
Jim Paris wrote:
If I stop KVM in the monitor with stop, wait a minute, and do
cont, a Linux guest gives me a BUG: soft lockup detected on
CPU#0. Is that expected behavior?
We have the same behavior on s390 when running in a virtual
environment.
Carsten Otte wrote:
Thanks to Avi's continued review, we've got even more common code this
time: KVM_CHECK_EXTENSION ioctl is now completely handled in kvm_main.c
instead of having arch callbacks to check extensions. The architectures
are expected to setup a bit mask named KVM_ARCH_EXTENSIONS
Zhang, Xiantao wrote:
2. kvm_x86_ops-kvm_ops.patch. In order to adapt different
architectures, we have to change it to an neutral name. kvm_ops maybe
not the best name, but shouldn't introduce different meanings. In the
third patch, we add a sub field struct kvm_arch_ops for arch-specific
Anthony Liguori wrote:
The memory size is currently hardcoded into the linker script (end_of_memory).
This prevents the memory size from being specified dynamically in kvmctl.
This patch adds a PIO port that can be used to query the memory size in the
tests.
Applied all three, thanks.
Avi Kivity wrote:
The new capability bitmap moves the patch out of the very trivial
realm. I removed those hunks and applied.
Thanks.
Send more, the approach is clearly right. Leave things which require
changes (like the capability bitmap) to the end, there's more than
enough stuff for
Anthony Liguori wrote:
Sorry, I didn't guilt refresh before sending. I'll have to modify my
patchbomb
script to check for that to avoid this in the future.
Some of the MMU functions take a struct kvm_vcpu even though they effect all
VCPUs. This patch cleans up some of them to instead take
Anthony Liguori wrote:
This time, the biggest change is gpa_to_hpa. The translation of GPA to HPA
does
not depend on the VCPU state unlike GVA to GPA so there's no need to pass in
the kvm_vcpu.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
Dong, Eddie wrote:
Avi Kivity wrote:
Dong, Eddie wrote:
Avi Kivity wrote:
It's just like the guest kernel executing hlt. Why is there a
difference?
Current VP wake up logic thru INIT/SIPI doesn't support this when
irqchip in kernel.
Doesn't this code
Christian Borntraeger wrote:
Currently kvm provides hypercalls only for x86* architectures. To
provide hypercall infrastructure for other kvm architectures I split
kvm_para.h into a generic header file and architecture specific
definitions.
Currently there are definitions for s390
Currently kvm provides hypercalls only for x86* architectures. To
provide hypercall infrastructure for other kvm architectures I split
kvm_para.h into a generic header file and architecture specific
definitions.
Currently there are definitions for s390 (experimental, ABI not final,
and I still
Avi Kivity wrote:
Zhang, Xiantao wrote:
2. kvm_x86_ops-kvm_ops.patch. In order to adapt different
architectures, we have to change it to an neutral name. kvm_ops maybe
not the best name, but shouldn't introduce different meanings. In the
third patch, we add a sub field struct kvm_arch_ops
Muli Ben-Yehuda wrote:
On Thu, Oct 11, 2007 at 10:40:47AM +0200, Laurent Vivier wrote:
There is work in progress for pci pass through capability. Besides
PCI it also required to have pv dma or 1-1 mapping between the
guest and the host. Both will be released in the following
month. NIC
Christian Borntraeger wrote:
---
include/asm-s390/kvm_para.h | 128
include/asm-x86/kvm_para.h | 110 +
include/linux/kvm_para.h| 112 --
3 files changed, 251
Avi Kivity wrote:
Dong, Eddie wrote:
Avi:
Time to time, I see this error message, any typo exist?
thx,eddie
slab error in kmem_cache_destroy(): cache `kvm_rmap_desc': Can't free
all objects
Call Trace:
[8027c0fe] kmem_cache_destroy+0x93/0xdc
[88009125]
+/* Return values for hypercalls */
+#define KVM_ENOSYS 1000
errno's can probably be in common code, right?
Yes, they can. Will move.
I originally had one of these in my paravirt_ops implementation but
quickly found that the code it produced was pretty ugly. I think:
Zhang, Xiantao wrote:
Avi Kivity wrote:
Zhang, Xiantao wrote:
2. kvm_x86_ops-kvm_ops.patch. In order to adapt different
architectures, we have to change it to an neutral name. kvm_ops maybe
not the best name, but shouldn't introduce different meanings. In the
third patch, we add a
Christian Borntraeger wrote:
I agree. It seems I can simply remove the kvm_hypercall macro.
Here is the updated patch (without the s390 parts. Will send them later
when ready) and the changes mentioned above.
Avi, Anthony, comments?
It looks good to me.
Regards,
Anthony Liguori
Jerone Young wrote:
This patch enables enable makefile in user for cross compile.
This time is a proper git formatted patch.
Thanks, applied both.
--
error compiling committee.c: too many arguments to function
-
Zhao, Yunfeng wrote:
I meet following error while compile latest kvm source code.
..
make -C qemu
make[1]: Entering directory
`/workspace/ia32e/nightly/kvm-master-2.6.22-rc4-20071010190122210/kvm-userspace/qemu'
Makefile:3: config-host.mak: No such file or directory
make[1]: ***
The same as under qemu/
[EMAIL PROTECTED] kvm-userspace]# ./configure
./configure: line 415: /tmp/qemu-conf-24955-17104-27972.c: No such file
or directory
ERROR: /usr/bin/gcc34 either does not exist or does not work
I am using RHEL5, and compat-gcc-34-g77-3.4.6-4 has been installed on
it.
This
if you put set -x at line 409 of configure, perhaps we can have more
information.
Laurent
Zhao, Yunfeng wrote:
The same as under qemu/
[EMAIL PROTECTED] kvm-userspace]# ./configure
./configure: line 415: /tmp/qemu-conf-24955-17104-27972.c: No such file
or directory
ERROR: /usr/bin/gcc34
Zhao, Yunfeng wrote:
The same as under qemu/
[EMAIL PROTECTED] kvm-userspace]# ./configure
./configure: line 415: /tmp/qemu-conf-24955-17104-27972.c: No such file
or directory
ERROR: /usr/bin/gcc34 either does not exist or does not work
Looks like /tmp is full, of read-only, or
My fault~ :(
I should spend more time to check the problem.
Don't know why the system lost the /tmp!
Thanks for your help!
Yunfeng
-Original Message-
From: Avi Kivity [mailto:[EMAIL PROTECTED]
Sent: 2007年10月11日 22:38
To: Zhao, Yunfeng
Cc: kvm-devel@lists.sourceforge.net
Subject: Re:
Steffen Winterfeldt wrote:
Hi,
sorry for the delay, but I've been on vacation. :-)
No worries :-)
You're right. Good catch!
Actually that is not true. 'mov eax,ss' does implicitly clear the upper
16 bits (both processor docs and hardware agree here).
I wasn't able to find
Hello Dong and others,
thanks for the replies. I was trying to get KVM up with latest kernel, but
didn't immediately succeed. I have it built with the instructions from a
previous reply and it seemed OK, but I haven't had a chance to try it out
yet.
As for testing the time shift: To us the
Dor Laor wrote:
Cam Macdonell wrote:
You may choose the interactivity improvements:in
http://kvm.qumranet.com/kvmwiki/TODO
Dor
Thanks Dor, I'll look into it. Beyond the description, can you
elaborate on the problem with frame rate during interactivity? Is the a
simple test that
Carsten Otte/Germany/[EMAIL PROTECTED] wrote on 10/11/2007 12:57:38 PM:
Dong, Eddie wrote:
[EMAIL PROTECTED] wrote:
Jim Paris wrote:
If I stop KVM in the monitor with stop, wait a minute, and do
cont, a Linux guest gives me a BUG: soft lockup detected on
CPU#0. Is that expected
This patch splits kvm_vcpu_ioctl into archtecture independent parts, and
x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c.
Common ioctls for all architectures are:
KVM_RUN, KVM_GET/SET_(S-)REGS, KVM_TRANSLATE, KVM_INTERRUPT,
KVM_DEBUG_GUEST, KVM_SET_SIGNAL_MASK, KVM_GET/SET_FPU
Note
Avi Kivity wrote:
This is wrong -- kvm_main.c calls vmalloc() so this is needed. The fact
that it is included by something else doesn't mean we can remove it; we
don't want to depend on random #includes within header files.
Only remove a #include if nothing within the including file
Avi Kivity wrote:
Applied, thanks. I renamed kvm_vcpu_load() and kvm_vcpu_put() back to
vcpu_load() and vcpu_put() in order to keep the patch small and simple,
and because I'm emotionally attached to the original names.
Oh, I think I had a very good reason for renaming it: it's no longer
Dor,
I ran some netperf tests with your PV
virtio drivers, along with some Xen PV cases
and a few others for comparison. I thought you
(and the list) might be interested in the numbers.
I am going to start looking for bottlenecks, unless
you need help with the new hypercall updates.
I'll
Now that we have userspace memory allocation, I wanted to play with ballooning.
The idea is that when a guest balloons down, we simply unpin the underlying
physical memory and the host kernel may or may not swap it. To reclaim
ballooned memory, the guest can just start using it and we'll pin it
Anthony Liguori wrote:
Now that we have userspace memory allocation, I wanted to play with
ballooning.
The idea is that when a guest balloons down, we simply unpin the underlying
physical memory and the host kernel may or may not swap it. To reclaim
ballooned memory, the guest can just
Izik Eidus wrote:
static void page_header_update_slot(struct kvm *kvm, void *pte,
gpa_t gpa)
{
int slot = memslot_id(kvm, gfn_to_memslot(kvm, gpa PAGE_SHIFT));
-
kvm_memory_slot
heh, i am working on
Anthony Liguori wrote:
Izik Eidus wrote:
static void page_header_update_slot(struct kvm *kvm, void *pte,
gpa_t gpa)
{
int slot = memslot_id(kvm, gfn_to_memslot(kvm, gpa
PAGE_SHIFT));
-
kvm_memory_slot
James Dykman wrote:
Dor,
I ran some netperf tests with your PV
virtio drivers, along with some Xen PV cases
and a few others for comparison. I thought you
(and the list) might be interested in the numbers.
Thanks for the tests it indeed interesting.
Actually except for a small
The idea being that kvm_read_guest_page() will effectively pin the page
and put_page() has the effect of unpinning it? It seems to me that we
should be using page_cache_release()'ing since we're not just
get_page()'ing the memory. I may be wrong though.
Both of these are an optimization
Current VP wake up logic thru INIT/SIPI doesn't support this when
irqchip in kernel.
Doesn't this code imply that waiting for SIPI is supported?
It is supported to wake up VCPU in kernel, but can't wake up the VCPU
in user level since irqchip_in_kernel is TRUE here. vcpu-mp_state
Kay Hayen wrote:
Hello Dong and others,
thanks for the replies. I was trying to get KVM up with latest
kernel, but didn't immediately succeed. I have it built with the
instructions from a previous reply and it seemed OK, but I haven't
had a chance to try it out yet.
As for testing the
Avi Kivity wrote:
Zhang, Xiantao wrote:
Avi Kivity wrote:
Zhang, Xiantao wrote:
2. kvm_x86_ops-kvm_ops.patch. In order to adapt different
architectures, we have to change it to an neutral name. kvm_ops
maybe not the best name, but shouldn't introduce different
meanings. In the third
Hi,Avi
With latest kvm commits, the SMP linux guests causes host soft lock issues can
not be reproduced on my machine.
Have you fixed it?
Thanks
Yunfeng
-Original Message-
From: Avi Kivity [mailto:[EMAIL PROTECTED]
Sent: 2007年10月9日 18:19
To: Zhao, Yunfeng
Cc: kvm-devel
Subject: Re:
60 matches
Mail list logo
