Dear all,
it seems that I am unable to pass multiple cores / CPUs to KVM guests. Whatever
I do, the guests only report one CPU / core.
Host hardware: Xeon E5620 on a Supermicro mainboard
Host software: Ubuntu 11.04 (Natty) 64-Bit
I have compiled my own (newer) kernel 2.6.37 for Natty (since I
On 01/27/2012 08:50 AM, Gerhard Wiesinger wrote:
On Thu, 26 Jan 2012, Avi Kivity wrote:
On 01/25/2012 10:15 PM, Gerhard Wiesinger wrote:
On Sun, 15 Jan 2012, Avi Kivity wrote:
On 01/15/2012 04:40 PM, Gerhard Wiesinger wrote:
On Sun, 15 Jan 2012, Jan Kiszka wrote:
On 2012-01-15 15:17, Avi
On 01/27/2012 11:34 PM, Jan Kiszka wrote:
Yes please. It's halfway through autotest and looks good. Even if I
have to change it, we can 'git rebase -p --onto' your branch (though I
doubt it will be necessary).
Done, see
git://git.kiszka.org/qemu-kvm.git queues/qemu-merge
Only
On 01/27/2012 01:24 AM, Eric Northup wrote:
Flush the shadow MMU instead of iterating over each host VA when doing
a large invalidate range callback.
The previous code is O(N) in the number of virtual pages being
invalidated, while holding both the MMU spinlock and the mmap_sem.
Large unmaps
On 01/29/2012 12:33 PM, Avi Kivity wrote:
On 01/27/2012 11:34 PM, Jan Kiszka wrote:
Yes please. It's halfway through autotest and looks good. Even if I
have to change it, we can 'git rebase -p --onto' your branch (though I
doubt it will be necessary).
Done, see
On 2012-01-29 12:12, Avi Kivity wrote:
On 01/29/2012 12:33 PM, Avi Kivity wrote:
On 01/27/2012 11:34 PM, Jan Kiszka wrote:
Yes please. It's halfway through autotest and looks good. Even if I
have to change it, we can 'git rebase -p --onto' your branch (though I
doubt it will be necessary).
On 01/29/2012 01:15 PM, Jan Kiszka wrote:
On 2012-01-29 12:12, Avi Kivity wrote:
On 01/29/2012 12:33 PM, Avi Kivity wrote:
On 01/27/2012 11:34 PM, Jan Kiszka wrote:
Yes please. It's halfway through autotest and looks good. Even if I
have to change it, we can 'git rebase -p --onto'
On 2012-01-29 12:18, Avi Kivity wrote:
On 01/29/2012 01:15 PM, Jan Kiszka wrote:
On 2012-01-29 12:12, Avi Kivity wrote:
On 01/29/2012 12:33 PM, Avi Kivity wrote:
On 01/27/2012 11:34 PM, Jan Kiszka wrote:
Yes please. It's halfway through autotest and looks good. Even if I
have to change
On 2012-01-29 12:18, Avi Kivity wrote:
2. Migration is broken.
OK, that's new. A trivial scenario?
Incoming command line:
qemu-system-x86_64 -m 512 /images/Fedora.img -smp 2 -monitor stdio
-incoming tcp::
I expect you can remove '-smp 2' and it would still fail.
Could you
On 01/29/2012 01:54 PM, Jan Kiszka wrote:
On 2012-01-29 12:18, Avi Kivity wrote:
2. Migration is broken.
OK, that's new. A trivial scenario?
Incoming command line:
qemu-system-x86_64 -m 512 /images/Fedora.img -smp 2 -monitor stdio
-incoming tcp::
I expect you can
On 2012-01-29 13:01, Avi Kivity wrote:
On 01/29/2012 01:54 PM, Jan Kiszka wrote:
On 2012-01-29 12:18, Avi Kivity wrote:
2. Migration is broken.
OK, that's new. A trivial scenario?
Incoming command line:
qemu-system-x86_64 -m 512 /images/Fedora.img -smp 2 -monitor stdio
-incoming
On 01/29/2012 02:02 PM, Jan Kiszka wrote:
On 2012-01-29 13:01, Avi Kivity wrote:
On 01/29/2012 01:54 PM, Jan Kiszka wrote:
On 2012-01-29 12:18, Avi Kivity wrote:
2. Migration is broken.
OK, that's new. A trivial scenario?
Incoming command line:
qemu-system-x86_64 -m 512
On 01/29/2012 02:04 PM, Avi Kivity wrote:
On 01/29/2012 02:02 PM, Jan Kiszka wrote:
On 2012-01-29 13:01, Avi Kivity wrote:
On 01/29/2012 01:54 PM, Jan Kiszka wrote:
On 2012-01-29 12:18, Avi Kivity wrote:
2. Migration is broken.
OK, that's new. A trivial scenario?
This is the first step to separate the architecture specific members.
The rmap and dirty_bitmap can be treated later based on this.
Takuya
arch/ia64/include/asm/kvm_host.h|3 +
arch/ia64/kvm/kvm-ia64.c| 10
arch/powerpc/include/asm/kvm_host.h |3 +
From: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
This patch cleans up the code and removes the (void)level; warning
suppressor.
Note that we can also use this for PT_PAGE_TABLE_LEVEL to treat every
level uniformly later.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
From: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
This makes it easy to make lpage_info architecture specific.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
virt/kvm/kvm_main.c | 83 ---
1 files changed, 52
From: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
Narrow down the controlled text inside the conditional so that it will
include lpage_info and rmap stuff only.
For this we change the way we check whether the slot is being created
from if (npages !new.rmap) to if (npages !old.npages).
From: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
Some members added recently to kvm_memory_slot are not used by every
architectures.
This patch is the first step to make this difference clear by
introducing kvm_memory_slot::arch; lpage_info is moved into it.
Signed-off-by: Takuya
On 01/29/2012 02:06 PM, Avi Kivity wrote:
Blue posted patches for this. s/=// is the simplest.
Err, not. I'll just try Blue's patch.
With a fix, migration doesn't complete. Looking into it.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this
From: Sergei Trofimovich sly...@gentoo.org
$ ./configure --target-list=alpha-softmmu make
CCalpha-softmmu/i8259.o
cc1: warnings being treated as errors
/home/slyfox/dev/git/qemu-kvm/hw/i8259.c: In function 'kvm_i8259_set_irq':
On Sun, 29 Jan 2012 13:01:18 +0200
Avi Kivity a...@redhat.com wrote:
Tested by attaching a debugger to a running qemu w/kvm and running
call munmap(0, 1UL 46).
How about computing the intersection of (start, end) with the hva ranges
in kvm-memslots?
If there is no intersection, you
On 01/29/2012 03:22 PM, Takuya Yoshikawa wrote:
On Sun, 29 Jan 2012 13:01:18 +0200
Avi Kivity a...@redhat.com wrote:
Tested by attaching a debugger to a running qemu w/kvm and running
call munmap(0, 1UL 46).
How about computing the intersection of (start, end) with the hva ranges
On Sun, 29 Jan 2012 15:25:59 +0200
Avi Kivity a...@redhat.com wrote:
I think introducing kvm_handle_hva_range() is the right thing if we really
care about unmapping large area at once.
Current iteration:
for each page
for each slot
for each level
My suggestion:
Dear All,
I am using RHEL 6.2 + KVM on a X86_64 server. I have been able to create Linux
guests using virt-install (using virto and/or pci passthrough) and am able to
manage the guests using virsh and/or virt-manager for doing some basic stuff.
Here is a sample guest (that I was able to
Hi all,
I'm studying the TPR access optimization in qemu-kvm for quite a while
now. It's one of the, well, let's call it hardest parts of qemu-kvm I
dealt with so far. But it's slowly getting clearer.
One thing I'm wondering now: This is practically targeting only 32-bit
Windows, right? Already
On 01/29/2012 05:37 PM, Jan Kiszka wrote:
Hi all,
I'm studying the TPR access optimization in qemu-kvm for quite a while
now. It's one of the, well, let's call it hardest parts of qemu-kvm I
dealt with so far. But it's slowly getting clearer.
I'll be happy to answer questions here or on IRC.
On 01/29/2012 05:51 PM, Avi Kivity wrote:
Already the assumption that we find a CPU index at
fs:0x51 is apparently hard-coding this. Or that kernel code is at
0x8xxx or 0xExxx.
But what makes sure that we aren't patching some other obscure OS that
doesn't comply with our
On 2012-01-29 16:52, Avi Kivity wrote:
On 01/29/2012 05:51 PM, Avi Kivity wrote:
Already the assumption that we find a CPU index at
fs:0x51 is apparently hard-coding this. Or that kernel code is at
0x8xxx or 0xExxx.
But what makes sure that we aren't patching some other obscure OS
On 01/29/2012 02:35 PM, Avi Kivity wrote:
On 01/29/2012 02:06 PM, Avi Kivity wrote:
Blue posted patches for this. s/=// is the simplest.
Err, not. I'll just try Blue's patch.
With a fix, migration doesn't complete. Looking into it.
Turns out the migration problems are
On 29.01.2012 19:17, Vinod Chegu wrote:
Dear All,
I am using RHEL 6.2 + KVM on a X86_64 server. I have been able to create
Linux
guests using virt-install (using virto and/or pci passthrough) and am able to
manage the guests using virsh and/or virt-manager for doing some basic stuff.
On 01/29/2012 05:55 PM, Jan Kiszka wrote:
On 2012-01-29 16:52, Avi Kivity wrote:
On 01/29/2012 05:51 PM, Avi Kivity wrote:
Already the assumption that we find a CPU index at
fs:0x51 is apparently hard-coding this. Or that kernel code is at
0x8xxx or 0xExxx.
But what makes sure
On 2012-01-29 17:27, Avi Kivity wrote:
On 01/29/2012 05:55 PM, Jan Kiszka wrote:
On 2012-01-29 16:52, Avi Kivity wrote:
On 01/29/2012 05:51 PM, Avi Kivity wrote:
Already the assumption that we find a CPU index at
fs:0x51 is apparently hard-coding this. Or that kernel code is at
0x8xxx or
Hi everyone,
I'm having a strange problem passing an mlx4 device into a kvm guest.
The device in question is:
05:00.0 InfiniBand [0c06]: Mellanox Technologies MT26428 [ConnectX
VPI PCIe 2.0 5GT/s - IB QDR / 10GigE] [15b3:673c] (rev b0)
running the latest (I believe) FW version 2.9.1000.
Hi Asias,
Remember this patch? :-) I didn't... oops.
On 09/01/12 18:51, Asias He wrote:
On 01/09/2012 02:45 PM, Matt Evans wrote:
This commit adds a target for 'lkvm-static' which is linked -static.
(This can be useful to construct kvmtool binaries for minimalist
auto-test host
This is the first step to separate the architecture specific members.
The rmap and dirty_bitmap can be treated later based on this.
v1-v2:
Patch 3:
- Removed extra checks for NULL when we create a new slot.
- Removed if (user_alloc) check taken from the s390 code.
Patch 4:
- Just
This patch cleans up the code and removes the (void)level; warning
suppressor.
Note that we can also use this for PT_PAGE_TABLE_LEVEL to treat every
level uniformly later.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
arch/x86/kvm/mmu.c |3 +--
This makes it easy to make lpage_info architecture specific.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
virt/kvm/kvm_main.c | 83 ---
1 files changed, 52 insertions(+), 31 deletions(-)
diff --git a/virt/kvm/kvm_main.c
Narrow down the controlled text inside the conditional so that it will
include lpage_info and rmap stuff only.
For this we change the way we check whether the slot is being created
from if (npages !new.rmap) to if (npages !old.npages).
We also stop checking if lpage_info is NULL when we create
Some members of kvm_memory_slot are not used by every architecture.
This patch is the first step to make this difference clear by
introducing kvm_memory_slot::arch; lpage_info is moved into it.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
arch/ia64/include/asm/kvm_host.h
On Mon, 2012-01-30 at 14:18 +1100, Matt Evans wrote:
In lieu of any good lightweight solutions, can we include this patch as it is
still useful for builds on systems without the offending optional libraries?
How about we do it as a 'make static' target which will generate a
static binary
On 30/01/12 14:51, Sasha Levin wrote:
On Mon, 2012-01-30 at 14:18 +1100, Matt Evans wrote:
In lieu of any good lightweight solutions, can we include this patch as it is
still useful for builds on systems without the offending optional libraries?
How about we do it as a 'make static' target
(2012/01/30 12:53), Takuya Yoshikawa wrote:
@@ -833,7 +778,7 @@ int __kvm_set_memory_region(struct kvm *kvm,
if (!new.rmap)
goto out_free;
- if (create_lpage_info(new, npages))
+ if (kvm_arch_create_memslot(new, npages))
Some members of kvm_memory_slot are not used by every architecture.
This patch is the first step to make this difference clear by
introducing kvm_memory_slot::arch; lpage_info is moved into it.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
arch/ia64/include/asm/kvm_host.h
43 matches
Mail list logo
