Re: [kvm-devel] Booting from Virtio block device
On Thu, 2008-02-28 at 00:22 -0500, Haydn Solomon wrote: First of all, thank you for all the great work on this project. I am trying to boot a linux guest from virtio block device. I followed the howto on the wiki but guest is not able to locate root device. Only thing I am doing differently from the wiki is using the virtio_* modules rather than recompiling kernel. My test environment is as follows I haven't test it but just to make sure, do you load virtio modules in initrd? If their not part of the kernel you must do it before mounting the root device. guest: Fedora 9 with latest 2.6.25 kernel KVM ver 62 Host: (Fedora 8) Linux localhost.localdomain 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:03:13 EST 2008 x86_64 x86_64 x86_64 GNU/Linux Any guidance will be appreciated. Thanks. Haydn - 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 - 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] Booting from Virtio block device
Hello You must add root=/dev/vdaX, where X is number of your boot partition, to kernel boot parameters. In lilo.conf you must add this to append line. Have a nice day Haydn Solomon napsal(a): First of all, thank you for all the great work on this project. I am trying to boot a linux guest from virtio block device. I followed the howto on the wiki but guest is not able to locate root device. Only thing I am doing differently from the wiki is using the virtio_* modules rather than recompiling kernel. My test environment is as follows guest: Fedora 9 with latest 2.6.25 kernel KVM ver 62 Host: (Fedora 8) Linux localhost.localdomain 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:03:13 EST 2008 x86_64 x86_64 x86_64 GNU/Linux Any guidance will be appreciated. Thanks. Haydn - 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 -- Tomas Rusnak, Korex Networks Korex s.r.o. Pernikarska 8 010 01 Zilina Slovak Republic tel +421 41 562 5648 email [EMAIL PROTECTED] web www.korex.sk - 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] [kvm-ppc-devel] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies
Hollis Blanchard wrote: It doesn't have to be a package; it can be as simple as a tarball that people have to make; sudo make install before compiling kvm, the same as other prerequisite libraries. Sure. Let's put that tarball inside the qemu directory, and then have it extracted and built automatically when the user types make. I'm really not clear on what advantage you think will be gained here. If the package never changes in kvm-specific ways, there is no point in including it in kvm. The user can install it once, just like they install the X devel packages (for example) which we don't carry in kvm either. Is it indeed the case that no modifications are needed for kvm? The barrier should be whether we need to carry local changes or not. If we can use upstream as is, then it should be installed independently. So let me get this straight... you think it's cool to awk kernel source, Awking the kernel source is not done for the sheer pleasure of it. It is painful to maintain and I only do it out of necessity. but not to copy library code that was designed to be copied in the first place? Seriously? Would it be more palatable to you if I ran awk over arch/powerpc/boot/libdft? Including the source in kvm is of course preferable to awk, but less preferable to an external dependency. -- error compiling committee.c: too many arguments to function - 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] Fix qemu PPC breakage in monitor.c
Jerone Young wrote: Recent pull of qemu_cvs has added function qemu_system_cpu_hot_add to the function do_cput_set_nr in monitor.c . Issue is qemu_system_cpu_hot_add is defined in acpi.c which is only compiled for arch with target base i386 (which are i386 x86-64). Applied, thanks. (It wasn't a qemu-cvs pull, rather the cpu hotplug patches from Glauber). -- error compiling committee.c: too many arguments to function - 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] [kvm-ppc-devel] [PATCH] Fix qemu PPC breakage in monitor.c
Hollis Blanchard wrote: On Wed, 2008-02-27 at 16:14 -0600, Jerone Young wrote: # HG changeset patch # User Jerone Young [EMAIL PROTECTED] # Date 1204150440 21600 # Branch merge # Node ID f255b23b6ef9461be4ee18fa0745f30c4fb66e6a # Parent 64a281615f436e65ca7fb2f3c2721c374fbfc8be Fix qemu PPC breakage in monitor.c Recent pull of qemu_cvs has added function qemu_system_cpu_hot_add to the function do_cput_set_nr in monitor.c . Issue is qemu_system_cpu_hot_add is defined in acpi.c which is only compiled for arch with target base i386 (which are i386 x86-64). Signed-off-by: Jerone Young [EMAIL PROTECTED] diff --git a/qemu/monitor.c b/qemu/monitor.c --- a/qemu/monitor.c +++ b/qemu/monitor.c @@ -357,7 +357,9 @@ static void do_cpu_set_nr(int value, con term_printf(invalid status: %s\n, status); return; } +#if defined(TARGET_I386) || defined(TARGET_X86_64) qemu_system_cpu_hot_add(value, state); +#endif } static void do_info_jit(void) This should be submitted to qemu-devel too, no? qemu hasn't merged the cpu hotplug patches (yet?). -- error compiling committee.c: too many arguments to function - 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] Add --disable-cpu-emulation to qemu help screen
Jerone Young wrote: This patch adds a line to the help screen of configure for qemu to show the option --disable-cpu-emulation Applied, thanks. -- error compiling committee.c: too many arguments to function - 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] virtio: kvm-62, lilo cannot be installed into virtio device
Hello I test virtio block device. I can boot from vda as root partition, but if I want to install lilo into boot sector, lilo give me this error: Fatal: Linux experimental device 0x04x needs to be defined. Check 'man lilo.conf' under 'disk=' and 'max-partitions=' I boot it like this: kvm -boot c -drive file=basic-virtio.qcow2,if=virtio,boot=on -m 512 -vnc :0 -net nic,model=virtio,vlan=0,macaddr=00:00:10:52:37:48 -net tap,vlan=0,ifname=tap0,script=no -daemonize -localtime basic-virtio.qcow is with lilo in boot sector installed, because is image what I use before virtio testing. But with each boot I must manually add root=/dev/vda2 if I want to boot it. Host: Gentoo, kernel with gentoo patchset 2.6.24-r3 Guest: Gentoo, kernel vanilla 2.6.25-rc3 KVM: 62 qemu: 0.9.1 Thank you for your job. -- Tomas Rusnak, Korex Networks Korex s.r.o. Pernikarska 8 010 01 Zilina Slovak Republic email [EMAIL PROTECTED] web www.korex.sk - 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] KVM swapping with mmu notifiers #v7
ציטוט Andrea Arcangeli:
Same as before but one one hand ported to #v7 API and on the other
hand ported to latest kvm.git.
Signed-off-by: Andrea Arcangeli [EMAIL PROTECTED]
diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index 41962e7..e1287ab 100644
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -21,6 +21,7 @@ config KVM
tristate Kernel-based Virtual Machine (KVM) support
depends on HAVE_KVM EXPERIMENTAL
select PREEMPT_NOTIFIERS
+ select MMU_NOTIFIER
select ANON_INODES
---help---
Support hosting fully virtualized guest machines using hardware
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 4583329..4067b0f 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -642,6 +642,110 @@ static void rmap_write_protect(struct kvm *kvm, u64 gfn)
account_shadowed(kvm, gfn);
}
+static void kvm_unmap_spte(struct kvm *kvm, u64 *spte)
+{
+ struct page *page = pfn_to_page((*spte PT64_BASE_ADDR_MASK)
PAGE_SHIFT);
+ get_page(page);
+ rmap_remove(kvm, spte);
+ set_shadow_pte(spte, shadow_trap_nonpresent_pte);
+ kvm_flush_remote_tlbs(kvm);
+ __free_page(page);
with large page support i think we need here put_page...
+}
+
+static void kvm_unmap_rmapp(struct kvm *kvm, unsigned long *rmapp)
+{
+ u64 *spte, *curr_spte;
+
+ spte = rmap_next(kvm, rmapp, NULL);
+ while (spte) {
+ BUG_ON(!(*spte PT_PRESENT_MASK));
+ rmap_printk(kvm_rmap_unmap_hva: spte %p %llx\n, spte, *spte);
+ curr_spte = spte;
+ spte = rmap_next(kvm, rmapp, spte);
+ kvm_unmap_spte(kvm, curr_spte);
+ }
+}
+
+void kvm_unmap_hva(struct kvm *kvm, unsigned long hva)
+{
+ int i;
+
+ /*
+ * If mmap_sem isn't taken, we can look the memslots with only
+ * the mmu_lock by skipping over the slots with userspace_addr == 0.
+ */
+ spin_lock(kvm-mmu_lock);
+ for (i = 0; i kvm-nmemslots; i++) {
+ struct kvm_memory_slot *memslot = kvm-memslots[i];
+ unsigned long start = memslot-userspace_addr;
+ unsigned long end;
+
+ /* mmu_lock protects userspace_addr */
+ if (!start)
+ continue;
+
+ end = start + (memslot-npages PAGE_SHIFT);
+ if (hva = start hva end) {
+ gfn_t gfn_offset = (hva - start) PAGE_SHIFT;
+ kvm_unmap_rmapp(kvm, memslot-rmap[gfn_offset]);
+ }
+ }
+ spin_unlock(kvm-mmu_lock);
+}
+
+static int kvm_age_rmapp(struct kvm *kvm, unsigned long *rmapp)
+{
+ u64 *spte;
+ int young = 0;
+
+ spte = rmap_next(kvm, rmapp, NULL);
+ while (spte) {
+ int _young;
+ u64 _spte = *spte;
+ BUG_ON(!(_spte PT_PRESENT_MASK));
+ _young = _spte PT_ACCESSED_MASK;
+ if (_young) {
+ young = !!_young;
+ set_shadow_pte(spte, _spte ~PT_ACCESSED_MASK);
+ }
+ spte = rmap_next(kvm, rmapp, spte);
+ }
+ return young;
+}
+
+int kvm_age_hva(struct kvm *kvm, unsigned long hva)
+{
+ int i;
+ int young = 0;
+
+ /*
+ * If mmap_sem isn't taken, we can look the memslots with only
+ * the mmu_lock by skipping over the slots with userspace_addr == 0.
+ */
+ spin_lock(kvm-mmu_lock);
+ for (i = 0; i kvm-nmemslots; i++) {
+ struct kvm_memory_slot *memslot = kvm-memslots[i];
+ unsigned long start = memslot-userspace_addr;
+ unsigned long end;
+
+ /* mmu_lock protects userspace_addr */
+ if (!start)
+ continue;
+
+ end = start + (memslot-npages PAGE_SHIFT);
+ if (hva = start hva end) {
+ gfn_t gfn_offset = (hva - start) PAGE_SHIFT;
+ young |= kvm_age_rmapp(kvm, memslot-rmap[gfn_offset]);
+ }
+ }
+ spin_unlock(kvm-mmu_lock);
+
+ if (young)
+ kvm_flush_remote_tlbs(kvm);
+
+ return young;
+}
+
#ifdef MMU_DEBUG
static int is_empty_shadow_page(u64 *spt)
{
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 17f9d16..b014b19 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -380,6 +380,7 @@ static int FNAME(page_fault)(struct kvm_vcpu *vcpu, gva_t
addr,
int r;
struct page *page;
int largepage = 0;
+ unsigned mmu_seq;
pgprintk(%s: addr %lx err %x\n, __FUNCTION__, addr, error_code);
kvm_mmu_audit(vcpu, pre page fault);
@@ -415,6 +416,7 @@ static int FNAME(page_fault)(struct kvm_vcpu *vcpu, gva_t
addr,
largepage = 1;
}
}
+ mmu_seq =
[kvm-devel] [ kvm-Bugs-1903732 ] can not boot guests with 2.6.9 smp pae kernel
Bugs item #1903732, was opened at 2008-02-28 16:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1903732group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: yunfeng (yunfeng) Assigned to: Nobody/Anonymous (nobody) Summary: can not boot guests with 2.6.9 smp pae kernel Initial Comment: Environment: HOSTia32e/pae rhel5 GUEST: ia32pae rhel4u1/rhel4u2/rhel4u3/fc4 Change Set:kernel4a7f582a07e14763ee4714b681e98b3b134d1d46 userspace bc6db37817ce749dcc88fbc761a36bb8df5cf60a Hardware:Platform Woodcrest CPU 4 Memory size 8G' Bug detailed description: -- Can't boot 32 bits up or smp guests with smp 2.6.9 kernel on 32e and pae platform. Use ia32pae rhel4u1/rhel4u2/rhel4u3/fc4 images with smp kernel to boot guests will see the guest hang as the attachment shows. with -no-acpi option can boot; use up 2.6.9 kernel to boot guest have no problem; Reproduce steps: 1 create qcow image qemu-img create -b /share/xvs/img/linux/ia32p_rhel4u3.img -f qcow2 /share/xvs/var/4u1 2 boot guest with acpi enabled qemu-system-x86_64 -m 512 -net nic,macaddr=00:16:3e:3c:0c:9e,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /share/xvs/var/4u1 Current result: -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1903732group_id=180599 - 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] virtio: kvm-62, lilo cannot be installed into virtio device
On Thu, Feb 28, 2008 at 09:40:00AM +0100, Tomas Rusnak wrote: I test virtio block device. I can boot from vda as root partition, but if I want to install lilo into boot sector, lilo give me this error: Fatal: Linux experimental device 0x04x needs to be defined. Check 'man lilo.conf' under 'disk=' and 'max-partitions=' lilo can't figure out what /dev/vda to the bios, does adding: disk=/dev/vda bios=0x80 help? - 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] KVM Test result, kernel 4a7f582.., userspace bc6db37..
Hi, all, This is today's KVM test result against kvm.git 4a7f582a07e14763ee4714b681e98b3b134d1d46 and kvm-userspace.git bc6db37817ce749dcc88fbc761a36bb8df5cf60a. LTP and kernel build test on pae linux guest are failed, because these case boot guests with smp 2.6.9 kernel, it's related with today's new issue. With manual test save restore have no problem for the first time. Save/restore test cases passed in manually testing. Because the command has been changed, it failed in auto testing. We will change the test cases. One new issue: 1. Can not boot guests with 2.6.9 smp pae kernel https://sourceforge.net/tracker/index.php?func=detailaid=1903732group_ id=180599atid=893831 Five Old Issues: 2. qcow based smp linux guests likely hang https://sourceforge.net/tracker/index.php?func=detailaid=1901980group_ id=180599atid=893831 3. Fails to save/restore guests https://sourceforge.net/tracker/index.php?func=detailaid=1824525group_ id=180599atid=893831 4. smp windows installer crashes while rebooting https://sourceforge.net/tracker/index.php?func=detailaid=1877875group_ id=180599atid=893831 5. Timer of guest is inaccurate https://sourceforge.net/tracker/?func=detailatid=893831aid=1826080gro up_id=180599 6. Installer of 64bit vista guest will pause for ten minutes after reboot https://sourceforge.net/tracker/?func=detailatid=893831aid=1836905gro 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 guest PASS 3. boot 4 same guest in parallelPASS 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 PASS 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 PASS 13. save/restore 32-bit linux guests PASS 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 Test environment PlatformWoodcrest CPU 4 Memory size 8G' Details IA32-pae: 1. boot guest with 256M memory PASS 2. boot two windows xp guest PASS 3. boot 4 same guest in parallelPASS 4. boot linux and windows guest in parallel PASS 5. boot guest with 1500M memory PASS 6. boot windows 2003 with ACPI enabled
Re: [kvm-devel] virtio: kvm-62, lilo cannot be installed into virtio device
Chris Wedgwood napsal(a): On Thu, Feb 28, 2008 at 09:40:00AM +0100, Tomas Rusnak wrote: I test virtio block device. I can boot from vda as root partition, but if I want to install lilo into boot sector, lilo give me this error: Fatal: Linux experimental device 0x04x needs to be defined. Check 'man lilo.conf' under 'disk=' and 'max-partitions=' lilo can't figure out what /dev/vda to the bios, does adding: disk=/dev/vda bios=0x80 help? Thank you for your quick answer, but this doesn't help. After i run lilo, it give me the same error message. -- Tomas Rusnak, Korex Networks Korex s.r.o. Pernikarska 8 010 01 Zilina Slovak Republic tel +421 41 562 5648 email [EMAIL PROTECTED] web www.korex.sk - 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] virtio: kvm-62, lilo cannot be installed into virtio device
On Thu, Feb 28, 2008 at 10:11:30AM +0100, Tomas Rusnak wrote: Check 'man lilo.conf' under 'disk=' and 'max-partitions=' Thank you for your quick answer, but this doesn't help. After i run lilo, it give me the same error message. did you try adding 'max-partitions=16' or similar? - 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] virtio: kvm-62, lilo cannot be installed into virtio device
Chris Wedgwood napsal(a): On Thu, Feb 28, 2008 at 10:11:30AM +0100, Tomas Rusnak wrote: Check 'man lilo.conf' under 'disk=' and 'max-partitions=' Thank you for your quick answer, but this doesn't help. After i run lilo, it give me the same error message. did you try adding 'max-partitions=16' or similar? Oh yes, i forgot it :) But max-partitions=16 give you bad value. After this I try max-partitions=7 and run lilo with following result: Warning: /proc/partitions references Experimental major device 254. Warning: /proc/partitions references Experimental major device 254. Warning: /proc/partitions references Experimental major device 254. Added Gentoo-25 * 3 warnings were issued. Now I can boot it correctly. Thank you very much again. -- Tomas Rusnak, Korex Networks Korex s.r.o. Pernikarska 8 010 01 Zilina Slovak Republic email [EMAIL PROTECTED] web www.korex.sk - 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] virtio: kvm-62, lilo cannot be installed into virtio device
On Thu, Feb 28, 2008 at 10:25:49AM +0100, Tomas Rusnak wrote: But max-partitions=16 give you bad value. I suggested 16 because that's what the called to alloc_disk in the virtio block driver is using. I'm not sure why lilo dislikes that value. Now I can boot it correctly. Thank you very much again. It might be useful to put up a Wiki page now that you have it working for this. - 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] Change the e1000 mmio addr space according to spec
repository: /home/build/src/kvm branch: trunk commit cd5edbab7d647b81cbbf60d530068f2916658753 Author: Dor Laor [EMAIL PROTECTED] Date: Thu Feb 28 11:01:41 2008 +0200 Change the e1000 mmio addr space according to spec. According to the Intel 82540EM manual, the mmio space is 128k size. Copied from Xen list and noted by [EMAIL PROTECTED] Signed-off-by: Dor Laor [EMAIL PROTECTED] diff --git a/qemu/hw/e1000.c b/qemu/hw/e1000.c index d573f70..e091958 100644 --- a/qemu/hw/e1000.c +++ b/qemu/hw/e1000.c @@ -52,7 +52,7 @@ static int debugflags = DBGBIT(TXERR) | DBGBIT(GENERAL); #endif #define IOPORT_SIZE 0x40 -#define PNPMMIO_SIZE 0x6 +#define PNPMMIO_SIZE 0x2 /* * HW models: - 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] virtio: kvm-62, lilo cannot be installed into virtio device
Chris Wedgwood napsal(a): On Thu, Feb 28, 2008 at 10:25:49AM +0100, Tomas Rusnak wrote: But max-partitions=16 give you bad value. I suggested 16 because that's what the called to alloc_disk in the virtio block driver is using. I'm not sure why lilo dislikes that value. Now I can boot it correctly. Thank you very much again. It might be useful to put up a Wiki page now that you have it working for this. It's no problem to publish it for others, but did you mean to update this page? http://kvm.qumranet.com/kvmwiki/Virtio?highlight=%28virtio%29/edit or make a new page? I don't know how, because I never put something onto kvm wiki. Can you point me to right way? :) -- Tomas Rusnak, Korex Networks Korex s.r.o. Pernikarska 8 010 01 Zilina Slovak Republic tel +421 41 562 5648 email [EMAIL PROTECTED] web www.korex.sk - 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/6] mmu_notifier: Callbacks to invalidate address ranges
On Thu, Feb 28, 2008 at 01:52:50AM +0100, Andrea Arcangeli wrote: On Wed, Feb 27, 2008 at 04:14:08PM -0800, Christoph Lameter wrote: Erm. This would also be needed by RDMA etc. The only RDMA I know is Quadrics, and Quadrics apparently doesn't need to schedule inside the invalidate methods AFIK, so I doubt the above is true. It'd be interesting to know if IB is like Quadrics and it also doesn't require blocking to invalidate certain remote mappings. We got an answer from the IB guys already. They do not track which of their handles are being used by remote processes so neither approach will work for their purposes with the exception of straight unmaps. In that case, they could use the callout to remove TLB information and rely on the lack of page table information to kill the users process. Without changes to their library spec, I don't believe anything further is possible. If they did change their library spec, I believe they could get things to work the same way that XPMEM has gotten things to work, where a message is sent to the remote side for TLB clearing and that will require sleeping. Thanks, Robin - 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] Booting from Virtio block device
Haydn Solomon wrote: I didn't create the initrd with the modules preloaded. Still not working yet but I'm wondering... will this work with LVM volumes? It's actually easier since you don't have to change your root= line. -- error compiling committee.c: too many arguments to function - 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] [kvm-ppc-devel] [PATCH] Add --disable-cpu-emulation to qemu help screen
On Wed, 2008-02-27 at 16:47 -0600, Hollis Blanchard wrote: On Wed, 2008-02-27 at 16:34 -0600, Jerone Young wrote: # HG changeset patch # User Jerone Young [EMAIL PROTECTED] # Date 1204151598 21600 # Branch merge # Node ID cd9eab52ef2d78809540518c4e18f4730d5d8400 # Parent f255b23b6ef9461be4ee18fa0745f30c4fb66e6a Add --disable-cpu-emulation to qemu help screen. This patch adds a line to the help screen of configure for qemu to show the option --disable-cpu-emulation Signed-off-by: Jerone Young [EMAIL PROTECTED] diff --git a/qemu/configure b/qemu/configure --- a/qemu/configure +++ b/qemu/configure @@ -445,6 +445,7 @@ echo --fmod-inc path to echo --fmod-inc path to FMOD includes echo --enable-uname-release=R Return R for uname -r in usermode emulation echo --sparc_cpu=VBuild qemu for Sparc architecture v7, v8, v8plus, v8plusa, v9 +echo --no-cpu-emulation disables use of qemu cpu emulation code echo echo NOTE: The object files are built at the place where configure is launched exit 1 The patch summary is correct, but the help text is not. Exactly how is this not correct? While on PowerPC at the moment the TCG code is not there (and you need this option anyway)...on x86 using this option does mean by passing the TCG CPU emulation code. If you use this option you have to be using KVM.. what text do you think whould be better ? - 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] Add --disable-cpu-emulation to qemu help screen
Whoops ok looks like I made a mistake with the help text. I use --no-cpu-emulation .. when I meant --disable-cpu-emulation that was in the summary. I think I got my self screwedup by the defines we use in the code. This is what Hollis was pointing out. Here is a more proper patch. Signed-off-by: Jerone Young [EMAIL PROTECTED] diff --git a/qemu/configure b/qemu/configure --- a/qemu/configure +++ b/qemu/configure @@ -445,6 +445,7 @@ echo --fmod-inc path to echo --fmod-inc path to FMOD includes echo --enable-uname-release=R Return R for uname -r in usermode emulation echo --sparc_cpu=VBuild qemu for Sparc architecture v7, v8, v8plus, v8plusa, v9 +echo --disable-cpu-emulation disable use of qemu cpu emulation code echo echo NOTE: The object files are built at the place where configure is launched exit 1 On Thu, 2008-02-28 at 10:24 +0200, Avi Kivity wrote: Jerone Young wrote: This patch adds a line to the help screen of configure for qemu to show the option --disable-cpu-emulation Applied, thanks. - 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] Booting from Virtio block device
Ok, got it to work. Like the docs said, I needed to be careful with ramdisk; I didn't install enough modules in the ramdisk first time around. The Fedora9 vm is booting up much faster on virtio but haven't done any official timings. Network seems to be performing faster too when downloading big files but again, no official timings. Question: As far as balloon driver, does it give any advantage at the moment? Thanks Haydn On Thu, Feb 28, 2008 at 8:08 AM, Avi Kivity [EMAIL PROTECTED] wrote: Haydn Solomon wrote: I didn't create the initrd with the modules preloaded. Still not working yet but I'm wondering... will this work with LVM volumes? It's actually easier since you don't have to change your root= line. -- error compiling committee.c: too many arguments to function - 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/6] mmu_notifier: Callbacks to invalidate address ranges
On Thu, 28 Feb 2008, Andrea Arcangeli wrote: On Wed, Feb 27, 2008 at 05:03:21PM -0800, Christoph Lameter wrote: RDMA works across a network and I would assume that it needs confirmation that a connection has been torn down before pages can be unmapped. Depends on the latency of the network, for example with page pinning it can even try to reduce the wait time, by tearing down the mapping in range_begin and spin waiting the ack only later in range_end. What about invalidate_page()? - 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] VMGL support on KVM
Cam Macdonell wrote: Hi, To be clear, do you have VMGL running? And you're only getting ~35 FPS? For me, using VMGL doubles the performance of glxgears on two different machines. As well, I'm using the Enemy Territory demos the author used and they are usable with VMGL but still jumpy. How do you use VMGL? Do you use VNC or do you have SDL working some how? If someone posts a simple howto with how to setup VMGL in a guest and host, I'll take a look at it this weekend and see if I can't increase the FPS by tweaking the virtio network driver. virtio should get very good throughput but the latencies aren't very optimized yet so if VMGL is latency sensitive, this may be what you're seeing. I don't know what is normal to expect from VMGL though. Regards, Anthony Liguori Thanks, Cam - 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 - 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] [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
Attached is a repost of the preliminary patch implementing USB 2.0 EHCI emulation. I want to start testing your patches for the EHCI stuff. Do i need to enable anything inorder to get EHCI emulation working after applying your patch? Unfortunately, with this patch it doesn't work for me. My guest host (windows vista) still became really slow when I add the a usb device. Waiting for your comments, Arnon Thanks, Jerry - 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 #v7
On Wed, 27 Feb 2008, Andrea Arcangeli wrote:
What Christoph need to do when he's back from vacations to support
sleepable mmu notifiers is to add a CONFIG_XPMEM config option that
will switch the i_mmap_lock from a semaphore to a mutex (any other
change to this patch will be minor compared to that) so XPMEM hardware
will have kernels compiled that way. I don't see other sane ways to
remove the atomic parameter from the API (apparently required by
Andrew for merging something not restricted to the xpmem current usage
with only anonymous memory) and I don't want to have such a
locking-change intrusive dependency for all other non-blocking users
that are fine without having to alter how the VM works (for example
KVM and GRU). Very minor changes will be required to this patch to
make it work after the VM locking will be altered (for example the
CONFIG_XPMEM should also switch the mmu_register/unregister locking
from RCU to mutex as well). XPMEM then will only compile if
CONFIG_XPMEM=y and in turn the invalidate_range_* will support
scheduling inside.
This is not going to work even if the mutex would work as easily as you
think since the patch here still does an rcu_lock/unlock around a callback.
I don't think pretending to merge all in one block (I mean including
xpmem support that requires blocking methods) is good idea anymore as
long as we agree the atomic parameter shouldn't be merged. But we
can quite easily agree on the below to be optimal for GRU/KVM and
trivially extendible once a CONFIG_XPMEM will be added. So this first
part can go in now I think.
Changing the locking for the callouts for users of the mmu notivier that
f.e. require a response via the network (RDMA, XPMEM etc) is not trivial
at all. RCU lock cannot be used. So we are looking at totally disjunct
methods for those users who have to sleep.
+struct mmu_notifier_ops {
+ /*
+ * Called when nobody can register any more notifier in the mm
+ * and after the mn notifier has been disarmed already.
+ */
+ void (*release)(struct mmu_notifier *mn,
+ struct mm_struct *mm);
Who disarms the notifier? Why is the method not called to disarm the
notifier on exit?
+obj-$(CONFIG_MMU_NOTIFIER) += mmu_notifier.o
diff --git a/mm/filemap_xip.c b/mm/filemap_xip.c
--- a/mm/filemap_xip.c
+++ b/mm/filemap_xip.c
@@ -194,7 +194,7 @@ __xip_unmap (struct address_space * mapp
if (pte) {
/* Nuke the page table entry. */
flush_cache_page(vma, address, pte_pfn(*pte));
- pteval = ptep_clear_flush(vma, address, pte);
+ pteval = ptep_clear_flush_notify(vma, address, pte);
page_remove_rmap(page, vma);
dec_mm_counter(mm, file_rss);
BUG_ON(pte_dirty(pteval));
Well a bit better but now we have to modify both the macro and the code
in teh VM. It would be easier to put the notify call in here.
@@ -2048,6 +2050,7 @@ void exit_mmap(struct mm_struct *mm)
vm_unacct_memory(nr_accounted);
free_pgtables(tlb, vma, FIRST_USER_ADDRESS, 0);
tlb_finish_mmu(tlb, 0, end);
+ mmu_notifier_release(mm);
The release should be called much earlier to allow the driver to release
all resources in one go. This way each vma must be processed individually.
For our gobs of memory this method may create a scaling problem on exit().
-
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/RFC 1/2] anon-inodes: Remove fd_install() from anon_inode_getfd()
On Wed, 27 Feb 2008, Roland Dreier wrote:
http://git.kernel.org/?p=linux/kernel/git/viro/vfs-2.6.git;a=commit;h=49be4f8114e6ff0efdab10ebba2493fb67bc3034
Actually, looking closer at the kvm changes here, I think that
create_vcpu_fd() needs the same treatment as kvm_dev_ioctl_create_vm()
gets in the patch because of the race I mentioned in the changelog
for my patch: otherwise kvm_vcpu_release() could drop the last
reference to vcpu-kvm-filp before the get_file() gets an extra
reference.
I'm beginning to think that moving the fd_install() out of
anon_inode_getfd() really is worth it to make a safer interface.
If we let the caller call fd_install(), then it may be messed up WRT
cleanup (fd, file, inode).
How about removing the inode pointer handout altogether, and *doing*
fd_install() inside anon_inode_getfd() like:
if (pfile != NULL) {
get_file(file);
*pfile = file;
}
fd_install(fd, file);
In this way, if the caller want the file* back, he gets the reference
bumped before fd_install().
- Davide
-
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/RFC 1/2] anon-inodes: Remove fd_install() from anon_inode_getfd()
If we let the caller call fd_install(), then it may be messed up WRT
cleanup (fd, file, inode).
Yes, that is a tiny bit tricky (need to call put_unused_fd() if you
don't install the fd).
How about removing the inode pointer handout altogether, and *doing*
fd_install() inside anon_inode_getfd() like:
if (pfile != NULL) {
get_file(file);
*pfile = file;
}
fd_install(fd, file);
In this way, if the caller want the file* back, he gets the reference
bumped before fd_install().
I think that may be a bit cleaner than Al's approach, but it still
leaves the same trap that create_vcpu_fd() falls into. The current
code is:
static int create_vcpu_fd(struct kvm_vcpu *vcpu)
{
int fd, r;
struct inode *inode;
struct file *file;
r = anon_inode_getfd(fd, inode, file,
kvm-vcpu, kvm_vcpu_fops, vcpu);
if (r)
return r;
atomic_inc(vcpu-kvm-filp-f_count);
return fd;
}
and with your proposal, the natural way to write that becomes:
static int create_vcpu_fd(struct kvm_vcpu *vcpu)
{
int fd, r;
r = anon_inode_getfd(fd, NULL,
kvm-vcpu, kvm_vcpu_fops, vcpu);
if (r)
return r;
atomic_inc(vcpu-kvm-filp-f_count);
return fd;
}
which still has the same bug.
Maybe a good way to handle this is just to make the get_file() not
optional. I dunno... I feel like we've spent more discussion on this
point than it deserves, so someone should just make a decision and
I'll adapt the ib_uverbs code to work with whatever it is.
- R.
-
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] [kvm-ppc-devel] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies
So I forgot to CC all the interested parties on this list (sorry about that I wasn't thinking at the time), but I did start up a conversation on linuxppc-dev on the subject of splitting out libfdt from dtc. Mainly to get the thought of what the dtc folks thought about splitting out libfdt. The outcome of this discussion is the point of libfdt is to be integrated into different projects. I could not make a good argument at all as to why it should be split out (actually I did a terrible job at it :-)). A good analogy was made also as this is equivalent to splitting libcrypto out of openssl. So the concessious from others in the libfdt community is the it should go in the project. This would be in line with what Hollis has been saying on the list. Now for us we can do one of the following options: 1) Integrate libfdt into our kvm-userspace or qemu (which would then require going upstream qemu folks also agree). 2) Can use wget or something to first grab the dtc source and get libfdt from it. Then place in our make file and build it. As well as point cflags ldflags to it. (This can be done, though I wanted to avoid going this route) Here is a link to the discussion on linuxppc-dev: http://ozlabs.org/pipermail/linuxppc-dev/2008-February/052262.html On Thu, 2008-02-28 at 10:16 +0200, Avi Kivity wrote: Hollis Blanchard wrote: It doesn't have to be a package; it can be as simple as a tarball that people have to make; sudo make install before compiling kvm, the same as other prerequisite libraries. Sure. Let's put that tarball inside the qemu directory, and then have it extracted and built automatically when the user types make. I'm really not clear on what advantage you think will be gained here. If the package never changes in kvm-specific ways, there is no point in including it in kvm. The user can install it once, just like they install the X devel packages (for example) which we don't carry in kvm either. Is it indeed the case that no modifications are needed for kvm? The barrier should be whether we need to carry local changes or not. If we can use upstream as is, then it should be installed independently. So let me get this straight... you think it's cool to awk kernel source, Awking the kernel source is not done for the sheer pleasure of it. It is painful to maintain and I only do it out of necessity. but not to copy library code that was designed to be copied in the first place? Seriously? Would it be more palatable to you if I ran awk over arch/powerpc/boot/libdft? Including the source in kvm is of course preferable to awk, but less preferable to an external dependency. - 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] VMGL support on KVM
Anthony Liguori wrote: If someone posts a simple howto with how to setup VMGL in a guest and host, I'll take a look at it this weekend and see if I can't increase the FPS by tweaking the virtio network driver. virtio should get very good throughput but the latencies aren't very optimized yet so if VMGL is latency sensitive, this may be what you're seeing. I don't know what is normal to expect from VMGL though. Regards, Anthony Liguori Hi Anthony Here is one I made as I went along. If it's useful I will move it to the KVM wiki. VirtIO does seem to improve performance of an openGL video game (enemy territory used in the paper). However glxgears gets better performance (more FPS) using rtl8139. Perhaps a bandwidth v. latency difference? http://warburg.cs.ualberta.ca/~cam/dokuwiki/doku.php?id=vmgl Cam - 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 #v7
On Thu, Feb 28, 2008 at 11:48:10AM -0800, Christoph Lameter wrote:
make it work after the VM locking will be altered (for example the
^^^
CONFIG_XPMEM should also switch the mmu_register/unregister locking
^^^
from RCU to mutex as well). XPMEM then will only compile if
^
CONFIG_XPMEM=y and in turn the invalidate_range_* will support
scheduling inside.
This is not going to work even if the mutex would work as easily as you
think since the patch here still does an rcu_lock/unlock around a callback.
See underlined.
+struct mmu_notifier_ops {
+ /*
+* Called when nobody can register any more notifier in the mm
+* and after the mn notifier has been disarmed already.
+*/
+ void (*release)(struct mmu_notifier *mn,
+ struct mm_struct *mm);
Who disarms the notifier? Why is the method not called to disarm the
notifier on exit?
The notifier is auto-disarmed by mmu_notifier_release, your patch
works the same way. -release is further called just in case anybody
wants to know the notifier was disarmed.
@@ -2048,6 +2050,7 @@ void exit_mmap(struct mm_struct *mm)
vm_unacct_memory(nr_accounted);
free_pgtables(tlb, vma, FIRST_USER_ADDRESS, 0);
tlb_finish_mmu(tlb, 0, end);
+ mmu_notifier_release(mm);
The release should be called much earlier to allow the driver to release
all resources in one go. This way each vma must be processed individually.
For our gobs of memory this method may create a scaling problem on exit().
Good point, it has to be called earlier for GRU, but it's not a
performance issue. GRU doesn't pin the pages so it should make the
global invalidate in -release _before_ unmap_vmas. Linux can't fault
in the ptes anymore because mm_users is zero so there's no need of a
-release_begin/end, the _begin is enough.
In #v6 I was invalidating inside unmap_vmas so it was ok. The
performance issues you're talking about refers to #v6 I guess, for #v7
there's a single call.
Thanks!
diff --git a/mm/mmap.c b/mm/mmap.c
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2039,6 +2039,7 @@ void exit_mmap(struct mm_struct *mm)
unsigned long end;
/* mm's last user has gone, and its about to be pulled down */
+ mmu_notifier_release(mm);
arch_exit_mmap(mm);
lru_add_drain();
@@ -2050,7 +2051,6 @@ void exit_mmap(struct mm_struct *mm)
vm_unacct_memory(nr_accounted);
free_pgtables(tlb, vma, FIRST_USER_ADDRESS, 0);
tlb_finish_mmu(tlb, 0, end);
- mmu_notifier_release(mm);
/*
* Walk the list again, actually closing and freeing it,
-
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 #v7
On Thu, 28 Feb 2008, Andrea Arcangeli wrote: This is not going to work even if the mutex would work as easily as you think since the patch here still does an rcu_lock/unlock around a callback. See underlined. Mutex is not acceptable for performance reasons. I think we can just drop the RCU lock if we simply unregister the mmu notifier in release and forbid the drivers from removing themselves from the notification chain. They can simply do nothing until release. At that time there is no concurrency and thus its safe to remove even without rcu locking. Good point, it has to be called earlier for GRU, but it's not a performance issue. GRU doesn't pin the pages so it should make the global invalidate in -release _before_ unmap_vmas. Linux can't fault in the ptes anymore because mm_users is zero so there's no need of a -release_begin/end, the _begin is enough. I do not follow you about the _begin without end but the following fix seems okay. - 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] virtio: kvm-62, lilo cannot be installed into virtio device
Tomas Rusnak wrote: Chris Wedgwood napsal(a): On Thu, Feb 28, 2008 at 10:11:30AM +0100, Tomas Rusnak wrote: Check 'man lilo.conf' under 'disk=' and 'max-partitions=' Thank you for your quick answer, but this doesn't help. After i run lilo, it give me the same error message. did you try adding 'max-partitions=16' or similar? Oh yes, i forgot it :) But max-partitions=16 give you bad value. After this I try max-partitions=7 and run lilo with following result: Warning: /proc/partitions references Experimental major device 254. Warning: /proc/partitions references Experimental major device 254. Warning: /proc/partitions references Experimental major device 254. Added Gentoo-25 * 3 warnings were issued. max-partitions=7 sounds a bit confining, why are we using such a low number? LILO is one of several reasons why using dynamic major really isn't such a great idea. We don't have the 8:8 limitation anymore. -hpa - 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][QEMU] Change -hugetlb-path to -mem-path
This patch changes -hugetlb-path to -mem-path and also updates the code so that
it works for hugetlbfs or tmpfs.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/qemu/vl.c b/qemu/vl.c
index c9ed3f0..2896024 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -237,8 +237,7 @@ int semihosting_enabled = 0;
int autostart = 1;
int time_drift_fix = 0;
unsigned int kvm_shadow_memory = 0;
-const char *hugetlbpath = NULL;
-const char *hugetlbfile = NULL;
+const char *mem_path = NULL;
int hpagesize = 0;
const char *cpu_vendor_string;
#ifdef TARGET_ARM
@@ -8074,7 +8073,7 @@ static void help(int exitcode)
#endif
-tdfinject timer interrupts that got lost\n
-kvm-shadow-memory megs set the amount of shadow pages to be
allocated\n
- -hugetlb-path set the path to hugetlbfs mounted directory, also
enables allocation of guest memory with huge pages\n
+ -mem-path set the path to hugetlbfs/tmpfs mounted directory,
also enables allocation of guest memory with huge pages\n
-option-rom rom load a file, rom, into the option ROM space\n
#ifdef TARGET_SPARC
-prom-env variable=value set OpenBIOS nvram variables\n
@@ -8193,7 +8192,7 @@ enum {
QEMU_OPTION_incoming,
QEMU_OPTION_tdf,
QEMU_OPTION_kvm_shadow_memory,
-QEMU_OPTION_hugetlbpath,
+QEMU_OPTION_mempath,
};
typedef struct QEMUOption {
@@ -8315,7 +8314,7 @@ const QEMUOption qemu_options[] = {
#endif
{ clock, HAS_ARG, QEMU_OPTION_clock },
{ startdate, HAS_ARG, QEMU_OPTION_startdate },
-{ hugetlb-path, HAS_ARG, QEMU_OPTION_hugetlbpath },
+{ mem-path, HAS_ARG, QEMU_OPTION_mempath },
{ NULL },
};
@@ -8570,89 +8569,82 @@ void qemu_get_launch_info(int *argc, char ***argv, int
*opt_daemonize, const cha
static int gethugepagesize(void)
{
- int ret, fd;
- char buf[4096];
- char *needle = Hugepagesize:;
- char *size;
- unsigned long hugepagesize;
-
- fd = open(/proc/meminfo, O_RDONLY);
- if (fd 0) {
- perror(open);
- exit(0);
- }
+int ret, fd;
+char buf[4096];
+char *needle = Hugepagesize:;
+char *size;
+unsigned long hugepagesize;
- ret = read(fd, buf, sizeof(buf));
- if (ret 0) {
- perror(read);
- exit(0);
- }
+fd = open(/proc/meminfo, O_RDONLY);
+if (fd 0) {
+ perror(open);
+ exit(0);
+}
- size = strstr(buf, needle);
- if (!size)
- return 0;
- size += strlen(needle);
- hugepagesize = strtol(size, NULL, 0);
- return hugepagesize;
-}
+ret = read(fd, buf, sizeof(buf));
+if (ret 0) {
+ perror(read);
+ exit(0);
+}
-void cleanup_hugetlb(void)
-{
- if (hugetlbfile)
- unlink(hugetlbfile);
+size = strstr(buf, needle);
+if (!size)
+ return 0;
+size += strlen(needle);
+hugepagesize = strtol(size, NULL, 0);
+return hugepagesize;
}
-void *alloc_huge_area(unsigned long memory, const char *path)
+void *alloc_mem_area(unsigned long memory, const char *path)
{
- void *area;
- int fd;
- char *filename;
- char *tmpfile = /kvm.XX;
-
- filename = qemu_malloc(4096);
- if (!filename)
- return NULL;
+char *filename;
+void *area;
+int fd;
- memset(filename, 0, 4096);
- strncpy(filename, path, 4096 - strlen(tmpfile) - 1);
- strcat(filename, tmpfile);
+if (asprintf(filename, %s/kvm.XX, path) == -1)
+ return NULL;
- hpagesize = gethugepagesize() * 1024;
- if (!hpagesize)
- return NULL;
+hpagesize = gethugepagesize() * 1024;
+if (!hpagesize)
+ return NULL;
- mkstemp(filename);
- fd = open(filename, O_RDWR);
- if (fd 0) {
- perror(open);
- hpagesize = 0;
- exit(0);
- }
- memory = (memory+hpagesize-1) ~(hpagesize-1);
+fd = mkstemp(filename);
+if (fd 0) {
+ perror(mkstemp);
+ free(filename);
+ return NULL;
+}
+unlink(filename);
+free(filename);
- area = mmap(0, memory, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
- if (area == MAP_FAILED) {
- perror(mmap);
- hpagesize = 0;
- exit(0);
- }
+memory = (memory+hpagesize-1) ~(hpagesize-1);
- hugetlbfile = filename;
- atexit(cleanup_hugetlb);
+if (ftruncate(fd, memory) == -1) {
+ perror(ftruncate);
+ close(fd);
+ return NULL;
+}
- return area;
+area = mmap(0, memory, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
+if (area == MAP_FAILED) {
+ perror(mmap);
+ close(fd);
+ return NULL;
+}
+
+return area;
}
void *qemu_alloc_physram(unsigned long memory)
{
- void *area = NULL;
+void *area = NULL;
- if
Re: [kvm-devel] [PATCH] mmu notifiers #v7
On Wed, 27 Feb 2008, Andrea Arcangeli wrote:
+struct mmu_notifier_head {
+ struct hlist_head head;
+ spinlock_t lock;
+};
Still think that the lock here is not of too much use and can be easily
replaced by mmap_sem.
+#define mmu_notifier(function, mm, args...) \
+ do {\
+ struct mmu_notifier *__mn; \
+ struct hlist_node *__n; \
+ \
+ if (unlikely(!hlist_empty((mm)-mmu_notifier.head))) { \
+ rcu_read_lock();\
+ hlist_for_each_entry_rcu(__mn, __n, \
+ (mm)-mmu_notifier.head, \
+ hlist) \
+ if (__mn-ops-function)\
+ __mn-ops-function(__mn, \
+ mm, \
+ args); \
+ rcu_read_unlock(); \
+ } \
+ } while (0)
Andrew recomended local variables for parameters used multile times. This
means the mm parameter here.
+/*
+ * Notifiers that use the parameters that they were passed so that the
+ * compiler does not complain about unused variables but does proper
+ * parameter checks even if !CONFIG_MMU_NOTIFIER.
+ * Macros generate no code.
+ */
+#define mmu_notifier(function, mm, args...) \
+ do { \
+ if (0) { \
+ struct mmu_notifier *__mn; \
+\
+ __mn = (struct mmu_notifier *)(0x00ff);\
+ __mn-ops-function(__mn, mm, args); \
+ }; \
+ } while (0)
Note also Andrew's comments on the use of 0x00ff...
+/*
+ * No synchronization. This function can only be called when only a single
+ * process remains that performs teardown.
+ */
+void mmu_notifier_release(struct mm_struct *mm)
+{
+ struct mmu_notifier *mn;
+ struct hlist_node *n, *tmp;
+
+ if (unlikely(!hlist_empty(mm-mmu_notifier.head))) {
+ hlist_for_each_entry_safe(mn, n, tmp,
+ mm-mmu_notifier.head, hlist) {
+ hlist_del(mn-hlist);
+ if (mn-ops-release)
+ mn-ops-release(mn, mm);
+ }
+ }
+}
One could avoid a hlist_for_each_entry_safe here by simply always deleting
the first object.
Also re the _notify variants: The binding to pte_clear_flush_young etc
will become a problem for notifiers that want to sleep because
pte_clear_flush is usually called with the pte lock held. See f.e.
try_to_unmap_one, page_mkclean_one etc.
It would be better if the notifier calls could be moved outside of the
pte lock.
-
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 #v7
The release should be called much earlier to allow the driver to release all resources in one go. This way each vma must be processed individually. For our gobs of memory this method may create a scaling problem on exit(). Good point, it has to be called earlier for GRU, but it's not a performance issue. GRU doesn't pin the pages so it should make the global invalidate in -release _before_ unmap_vmas. Linux can't fault in the ptes anymore because mm_users is zero so there's no need of a -release_begin/end, the _begin is enough. I disagree. The location of the callout IS a performance issue. In simple comparisons of the 2 patches (Christoph's vs. Andrea's), Andrea's has a 7X increase in the number of TLB purges being issued to the GRU. TLB flushing is slow and can impact the performance of of tasks using the GRU. --- 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 list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] mmu notifiers #v7
On Thu, Feb 28, 2008 at 05:17:33PM -0600, Jack Steiner wrote: I disagree. The location of the callout IS a performance issue. In simple comparisons of the 2 patches (Christoph's vs. Andrea's), Andrea's has a 7X increase in the number of TLB purges being issued to the GRU. TLB flushing Are you sure that you're referring to #v7? - 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 #v7
On Thu, Feb 28, 2008 at 03:05:30PM -0800, Christoph Lameter wrote:
Still think that the lock here is not of too much use and can be easily
replaced by mmap_sem.
I can use the mmap_sem.
+#define mmu_notifier(function, mm, args...)
\
+ do {\
+ struct mmu_notifier *__mn; \
+ struct hlist_node *__n; \
+ \
+ if (unlikely(!hlist_empty((mm)-mmu_notifier.head))) { \
+ rcu_read_lock();\
+ hlist_for_each_entry_rcu(__mn, __n, \
+(mm)-mmu_notifier.head, \
+hlist) \
+ if (__mn-ops-function)\
+ __mn-ops-function(__mn, \
+ mm, \
+ args); \
+ rcu_read_unlock(); \
+ } \
+ } while (0)
Andrew recomended local variables for parameters used multile times. This
means the mm parameter here.
I don't exactly see what buggy macro meant? I already use
parenthesis as needed to avoid the need of local variables to be
safe. Not really sure what's buggy, sorry!
Note also Andrew's comments on the use of 0x00ff...
I thought I tried the (void) but it didn't work and your solution
worked, but perhaps I did something wrong, I'll try again with (void)
nevertheless.
+/*
+ * No synchronization. This function can only be called when only a single
+ * process remains that performs teardown.
+ */
+void mmu_notifier_release(struct mm_struct *mm)
+{
+ struct mmu_notifier *mn;
+ struct hlist_node *n, *tmp;
+
+ if (unlikely(!hlist_empty(mm-mmu_notifier.head))) {
+ hlist_for_each_entry_safe(mn, n, tmp,
+ mm-mmu_notifier.head, hlist) {
+ hlist_del(mn-hlist);
+ if (mn-ops-release)
+ mn-ops-release(mn, mm);
+ }
+ }
+}
One could avoid a hlist_for_each_entry_safe here by simply always deleting
the first object.
Agreed, the current construct come from the fact we previously didn't
assume nobody could ever call mmu_notifier_unregister by the time
mm_users is 0.
Also re the _notify variants: The binding to pte_clear_flush_young etc
will become a problem for notifiers that want to sleep because
pte_clear_flush is usually called with the pte lock held. See f.e.
try_to_unmap_one, page_mkclean_one etc.
Calling __free_page out of the PT lock is much bigger
change. do_wp_page will require changes anyway when the sleepable
notifiers are merged.
It would be better if the notifier calls could be moved outside of the
pte lock.
The point is that it can't make a difference right now, and my
objective was to avoid unnecessary source code duplication (later it
will be necessary, right now it isn't). By the time you rework
do_wp_page, removing _notify will be a very minor detail compared to
the rest of the changes to do_wp_page IMHO. Expanding it now won't
provide a real advantage later.
-
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/6] mmu_notifier: Callbacks to invalidate address ranges
On Thu, Feb 28, 2008 at 10:43:54AM -0800, Christoph Lameter wrote: What about invalidate_page()? That would just spin waiting an ack (just like the smp-tlb-flushing invalidates in numa already does). Thinking more about this, we could also parallelize it with an invalidate_page_before/end. If it takes 1usec to flush remotely, scheduling would be overkill, but spending 1usec in a while loop isn't nice if we can parallelize that 1usec with the ipi-tlb-flush. Not sure if it makes sense... it certainly would be quick to add it (especially thanks to _notify ;). - 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 #v7
On Fri, 29 Feb 2008 01:40:01 +0100 Andrea Arcangeli [EMAIL PROTECTED] wrote:
+#define mmu_notifier(function, mm, args...)
\
+ do {\
+ struct mmu_notifier *__mn; \
+ struct hlist_node *__n; \
+ \
+ if (unlikely(!hlist_empty((mm)-mmu_notifier.head))) { \
+ rcu_read_lock();\
+ hlist_for_each_entry_rcu(__mn, __n, \
+ (mm)-mmu_notifier.head, \
+ hlist) \
+ if (__mn-ops-function)\
+ __mn-ops-function(__mn, \
+ mm, \
+ args); \
+ rcu_read_unlock(); \
+ } \
+ } while (0)
Andrew recomended local variables for parameters used multile times. This
means the mm parameter here.
I don't exactly see what buggy macro meant?
multiple refernces to the argument, so
mmu_notifier(foo, bar(), zot);
will call bar() either once or twice.
Unlikely in this case, but bad practice. Easily fixable by using another
temporary.
-
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/6] mmu_notifier: Callbacks to invalidate address ranges
On Fri, 29 Feb 2008, Andrea Arcangeli wrote: On Thu, Feb 28, 2008 at 10:43:54AM -0800, Christoph Lameter wrote: What about invalidate_page()? That would just spin waiting an ack (just like the smp-tlb-flushing invalidates in numa already does). And thus the device driver may stop receiving data on a UP system? It will never get the ack. Thinking more about this, we could also parallelize it with an invalidate_page_before/end. If it takes 1usec to flush remotely, scheduling would be overkill, but spending 1usec in a while loop isn't nice if we can parallelize that 1usec with the ipi-tlb-flush. Not sure if it makes sense... it certainly would be quick to add it (especially thanks to _notify ;). invalidate_page_before/end could be realized as an invalidate_range_begin/end on a page sized range? - 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 #v7
On Fri, 29 Feb 2008, Andrea Arcangeli wrote: Also re the _notify variants: The binding to pte_clear_flush_young etc will become a problem for notifiers that want to sleep because pte_clear_flush is usually called with the pte lock held. See f.e. try_to_unmap_one, page_mkclean_one etc. Calling __free_page out of the PT lock is much bigger change. do_wp_page will require changes anyway when the sleepable notifiers are merged. I thought you wanted to get rid of the sync via pte lock? What changes to do_wp_page do you envision? It would be better if the notifier calls could be moved outside of the pte lock. The point is that it can't make a difference right now, and my objective was to avoid unnecessary source code duplication (later it will be necessary, right now it isn't). By the time you rework do_wp_page, removing _notify will be a very minor detail compared to the rest of the changes to do_wp_page IMHO. Expanding it now won't provide a real advantage later. What is the trouble with the current do_wp_page modifications? There is no need for invalidate_page() there so far. invalidate_range() does the trick there. - 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 #v7
On Fri, 29 Feb 2008, Andrea Arcangeli wrote: On Thu, Feb 28, 2008 at 05:17:33PM -0600, Jack Steiner wrote: I disagree. The location of the callout IS a performance issue. In simple comparisons of the 2 patches (Christoph's vs. Andrea's), Andrea's has a 7X increase in the number of TLB purges being issued to the GRU. TLB flushing Are you sure that you're referring to #v7? Jack: AFAICT Andrea moved the release callout and things will be fine in the next release. - 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] The SMP RHEL 5.1 PAE guest can't boot up issue
Avi, Eddie, I have a kernel-newbie question related to this thread. I think that Yang's mentioned case that TSC between different vcpus doesn't sync could also happen with physical cpus. Namely I think a OS running on bare metal hardware need to handle the unsynced TSC between physical cpus. But from the discussion of this thread, it seems that RHEL5.1 kernel can not handle the unsynced TSC, right? Thanks for your advice in advance, Forrest - 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] VMGL support on KVM
On Thu, Feb 28, 2008 at 1:55 PM, Cam Macdonell [EMAIL PROTECTED] wrote: Anthony Liguori wrote: If someone posts a simple howto with how to setup VMGL in a guest and host, I'll take a look at it this weekend and see if I can't increase the FPS by tweaking the virtio network driver. virtio should get very good throughput but the latencies aren't very optimized yet so if VMGL is latency sensitive, this may be what you're seeing. I don't know what is normal to expect from VMGL though. Regards, Anthony Liguori Hi Anthony Here is one I made as I went along. If it's useful I will move it to the KVM wiki. VirtIO does seem to improve performance of an openGL video game (enemy territory used in the paper). However glxgears gets better performance (more FPS) using rtl8139. Perhaps a bandwidth v. latency difference? http://warburg.cs.ualberta.ca/~cam/dokuwiki/doku.php?id=vmgl I can confirm Cam's findings, though I'm also getting better glxgears performance with virtio. Quake 3 plays great in a 800x600 window on my GMA 950 (Intel integrated graphics) laptop. I'll try and get some numbers to compare. Cam's HOWTO is important IMHO as VMGL does not compile by default on 64 bits. We should move it to the KVM wiki. The only thing I would add is a big warning that the usermode network stack _kills_ performance. I went from ~30 to ~1000 FPS in glxgears by changing usermode to tap. Cheers, Jorge - 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][QEMU] Change -hugetlb-path to -mem-path
Looks good, please apply. Thanks. On Thu, Feb 28, 2008 at 04:46:58PM -0600, Anthony Liguori wrote: This patch changes -hugetlb-path to -mem-path and also updates the code so that it works for hugetlbfs or tmpfs. Signed-off-by: Anthony Liguori [EMAIL PROTECTED] - 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] [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
In hw/pc.c, replace usb_uhci_piix3_init(pci_bus, piix3_devfn + 2); With usb_ehci_init(pci_bus, piix3_devfn + 2); Note my comments on the original post: -tested on XP guest -does not support ISO transfers -timing issues -Original Message- From: Gerb Stralko [mailto:[EMAIL PROTECTED] Sent: Thursday, February 28, 2008 9:46 PM To: Arnon Gilboa Cc: [EMAIL PROTECTED]; kvm-devel@lists.sourceforge.net Subject: Re: [kvm-devel] [Qemu-devel] [PATCH] USB 2.0 EHCI emulation Attached is a repost of the preliminary patch implementing USB 2.0 EHCI emulation. I want to start testing your patches for the EHCI stuff. Do i need to enable anything inorder to get EHCI emulation working after applying your patch? Unfortunately, with this patch it doesn't work for me. My guest host (windows vista) still became really slow when I add the a usb device. Waiting for your comments, Arnon Thanks, Jerry - 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
