Unable to pass multiple cores / CPUs to guests
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 had certain problems with PCI passthrough if I used the standard kernel). I did not alter the other parts of the distribution; notably, I am using the original qemu-kvm package which was included. Since virt-manager and the related tools were failing with unintelligible error messages when trying the very first basic action, I am starting the virtual machines by hand instead of using any wrappers / managers. I am using commands like this one: /usr/bin/qemu-system-x86_64 -M pc -cpu host -smp cores=2,threads=1,sockets=1 -drive file=/dev/sda6,if=virtio,cache=none,index=0 -drive file=/dev/sdb,if=virtio,cache=none,index=1 -cdrom /dev/cdrom -pidfile ./qemu-garak.pid -boot c -k de -m 4096 -smp 1 -device pci-assign,host=01:05.0 -daemonize -usb -usbdevice tablet -name garak -net nic,vlan=0,model=virtio,macaddr=02:01:01:01:01:01 -net tap,vlan=0,ifname=virtnet1,script=/etc/qemu-ifup,downscript=/etc/qemu-ifup -vnc :1 I also have tried -cpu host and -smp cores=1,threads=1,sockets=2 (amongst other things). I am running several Windows guests (Server 2003 R2 (32 Bit), Server 2008 R2 (64 Bit), Windows XP Pro (32 Bit), Windows 7 Pro (64 Bit)) and Linux guests (Ubuntu 11.10 (64 Bit), Debian squeeze (32 Bit)), but all of these only report one processor / core, regardless of the -smp settings; besides that, the setup works reliably. Now, I really need additional CPU power in one of the guests, so I am wondering what I am doing wrong. Of course, I have read about changing the HAL within Windows and tried several things (Uniprocessor HAL vs. Multiprocessor HAL), but with no success. After having put a whole day into trying to solve the problem, I now don't know what else I could do. Does anybody have any idea what is going wrong? Is there some kernel compile option (2.6.37) which may be responsible for not being able to pass multiple cores to the guests? Does the qemu-kvm version have to fit to the kernel version (there are no warning messages when I start the guests like shown above)? Thank you very much, Binarus -- 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
Re: [Qemu-devel] [PATCH] kvm: flush the dirty log when unregistering a slot
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 Kivity wrote: Otherwise, the dirty log information is lost in the kernel forever. Fixes opensuse-12.1 boot screen, which changes the vga windows rapidly. Confirmed, problems solved here. Problem from: http://permalink.gmane.org/gmane.comp.emulators.qemu/131853 Confirmed to be fixed, too. Long awaited patch :-) Sorry, I forgot about that. Please ping me if I do that. BTW: There is also a major difference in video performance: 1.) With Patch: 1400MB/s (MByte/s) 2.) Without Patch: 6MB/s Any reason for that? What are you measuring exactly? I'm measuring VGA video performance under DOS with own written test program. What's strange, new findings: Measurement doesn't depend on the patch. Sometimes it is high sometimes low. I think I have to investigate further. Any ideas? What vga mode are you using? What does the test program do? DOS Test programs, source and binaries can be found at: http://www.wiesinger.com/opensource/qemu/ And which one is slower? 1.) Measures page A000: with videomode 4F02, see: http://www.wiesinger.com/opensource/qemu/memperf.c 2.) Second test program measures setting and getting video bank, see: http://www.wiesinger.com/opensource/qemu/int10per.c We already talked about the low performance some time ago and tracked it down to kernel = userspace switching. But I benchmarked it already once and I think there are some optimizations possible (linear list search) with mapping functions (e.g. trivial hash function before) That would be due to srcu, but recent optimizations in srcu should make is faster than it was initially (though still slow - kvm trades off memory map update speed for run-time memory access speed). -- error compiling committee.c: too many arguments to function -- 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
Re: Merging kvm-apic into qemu-kvm
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 moderately tested so far, I'm counting on your machinery. Pulled, thanks a lot. Testing now. -- error compiling committee.c: too many arguments to function -- 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
Re: [RFC] KVM MMU: improve large munmap efficiency
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 can cause significant delay, during which the process is unkillable. Worse, all page allocation could be delayed if there's enough memory pressure that mmu_shrink gets called. Signed-off-by: Eric Northup digitale...@google.com --- We have seen delays of over 30 seconds doing a large (128GB) unmap. It'd be nicer to check if the amount of work to be done by the entire flush is less than the work to be done iterating over each HVA page, but that information isn't currently available to the arch- independent part of KVM. Better ideas would be most welcome ;-) 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 exit immediately. It's still possible for the work to drop the intersection to be larger than dropping the entire shadow, but it's unlikely. -- error compiling committee.c: too many arguments to function -- 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
Re: Merging kvm-apic into qemu-kvm
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 git://git.kiszka.org/qemu-kvm.git queues/qemu-merge Only moderately tested so far, I'm counting on your machinery. Pulled, thanks a lot. Testing now. 1. The default shows apic/ioapic in 'info qtree' (no kvm-), yet I see the vcpu threads in kvm_vcpu_block(), implying in-kernel irqchip. Something's wrong. 2. Migration is broken. -- error compiling committee.c: too many arguments to function -- 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
Re: Merging kvm-apic into qemu-kvm
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). Done, see git://git.kiszka.org/qemu-kvm.git queues/qemu-merge Only moderately tested so far, I'm counting on your machinery. Pulled, thanks a lot. Testing now. 1. The default shows apic/ioapic in 'info qtree' (no kvm-), yet I see the vcpu threads in kvm_vcpu_block(), implying in-kernel irqchip. Something's wrong. Nope, that's just the behavior of the original qemu-kvm irqchip (i.e. kvm extension is merged into the emulated device). Nothing changed here so far. 2. Migration is broken. OK, that's new. A trivial scenario? Jan signature.asc Description: OpenPGP digital signature
Re: Merging kvm-apic into qemu-kvm
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' your branch (though I doubt it will be necessary). Done, see git://git.kiszka.org/qemu-kvm.git queues/qemu-merge Only moderately tested so far, I'm counting on your machinery. Pulled, thanks a lot. Testing now. 1. The default shows apic/ioapic in 'info qtree' (no kvm-), yet I see the vcpu threads in kvm_vcpu_block(), implying in-kernel irqchip. Something's wrong. Nope, that's just the behavior of the original qemu-kvm irqchip (i.e. kvm extension is merged into the emulated device). Nothing changed here so far. So, -no-kvm-irqchip should still work as expected? 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. -- error compiling committee.c: too many arguments to function -- 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
Re: Merging kvm-apic into qemu-kvm
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 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 moderately tested so far, I'm counting on your machinery. Pulled, thanks a lot. Testing now. 1. The default shows apic/ioapic in 'info qtree' (no kvm-), yet I see the vcpu threads in kvm_vcpu_block(), implying in-kernel irqchip. Something's wrong. Nope, that's just the behavior of the original qemu-kvm irqchip (i.e. kvm extension is merged into the emulated device). Nothing changed here so far. So, -no-kvm-irqchip should still work as expected? Yes. In addition, I've patches here to make -machine kernel_irqchip=off work as well. 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. Will check. Jan signature.asc Description: OpenPGP digital signature
Re: Merging kvm-apic into qemu-kvm
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 check if merge point 5fc4ecdf10 works for you? For me it does, and b1b774ba43 starts failing. Given that the screen is corrupted on the target side, I suspect the cirrus hwlib moving may have an influence. Jan signature.asc Description: OpenPGP digital signature
Re: Merging kvm-apic into qemu-kvm
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 remove '-smp 2' and it would still fail. Could you check if merge point 5fc4ecdf10 works for you? For me it does, and b1b774ba43 starts failing. Given that the screen is corrupted on the target side, I suspect the cirrus hwlib moving may have an influence. It does, and I see the screen corruption as well (on the HEAD of the merge, not 5fc4). -- error compiling committee.c: too many arguments to function -- 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
Re: Merging kvm-apic into qemu-kvm
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 tcp:: I expect you can remove '-smp 2' and it would still fail. Could you check if merge point 5fc4ecdf10 works for you? For me it does, and b1b774ba43 starts failing. Given that the screen is corrupted on the target side, I suspect the cirrus hwlib moving may have an influence. It does, and I see the screen corruption as well (on the HEAD of the merge, not 5fc4). Looks like 59abb06198 (memory: fix dirty mask function length handling) is causing this. Might be visible with upstream as well then. Any idea? Jan signature.asc Description: OpenPGP digital signature
Re: Merging kvm-apic into qemu-kvm
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 /images/Fedora.img -smp 2 -monitor stdio -incoming tcp:: I expect you can remove '-smp 2' and it would still fail. Could you check if merge point 5fc4ecdf10 works for you? For me it does, and b1b774ba43 starts failing. Given that the screen is corrupted on the target side, I suspect the cirrus hwlib moving may have an influence. It does, and I see the screen corruption as well (on the HEAD of the merge, not 5fc4). Looks like 59abb06198 (memory: fix dirty mask function length handling) is causing this. Might be visible with upstream as well then. Any idea? Blue posted patches for this. s/=// is the simplest. -- error compiling committee.c: too many arguments to function -- 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
Re: Merging kvm-apic into qemu-kvm
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? 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 check if merge point 5fc4ecdf10 works for you? For me it does, and b1b774ba43 starts failing. Given that the screen is corrupted on the target side, I suspect the cirrus hwlib moving may have an influence. It does, and I see the screen corruption as well (on the HEAD of the merge, not 5fc4). Looks like 59abb06198 (memory: fix dirty mask function length handling) is causing this. Might be visible with upstream as well then. Any idea? Blue posted patches for this. s/=// is the simplest. Err, not. I'll just try Blue's patch. -- error compiling committee.c: too many arguments to function -- 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
[PATCH 0/4] KVM: Introduce kvm_memory_slot::arch
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 + arch/powerpc/kvm/powerpc.c | 10 arch/s390/include/asm/kvm_host.h|3 + arch/s390/kvm/kvm-s390.c| 10 arch/x86/include/asm/kvm_host.h |9 arch/x86/kvm/mmu.c |5 +- arch/x86/kvm/x86.c | 62 + include/linux/kvm_host.h| 18 +--- virt/kvm/kvm_main.c | 86 --- 11 files changed, 144 insertions(+), 75 deletions(-) -- 1.7.5.4 -- 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
[PATCH 1/4] KVM: Introduce gfn_to_index() which returns the index for a given level
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
---
arch/x86/kvm/mmu.c |3 +--
include/linux/kvm_host.h |7 +++
virt/kvm/kvm_main.c |7 +--
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index ae76cc3..37e7f10 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -688,8 +688,7 @@ static struct kvm_lpage_info *lpage_info_slot(gfn_t gfn,
{
unsigned long idx;
- idx = (gfn KVM_HPAGE_GFN_SHIFT(level)) -
- (slot-base_gfn KVM_HPAGE_GFN_SHIFT(level));
+ idx = gfn_to_index(gfn, slot-base_gfn, level);
return slot-lpage_info[level - 2][idx];
}
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index eada8e6..06d4e41 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -656,6 +656,13 @@ static inline int memslot_id(struct kvm *kvm, gfn_t gfn)
return gfn_to_memslot(kvm, gfn)-id;
}
+static inline gfn_t gfn_to_index(gfn_t gfn, gfn_t base_gfn, int level)
+{
+ /* KVM_HPAGE_GFN_SHIFT(PT_PAGE_TABLE_LEVEL) must be 0. */
+ return (gfn KVM_HPAGE_GFN_SHIFT(level)) -
+ (base_gfn KVM_HPAGE_GFN_SHIFT(level));
+}
+
static inline unsigned long gfn_to_hva_memslot(struct kvm_memory_slot *slot,
gfn_t gfn)
{
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 9f32bff..e483ae4 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -797,15 +797,10 @@ int __kvm_set_memory_region(struct kvm *kvm,
int lpages;
int level = i + 2;
- /* Avoid unused variable warning if no large pages */
- (void)level;
-
if (new.lpage_info[i])
continue;
- lpages = 1 + ((base_gfn + npages - 1)
- KVM_HPAGE_GFN_SHIFT(level));
- lpages -= base_gfn KVM_HPAGE_GFN_SHIFT(level);
+ lpages = gfn_to_index(base_gfn + npages - 1, base_gfn, level) +
1;
new.lpage_info[i] = vzalloc(lpages *
sizeof(*new.lpage_info[i]));
--
1.7.5.4
--
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
[PATCH 2/4] KVM: Split lpage_info creation out from __kvm_set_memory_region()
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 insertions(+), 31 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index e483ae4..2ef9f2d 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -698,6 +698,56 @@ void update_memslots(struct kvm_memslots *slots, struct
kvm_memory_slot *new)
slots-generation++;
}
+#ifndef CONFIG_S390
+static int create_lpage_info(struct kvm_memory_slot *slot, unsigned long
npages)
+{
+ int i;
+
+ for (i = 0; i KVM_NR_PAGE_SIZES - 1; ++i) {
+ unsigned long ugfn;
+ int lpages;
+ int level = i + 2;
+
+ if (slot-lpage_info[i])
+ continue;
+
+ lpages = gfn_to_index(slot-base_gfn + npages - 1,
+ slot-base_gfn, level) + 1;
+
+ slot-lpage_info[i] = vzalloc(lpages *
sizeof(*slot-lpage_info[i]));
+ if (!slot-lpage_info[i])
+ goto out_free;
+
+ if (slot-base_gfn (KVM_PAGES_PER_HPAGE(level) - 1))
+ slot-lpage_info[i][0].write_count = 1;
+ if ((slot-base_gfn + npages) (KVM_PAGES_PER_HPAGE(level) -
1))
+ slot-lpage_info[i][lpages - 1].write_count = 1;
+ ugfn = slot-userspace_addr PAGE_SHIFT;
+ /*
+* If the gfn and userspace address are not aligned wrt each
+* other, or if explicitly asked to, disable large page
+* support for this slot
+*/
+ if ((slot-base_gfn ^ ugfn) (KVM_PAGES_PER_HPAGE(level) - 1)
||
+ !largepages_enabled) {
+ unsigned long j;
+
+ for (j = 0; j lpages; ++j)
+ slot-lpage_info[i][j].write_count = 1;
+ }
+ }
+
+ return 0;
+
+out_free:
+ for (i = 0; i KVM_NR_PAGE_SIZES - 1; ++i) {
+ vfree(slot-lpage_info[i]);
+ slot-lpage_info[i] = NULL;
+ }
+ return -ENOMEM;
+}
+#endif /* not defined CONFIG_S390 */
+
/*
* Allocate some memory and give it an address in the guest physical address
* space.
@@ -791,37 +841,8 @@ int __kvm_set_memory_region(struct kvm *kvm,
if (!npages)
goto skip_lpage;
- for (i = 0; i KVM_NR_PAGE_SIZES - 1; ++i) {
- unsigned long ugfn;
- unsigned long j;
- int lpages;
- int level = i + 2;
-
- if (new.lpage_info[i])
- continue;
-
- lpages = gfn_to_index(base_gfn + npages - 1, base_gfn, level) +
1;
-
- new.lpage_info[i] = vzalloc(lpages *
sizeof(*new.lpage_info[i]));
-
- if (!new.lpage_info[i])
- goto out_free;
-
- if (base_gfn (KVM_PAGES_PER_HPAGE(level) - 1))
- new.lpage_info[i][0].write_count = 1;
- if ((base_gfn+npages) (KVM_PAGES_PER_HPAGE(level) - 1))
- new.lpage_info[i][lpages - 1].write_count = 1;
- ugfn = new.userspace_addr PAGE_SHIFT;
- /*
-* If the gfn and userspace address are not aligned wrt each
-* other, or if explicitly asked to, disable large page
-* support for this slot
-*/
- if ((base_gfn ^ ugfn) (KVM_PAGES_PER_HPAGE(level) - 1) ||
- !largepages_enabled)
- for (j = 0; j lpages; ++j)
- new.lpage_info[i][j].write_count = 1;
- }
+ if (create_lpage_info(new, npages))
+ goto out_free;
skip_lpage:
--
1.7.5.4
--
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
[PATCH 3/4] KVM: Simplify ifndef conditional usage in __kvm_set_memory_region()
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).
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
virt/kvm/kvm_main.c | 34 +-
1 files changed, 13 insertions(+), 21 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 2ef9f2d..ee233ce 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -616,7 +616,6 @@ static int kvm_vm_release(struct inode *inode, struct file
*filp)
return 0;
}
-#ifndef CONFIG_S390
/*
* Allocation size is twice as large as the actual dirty bitmap size.
* This makes it possible to do double buffering: see x86's
@@ -624,6 +623,7 @@ static int kvm_vm_release(struct inode *inode, struct file
*filp)
*/
static int kvm_create_dirty_bitmap(struct kvm_memory_slot *memslot)
{
+#ifndef CONFIG_S390
unsigned long dirty_bytes = 2 * kvm_dirty_bitmap_bytes(memslot);
if (dirty_bytes PAGE_SIZE)
@@ -636,9 +636,9 @@ static int kvm_create_dirty_bitmap(struct kvm_memory_slot
*memslot)
memslot-dirty_bitmap_head = memslot-dirty_bitmap;
memslot-nr_dirty_pages = 0;
+#endif /* !CONFIG_S390 */
return 0;
}
-#endif /* !CONFIG_S390 */
static struct kvm_memory_slot *
search_memslots(struct kvm_memslots *slots, gfn_t gfn)
@@ -828,23 +828,20 @@ int __kvm_set_memory_region(struct kvm *kvm,
r = -ENOMEM;
/* Allocate if a slot is being created */
+ if (npages !old.npages) {
+ new.user_alloc = user_alloc;
+ if (user_alloc)
+ new.userspace_addr = mem-userspace_addr;
#ifndef CONFIG_S390
- if (npages !new.rmap) {
- new.rmap = vzalloc(npages * sizeof(*new.rmap));
-
- if (!new.rmap)
+ if (!new.rmap) {
+ new.rmap = vzalloc(npages * sizeof(*new.rmap));
+ if (!new.rmap)
+ goto out_free;
+ }
+ if (create_lpage_info(new, npages))
goto out_free;
-
- new.user_alloc = user_alloc;
- new.userspace_addr = mem-userspace_addr;
+#endif /* not defined CONFIG_S390 */
}
- if (!npages)
- goto skip_lpage;
-
- if (create_lpage_info(new, npages))
- goto out_free;
-
-skip_lpage:
/* Allocate page dirty bitmap if needed */
if ((new.flags KVM_MEM_LOG_DIRTY_PAGES) !new.dirty_bitmap) {
@@ -852,11 +849,6 @@ skip_lpage:
goto out_free;
/* destroy any largepage mappings for dirty tracking */
}
-#else /* not defined CONFIG_S390 */
- new.user_alloc = user_alloc;
- if (user_alloc)
- new.userspace_addr = mem-userspace_addr;
-#endif /* not defined CONFIG_S390 */
if (!npages) {
struct kvm_memory_slot *slot;
--
1.7.5.4
--
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
[PATCH 4/4] KVM: Introduce kvm_memory_slot::arch and move lpage_info into it
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 Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
arch/ia64/include/asm/kvm_host.h|3 +
arch/ia64/kvm/kvm-ia64.c| 10 +
arch/powerpc/include/asm/kvm_host.h |3 +
arch/powerpc/kvm/powerpc.c | 10 +
arch/s390/include/asm/kvm_host.h|3 +
arch/s390/kvm/kvm-s390.c| 10 +
arch/x86/include/asm/kvm_host.h |9
arch/x86/kvm/mmu.c |2 +-
arch/x86/kvm/x86.c | 62 +++
include/linux/kvm_host.h| 11 ++---
virt/kvm/kvm_main.c | 70 ---
11 files changed, 124 insertions(+), 69 deletions(-)
diff --git a/arch/ia64/include/asm/kvm_host.h b/arch/ia64/include/asm/kvm_host.h
index 2689ee5..e35b3a8 100644
--- a/arch/ia64/include/asm/kvm_host.h
+++ b/arch/ia64/include/asm/kvm_host.h
@@ -459,6 +459,9 @@ struct kvm_sal_data {
unsigned long boot_gp;
};
+struct kvm_arch_memory_slot {
+};
+
struct kvm_arch {
spinlock_t dirty_log_lock;
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index 8ca7261..d8ddbba 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -1571,6 +1571,16 @@ int kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct
vm_fault *vmf)
return VM_FAULT_SIGBUS;
}
+void kvm_arch_free_memslot(struct kvm_memory_slot *free,
+ struct kvm_memory_slot *dont)
+{
+}
+
+int kvm_arch_create_memslot(struct kvm_memory_slot *slot, unsigned long npages)
+{
+ return 0;
+}
+
int kvm_arch_prepare_memory_region(struct kvm *kvm,
struct kvm_memory_slot *memslot,
struct kvm_memory_slot old,
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index af438b1..b9188aa 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -212,6 +212,9 @@ struct revmap_entry {
#define KVMPPC_PAGE_WRITETHRU HPTE_R_W/* 0x40 */
#define KVMPPC_GOT_PAGE0x80
+struct kvm_arch_memory_slot {
+};
+
struct kvm_arch {
#ifdef CONFIG_KVM_BOOK3S_64_HV
unsigned long hpt_virt;
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 0e21d15..00d7e34 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -281,6 +281,16 @@ long kvm_arch_dev_ioctl(struct file *filp,
return -EINVAL;
}
+void kvm_arch_free_memslot(struct kvm_memory_slot *free,
+ struct kvm_memory_slot *dont)
+{
+}
+
+int kvm_arch_create_memslot(struct kvm_memory_slot *slot, unsigned long npages)
+{
+ return 0;
+}
+
int kvm_arch_prepare_memory_region(struct kvm *kvm,
struct kvm_memory_slot *memslot,
struct kvm_memory_slot old,
diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
index e630426..7343872 100644
--- a/arch/s390/include/asm/kvm_host.h
+++ b/arch/s390/include/asm/kvm_host.h
@@ -245,6 +245,9 @@ struct kvm_vm_stat {
u32 remote_tlb_flush;
};
+struct kvm_arch_memory_slot {
+};
+
struct kvm_arch{
struct sca_block *sca;
debug_info_t *dbf;
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 0b91679..418a69c 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -807,6 +807,16 @@ int kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct
vm_fault *vmf)
return VM_FAULT_SIGBUS;
}
+void kvm_arch_free_memslot(struct kvm_memory_slot *free,
+ struct kvm_memory_slot *dont)
+{
+}
+
+int kvm_arch_create_memslot(struct kvm_memory_slot *slot, unsigned long npages)
+{
+ return 0;
+}
+
/* Section: memory related */
int kvm_arch_prepare_memory_region(struct kvm *kvm,
struct kvm_memory_slot *memslot,
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 4610166..de3aa43 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -479,6 +479,15 @@ struct kvm_vcpu_arch {
} osvw;
};
+struct kvm_lpage_info {
+ unsigned long rmap_pde;
+ int write_count;
+};
+
+struct kvm_arch_memory_slot {
+ struct kvm_lpage_info *lpage_info[KVM_NR_PAGE_SIZES - 1];
+};
+
struct kvm_arch {
unsigned int n_used_mmu_pages;
unsigned int n_requested_mmu_pages;
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 37e7f10..ff053ca 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -689,7 +689,7 @@ static struct kvm_lpage_info *lpage_info_slot(gfn_t gfn,
unsigned long idx;
idx =
Re: Merging kvm-apic into qemu-kvm
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 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
[PATCH] Fix i8259 for target-arches not supporting KVM
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':
/home/slyfox/dev/git/qemu-kvm/hw/i8259.c:688:13: error: implicit
declaration of function 'apic_set_irq_delivered'
/home/slyfox/dev/git/qemu-kvm/hw/i8259.c:688:13: error: nested extern
declaration of 'apic_set_irq_delivered'
make[1]: *** [i8259.o] Error 1
make: *** [subdir-alpha-softmmu] Error 2
LINK alpha-softmmu/qemu-system-alpha
i8259.o: In function `kvm_i8259_set_irq':
/tmp/portage/app-emulation/qemu-kvm-/work/qemu-kvm-/hw/i8259.c:689:
undefined reference to `apic_set_irq_delivered'
Signed-off-by: Sergei Trofimovich sly...@gentoo.org
---
hw/i8259.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/hw/i8259.c b/hw/i8259.c
index 0632ea2..2f6789d 100644
--- a/hw/i8259.c
+++ b/hw/i8259.c
@@ -21,6 +21,7 @@
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
+#include apic.h
#include hw.h
#include pc.h
#include isa.h
@@ -682,12 +683,14 @@ static int kvm_kernel_pic_load_from_user(PicState *s)
static void kvm_i8259_set_irq(void *opaque, int irq, int level)
{
+#ifdef CONFIG_KVM
int pic_ret;
if (kvm_set_irq(irq, level, pic_ret)) {
if (pic_ret != 0)
apic_set_irq_delivered();
return;
}
+#endif
}
device_init(pic_register)
--
1.7.8.3
--
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
Re: [RFC] KVM MMU: improve large munmap efficiency
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 exit immediately. 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: for each slot for each level for each page This way compiler can optimize the task to be a simple iteration over the rmap array. But I could not imagine why unmapping 128GB is needed. mmu_notifier will not do such crazy thing. Takuya It's still possible for the work to drop the intersection to be larger than dropping the entire shadow, but it's unlikely. -- 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
Re: [RFC] KVM MMU: improve large munmap efficiency
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 in kvm-memslots? If there is no intersection, you exit immediately. 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: for each slot for each level for each page This way compiler can optimize the task to be a simple iteration over the rmap array. Yes. This automatically includes the intersection calculation, since you have to do it for the 'for each page in slot' loop. -- error compiling committee.c: too many arguments to function -- 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
Re: [RFC] KVM MMU: improve large munmap efficiency
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: for each slot for each level for each page This way compiler can optimize the task to be a simple iteration over the rmap array. Yes. This automatically includes the intersection calculation, since you have to do it for the 'for each page in slot' loop. I personally implemented this before but stopped it because I wanted to do rmap and rmap_pde refactoring first. Takuya -- 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
Unable to start a guest using qemu-kvm directly
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 create using virt-install and able to boot fine using either virsh or virt-manager) : domain type='kvm' id='11' nametestvm2/name uuidd44e8618-e48c-531b-01c4-80fc2a026a25/uuid memory4194304/memory currentMemory4194304/currentMemory vcpu1/vcpu os type arch='x86_64' machine='rhel6.2.0'hvm/type boot dev='hd'/ /os features acpi/ apic/ pae/ /features clock offset='utc'/ on_poweroffdestroy/on_poweroff on_rebootrestart/on_reboot on_crashrestart/on_crash devices emulator/usr/libexec/qemu-kvm/emulator disk type='file' device='disk' driver name='qemu' type='qcow2' cache='none'/ source file='/var/lib/libvirt/images/vmStorage/vm2.img'/ target dev='vda' bus='virtio'/ alias name='virtio-disk0'/ address type='pci' domain='0x' bus='0x00' slot='0x04' function='0x0'/ /disk disk type='block' device='cdrom' driver name='qemu' type='raw'/ target dev='hdc' bus='ide'/ readonly/ alias name='ide0-1-0'/ address type='drive' controller='0' bus='1' unit='0'/ /disk controller type='ide' index='0' alias name='ide0'/ address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/ /controller interface type='bridge' mac address='52:54:00:7b:dc:d3'/ source bridge='vbr1'/ target dev='vnet0'/ model type='virtio'/ alias name='net0'/ address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/ /interface serial type='pty' source path='/dev/pts/4'/ target port='0'/ alias name='serial0'/ /serial console type='pty' tty='/dev/pts/4' source path='/dev/pts/4'/ target type='serial' port='0'/ alias name='serial0'/ /console input type='tablet' bus='usb' alias name='input0'/ /input input type='mouse' bus='ps2'/ graphics type='vnc' port='5900' autoport='yes'/ video model type='cirrus' vram='9216' heads='1'/ alias name='video0'/ address type='pci' domain='0x' bus='0x00' slot='0x02' function='0x0'/ /video memballoon model='virtio' alias name='balloon0'/ address type='pci' domain='0x' bus='0x00' slot='0x05' function='0x0'/ /memballoon /devices seclabel type='dynamic' model='selinux' relabel='yes' labelsystem_u:system_r:svirt_t:s0:c290,c578/label imagelabelsystem_u:object_r:svirt_image_t:s0:c290,c578/imagelabel /seclabel /domain Tried to start the above guest using qemu-kvm directly (so that I can in future specify different options etc). But I am getting some errors. (pl. see below). # /usr/libexec/qemu-kvm -version QEMU PC emulator version 0.12.1 (qemu-kvm-0.12.1.2), Copyright (c) 2003-2008 Fabrice Bellard # /usr/libexec/qemu-kvm -S -M rhel6.2.0 -enable-kvm -m 4096 -smp 1,sockets=1,cores=1,threads=1 -name testvm2 -uuid d44e8618-e48c-531b-01c4- 80fc2a026a25 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/testvm2.monitor,server,nowait - mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown - drive file=/var/lib/libvirt/images/vmStorage/vm2.img,if=none,id=drive-virtio- disk0,format=qcow2,cache=none -device virtio-blk- pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 - drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide- drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net- pci,netdev=hostnet0,id=net0,mac=52:54:00:7b:dc:d3,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb - device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus -device virtio-balloon- pci,id=balloon0,bus=pci.0,addr=0x5 char device redirected to /dev/pts/5 qemu-system-x86_64: -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24: TUNGETIFF ioctl() failed: Bad file descriptor TUNSETOFFLOAD ioctl() failed: Bad file descriptor qemu-system-x86_64: -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24: vhost-net requested but could not be initialized qemu-system-x86_64: -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24: Device 'tap' could not be initialized Can someone please tell me what this means and any tips on how I can solve this? Do I have to do some other setup to make qemu-kvm happy w.r.t the -netdev options? Thank you in anticiaption!! Vinod -- 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
kvm's vapic
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 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 assumptions but triggers the TPR access reports nevertheless? Is there a way to detect the supported target OSes reliably before patching anything? Otherwise this feature has to remain off by default in upstream, I suppose. Jan signature.asc Description: OpenPGP digital signature
Re: kvm's vapic
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. One thing I'm wondering now: This is practically targeting only 32-bit Windows, right? Correct. 64-bit Windows uses cr8, which can be selectively intercepted according to the priority of a pending interrupt, if any, so it doesn't cause any excessive exits. 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 assumptions but triggers the TPR access reports nevertheless? Not much, but we've never had an issue. Is there a way to detect the supported target OSes reliably before patching anything? Otherwise this feature has to remain off by default in upstream, I suppose. We could match fields with known values in the PCR, see http://www.reverse-engineering.info/SystemInformation/GetVarXP.pdf. Off-by-default dooms XP users to unusable performance on AMD hardware. -- error compiling committee.c: too many arguments to function -- 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
Re: kvm's vapic
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 assumptions but triggers the TPR access reports nevertheless? Not much, but we've never had an issue. Checking that the bios is mapped at 0x[8e]000 + phys should filter out most non-Windows OSes. -- error compiling committee.c: too many arguments to function -- 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
Re: kvm's vapic
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 that doesn't comply with our assumptions but triggers the TPR access reports nevertheless? Not much, but we've never had an issue. Checking that the bios is mapped at 0x[8e]000 + phys should filter out most non-Windows OSes. Possibly. What about that major/minor version entries in the KPCR? Do they work, and do we have a list of what should be there? Jan signature.asc Description: OpenPGP digital signature
Re: Merging kvm-apic into qemu-kvm
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 unrelated, and are descendents of the apic merge, so I merged just that. I'll look at the migration problems now. Thanks again! -- error compiling committee.c: too many arguments to function -- 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
Re: Unable to start a guest using qemu-kvm directly
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. Here is a sample guest (that I was able to create using virt-install and able to boot fine using either virsh or virt-manager) : [] Tried to start the above guest using qemu-kvm directly (so that I can in future specify different options etc). But I am getting some errors. (pl. see below). # /usr/libexec/qemu-kvm -version QEMU PC emulator version 0.12.1 (qemu-kvm-0.12.1.2), Copyright (c) 2003-2008 Fabrice Bellard # /usr/libexec/qemu-kvm -S -M rhel6.2.0 -enable-kvm -m 4096 -smp 1,sockets=1,cores=1,threads=1 -name testvm2 -uuid d44e8618-e48c-531b-01c4- 80fc2a026a25 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/testvm2.monitor,server,nowait - mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown - drive file=/var/lib/libvirt/images/vmStorage/vm2.img,if=none,id=drive-virtio- disk0,format=qcow2,cache=none -device virtio-blk- pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 - drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide- drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net- ^ ^^ pci,netdev=hostnet0,id=net0,mac=52:54:00:7b:dc:d3,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb - device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus -device virtio-balloon- pci,id=balloon0,bus=pci.0,addr=0x5 char device redirected to /dev/pts/5 qemu-system-x86_64: -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24: TUNGETIFF ioctl() failed: Bad file descriptor libvirt pre-configures network tap devices and pre-opens /dev/vhost-net file and passes these to qemu[-kvm] as open, ready to use file descriptors. Like you can do to redirect stdin: cat file there, cat opens file and reads it, or cat file where cat reads stdin. In particular, libvirtd has more privileges to open tap and vhost-net devices since it does that as root but spawns qemu[-kvm] as unprivileged user. [] Can someone please tell me what this means and any tips on how I can solve this? Do I have to do some other setup to make qemu-kvm happy w.r.t the -netdev options? You need to understand how to (pre-)configure networking for qemu (pre- if you want to run it as non-root), this is described in the users guide and in a lot of howtos all around the 'net. /mjt -- 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
Re: kvm's vapic
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 that we aren't patching some other obscure OS that doesn't comply with our assumptions but triggers the TPR access reports nevertheless? Not much, but we've never had an issue. Checking that the bios is mapped at 0x[8e]000 + phys should filter out most non-Windows OSes. Possibly. What about that major/minor version entries in the KPCR? Do they work, and do we have a list of what should be there? We don't. But things like the IDT/GTD/TSS and especially SelfPcr look like good candidates. -- error compiling committee.c: too many arguments to function -- 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
Re: kvm's vapic
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 0xExxx. But what makes sure that we aren't patching some other obscure OS that doesn't comply with our assumptions but triggers the TPR access reports nevertheless? Not much, but we've never had an issue. Checking that the bios is mapped at 0x[8e]000 + phys should filter out most non-Windows OSes. Possibly. What about that major/minor version entries in the KPCR? Do they work, and do we have a list of what should be there? We don't. But things like the IDT/GTD/TSS and especially SelfPcr look like good candidates. So fs.base should be SelfPcr? Will check. Jan signature.asc Description: OpenPGP digital signature
Help with strange problem passing mlx4 device into kvm guests
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. The host system is a fairly standard dual-socket Xeon 5600 system, perhaps a tiny bit unusual in that it is a dual Tylersburg motherboard. I'm using QEMU emulator version 1.0 (qemu-kvm-1.0 Debian 1.0+dfsg-3), Copyright (c) 2003-2008 Fabrice Bellard and Linux pure-driver3 3.1.0-1-amd64 #1 SMP Tue Jan 10 05:01:58 UTC 2012 x86_64 GNU/Linux (the latest Debian testing versions). The symptom of the problem is that when the mlx4_core driver starts, I get normal output like mlx4_core :00:04.0: FW version 2.9.1000 (cmd intf rev 3), max commands 16 mlx4_core :00:04.0: Catastrophic error buffer at 0x1f020, size 0x10, BAR 0 mlx4_core :00:04.0: FW size 385 KB up until the driver tries to enable interrupts, when I get a long stream of Completion event for bogus CQ and then it gives up because the NOP command interrupt test fails. Apparently what happens is that the SW2HW_EQ firmware command succeeds as far as the driver is concerned, but the EQ buffer is left as all 0s, so the driver thinks every entry is a completion event (for CQN 0). Several things are weird here: first, the command interface including DMA from the device is definitely working since we get a reasonable-looking response for the query FW command etc, so I'm not sure what is different about the SW2HW_EQ command (it is the first thing that uses the MTT I guess, so maybe there is a problem setting that up?) The guest is running 2.6.39, so there is no SR-IOV support in the mlx4 driver (but I am passing the only physical function of a non-virtualized device through, so I hope that isn't needed -- the device shouldn't know it's talking to a guest at all) Second, passing through another device on the same system: 86:00.0 Ethernet controller [0200]: Intel Corporation 82599EB 10 Gigabit TN Network Connection [8086:151c] (rev 01) works fine, including MSI-X interrupts, running traffic works, etc. Finally, the craziest thing is that this setup was working a week or so ago, but there may have been BIOS, kernel and kvm updates since then (my guest image is unchanged at least ;). Anyone have any idea what might be going on or how to debug this further? Unfortunately I don't have a PCIe analyzer handy to get a better idea of what's happening with the device... Thanks, Roland -- 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
Re: [PATCH V2] kvm tools: Add build target for statically-linked binary
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 filesystems.) This is useful. However, It fails to build for me. Some problem with sdl, bfd and vnc library. Log attached. OK, so I've been building statically without the (autodetected) SDL/BFD/VNC libraries, and this works fine on PPC64 and x86. I'm not quite sure why the libSDL.a/libbfd.a etc. don't statically link. Sasha's idea of disable things that don't link correctly is a good one, though I'm not a Make guru and can't see how to retrospectively unset 'has_SDL', 'has_vncserver' etc. IFF the makefile target is lkvm-static :( (I guess one way is to try to find every .o that depends on CONFIG_SDL, for example, and add another target compiled without -DCONFIG_SDL :( Ew, and I don't know how to do this.) This would be easier if we had a proper config system.. 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? Cheers, Matt Signed-off-by: Matt Evans m...@ozlabs.org --- V2: Argh! Let's remove it on make clean, too... tools/kvm/Makefile |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/tools/kvm/Makefile b/tools/kvm/Makefile index d54fa47..ebc0c7c 100644 --- a/tools/kvm/Makefile +++ b/tools/kvm/Makefile @@ -233,6 +233,10 @@ $(PROGRAM): $(DEPS) $(OBJS) $(E) LINK $@ $(Q) $(CC) $(CFLAGS) $(OBJS) $(LIBS) -o $@ +$(PROGRAM)-static: $(DEPS) $(OBJS) +$(E) LINK $@ +$(Q) $(CC) -static $(CFLAGS) $(OBJS) $(LIBS) -o $@ + $(PROGRAM_ALIAS): $(PROGRAM) $(E) LN $@ $(Q) ln -f $(PROGRAM) $@ @@ -325,7 +329,7 @@ clean: $(Q) rm -f x86/bios/bios-rom.h $(Q) rm -f tests/boot/boot_test.iso $(Q) rm -rf tests/boot/rootfs/ -$(Q) rm -f $(DEPS) $(OBJS) $(PROGRAM) $(PROGRAM_ALIAS) $(GUEST_INIT) $(GUEST_INIT_S2) +$(Q) rm -f $(DEPS) $(OBJS) $(PROGRAM) $(PROGRAM_ALIAS) $(PROGRAM)-static $(GUEST_INIT) $(GUEST_INIT_S2) $(Q) rm -f cscope.* $(Q) rm -f $(KVM_INCLUDE)/common-cmds.h $(Q) rm -f KVMTOOLS-VERSION-FILE -- 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
[PATCH 0/4] KVM: Introduce kvm_memory_slot::arch
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 rebased. Takuya arch/ia64/include/asm/kvm_host.h|3 + arch/ia64/kvm/kvm-ia64.c| 10 + arch/powerpc/include/asm/kvm_host.h |3 + arch/powerpc/kvm/powerpc.c | 10 + arch/s390/include/asm/kvm_host.h|3 + arch/s390/kvm/kvm-s390.c| 10 + arch/x86/include/asm/kvm_host.h |9 arch/x86/kvm/mmu.c |5 +- arch/x86/kvm/x86.c | 59 +++ include/linux/kvm_host.h| 18 +--- virt/kvm/kvm_main.c | 76 ++ 11 files changed, 135 insertions(+), 71 deletions(-) -- 1.7.5.4 -- 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
[PATCH 1/4] KVM: Introduce gfn_to_index() which returns the index for a given level
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 +--
include/linux/kvm_host.h |7 +++
virt/kvm/kvm_main.c |7 +--
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index ae76cc3..37e7f10 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -688,8 +688,7 @@ static struct kvm_lpage_info *lpage_info_slot(gfn_t gfn,
{
unsigned long idx;
- idx = (gfn KVM_HPAGE_GFN_SHIFT(level)) -
- (slot-base_gfn KVM_HPAGE_GFN_SHIFT(level));
+ idx = gfn_to_index(gfn, slot-base_gfn, level);
return slot-lpage_info[level - 2][idx];
}
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index eada8e6..06d4e41 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -656,6 +656,13 @@ static inline int memslot_id(struct kvm *kvm, gfn_t gfn)
return gfn_to_memslot(kvm, gfn)-id;
}
+static inline gfn_t gfn_to_index(gfn_t gfn, gfn_t base_gfn, int level)
+{
+ /* KVM_HPAGE_GFN_SHIFT(PT_PAGE_TABLE_LEVEL) must be 0. */
+ return (gfn KVM_HPAGE_GFN_SHIFT(level)) -
+ (base_gfn KVM_HPAGE_GFN_SHIFT(level));
+}
+
static inline unsigned long gfn_to_hva_memslot(struct kvm_memory_slot *slot,
gfn_t gfn)
{
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 9f32bff..e483ae4 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -797,15 +797,10 @@ int __kvm_set_memory_region(struct kvm *kvm,
int lpages;
int level = i + 2;
- /* Avoid unused variable warning if no large pages */
- (void)level;
-
if (new.lpage_info[i])
continue;
- lpages = 1 + ((base_gfn + npages - 1)
- KVM_HPAGE_GFN_SHIFT(level));
- lpages -= base_gfn KVM_HPAGE_GFN_SHIFT(level);
+ lpages = gfn_to_index(base_gfn + npages - 1, base_gfn, level) +
1;
new.lpage_info[i] = vzalloc(lpages *
sizeof(*new.lpage_info[i]));
--
1.7.5.4
--
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
[PATCH 2/4] KVM: Split lpage_info creation out from __kvm_set_memory_region()
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 b/virt/kvm/kvm_main.c
index e483ae4..2ef9f2d 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -698,6 +698,56 @@ void update_memslots(struct kvm_memslots *slots, struct
kvm_memory_slot *new)
slots-generation++;
}
+#ifndef CONFIG_S390
+static int create_lpage_info(struct kvm_memory_slot *slot, unsigned long
npages)
+{
+ int i;
+
+ for (i = 0; i KVM_NR_PAGE_SIZES - 1; ++i) {
+ unsigned long ugfn;
+ int lpages;
+ int level = i + 2;
+
+ if (slot-lpage_info[i])
+ continue;
+
+ lpages = gfn_to_index(slot-base_gfn + npages - 1,
+ slot-base_gfn, level) + 1;
+
+ slot-lpage_info[i] = vzalloc(lpages *
sizeof(*slot-lpage_info[i]));
+ if (!slot-lpage_info[i])
+ goto out_free;
+
+ if (slot-base_gfn (KVM_PAGES_PER_HPAGE(level) - 1))
+ slot-lpage_info[i][0].write_count = 1;
+ if ((slot-base_gfn + npages) (KVM_PAGES_PER_HPAGE(level) -
1))
+ slot-lpage_info[i][lpages - 1].write_count = 1;
+ ugfn = slot-userspace_addr PAGE_SHIFT;
+ /*
+* If the gfn and userspace address are not aligned wrt each
+* other, or if explicitly asked to, disable large page
+* support for this slot
+*/
+ if ((slot-base_gfn ^ ugfn) (KVM_PAGES_PER_HPAGE(level) - 1)
||
+ !largepages_enabled) {
+ unsigned long j;
+
+ for (j = 0; j lpages; ++j)
+ slot-lpage_info[i][j].write_count = 1;
+ }
+ }
+
+ return 0;
+
+out_free:
+ for (i = 0; i KVM_NR_PAGE_SIZES - 1; ++i) {
+ vfree(slot-lpage_info[i]);
+ slot-lpage_info[i] = NULL;
+ }
+ return -ENOMEM;
+}
+#endif /* not defined CONFIG_S390 */
+
/*
* Allocate some memory and give it an address in the guest physical address
* space.
@@ -791,37 +841,8 @@ int __kvm_set_memory_region(struct kvm *kvm,
if (!npages)
goto skip_lpage;
- for (i = 0; i KVM_NR_PAGE_SIZES - 1; ++i) {
- unsigned long ugfn;
- unsigned long j;
- int lpages;
- int level = i + 2;
-
- if (new.lpage_info[i])
- continue;
-
- lpages = gfn_to_index(base_gfn + npages - 1, base_gfn, level) +
1;
-
- new.lpage_info[i] = vzalloc(lpages *
sizeof(*new.lpage_info[i]));
-
- if (!new.lpage_info[i])
- goto out_free;
-
- if (base_gfn (KVM_PAGES_PER_HPAGE(level) - 1))
- new.lpage_info[i][0].write_count = 1;
- if ((base_gfn+npages) (KVM_PAGES_PER_HPAGE(level) - 1))
- new.lpage_info[i][lpages - 1].write_count = 1;
- ugfn = new.userspace_addr PAGE_SHIFT;
- /*
-* If the gfn and userspace address are not aligned wrt each
-* other, or if explicitly asked to, disable large page
-* support for this slot
-*/
- if ((base_gfn ^ ugfn) (KVM_PAGES_PER_HPAGE(level) - 1) ||
- !largepages_enabled)
- for (j = 0; j lpages; ++j)
- new.lpage_info[i][j].write_count = 1;
- }
+ if (create_lpage_info(new, npages))
+ goto out_free;
skip_lpage:
--
1.7.5.4
--
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
[PATCH 3/4 v2] KVM: Simplify ifndef conditional usage in __kvm_set_memory_region()
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 lpage_info
because we do it from inside the slot creation code block.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
virt/kvm/kvm_main.c | 29 -
1 files changed, 8 insertions(+), 21 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 2ef9f2d..b6bc866 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -616,7 +616,6 @@ static int kvm_vm_release(struct inode *inode, struct file
*filp)
return 0;
}
-#ifndef CONFIG_S390
/*
* Allocation size is twice as large as the actual dirty bitmap size.
* This makes it possible to do double buffering: see x86's
@@ -624,6 +623,7 @@ static int kvm_vm_release(struct inode *inode, struct file
*filp)
*/
static int kvm_create_dirty_bitmap(struct kvm_memory_slot *memslot)
{
+#ifndef CONFIG_S390
unsigned long dirty_bytes = 2 * kvm_dirty_bitmap_bytes(memslot);
if (dirty_bytes PAGE_SIZE)
@@ -636,9 +636,9 @@ static int kvm_create_dirty_bitmap(struct kvm_memory_slot
*memslot)
memslot-dirty_bitmap_head = memslot-dirty_bitmap;
memslot-nr_dirty_pages = 0;
+#endif /* !CONFIG_S390 */
return 0;
}
-#endif /* !CONFIG_S390 */
static struct kvm_memory_slot *
search_memslots(struct kvm_memslots *slots, gfn_t gfn)
@@ -708,9 +708,6 @@ static int create_lpage_info(struct kvm_memory_slot *slot,
unsigned long npages)
int lpages;
int level = i + 2;
- if (slot-lpage_info[i])
- continue;
-
lpages = gfn_to_index(slot-base_gfn + npages - 1,
slot-base_gfn, level) + 1;
@@ -828,23 +825,18 @@ int __kvm_set_memory_region(struct kvm *kvm,
r = -ENOMEM;
/* Allocate if a slot is being created */
+ if (npages !old.npages) {
+ new.user_alloc = user_alloc;
+ new.userspace_addr = mem-userspace_addr;
#ifndef CONFIG_S390
- if (npages !new.rmap) {
new.rmap = vzalloc(npages * sizeof(*new.rmap));
-
if (!new.rmap)
goto out_free;
- new.user_alloc = user_alloc;
- new.userspace_addr = mem-userspace_addr;
+ if (create_lpage_info(new, npages))
+ goto out_free;
+#endif /* not defined CONFIG_S390 */
}
- if (!npages)
- goto skip_lpage;
-
- if (create_lpage_info(new, npages))
- goto out_free;
-
-skip_lpage:
/* Allocate page dirty bitmap if needed */
if ((new.flags KVM_MEM_LOG_DIRTY_PAGES) !new.dirty_bitmap) {
@@ -852,11 +844,6 @@ skip_lpage:
goto out_free;
/* destroy any largepage mappings for dirty tracking */
}
-#else /* not defined CONFIG_S390 */
- new.user_alloc = user_alloc;
- if (user_alloc)
- new.userspace_addr = mem-userspace_addr;
-#endif /* not defined CONFIG_S390 */
if (!npages) {
struct kvm_memory_slot *slot;
--
1.7.5.4
--
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
[PATCH 4/4 v2] KVM: Introduce kvm_memory_slot::arch and move lpage_info into it
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|3 ++
arch/ia64/kvm/kvm-ia64.c| 10 +
arch/powerpc/include/asm/kvm_host.h |3 ++
arch/powerpc/kvm/powerpc.c | 10 +
arch/s390/include/asm/kvm_host.h|3 ++
arch/s390/kvm/kvm-s390.c| 10 +
arch/x86/include/asm/kvm_host.h |9 +
arch/x86/kvm/mmu.c |2 +-
arch/x86/kvm/x86.c | 59 ++
include/linux/kvm_host.h| 11 +++---
virt/kvm/kvm_main.c | 67 --
11 files changed, 121 insertions(+), 66 deletions(-)
diff --git a/arch/ia64/include/asm/kvm_host.h b/arch/ia64/include/asm/kvm_host.h
index 2689ee5..e35b3a8 100644
--- a/arch/ia64/include/asm/kvm_host.h
+++ b/arch/ia64/include/asm/kvm_host.h
@@ -459,6 +459,9 @@ struct kvm_sal_data {
unsigned long boot_gp;
};
+struct kvm_arch_memory_slot {
+};
+
struct kvm_arch {
spinlock_t dirty_log_lock;
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index 8ca7261..d8ddbba 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -1571,6 +1571,16 @@ int kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct
vm_fault *vmf)
return VM_FAULT_SIGBUS;
}
+void kvm_arch_free_memslot(struct kvm_memory_slot *free,
+ struct kvm_memory_slot *dont)
+{
+}
+
+int kvm_arch_create_memslot(struct kvm_memory_slot *slot, unsigned long npages)
+{
+ return 0;
+}
+
int kvm_arch_prepare_memory_region(struct kvm *kvm,
struct kvm_memory_slot *memslot,
struct kvm_memory_slot old,
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index af438b1..b9188aa 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -212,6 +212,9 @@ struct revmap_entry {
#define KVMPPC_PAGE_WRITETHRU HPTE_R_W/* 0x40 */
#define KVMPPC_GOT_PAGE0x80
+struct kvm_arch_memory_slot {
+};
+
struct kvm_arch {
#ifdef CONFIG_KVM_BOOK3S_64_HV
unsigned long hpt_virt;
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 0e21d15..00d7e34 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -281,6 +281,16 @@ long kvm_arch_dev_ioctl(struct file *filp,
return -EINVAL;
}
+void kvm_arch_free_memslot(struct kvm_memory_slot *free,
+ struct kvm_memory_slot *dont)
+{
+}
+
+int kvm_arch_create_memslot(struct kvm_memory_slot *slot, unsigned long npages)
+{
+ return 0;
+}
+
int kvm_arch_prepare_memory_region(struct kvm *kvm,
struct kvm_memory_slot *memslot,
struct kvm_memory_slot old,
diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
index e630426..7343872 100644
--- a/arch/s390/include/asm/kvm_host.h
+++ b/arch/s390/include/asm/kvm_host.h
@@ -245,6 +245,9 @@ struct kvm_vm_stat {
u32 remote_tlb_flush;
};
+struct kvm_arch_memory_slot {
+};
+
struct kvm_arch{
struct sca_block *sca;
debug_info_t *dbf;
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 0b91679..418a69c 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -807,6 +807,16 @@ int kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct
vm_fault *vmf)
return VM_FAULT_SIGBUS;
}
+void kvm_arch_free_memslot(struct kvm_memory_slot *free,
+ struct kvm_memory_slot *dont)
+{
+}
+
+int kvm_arch_create_memslot(struct kvm_memory_slot *slot, unsigned long npages)
+{
+ return 0;
+}
+
/* Section: memory related */
int kvm_arch_prepare_memory_region(struct kvm *kvm,
struct kvm_memory_slot *memslot,
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 4610166..de3aa43 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -479,6 +479,15 @@ struct kvm_vcpu_arch {
} osvw;
};
+struct kvm_lpage_info {
+ unsigned long rmap_pde;
+ int write_count;
+};
+
+struct kvm_arch_memory_slot {
+ struct kvm_lpage_info *lpage_info[KVM_NR_PAGE_SIZES - 1];
+};
+
struct kvm_arch {
unsigned int n_used_mmu_pages;
unsigned int n_requested_mmu_pages;
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 37e7f10..ff053ca 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -689,7 +689,7 @@ static struct kvm_lpage_info *lpage_info_slot(gfn_t gfn,
unsigned long idx;
idx = gfn_to_index(gfn, slot-base_gfn, level);
- return
Re: [PATCH V2] kvm tools: Add build target for statically-linked binary
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 without optional libraries (or just libs that don't link statically)? -- Sasha. -- 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
Re: [PATCH V2] kvm tools: Add build target for statically-linked 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 which will generate a static binary without optional libraries (or just libs that don't link statically)? Sure, but that was my question: how? That 'make static' target can drop -lbfd, -lSDL etc. from the link line but all of the '.o's that we've already built either may depend on one of those libs or may do something different because CONFIG_HAS_SDL (or similar) was set. The only way I can think of doing this is to have 'make static' depend on a second set of $(all_objects_except_without_optional_libs) which are built without CONFIG_HAS_SDL etc., but that'd make Makefile fugly IMHO. Unless, that is, CFLAGS (and thus CONFIG_HAS_SDL, has_SDL probing, etc.) can somehow change depending on the make target. Matt -- 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
Re: [PATCH 4/4 v2] KVM: Introduce kvm_memory_slot::arch and move lpage_info into it
(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)) goto out_free; #endif /* not defined CONFIG_S390 */ I have to move this #endif upwards to not include kvm_arch_create_memslot(). Will update patch 4 and resend from now. Takuya -- 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
[PATCH 4/4 v3] KVM: Introduce kvm_memory_slot::arch and move lpage_info into it
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|3 +
arch/ia64/kvm/kvm-ia64.c| 10 +
arch/powerpc/include/asm/kvm_host.h |3 +
arch/powerpc/kvm/powerpc.c | 10 +
arch/s390/include/asm/kvm_host.h|3 +
arch/s390/kvm/kvm-s390.c| 10 +
arch/x86/include/asm/kvm_host.h |9
arch/x86/kvm/mmu.c |2 +-
arch/x86/kvm/x86.c | 59 +
include/linux/kvm_host.h| 11 ++---
virt/kvm/kvm_main.c | 70 --
11 files changed, 122 insertions(+), 68 deletions(-)
diff --git a/arch/ia64/include/asm/kvm_host.h b/arch/ia64/include/asm/kvm_host.h
index 2689ee5..e35b3a8 100644
--- a/arch/ia64/include/asm/kvm_host.h
+++ b/arch/ia64/include/asm/kvm_host.h
@@ -459,6 +459,9 @@ struct kvm_sal_data {
unsigned long boot_gp;
};
+struct kvm_arch_memory_slot {
+};
+
struct kvm_arch {
spinlock_t dirty_log_lock;
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index 8ca7261..d8ddbba 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -1571,6 +1571,16 @@ int kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct
vm_fault *vmf)
return VM_FAULT_SIGBUS;
}
+void kvm_arch_free_memslot(struct kvm_memory_slot *free,
+ struct kvm_memory_slot *dont)
+{
+}
+
+int kvm_arch_create_memslot(struct kvm_memory_slot *slot, unsigned long npages)
+{
+ return 0;
+}
+
int kvm_arch_prepare_memory_region(struct kvm *kvm,
struct kvm_memory_slot *memslot,
struct kvm_memory_slot old,
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index af438b1..b9188aa 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -212,6 +212,9 @@ struct revmap_entry {
#define KVMPPC_PAGE_WRITETHRU HPTE_R_W/* 0x40 */
#define KVMPPC_GOT_PAGE0x80
+struct kvm_arch_memory_slot {
+};
+
struct kvm_arch {
#ifdef CONFIG_KVM_BOOK3S_64_HV
unsigned long hpt_virt;
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 0e21d15..00d7e34 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -281,6 +281,16 @@ long kvm_arch_dev_ioctl(struct file *filp,
return -EINVAL;
}
+void kvm_arch_free_memslot(struct kvm_memory_slot *free,
+ struct kvm_memory_slot *dont)
+{
+}
+
+int kvm_arch_create_memslot(struct kvm_memory_slot *slot, unsigned long npages)
+{
+ return 0;
+}
+
int kvm_arch_prepare_memory_region(struct kvm *kvm,
struct kvm_memory_slot *memslot,
struct kvm_memory_slot old,
diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
index e630426..7343872 100644
--- a/arch/s390/include/asm/kvm_host.h
+++ b/arch/s390/include/asm/kvm_host.h
@@ -245,6 +245,9 @@ struct kvm_vm_stat {
u32 remote_tlb_flush;
};
+struct kvm_arch_memory_slot {
+};
+
struct kvm_arch{
struct sca_block *sca;
debug_info_t *dbf;
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 0b91679..418a69c 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -807,6 +807,16 @@ int kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct
vm_fault *vmf)
return VM_FAULT_SIGBUS;
}
+void kvm_arch_free_memslot(struct kvm_memory_slot *free,
+ struct kvm_memory_slot *dont)
+{
+}
+
+int kvm_arch_create_memslot(struct kvm_memory_slot *slot, unsigned long npages)
+{
+ return 0;
+}
+
/* Section: memory related */
int kvm_arch_prepare_memory_region(struct kvm *kvm,
struct kvm_memory_slot *memslot,
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 4610166..de3aa43 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -479,6 +479,15 @@ struct kvm_vcpu_arch {
} osvw;
};
+struct kvm_lpage_info {
+ unsigned long rmap_pde;
+ int write_count;
+};
+
+struct kvm_arch_memory_slot {
+ struct kvm_lpage_info *lpage_info[KVM_NR_PAGE_SIZES - 1];
+};
+
struct kvm_arch {
unsigned int n_used_mmu_pages;
unsigned int n_requested_mmu_pages;
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 37e7f10..ff053ca 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -689,7 +689,7 @@ static struct kvm_lpage_info *lpage_info_slot(gfn_t gfn,
unsigned long idx;
idx = gfn_to_index(gfn, slot-base_gfn, level);
- return slot-lpage_info[level -
