[kvm-devel] [ kvm-Bugs-1901208 ] fc5/fc6/rhel5u1 no-acpi up guests can't boot on ia32pae pl
Bugs item #1901208, was opened at 2008-02-25 16:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1901208group_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: fc5/fc6/rhel5u1 no-acpi up guests can't boot on ia32pae pl Initial Comment: Environment: Host OS :ia32pae rhel5 Guest OS (ia32/ia32e/IA64): ia32pae fc5/fc6/rhel5u1 Change Set: kernel81e4400b4df4e597a81c19c1161aa03c73613710 userspace 08385e49dcff3585f597870af67301d7659a1ecb Hardware:platform woodcrest memory size8G' Bug detailed description: -- fc5/fc6/rhel5u1 guests can't boot with -no-acpi option, guests will hang at some points as attachments show. without -no-acpi option the guests can boot; with -smp 2 option the guests can boot,too. Reproduce steps: 1.create qcow image: qemu-img create -b /share/xvs/img/linux/ia32p_fc6.img -f qcow2 /share/xvs/var/tmp-img 2.create the guest with -no-acpi: qemu -m 256 -no-acpi -net nic,macaddr=00:16:3e:60:8f:41,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /share/xvs/var/tmp-img1 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1901208group_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
[kvm-devel] KVM Test result, kernel 81e4400.., userspace 08385e4.. , One new issue
Hi, all, This is today's KVM test result against kvm.git 81e4400b4df4e597a81c19c1161aa03c73613710 and kvm-userspace.git 08385e49dcff3585f597870af67301d7659a1ecb. One new issue has been found in today's testing: 1. fc5/fc6/rhel5u1 no-acpi up guests can't boot on pae host https://sourceforge.net/tracker/index.php?func=detailaid=1901208group_ id=180599atid=893831 Five old issues: 2. Fails to save/restore guests https://sourceforge.net/tracker/index.php?func=detailaid=1824525group_ id=180599atid=893831 3. smp windows installer crashes while rebooting https://sourceforge.net/tracker/index.php?func=detailaid=1877875group_ id=180599atid=893831 4. Timer of guest is inaccurate https://sourceforge.net/tracker/?func=detailatid=893831aid=1826080gro up_id=180599 5. Installer of 64bit vista guest will pause for ten minutes after reboot https://sourceforge.net/tracker/?func=detailatid=893831aid=1836905gro up_id=180599 6. Cannot boot 32bit smp RHEL5.1 guest with nic on 64bit host https://sourceforge.net/tracker/?func=detailatid=893831aid=1812043gro 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 Report Summary on IA32-pae Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel 6 5 1 00 Restart 2 2 0 00 gtest 14 13 1 00 = control_panel 6 5 1 00 :KVM_LM_PAE_gPAE 1 0 1 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
Re: [kvm-devel] still seeing network freezes with rtl8139 nic
david ahern wrote: I've run a lot more tests: - if I remove the if (!change) return optimization from pci_set_irq the rtl8139 nic worked fine for 16+ hours. I'm not recommending this as a fix, just confirming that the problem goes away. Interesting. What can cause this to happen? - some non-pci device shares the same irq (unlikely) - the pci link sharing is broken. Is the eth0 irq shared? Please post /proc/interrupts. - the in-kernel ioapic is buggy and needs the extra kicking the optimization prevents. Can be checked by re-adding the optimization to kvm_ioapic_set_irq() (keeping it removed in qemu). If it works, the problem is in userspace. If it fails, the problem is in the kernel. Something like static int old_level[16]; if (level == old_level[irq]) return; old_level[irq] = level; -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - 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] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies
Jerone Young wrote: The top level directory of kvm-userspace is starting to get a little crowded as we start to bring in more external dependencies. Perhaps we can create a folder tools and move directories: bios extboot vgabios The reason I mention this is soon I will be sending a patch to the list soon that will add libfdt (which is a library to read device trees for ppc) as a dependency for qemu .. and it's another directory at the top level, there will most likely be more libs and tools added in the future. Not sure if tools is the best name .. maybe external_libs .. not sure .. but just a place to put external dependencies for qemu whould be a good thing. I don't really see why we need to keep the top-level directory small. However, why do we need libfdt? Is it not carried by distros, or do you need to make changes? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - 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 screen corruption bug in vga_draw_graphic()
Hey, this patch works like a charm! No pointer trails, no bars through dialogs... Perfect quality. Thanks alot Andreas! Arne On Fr, 2008-02-22 at 21:36 +0100, Andreas Winkelbauer wrote: hi, the attached patch fixes the screen corruption issues which were reported by others, see: http://article.gmane.org/gmane.comp.emulators.kvm.devel/13543 http://article.gmane.org/gmane.comp.emulators.kvm.devel/13409 The bug is kvm specific and can only be observed in graphics mode using relatively high resolutions (when one line uses more than one page of memory). As far as I've seen this bug is around since commit dd9591e0fea25a1414f4a6b2faa61ed733e0acc6 (5 nov 2006). I've attached two versions of the patch. One just changes the relevant line and the other one also cleans up formatting (indention) of the kvm specific code. cheers, Andi - 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 Test result, kernel 81e4400.., userspace 08385e4.. , One new issue
On Monday 25 February 2008 16:41:25 Zhao, Yunfeng wrote: Hi, all, This is today's KVM test result against kvm.git 81e4400b4df4e597a81c19c1161aa03c73613710 and kvm-userspace.git 08385e49dcff3585f597870af67301d7659a1ecb. One new issue has been found in today's testing: 1. fc5/fc6/rhel5u1 no-acpi up guests can't boot on pae host https://sourceforge.net/tracker/index.php?func=detailaid=1901208group_ id=180599atid=893831 A quick bisect shows that the problem caused by kvm: qemu: fix host_cpuid() on x86_64. Five old issues: 2. Fails to save/restore guests https://sourceforge.net/tracker/index.php?func=detailaid=1824525group_ id=180599atid=893831 3. smp windows installer crashes while rebooting https://sourceforge.net/tracker/index.php?func=detailaid=1877875group_ id=180599atid=893831 4. Timer of guest is inaccurate https://sourceforge.net/tracker/?func=detailatid=893831aid=1826080gro up_id=180599 5. Installer of 64bit vista guest will pause for ten minutes after reboot https://sourceforge.net/tracker/?func=detailatid=893831aid=1836905gro up_id=180599 6. Cannot boot 32bit smp RHEL5.1 guest with nic on 64bit host https://sourceforge.net/tracker/?func=detailatid=893831aid=1812043gro up_id=180599 Should be fixed now. Wait for your result tomorrow. :) 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 Report Summary on IA32-pae Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel 6 5 1 00 Restart 2 2 0 00 gtest 14 13 1 00 = control_panel 6 5 1 00 :KVM_LM_PAE_gPAE 1
Re: [kvm-devel] [PATCH] Using kzalloc to avoid allocating kvm_regs from kernel stack
Please use the new one. Add the check for failed allocation.
From: Xiantao Zhang [EMAIL PROTECTED]
Date: Mon, 25 Feb 2008 17:25:07 +0800
Subject: [PATCH] kvm: Using kzalloc to avoid allocating kvm_regs from
kernel stack.
Since the size of kvm_regs maybe too big to allocate from kernel stack,
here use kzalloc to allocate it.
Signed-off-by: Xiantao Zhang [EMAIL PROTECTED]
---
virt/kvm/kvm_main.c | 21 ++---
1 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index cf6df51..8d4326f 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -806,25 +806,32 @@ static long kvm_vcpu_ioctl(struct file *filp,
r = kvm_arch_vcpu_ioctl_run(vcpu, vcpu-run);
break;
case KVM_GET_REGS: {
- struct kvm_regs kvm_regs;
+ struct kvm_regs *kvm_regs;
- memset(kvm_regs, 0, sizeof kvm_regs);
- r = kvm_arch_vcpu_ioctl_get_regs(vcpu, kvm_regs);
+ r = -ENOMEM;
+ kvm_regs = kzalloc(sizeof(struct kvm_regs), GFP_KERNEL);
+ if (!kvm_regs)
+ goto out;
+ r = kvm_arch_vcpu_ioctl_get_regs(vcpu, kvm_regs);
if (r)
goto out;
r = -EFAULT;
- if (copy_to_user(argp, kvm_regs, sizeof kvm_regs))
+ if (copy_to_user(argp, kvm_regs, sizeof(struct
kvm_regs)))
goto out;
r = 0;
break;
}
case KVM_SET_REGS: {
- struct kvm_regs kvm_regs;
+ struct kvm_regs *kvm_regs;
+ r = -ENOMEM;
+ kvm_regs = kzalloc(sizeof(struct kvm_regs), GFP_KERNEL);
+ if (!kvm_regs)
+ goto out;
r = -EFAULT;
- if (copy_from_user(kvm_regs, argp, sizeof kvm_regs))
+ if (copy_from_user(kvm_regs, argp, sizeof(struct
kvm_regs)))
goto out;
- r = kvm_arch_vcpu_ioctl_set_regs(vcpu, kvm_regs);
+ r = kvm_arch_vcpu_ioctl_set_regs(vcpu, kvm_regs);
if (r)
goto out;
r = 0;
--
1.5.2
0001-kvm-Using-kzalloc-to-avoid-allocating-kvm_regs-from.patch
Description: 0001-kvm-Using-kzalloc-to-avoid-allocating-kvm_regs-from.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
Re: [kvm-devel] KVM Test result, kernel 81e4400.., userspace 08385e4.. , One new issue
Yang, Sheng wrote: On Monday 25 February 2008 16:41:25 Zhao, Yunfeng wrote: Hi, all, This is today's KVM test result against kvm.git 81e4400b4df4e597a81c19c1161aa03c73613710 and kvm-userspace.git 08385e49dcff3585f597870af67301d7659a1ecb. One new issue has been found in today's testing: 1. fc5/fc6/rhel5u1 no-acpi up guests can't boot on pae host https://sourceforge.net/tracker/index.php?func=detailaid=1901208group_ id=180599atid=893831 A quick bisect shows that the problem caused by kvm: qemu: fix host_cpuid() on x86_64. Yeah, I just found this out the hard way (by trying to debug this -- silly me). The effects were that the GenuineIntel in cpuid identification was corrupted. I'm reverting that patch. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - 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] Using kzalloc to avoid allocating kvm_regs from kernel stack
From: Xiantao Zhang [EMAIL PROTECTED]
Date: Mon, 25 Feb 2008 17:11:43 +0800
Subject: [PATCH] kvm: Using kzalloc to avoid allocating kvm_regs from
kernel stack.
Since the size of struct kvm_regs maybe too big to allocate from kernel
stack,
here use kzalloc to allocate it.
Signed-off-by: Xiantao Zhang [EMAIL PROTECTED]
---
virt/kvm/kvm_main.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index cf6df51..5348538 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -806,25 +806,26 @@ static long kvm_vcpu_ioctl(struct file *filp,
r = kvm_arch_vcpu_ioctl_run(vcpu, vcpu-run);
break;
case KVM_GET_REGS: {
- struct kvm_regs kvm_regs;
+ struct kvm_regs *kvm_regs;
- memset(kvm_regs, 0, sizeof kvm_regs);
- r = kvm_arch_vcpu_ioctl_get_regs(vcpu, kvm_regs);
+ kvm_regs = kzalloc(sizeof(struct kvm_regs), GFP_KERNEL);
+ r = kvm_arch_vcpu_ioctl_get_regs(vcpu, kvm_regs);
if (r)
goto out;
r = -EFAULT;
- if (copy_to_user(argp, kvm_regs, sizeof kvm_regs))
+ if (copy_to_user(argp, kvm_regs, sizeof(struct
kvm_regs)))
goto out;
r = 0;
break;
}
case KVM_SET_REGS: {
- struct kvm_regs kvm_regs;
+ struct kvm_regs *kvm_regs;
+ kvm_regs = kzalloc(sizeof(struct kvm_regs), GFP_KERNEL);
r = -EFAULT;
- if (copy_from_user(kvm_regs, argp, sizeof kvm_regs))
+ if (copy_from_user(kvm_regs, argp, sizeof(struct
kvm_regs)))
goto out;
- r = kvm_arch_vcpu_ioctl_set_regs(vcpu, kvm_regs);
+ r = kvm_arch_vcpu_ioctl_set_regs(vcpu, kvm_regs);
if (r)
goto out;
r = 0;
--
1.5.2
0001-kvm-Using-kzalloc-to-avoid-allocating-kvm_regs-from.patch
Description: 0001-kvm-Using-kzalloc-to-avoid-allocating-kvm_regs-from.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
Re: [kvm-devel] Status of FreeBSD 6.3 as a guest
Colin Paul Adams wrote: Avi == Avi Kivity [EMAIL PROTECTED] writes: Avi Colin Paul Adams wrote: This isn't mentioned on the guest status page. I went ahead and tried it anyway (32-bit). It works fine if I don't specify -smp 2. But qemu rejects -m 2048. -m 1024 is fine. I had over 3GB available memory (I presume all the memory is pae-fixed to avoid both host and guest paging - if I'm wrong, please explain) so I assumed this would be OK. Are you running on a 32-bit host? If so, try less memory (2047 might Avi work, or perhaps less). No - it's a 64-bit host with 8GB and a quad processor. Maybe the qemu binary is 32-bit? What does 'file /path/to/qemu-system-x86_64' say? What does qemu say to -m 2048? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - 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 Test result, kernel 81e4400.., userspace 08385e4.. , One new issue
Alexander Graf wrote: On Feb 25, 2008, at 10:34 AM, Avi Kivity wrote: Yang, Sheng wrote: On Monday 25 February 2008 16:41:25 Zhao, Yunfeng wrote: Hi, all, This is today's KVM test result against kvm.git 81e4400b4df4e597a81c19c1161aa03c73613710 and kvm-userspace.git 08385e49dcff3585f597870af67301d7659a1ecb. One new issue has been found in today's testing: 1. fc5/fc6/rhel5u1 no-acpi up guests can't boot on pae host https://sourceforge.net/tracker/index.php?func=detailaid=1901208group_ id=180599atid=893831 A quick bisect shows that the problem caused by kvm: qemu: fix host_cpuid() on x86_64. Yeah, I just found this out the hard way (by trying to debug this -- silly me). The effects were that the GenuineIntel in cpuid identification was corrupted. Could you please execute this source on a computer that fails with the argument 0 (please compile with the same switches as qemu) and give me the results + disassembly? 101c host_cpuid: 101c: 55 push %ebp 101d: 89 e5 mov%esp,%ebp 101f: 57 push %edi 1020: 56 push %esi 1021: 53 push %ebx 1022: 83 ec 3csub$0x3c,%esp 1025: 89 55 d4mov%edx,-0x2c(%ebp) 1028: 89 de mov%ebx,%esi 102a: 0f a2 cpuid 102c: 89 db mov%ebx,%ebx 102e: 89 f3 mov%esi,%ebx 1030: 89 d7 mov%edx,%edi 1032: 89 55 e4mov%edx,-0x1c(%ebp) 1035: 8b 55 d4mov-0x2c(%ebp),%edx 1038: 85 d2 test %edx,%edx 103a: 89 4d c4mov%ecx,-0x3c(%ebp) 103d: 89 5d d0mov%ebx,-0x30(%ebp) 1040: 89 45 d8mov%eax,-0x28(%ebp) 1043: 89 5d dcmov%ebx,-0x24(%ebp) 1046: 89 4d e0mov%ecx,-0x20(%ebp) 1049: 74 05 je 1050 host_cpuid+0x34 104b: 8b 55 d4mov-0x2c(%ebp),%edx 104e: 89 02 mov%eax,(%edx) 1050: 8b 75 08mov0x8(%ebp),%esi 1053: 85 f6 test %esi,%esi 1055: 74 08 je 105f host_cpuid+0x43 1057: 8b 5d d0mov-0x30(%ebp),%ebx 105a: 8b 4d 08mov0x8(%ebp),%ecx 105d: 89 19 mov%ebx,(%ecx) 105f: 8b 5d 0cmov0xc(%ebp),%ebx 1062: 85 db test %ebx,%ebx 1064: 74 08 je 106e host_cpuid+0x52 1066: 8b 55 c4mov-0x3c(%ebp),%edx 1069: 8b 45 0cmov0xc(%ebp),%eax 106c: 89 10 mov%edx,(%eax) 106e: 8b 4d 10mov0x10(%ebp),%ecx 1071: 85 c9 test %ecx,%ecx 1073: 74 05 je 107a host_cpuid+0x5e 1075: 8b 4d 10mov0x10(%ebp),%ecx 1078: 89 39 mov%edi,(%ecx) 107a: 83 c4 3cadd$0x3c,%esp 107d: 5b pop%ebx 107e: 5e pop%esi 107f: 5f pop%edi 1080: c9 leave 1081: c3 ret Looks like %ebx was chosen for %1. I also don't see where %eax is loaded. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - 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 Test result, kernel 81e4400.., userspace 08385e4.. , One new issue
On Feb 25, 2008, at 10:34 AM, Avi Kivity wrote: Yang, Sheng wrote: On Monday 25 February 2008 16:41:25 Zhao, Yunfeng wrote: Hi, all, This is today's KVM test result against kvm.git 81e4400b4df4e597a81c19c1161aa03c73613710 and kvm-userspace.git 08385e49dcff3585f597870af67301d7659a1ecb. One new issue has been found in today's testing: 1. fc5/fc6/rhel5u1 no-acpi up guests can't boot on pae host https://sourceforge.net/tracker/index.php?func=detailaid=1901208group_ id=180599atid=893831 A quick bisect shows that the problem caused by kvm: qemu: fix host_cpuid() on x86_64. Yeah, I just found this out the hard way (by trying to debug this -- silly me). The effects were that the GenuineIntel in cpuid identification was corrupted. Could you please execute this source on a computer that fails with the argument 0 (please compile with the same switches as qemu) and give me the results + disassembly? I'm reverting that patch. test.c Description: Binary data - 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] gfxboot disable
you may try disable gfxboot by quickly pressing Shift key when you start your guest OS. (very quickly) On 2/23/08, Anthony Liguori [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: I looked for a gz o bz archive. Is there a tarball with gfxboot disable program (URL)? I'm not sure I understand your question but the only way to get gfxboot-disable today is through mercurial. Regards, Anthony Liguori Thanks. L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail http://us.rd.yahoo.com/mail/it/taglines/hotmail/nowyoucan/nextgen/*http://it.docs.yahoo.com/nowyoucan.html - 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 - 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] KVM: release bad page on MSR_KVM_SYSTEM_TIME
Subject says it all.
Signed-off-by: Marcelo Tosatti [EMAIL PROTECTED]
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index e1aa6c9..ff7ef12 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -595,8 +595,10 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64
data)
gfn_to_page(vcpu-kvm, data PAGE_SHIFT);
up_read(current-mm-mmap_sem);
- if (is_error_page(vcpu-arch.time_page))
+ if (is_error_page(vcpu-arch.time_page)) {
+ kvm_release_page_clean(vcpu-arch.time_page);
vcpu-arch.time_page = NULL;
+ }
kvm_write_guest_time(vcpu);
break;
-
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 4/15] mark processors as presents
Avi Kivity wrote:
Glauber Costa wrote:
mark processors as present through the _STA method
Signed-off-by: Glauber Costa [EMAIL PROTECTED]
---
bios/acpi-dsdt.dsl | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
index e900795..cd42e23 100755
--- a/bios/acpi-dsdt.dsl
+++ b/bios/acpi-dsdt.dsl
@@ -25,9 +25,28 @@ DefinitionBlock (
0x1 // OEM Revision
)
{
+ Scope (\_PR)
+ {
+Processor (CPU0, 0x00, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPU1, 0x01, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPU2, 0x02, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPU3, 0x03, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPU4, 0x04, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPU5, 0x05, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPU6, 0x06, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPU7, 0x07, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPU8, 0x08, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPU9, 0x09, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPUA, 0x0a, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPUB, 0x0b, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPUC, 0x0c, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPUD, 0x0d, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+Processor (CPUE, 0x0e, 0xb010, 0x06) {Method (_STA) {
Return(0x1)}}
+}
There is now code in rombios32.c to do this. It needs to be removed.
See acpi_build_processor_ssdt().
Building the table by hand is trivial in the case where the processors
are just _listed_, and can be easily justified. This first patch just
add the _STA method, but other follows, which turns the processor block
into a quite complicated thing. Not to mention the operational region,
the notifications that have to refer to the processor objects, etc.
So I can't see any valid justification for using the code in
rombios32.c, instead of a high level language such as the one provided
by acpi.
-
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 4/15] mark processors as presents
Glauber Costa wrote: There is now code in rombios32.c to do this. It needs to be removed. See acpi_build_processor_ssdt(). Building the table by hand is trivial in the case where the processors are just _listed_, and can be easily justified. This first patch just add the _STA method, but other follows, which turns the processor block into a quite complicated thing. Not to mention the operational region, the notifications that have to refer to the processor objects, etc. So I can't see any valid justification for using the code in rombios32.c, instead of a high level language such as the one provided by acpi. I meant, remove the code in rombios32.c. Sorry about the confusion. -- 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 4/15] mark processors as presents
Avi Kivity wrote: Glauber Costa wrote: There is now code in rombios32.c to do this. It needs to be removed. See acpi_build_processor_ssdt(). Building the table by hand is trivial in the case where the processors are just _listed_, and can be easily justified. This first patch just add the _STA method, but other follows, which turns the processor block into a quite complicated thing. Not to mention the operational region, the notifications that have to refer to the processor objects, etc. So I can't see any valid justification for using the code in rombios32.c, instead of a high level language such as the one provided by acpi. I meant, remove the code in rombios32.c. Sorry about the confusion. Oh, so that's 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] still seeing network freezes with rtl8139 nic
Avi Kivity wrote: david ahern wrote: I've run a lot more tests: - if I remove the if (!change) return optimization from pci_set_irq the rtl8139 nic worked fine for 16+ hours. I'm not recommending this as a fix, just confirming that the problem goes away. Interesting. What can cause this to happen? - some non-pci device shares the same irq (unlikely) - the pci link sharing is broken. Is the eth0 irq shared? interrupt is not shared. Please post /proc/interrupts. # cat /proc/interrupts CPU0 CPU1 0: 10566 46468IO-APIC-edge timer 1: 5 5IO-APIC-edge i8042 8: 0 1IO-APIC-edge rtc 9: 0 0 IO-APIC-level acpi 11: 243118 5656 IO-APIC-level eth0 12:180 45IO-APIC-edge i8042 14: 2021 12592IO-APIC-edge ide0 15: 14 10IO-APIC-edge ide1 NMI: 0 0 LOC: 56947 56946 ERR: 0 MIS: 31 - the in-kernel ioapic is buggy and needs the extra kicking the optimization prevents. Can be checked by re-adding the optimization to kvm_ioapic_set_irq() (keeping it removed in qemu). If it works, the problem is in userspace. If it fails, the problem is in the kernel. Something like static int old_level[16]; if (level == old_level[irq]) return; old_level[irq] = level; I'll give this a shot and let you know. If you are interested, here's some more info on the -no-kvm-irqchip option: qemu ends up spinning with 1 thread consuming 100% cpu. Output from top (literally the top 11 lines) with 'show threads' and individual cpu stats: Tasks: 125 total, 2 running, 123 sleeping, 0 stopped, 0 zombie Cpu0 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 1.0%us, 0.0%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 4046804k total, 4013480k used,33324k free,42512k buffers Swap: 2096472k total, 120k used, 2096352k free, 1159892k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 4441 root 20 0 2675m 2.5g 9808 R 100 65.0 499:34.09 qemu-system-x86 4426 root 20 0 2675m 2.5g 9808 S1 65.0 16:24.50 qemu-system-x86 ... Hooking up gdb shows it cycling with the following backtrace: (gdb) bt #0 0x2ad97b5ee3e8 in do_sigtimedwait () from /lib64/libc.so.6 #1 0x2ad97b5ee4ae in sigtimedwait () from /lib64/libc.so.6 #2 0x004fb7df in kvm_eat_signal (env=0x2ade460, timeout=10) at /opt/kvm/kvm-61/qemu/qemu-kvm.c:156 #3 0x004fb9e4 in kvm_eat_signals (env=0x2ade460, timeout=10) at /opt/kvm/kvm-61/qemu/qemu-kvm.c:192 #4 0x004fba49 in kvm_main_loop_wait (env=0x2ade460, timeout=10) at /opt/kvm/kvm-61/qemu/qemu-kvm.c:211 #5 0x004fc278 in kvm_main_loop_cpu (env=0x2ade460) at /opt/kvm/kvm-61/qemu/qemu-kvm.c:299 #6 0x0040ff2d in main (argc=value optimized out, argv=0x7fff304607b8) at /opt/kvm/kvm-61/qemu/vl.c:7856 I have a dump of CPUX86State *env if you want to see it. david - 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] Using kzalloc to avoid allocating kvm_regs from kernel stack
On Mon, 2008-02-25 at 10:38 -0600, Hollis Blanchard wrote: On Mon, 2008-02-25 at 17:34 +0800, Zhang, Xiantao wrote: From: Xiantao Zhang [EMAIL PROTECTED] Date: Mon, 25 Feb 2008 17:11:43 +0800 Subject: [PATCH] kvm: Using kzalloc to avoid allocating kvm_regs from kernel stack. Since the size of struct kvm_regs maybe too big to allocate from kernel stack, here use kzalloc to allocate it. Where is this freed? Never mind; I see it now in rev #3. :) -- Hollis Blanchard IBM Linux Technology Center - 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] still seeing network freezes with rtl8139 nic
david ahern wrote: Avi Kivity wrote: - the in-kernel ioapic is buggy and needs the extra kicking the optimization prevents. Can be checked by re-adding the optimization to kvm_ioapic_set_irq() (keeping it removed in qemu). If it works, the problem is in userspace. If it fails, the problem is in the kernel. Something like static int old_level[16]; if (level == old_level[irq]) return; old_level[irq] = level; With the if (!change) return; taken out of pci_set_irq() and the above code added to kvm_ioapic_set_irq() networking froze. david - 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] Using kzalloc to avoid allocating kvm_regs from kernel stack
On Mon, 2008-02-25 at 17:34 +0800, Zhang, Xiantao wrote:
From: Xiantao Zhang [EMAIL PROTECTED]
Date: Mon, 25 Feb 2008 17:11:43 +0800
Subject: [PATCH] kvm: Using kzalloc to avoid allocating kvm_regs from
kernel stack.
Since the size of struct kvm_regs maybe too big to allocate from kernel
stack,
here use kzalloc to allocate it.
Signed-off-by: Xiantao Zhang [EMAIL PROTECTED]
---
virt/kvm/kvm_main.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index cf6df51..5348538 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -806,25 +806,26 @@ static long kvm_vcpu_ioctl(struct file *filp,
r = kvm_arch_vcpu_ioctl_run(vcpu, vcpu-run);
break;
case KVM_GET_REGS: {
- struct kvm_regs kvm_regs;
+ struct kvm_regs *kvm_regs;
- memset(kvm_regs, 0, sizeof kvm_regs);
- r = kvm_arch_vcpu_ioctl_get_regs(vcpu, kvm_regs);
+ kvm_regs = kzalloc(sizeof(struct kvm_regs), GFP_KERNEL);
+ r = kvm_arch_vcpu_ioctl_get_regs(vcpu, kvm_regs);
if (r)
goto out;
r = -EFAULT;
- if (copy_to_user(argp, kvm_regs, sizeof kvm_regs))
+ if (copy_to_user(argp, kvm_regs, sizeof(struct
kvm_regs)))
goto out;
r = 0;
break;
}
case KVM_SET_REGS: {
- struct kvm_regs kvm_regs;
+ struct kvm_regs *kvm_regs;
+ kvm_regs = kzalloc(sizeof(struct kvm_regs), GFP_KERNEL);
r = -EFAULT;
- if (copy_from_user(kvm_regs, argp, sizeof kvm_regs))
+ if (copy_from_user(kvm_regs, argp, sizeof(struct
kvm_regs)))
goto out;
- r = kvm_arch_vcpu_ioctl_set_regs(vcpu, kvm_regs);
+ r = kvm_arch_vcpu_ioctl_set_regs(vcpu, kvm_regs);
if (r)
goto out;
r = 0;
Where is this freed?
--
Hollis Blanchard
IBM Linux Technology Center
-
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-ia64-devel] [PATCH] Using kzalloc to avoid allocatingkvm_regs from kernel stack
Zhang, Xiantao wrote: Updated one. Sorry for inconvenience. 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
Re: [kvm-devel] [PATCH] KVM: release bad page on MSR_KVM_SYSTEM_TIME
Marcelo Tosatti wrote: Subject says it all. 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
Re: [kvm-devel] KVM Test result, kernel 81e4400.., userspace 08385e4.. , One new issue
Alexander Graf wrote: The ebx store was done because of PIC code, which does not allow ebx to get clobbered. If we are not in PIC code, =r contains ebx as GPR though, so the assumption that ebx needs to be restored was wrong then. This new version only enables the store/restore code if i386 and PIC code are used. There is no need to distinguish between x86_64 and i386 for the other cases. So does this version work? It probably will, but it seems fragile to depend on the details of PIC. I committed something more generic: #ifdef __x86_64__ asm volatile(cpuid : =a(vec[0]), =b(vec[1]), =c(vec[2]), =d(vec[3]) : 0(function) : cc); #else asm volatile(pusha \n\t cpuid \n\t mov %%eax, 0(%1) \n\t mov %%ebx, 4(%1) \n\t mov %%ecx, 8(%1) \n\t mov %%edx, 12(%1) \n\t popa : a(function), S(vec) : memory, cc); #endif -- 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] still seeing network freezes with rtl8139 nic
david ahern wrote: david ahern wrote: Avi Kivity wrote: - the in-kernel ioapic is buggy and needs the extra kicking the optimization prevents. Can be checked by re-adding the optimization to kvm_ioapic_set_irq() (keeping it removed in qemu). If it works, the problem is in userspace. If it fails, the problem is in the kernel. Something like static int old_level[16]; if (level == old_level[irq]) return; old_level[irq] = level; With the if (!change) return; taken out of pci_set_irq() and the above code added to kvm_ioapic_set_irq() networking froze. That points the finger at the kernel ioapic. I saw from the /proc/interrupts dump that it's an smp guest. Does it freeze on uniprocessor as well? Maybe it's bad locking in the kernel. -- 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] The SMP RHEL 5.1 PAE guest can't boot up issue
Avi Kivity wrote: Farkas Levente wrote: will be a new release in the near future? since many of us waiting for this bug to be fixed on quad and other multi core cpus. Certainly. Can you try out the attached patch? thanks. it works!:-))) we've been waiting for this in the last half year! thanks again. -- Levente Si vis pacem para bellum! - 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
Farkas Levente wrote: Avi Kivity wrote: Farkas Levente wrote: will be a new release in the near future? since many of us waiting for this bug to be fixed on quad and other multi core cpus. Certainly. Can you try out the attached patch? thanks. it works!:-))) we've been waiting for this in the last half year! thanks again. Well, it was a tough one. The credit belongs to Sheng Yang for figuring it out. The patch was easy once the problem was understood. -- 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 Test result, kernel 81e4400.., userspace 08385e4.. , One new issue
On Feb 25, 2008, at 6:40 PM, Avi Kivity wrote: Alexander Graf wrote: The ebx store was done because of PIC code, which does not allow ebx to get clobbered. If we are not in PIC code, =r contains ebx as GPR though, so the assumption that ebx needs to be restored was wrong then. This new version only enables the store/restore code if i386 and PIC code are used. There is no need to distinguish between x86_64 and i386 for the other cases. So does this version work? It probably will, but it seems fragile to depend on the details of PIC. I committed something more generic: #ifdef __x86_64__ asm volatile(cpuid : =a(vec[0]), =b(vec[1]), =c(vec[2]), =d(vec[3]) : 0(function) : cc); This code works fine for all targets, including i386. With PIC enabled, gcc registers the ebx registers and complains about this, thus errors out. This is the only special case I am aware of, so I doubt we should treat any case different from the normal case but the PIC one. #else asm volatile(pusha \n\t cpuid \n\t mov %%eax, 0(%1) \n\t mov %%ebx, 4(%1) \n\t mov %%ecx, 8(%1) \n\t mov %%edx, 12(%1) \n\t popa : a(function), S(vec) : memory, cc); #endif Basically #ifdef __x86_64__ is even wrong, as the problem is not that too many registers are being used, but that ebx is reserved and can't be saved/restored automatically. Furthermore I believe that the less assembler is used, the better the code looks. So for cases the snippet above is not required, why use it? Overusing assembler is imho exactly the reason the previous code broke. There's one more thing I'd like to add here. Gcc optimizes really well when one lets it to. So for this exact case with -O2 used, there are no memory accesses. The vector is simply stored in 4 registers and thus no more movs are required. Alex - 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 Kivity wrote: Farkas Levente wrote: Avi Kivity wrote: Farkas Levente wrote: will be a new release in the near future? since many of us waiting for this bug to be fixed on quad and other multi core cpus. Certainly. Can you try out the attached patch? thanks. it works!:-))) we've been waiting for this in the last half year! thanks again. Well, it was a tough one. The credit belongs to Sheng Yang for figuring it out. The patch was easy once the problem was understood. this patch alone deserve a new release. -- Levente Si vis pacem para bellum! - 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] voyager/KVM build problem
I could have sworn that we had patches that made KVM depend on !VOYAGER and !VISWS, but with 2.6.25-rc3 and linux-next, it's possible to select VOYAGER machine type (x86_32) and then enable KVM and watch the build fail. ERROR: smp_ops [arch/x86/kvm/kvm.ko] undefined! make[1]: *** [__modpost] Error 1 --- ~Randy - 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-60: kexec in guest crashes the host
On Wed, Feb 20, 2008 at 12:48:39PM +0200, Dan Aloni wrote: On Wed, Feb 20, 2008 at 11:09:44AM +0200, Avi Kivity wrote: Dan Aloni wrote: It happens at 100% of the times I invoke kexec. Can you provide a commandline which triggers this? I'm completely ignorant wrt kexec. I managed to verify that this problem can be reproduced with the 2.6.16.60 tree. Also, it's worth to note that with '-no-kvm' the kexec procedure works successfully and the second kernel executes. It still happens with kvm d602a5d8d74980a3c0b097c35c04036a04286018 and kvm-userspace 4eeb4e8cdaf0fefc4e9fdf628ddb786dc342fe8b. -- Dan Aloni XIV, an IBM (R) company. http://www.xivstorage.com da-x (at) monatomic.org, dan (at) xiv.co.il - 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 Test result, kernel 81e4400.., userspace 08385e4.. , One new issue
Alexander Graf wrote: On Feb 25, 2008, at 6:40 PM, Avi Kivity wrote: Alexander Graf wrote: The ebx store was done because of PIC code, which does not allow ebx to get clobbered. If we are not in PIC code, =r contains ebx as GPR though, so the assumption that ebx needs to be restored was wrong then. This new version only enables the store/restore code if i386 and PIC code are used. There is no need to distinguish between x86_64 and i386 for the other cases. So does this version work? It probably will, but it seems fragile to depend on the details of PIC. I committed something more generic: #ifdef __x86_64__ asm volatile(cpuid : =a(vec[0]), =b(vec[1]), =c(vec[2]), =d(vec[3]) : 0(function) : cc); This code works fine for all targets, including i386. With PIC enabled, gcc registers the ebx registers and complains about this, thus errors out. This is the only special case I am aware of, so I doubt we should treat any case different from the normal case but the PIC one. #else asm volatile(pusha \n\t cpuid \n\t mov %%eax, 0(%1) \n\t mov %%ebx, 4(%1) \n\t mov %%ecx, 8(%1) \n\t mov %%edx, 12(%1) \n\t popa : a(function), S(vec) : memory, cc); #endif Basically #ifdef __x86_64__ is even wrong, as the problem is not that too many registers are being used, but that ebx is reserved and can't be saved/restored automatically. Furthermore I believe that the less assembler is used, the better the code looks. So for cases the snippet above is not required, why use it? Overusing assembler is imho exactly the reason the previous code broke. I agree with all of this, but I think this case is an exception. gcc doesn't behave well with many register constraints on i386 and the PIC case shows things are not straightforward. I want something I can forget about. There's one more thing I'd like to add here. Gcc optimizes really well when one lets it to. So for this exact case with -O2 used, there are no memory accesses. The vector is simply stored in 4 registers and thus no more movs are required. Again I agree, but host_cpuid() is hardly an optimization target. you can add a usleep(1) there with no noticable effect. btw the cpuid instruction execution time itself will likely overwhelm any instructions around it (since it is microcoded). -- Any sufficiently difficult bug is indistinguishable from a feature. - 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] Windows XP activation regression in KVM-60
Hi, Original bug was submitted at http://bugs.debian.org/467043. The summary is that installs of Windows XP from pre-kvm-60 (pre-59?), then upgrading to kvm-60 or 61 causes Windows to trigger activation due to computer changed too much. Downgrading to kvm-58 or previous resolves the issue. Haven't tested kvm-59 yet. The kernel module is not part of the problem. Using kvm-60 kernel modules with kvm-58 user part works. CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ I'm not quite sure what these changes can be, but is it possible revert any changes that are causing this? - Adam - 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] kvm: qemu: don't die if switching to fullscreen mode fails
hi,
the attached patch fixes some glitches when switching to fullscreen mode
using ctrl+alt+f or when booting using -full-screen.
up to now the VM simply dies if one of the following situations occur:
* user switches from windowed to fullscreen mode using a resolution
which is too high (meaning higher than the maximum resolution of the
display)
* guest boots in fullscreen mode using a resolution which is too high
* guest is in fullscreen mode and the user switches to a resolution
which is too high
IMO this is not what the normal user would expect.
This patch changes the behaviour as follows:
* deny switching to fullscreen mode if the resolution is too high and
print a message to the console
* use windowed mode as fallback option if we are already in
fullscreen mode and the new resolution is too high and print a message
to the console
Signed-off-by: Andreas Winkelbauer [EMAIL PROTECTED]
--- kvm-61.orig/qemu/sdl.c 2008-02-19 15:58:28.0 +0100
+++ kvm-61/qemu/sdl.c 2008-02-25 21:04:28.0 +0100
@@ -56,46 +56,60 @@ static void sdl_update(DisplayState *ds,
SDL_UpdateRect(screen, x, y, w, h);
}
-static void sdl_resize(DisplayState *ds, int w, int h)
+static int sdl_resize2(DisplayState *ds, int w, int h, int full_screen, int no_frame)
{
+SDL_Surface *screen_tmp;
int flags;
-//printf(resizing to %d %d\n, w, h);
+//printf(trying to resize from w=%d h=%d %s to w=%d h=%d %s\n, width, height, gui_fullscreen ? fullscreen : windowed, w, h, full_screen ? fullscreen : windowed);
flags = SDL_HWSURFACE|SDL_ASYNCBLIT|SDL_HWACCEL;
-if (gui_fullscreen)
+if (full_screen)
flags |= SDL_FULLSCREEN;
-if (gui_noframe)
+if (no_frame)
flags |= SDL_NOFRAME;
-width = w;
-height = h;
-
- again:
-screen = SDL_SetVideoMode(w, h, 0, flags);
-if (!screen) {
-fprintf(stderr, Could not open SDL display\n);
-exit(1);
-}
-if (!screen-pixels (flags SDL_HWSURFACE) (flags SDL_FULLSCREEN)) {
-flags = ~SDL_HWSURFACE;
-goto again;
+if (!(screen_tmp = SDL_SetVideoMode(w, h, 0, flags))) {
+//fprintf(stderr, Could not open SDL display (try #1)\n);
+return -1;
+} else if (!screen_tmp-pixels (flags SDL_HWSURFACE) (flags SDL_FULLSCREEN)) {
+screen_tmp = SDL_SetVideoMode(w, h, 0, flags ~SDL_HWSURFACE);
}
-if (!screen-pixels) {
-fprintf(stderr, Could not open SDL display\n);
-exit(1);
-}
-ds-data = screen-pixels;
-ds-linesize = screen-pitch;
-ds-depth = screen-format-BitsPerPixel;
-if (ds-depth == 32 screen-format-Rshift == 0) {
-ds-bgr = 1;
+if (!screen_tmp || !screen_tmp-pixels) {
+//fprintf(stderr, Could not open SDL display (try #2)\n);
+return -1;
} else {
-ds-bgr = 0;
+screen = screen_tmp;
+gui_fullscreen = full_screen;
+gui_noframe = no_frame;
+
+ds-data = screen-pixels;
+ds-linesize = screen-pitch;
+ds-depth = screen-format-BitsPerPixel;
+if (ds-depth == 32 screen-format-Rshift == 0) {
+ds-bgr = 1;
+} else {
+ds-bgr = 0;
+}
+ds-width = width = w;
+ds-height = height = h;
+}
+}
+
+static void sdl_resize(DisplayState *ds, int w, int h)
+{
+if (sdl_resize2(ds, w, h, gui_fullscreen, gui_noframe) == -1) {
+fprintf(stderr, Could not resize display to %d x %d (%s)\n,
+ w, h, gui_fullscreen ? fullscreen : windowed);
+
+/* if we are in fullscreen mode use windowed mode as fallback */
+if (!gui_fullscreen || sdl_resize2(ds, w, h, 0, gui_noframe) == -1) {
+exit(1);
+} else {
+fprintf(stderr, Using windowed mode as fallback\n);
+}
}
-ds-width = w;
-ds-height = h;
}
/* generic keyboard conversion */
@@ -332,17 +346,21 @@ static void sdl_send_mouse_event(int dz)
static void toggle_full_screen(DisplayState *ds)
{
-gui_fullscreen = !gui_fullscreen;
-sdl_resize(ds, screen-w, screen-h);
-if (gui_fullscreen) {
-gui_saved_grab = gui_grab;
-sdl_grab_start();
-} else {
-if (!gui_saved_grab)
-sdl_grab_end();
+if (sdl_resize2(ds, screen-w, screen-h, !gui_fullscreen, gui_noframe) != -1) {
+if (gui_fullscreen) {
+gui_saved_grab = gui_grab;
+sdl_grab_start();
+} else {
+if (!gui_saved_grab)
+sdl_grab_end();
+}
+vga_hw_invalidate();
+vga_hw_update();
+}
+else {
+fprintf(stderr, Could not switch to %s mode\n,
+ !gui_fullscreen ? fullscreen : windowed);
}
-vga_hw_invalidate();
-vga_hw_update();
}
static void sdl_refresh(DisplayState *ds)
@@ -605,14 +623,14 @@ void sdl_display_init(DisplayState *ds,
exit(1);
}
-if (no_frame)
-gui_noframe = 1;
-
Re: [kvm-devel] howto set up a virtual firewall?
Kurt Neufeld kneufeld at burgundywall.com writes: It turns out I did have everything correctly configured but it still doesn't work. The problem is that I cannot get a DHCP address on my vm. Almost correctly. Some general questions, should br0 be up or down? What should my vm MAC be? The same as my physical card (peth) which is also the same as the bridge (br0)? The vnet0 does not match. (output later) br0 needs to be up. peth0 should have a different mac address. Found out this breakthrough on a Xen page: http://wiki.xensource.com/xenwiki/XenNetworking So I got it working and life is now good. Here's my rc.local script (which will probably change slightly as I refine what I'm trying accomplish). rc.local: ifdown br0 ip link set peth0 down ip link set peth0 address 00:ff:ff:ff:ff:00 arp off ifup peth0 sleep 1 ifup br0# but with no ip address, new mac address route add default gw 192.168.5.254 iptables -P FORWARD DROP iptables -A FORWARD -m physdev --physdev-is-bridged -j ACCEPT service libvirtd start :: ifcfg-br0 :: DEVICE=br0 BOOTPROTO=none ONBOOT=yes TYPE=bridge MACADDR=fe:ff:ff:ff:ff:00 # doesn't work unfortunately :: ifcfg-peth0 :: # 3Com Corporation 3c900B-TPO Etherlink XL [Cyclone] DEVICE=peth0 HWADDR=00:50:04:7F:B5:A3 ONBOOT=yes BRIDGE=br0 So over the weekend I got a virtual smoothwall firewall up and running and also a virtual CentOS 5 mail and http server. I can now upgrade my desktop with virtual impunity. Thanks team. Kurt - 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-Bugs-1900829 ] KVM crashes with AMD NPT
On Sun, Feb 24, 2008 at 04:40:09AM -0800, SourceForge.net wrote: Bugs item #1900829, was opened at 2008-02-24 14:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1900829group_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: Technologov (technologov) Assigned to: Nobody/Anonymous (nobody) Summary: KVM crashes with AMD NPT Initial Comment: KVM-61 guest crashes, when NPT=on, and when VM is accessed via VNC. It is 100% reproducible. Loading kvm-amd module without NPT, works fine. like: # modprobe kvm-amd npt=0 Host: AMD Barcelona, F7/x64, KVM-61. Guest: Debian 4/x86. The Command sent to Qemu/KVM: /usr/local/bin/qemu-system-x86_64 -hda /vm/debian4 -test32.qcow2 -m 256 -monitor tcp:localhost:4517,server,nowait -cdrom /isos/linu x/debian-40r0-i386-DVD-1.iso -boot d -name Debian4 -vnc :10 == *** glibc detected *** /usr/local/bin/qemu-system-x86_64: realloc(): invalid old size: 0x2aaabbde1010 *** === Backtrace: = /lib64/libc.so.6[0x3dd0271fbb] /lib64/libc.so.6(realloc+0x124)[0x3dd0273d94] /usr/local/bin/qemu-system-x86_64[0x471c02] /usr/local/bin/qemu-system-x86_64[0x47229b] /usr/local/bin/qemu-system-x86_64[0x471583] /usr/local/bin/qemu-system-x86_64[0x40de98] /usr/local/bin/qemu-system-x86_64[0x4fd81d] /usr/local/bin/qemu-system-x86_64[0x4fd859] /usr/local/bin/qemu-system-x86_64[0x4fe0a6] /usr/local/bin/qemu-system-x86_64[0x410e3d] /lib64/libc.so.6(__libc_start_main+0xf4)[0x3dd021daa4] /usr/local/bin/qemu-system-x86_64[0x406219] === Memory map: 0040-0057f000 r-xp fd:00 1952887 /usr/lo cal/bin/qemu-system-x86_64 0077e000-007b2000 rw-p 0017e000 fd:00 1952887 /usr/lo cal/bin/qemu-system-x86_64 007b2000-01a85000 rw-p 007b2000 00:00 0 01a85000-02a86000 rwxp 01a85000 00:00 0 02a86000-02e12000 rw-p 02a86000 00:00 0 [heap] Alexey, Running the test with MMU_DEBUG defined in arch/x86/kvm/mmu.c can probably shed some light into the issue. - 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] build #365 issue for v2.6.25-rc2-342-g5d9c4a7 in ./arch/x86/kvm/kvm.ko
On Wed, 20 Feb 2008 09:20:08 -0800 Randy Dunlap wrote: On Wed, 20 Feb 2008 16:07:03 +0200 Avi Kivity wrote: Looks like KVM conflicts with CONFIG_VOYAGER... Attached patch should fix. Subject: x86: disable KVM on Voyager Most classic Pentiums don't have hardware virtualization extension, and building kvm with voyager generates spurious failures. Signed-off-by: Avi Kivity [EMAIL PROTECTED] Might as well extend it for VISWS NUMAQ: Can we get this merged soon-ish? --- From: Avi Kivity [EMAIL PROTECTED] Most classic Pentiums don't have hardware virtualization extension, and building kvm with Voyager, Visual Workstation, or NUMAQ generates spurious failures. Signed-off-by: Avi Kivity [EMAIL PROTECTED] Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- arch/x86/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.25-rc2-git4.orig/arch/x86/Kconfig +++ linux-2.6.25-rc2-git4/arch/x86/Kconfig @@ -21,7 +21,7 @@ config X86 select HAVE_IDE select HAVE_OPROFILE select HAVE_KPROBES - select HAVE_KVM + select HAVE_KVM if ((X86_32 !X86_VOYAGER !X86_VISWS !X86_NUMAQ) || X86_64) config GENERIC_LOCKBREAK -- --- ~Randy - 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 support for virtio balloon driver
On Mon, 2008-02-25 at 13:47 -0600, Anthony Liguori wrote: This patch adds support to QEMU for Rusty's recently introduce virtio balloon driver. The user-facing portions of this are the introduction of a balloon and info balloon command in the monitor. The patch looks good. Might be a good idea to split it into 2 (balloon vs s-vdev.get_config patch. Right now madvise() is commented out since it causes host panics. Ballooning is still functional though--the host just doesn't reclaim the memory immediately. Since the mmu notifiers are not merged into 2.6.25 even, we need a temporary solution for it. There are two+ options: 1. Use the ksm (shared pages) scan and zero ballooned pages. This way the memory will be quickly picked up by the kernel. 2. Add in-kernel atomic ioctl for zapping the mmu + madvise 2+. Some sort of mmu notifiers backport (hard and hacky). IMHO 2 is the best option. btw: Izik's ksm module enable running 50 1G xp guests over a 16G host even without the ballooning running! - 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
I don't know if the patch was still needed now, since it was posted long ago(I don't know which issue it solved). I'd like to post a revert patch if necessary. I believe the patch is still necessary, since we still need to guarantee that a vcpu's tsc is monotonous. I think there are three issues to be addressed: 1. The majority of intel machines don't need the offset adjustment since they already have a constant rate tsc that is synchronized on all cpus. I think this is indicated by X86_FEATURE_CONSTANT_TSC (though I'm not 100% certain if it means that the rate is the same for all cpus, Thomas can you clarify?) So why not make the TSC_OFFSET adjustment conditional? The original patch doesn't bring any benefit for those platforms with CONSTANT TSC, especially if it is majority, while the accumurated difference due to the patch will be very big which makes guest timer worse. This will improve tsc quality for those machines, but we can't depend on it, since some machines don't have constant tsc. Further, I don't think really large machines can have constant tsc since clock distribution becomes difficult or impossible. For NUMA machines, this is an issue, but depend on how you support NUMA. One way is to bind VCPUs of a guest to same node if guest is not NUMA, if this is the model, then we don't have issue. I think Xen is planning in this way and it is same for KVM. 2. We should implement round robin and lowest priority like qemu does. Xen does the same thing: /* HACK: Route IRQ0 only to VCPU0 to prevent time jumps. */ #define IRQ0_SPECIAL_ROUTING 1 in arch/x86/hvm/vioapic.c, at least for irq 0. We did same thing in Xen long time ago to avoid this issue. It helps but not perfect. 3. The extra migrations on vcpu 0 are likely due to its role servicing I/O on behalf of the entire virtual machine. We should move this extra work to an independent thread. I have done some work in this area. It is becoming more important as kvm becomes more scalable. - 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] still seeing network freezes with rtl8139 nic
Almost 7 hours and the uniprocessor case is still chugging along. david Avi Kivity wrote: david ahern wrote: david ahern wrote: Avi Kivity wrote: - the in-kernel ioapic is buggy and needs the extra kicking the optimization prevents. Can be checked by re-adding the optimization to kvm_ioapic_set_irq() (keeping it removed in qemu). If it works, the problem is in userspace. If it fails, the problem is in the kernel. Something like static int old_level[16]; if (level == old_level[irq]) return; old_level[irq] = level; With the if (!change) return; taken out of pci_set_irq() and the above code added to kvm_ioapic_set_irq() networking froze. That points the finger at the kernel ioapic. I saw from the /proc/interrupts dump that it's an smp guest. Does it freeze on uniprocessor as well? Maybe it's bad locking in the kernel. - 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 5/6] mmu_notifier: Support for drivers with revers maps (f.e. for XPmem)
On Thursday 21 February 2008 21:58, Robin Holt wrote: On Thu, Feb 21, 2008 at 03:20:02PM +1100, Nick Piggin wrote: So why can't you export a device from your xpmem driver, which can be mmap()ed to give out anonymous memory pages to be used for these communication buffers? Because we need to have heap and stack available as well. MPT does not control all the communication buffer areas. I haven't checked, but this is the same problem that IB will have. I believe they are actually allowing any memory region be accessible, but I am not sure of that. Then you should create a driver that the user program can register and unregister regions of their memory with. The driver can do a get_user_pages to get the pages, and then you'd just need to set up some kind of mapping so that userspace can unmap pages / won't leak memory (and an exit_mm notifier I guess). OK. You need to explain this better to me. How would this driver supposedly work? What we have is an MPI library. It gets invoked at process load time to establish its rank-to-rank communication regions. It then turns control over to the processes main(). That is allowed to run until it hits the MPI_Init(argc, argv); The process is then totally under the users control until: MPI_Send(intmessage, m_size, MPI_INT, my_rank+half, tag, MPI_COMM_WORLD); MPI_Recv(intmessage, m_size, MPI_INT, my_rank+half,tag, MPI_COMM_WORLD, status); That is it. That is all our allowed interaction with the users process. OK, when you said something along the lines of the MPT library has control of the comm buffer, then I assumed it was an area of virtual memory which is set up as part of initialization, rather than during runtime. I guess I jumped to conclusions. That doesn't seem too unreasonable, except when you compare it to how the driver currently works. Remember, this is done from a library which has no insight into what the user has done to its own virtual address space. As a result, each MPI_Send() would result in a system call (or we would need to have a set of callouts for changes to a processes VMAs) which would be a significant increase in communication overhead. Maybe I am missing what you intend to do, but what we need is a means of tracking one processes virtual address space changes so other processes can do direct memory accesses without the need for a system call on each communication event. Yeah it's tricky. BTW. what is the performance difference between having a system call or no? Because you don't need to swap, you don't need coherency, and you are in control of the areas, then this seems like the best choice. It would allow you to use heap, stack, file-backed, anything. You are missing one point here. The MPI specifications that have been out there for decades do not require the process use a library for allocating the buffer. I realize that is a horrible shortcoming, but that is the world we live in. Even if we could change that spec, Can you change the spec? Are you working on it? we would still need to support the existing specs. As a result, the user can change their virtual address space as they need and still expect communications be cheap. That's true. How has it been supported up to now? Are you using these kind of notifiers in patched kernels? - 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] [ofa-general] Re: [patch 5/6] mmu_notifier: Support for drivers with revers maps (f.e. for XPmem)
On Tue, Feb 26, 2008 at 05:11:32PM +1100, Nick Piggin wrote: You are missing one point here. The MPI specifications that have been out there for decades do not require the process use a library for allocating the buffer. I realize that is a horrible shortcoming, but that is the world we live in. Even if we could change that spec, Can you change the spec? Not really. It will break all existing codes. MPI-2 provides a call for memory allocation (and it's beneficial to use this call for some interconnects), but many (most?) applications are still written for MPI-1 and those that are written for MPI-2 mostly uses the old habit of allocating memory by malloc(), or even use stack or BSS memory for communication buffer purposes. -- Gleb. - 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
