[kvm-devel] KVM Test result, kernel f1ca151.., userspace 0088a24..
Hi,All This is today's KVM test result against kvm.git f1ca151a368192b182a9f9e696e211e18927f040 and kvm-userspace.git 0088a24f6b38f534ae620e4c484d10aba4f5da96. No new issue has been found. Issue List: 1. smp windows installer crashes while rebooting https://sourceforge.net/tracker/index.php?func=detail&aid=1877875&group_ id=180599&atid=893831 2. Timer of guest is inaccurate https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1826080&gro up_id=180599 3. Installer of 64bit vista guest will pause for ten minutes after reboot https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1836905&gro up_id=180599 4. Fails to save/restore 64bit guests https://sourceforge.net/tracker/index.php?func=detail&aid=1824525&group_ id=180599&atid=893831 5. Cannot boot 32bit smp RHEL5.1 guest with nic on 64bit host https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1812043&gro up_id=180599 Test environment PlatformWoodcrest CPU 4 Memory size 8G' Details IA32-pae: 1. boot guest with 256M memory PASS 2. boot two windows xp guestPASS 3. boot 4 same guest in parallel PASS 4. boot linux and windows guest in parallel PASS 5. boot guest with 1500M memory PASS 6. boot windows 2003 with ACPI enabled PASS 7. boot Windows xp with ACPI enabled PASS 8. boot Windows 2000 without ACPI PASS 9. kernel build on SMP linux guestPASS 10. LTP on SMP linux guest PASS 11. boot base kernel linux PASS 12. save/restore 32-bit HVM guests FAIL 13. live migration 32-bit HVM guests PASS 14. boot SMP Windows xp with ACPI enabledPASS 15. boot SMP Windows 2003 with ACPI enabled PASS 16. boot SMP Windows 2000 with ACPI enabled PASS IA32e: 1. boot four 32-bit guest in parallel PASS 2. boot four 64-bit guest in parallel PASS 3. boot 4G 64-bit guest PASS 4. boot 4G pae guest PASS 5. boot 32-bit linux and 32 bit windows guest in parallelPASS 6. boot 32-bit guest with 1500M memory PASS 7. boot 64-bit guest with 1500M memory PASS 8. boot 32-bit guest with 256M memory PASS 9. boot 64-bit guest with 256M memory PASS 10. boot two 32-bit windows xp in parallel PASS 11. boot four 32-bit different guest in para PASS 12. save/restore 64-bit linux guests FAIL 13. save/restore 32-bit linux guests FAIL 14. boot 32-bit SMP windows 2003 with ACPI enabled PASS 15. boot 32-bit SMP Windows 2000 with ACPI enabledPASS 16. boot 32-bit SMP Windows xp with ACPI enabledPASS 17. boot 32-bit Windows 2000 without ACPIPASS 18. boot 64-bit Windows xp with ACPI enabledPASS 19. boot 32-bit Windows xp without ACPIPASS 20. boot 64-bit vista PASS 21. kernel build in 32-bit linux guest OS PASS 22. kernel build in 64-bit linux guest OS PASS 23. LTP on SMP 32-bit linux guest OSPASS 24. LTP on SMP 64-bit linux guest OSPASS 25. boot 64-bit guests with ACPI enabled PASS 26. boot 32-bit x-server PASS 27. boot 64-bit SMP windows XP with ACPI enabled PASS 28. boot 64-bit SMP windows 2003 with ACPI enabled PASS 29. live migration 64bit linux guests PASS 30. live migration 32bit linux guests PASS Report Summary on IA32-pae Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel 5 5 0 00 Restart 2 2 0 00 gtest 14 14 0 00 = control_panel 5 5 0 00 :KVM_four_sguest_PAE_gPA 1 1 0 00 :KVM_256M_guest_PAE_gPAE 1 1 0 00 :KVM_linux_win_PAE_gPAE1 1 0 00 :KVM_1500M_guest_PAE_gPA 1 1 0 00 :KVM_two_winxp_PAE_gPAE1 1 0 00 Restart 2 2 0 00 :GuestPAE_PAE_g64 1 1 0 00 :BootTo32pae_PAE_g64 1 1 0 00 gtest
Re: [kvm-devel] [patch 1/3] mmu_notifier: Core code
On Thu, Jan 31, 2008 at 07:58:40PM -0800, Christoph Lameter wrote: > Ok. Andrea wanted the same because then he can void the begin callouts. Exactly. I hope the page-pin will avoid me having to serialize the KVM page fault against the start/end critical section. BTW, I wonder if the start/end critical section API is intended to forbid scheduling inside it. In short I wonder if GRU can is allowed to take a spinlock in _range_start as last thing before returning, and to release that same spinlock in _range_end as first thing, and not to be forced to use a mutex. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 0/4] [RFC] EMMU Notifiers V5
On Thu, Jan 31, 2008 at 09:04:39PM -0800, Christoph Lameter wrote: > - Has page tables to track pages whose refcount was elevated(?) but > no reverse maps. Just a correction, rmaps exists or swap couldn't be sane, it's just that it's not built on the page_t because the guest memory is really virtual and not physical at all (hence it swaps really well, thanks to the regular linux VM algorithms without requiring any KVM knowledge at all, it all looks (shared) anonymous memory as far as linux is concerned ;). - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] mmu notifiers #v5
On Fri, Feb 01, 2008 at 11:23:57AM -0800, Christoph Lameter wrote: > Yes so your invalidate_range is still some sort of dysfunctional > optimization? Gazillions of invalidate_page's will have to be executed > when tearing down large memory areas. I don't know if gru can flush the external TLB references with a single instruction like the cpu can do by overwriting %cr3. As far as vmx/svm are concerned, you got to do some fixed amount of work on the rmap structures and each spte, for each 4k invalidated regardless of page/pages/range/ranges. You can only share the cost of the lock and of the memslot lookup, so you lookup and take the lock once and you drop 512 sptes instead of just 1. Similar to what we do in the main linux VM by taking the PT lock for every 512 sptes. So you worry about gazillions of invalidate_page without taking into account that even if you call invalidate_range_end(0, -1ULL) KVM will have to mangle over 4503599627370496 rmap entries anyway. Yes calling 1 invalidate_range_end instead of 4503599627370496 invalidate_page, will be faster, but not much faster. For KVM it remains an O(N) operation, where N is the number of pages. I'm not so sure we need to worry about my invalidate_pages being limited to 512 entries. Perhaps GRU is different, I'm just describing the KVM situation here. As far as KVM is concerned it's more sensible to be able to scale when there are 1024 kvm threads on 1024 cpus and each kvm-vcpu is accessing a different guest physical page (especially when new chunks of memory are allocated for the first time) that won't collide the whole time on naturally aligned 2M chunks of virtual addresses. > And that would not be enough to hold of new references? With small tweaks > this should work with a common scheme. We could also redefine the role > of _start and _end slightly to just require that the refs are removed when > _end completes. That would allow the KVM page count ref to work as is now > and would avoid the individual invalidate_page() callouts. I can already only use _end and ignore _start, only remaining problem is this won't be 100% coherent (my patch is 100% coherent thanks to PT lock implicitly serializing follow_page/get_user_pages of the KVM/GRU secondary MMU faults). My approach give a better peace of mind with full scalability and no lock recursion when it's the KVM page fault that invokes get_user_pages that invokes the linux page fault routines that will try to execute _start taking the lock to block the page fault that is already running... > > > The GRU has no page table on its own. It populates TLB entries on demand > > > using the linux page table. There is no way it can figure out when to > > > drop page counts again. The invalidate calls are turned directly into tlb > > > flushes. > > > > Yes, this is why it can't serialize follow_page with only the PT lock > > with your patch. KVM may do it once you add start,end to range_end > > only thanks to the additional pin on the page. > > Right but that pin requires taking a refcount which we cannot do. GRU can use my patch without the pin. XPMEM obviously can't use my patch as my invalidate_page[s] are under the PT lock (a feature to fit GRU/KVM in the simplest way), this is why an incremental patch adding invalidate_range_start/end would be required to support XPMEM too. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 2/4] mmu_notifier: Callbacks to invalidate address ranges
On Fri, Feb 01, 2008 at 05:35:28PM -0600, Robin Holt wrote: > No, we need a callout when we are becoming more restrictive, but not > when becoming more permissive. I would have to guess that is the case > for any of these callouts. It is for both GRU and XPMEM. I would > expect the same is true for KVM, but would like a ruling from Andrea on > that. I still hope I don't need to take any lock in _range_start and that losing coherency (w/o risking global memory corruption but only risking temporary userland data corruption thanks to the page pin) is ok for KVM. If I would have to take a lock in _range_start like XPMEM is forced to do (GRU is by far not forced to it, if it would switch to my #v5) then it would be a problem. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] mmu notifiers #v5
On Sun, Feb 03, 2008 at 03:17:04AM +0100, Andrea Arcangeli wrote: > On Fri, Feb 01, 2008 at 11:23:57AM -0800, Christoph Lameter wrote: > > Yes so your invalidate_range is still some sort of dysfunctional > > optimization? Gazillions of invalidate_page's will have to be executed > > when tearing down large memory areas. > > I don't know if gru can flush the external TLB references with a > single instruction like the cpu can do by overwriting %cr3. As far as The mechanism obviously is a little different, but the GRU can flush an external TLB in a single read/write/flush of a cacheline (should take a few 100 nsec). Typically, an application uses a single GRU. Threaded applications, however, could use one GRU per thread, so it is possible that multiple TLBs must be flushed. In some cases, the external flush can be avoided if the GRU is not currently in use by the thread. Also, most (but not all) applications that use the GRU do not usually do anything that requires frequent flushing (fortunately). The GRU is intended for HPC-like applications. These don't usually do frequent map/unmap operations or anything else that requires a lot of flushes. I expect that KVM is a lot different. I have most of the GRU code working with the latest mmuops patch. I still have a list of loose ends that I'll get to next week. The most important is the exact handling of the range invalidates. The code that I currently have works (mostly) but has a few endcases that will cause problems. Once I finish, I'll be glad to send you snippets of the code (or all of it) if you would like to take a look. > vmx/svm are concerned, you got to do some fixed amount of work on the > rmap structures and each spte, for each 4k invalidated regardless of > page/pages/range/ranges. You can only share the cost of the lock and > of the memslot lookup, so you lookup and take the lock once and you > drop 512 sptes instead of just 1. Similar to what we do in the main > linux VM by taking the PT lock for every 512 sptes. > > So you worry about gazillions of invalidate_page without taking into > account that even if you call invalidate_range_end(0, -1ULL) KVM will > have to mangle over 4503599627370496 rmap entries anyway. Yes calling > 1 invalidate_range_end instead of 4503599627370496 invalidate_page, > will be faster, but not much faster. For KVM it remains an O(N) > operation, where N is the number of pages. I'm not so sure we need to > worry about my invalidate_pages being limited to 512 entries. > > Perhaps GRU is different, I'm just describing the KVM situation here. > > As far as KVM is concerned it's more sensible to be able to scale when > there are 1024 kvm threads on 1024 cpus and each kvm-vcpu is accessing > a different guest physical page (especially when new chunks of memory > are allocated for the first time) that won't collide the whole time on > naturally aligned 2M chunks of virtual addresses. > > > And that would not be enough to hold of new references? With small tweaks > > this should work with a common scheme. We could also redefine the role > > of _start and _end slightly to just require that the refs are removed when > > _end completes. That would allow the KVM page count ref to work as is now > > and would avoid the individual invalidate_page() callouts. > > I can already only use _end and ignore _start, only remaining problem > is this won't be 100% coherent (my patch is 100% coherent thanks to PT > lock implicitly serializing follow_page/get_user_pages of the KVM/GRU > secondary MMU faults). My approach give a better peace of mind with > full scalability and no lock recursion when it's the KVM page fault > that invokes get_user_pages that invokes the linux page fault routines > that will try to execute _start taking the lock to block the page > fault that is already running... > > > > > The GRU has no page table on its own. It populates TLB entries on > > > > demand > > > > using the linux page table. There is no way it can figure out when to > > > > drop page counts again. The invalidate calls are turned directly into > > > > tlb > > > > flushes. > > > > > > Yes, this is why it can't serialize follow_page with only the PT lock > > > with your patch. KVM may do it once you add start,end to range_end > > > only thanks to the additional pin on the page. > > > > Right but that pin requires taking a refcount which we cannot do. > > GRU can use my patch without the pin. XPMEM obviously can't use my > patch as my invalidate_page[s] are under the PT lock (a feature to fit > GRU/KVM in the simplest way), this is why an incremental patch adding > invalidate_range_start/end would be required to support XPMEM too. --- jack - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing
Re: [kvm-devel] [PATCH] mmu notifiers #v5
On Sat, Feb 02, 2008 at 09:14:57PM -0600, Jack Steiner wrote: > Also, most (but not all) applications that use the GRU do not usually do > anything that requires frequent flushing (fortunately). The GRU is intended > for HPC-like applications. These don't usually do frequent map/unmap > operations or anything else that requires a lot of flushes. > > I expect that KVM is a lot different. I don't think so. invalidate_page/pages/range_start,end is a slow and unfrequent path for KVM (or alternatively the ranges are very small in which case _range_start/end won't payoff compared to _pages). Whenever invalidate_page[s] become a fast path, we're generally I/O bound. get_user_pages is always the fast path instead. I thought it was much more important that get_user_pages scale as well as it does now and that the KVM page fault isn't serialized with a mutex, than whatever invalidate side optimization. get_user_pages may run frequently from all vcpus even if there are no invalidates and no memory pressure and I don't mean only during startup. > I have most of the GRU code working with the latest mmuops patch. I still > have a list of loose ends that I'll get to next week. The most important is > the exact handling of the range invalidates. The code that I currently have > works (mostly) but has a few endcases that will cause problems. Once I > finish, I'll be glad to send you snippets of the code (or all of it) if you > would like to take a look. Sure. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Fedora 8 as kvm guest
I'm experimenting with kvm on a Fedora 8 system. I've installed the necessary packages, have a suitable CPU etc. I'll eventually aim for a Windows guest, but am trying out a virtual Fedora 8 guest. When I try to install a Fedora guest, it threatens to wipe and re-partition the whole drive. It does this whether I specify an installation file or partition in virt-manager. Can I ignore this? I don't want my whole installation wiped. Is the hypervisor presenting the Fedora install with a file/parition and making it think it has a whole drive? Bob T. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] Let ioctl_get_regs to support input parameters.
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Sun, 3 Feb 2008 14:46:02 +0800
Subject: [PATCH] kvm: Let ioctl_get_regs suppot input pararmeters.
Since kvm_regs is allocated from kernel stack, and
its size is limited. In order to save large register
files of some archs, this API should accept input parameters.
User need to pass a user-space pointer with large memory, and
kernel can copy reigster files to it.
Signed-off-by: Xiantao Zhang<[EMAIL PROTECTED]>
---
virt/kvm/kvm_main.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index a499f50..6d74d0b 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -807,7 +807,8 @@ static long kvm_vcpu_ioctl(struct file *filp,
case KVM_GET_REGS: {
struct kvm_regs kvm_regs;
- memset(&kvm_regs, 0, sizeof kvm_regs);
+ if (copy_from_user(&kvm_regs, argp, sizeof kvm_regs))
+ goto out;
r = kvm_arch_vcpu_ioctl_get_regs(vcpu, &kvm_regs);
if (r)
goto out;
--
1.5.2
0001-kvm-Let-ioctl_get_regs-suppot-input-pararmeters.patch
Description: 0001-kvm-Let-ioctl_get_regs-suppot-input-pararmeters.patch
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
