Re: KSM overcommit test review - 1st pass (issue183068)
Here is the full text of the review
http://codereview.appspot.com/183068/diff/1/3
File client/tests/kvm/tests/ksm_overcommit.py (right):
http://codereview.appspot.com/183068/diff/1/3#newcode5
client/tests/kvm/tests/ksm_overcommit.py:5: import random, string, math, os
Here we have the import of standard modules after the autotest and custom kvm
ones. All standard module imports should be grouped together.
http://codereview.appspot.com/183068/diff/1/3#newcode19
client/tests/kvm/tests/ksm_overcommit.py:19: def parse_meminfo(rowName):
There are functions on client/bin/base_utils.py that already parse meminfo, we
should consider using them instead of custom functions.
http://codereview.appspot.com/183068/diff/1/3#newcode29
client/tests/kvm/tests/ksm_overcommit.py:29:
Please don't use a single empty space between functions, as the autotest coding
standard asks for 2:
http://autotest.kernel.org/browser/trunk/CODING_STYLE
I will omit the comment for further occurrences of single line spacing to avoid
cluttering the review, but please fix them all.
http://codereview.appspot.com/183068/diff/1/3#newcode42
client/tests/kvm/tests/ksm_overcommit.py:42: "VM: %s" % vm.name)
Apparently a raise was forgotten on the line above. Also, the best way to do
multi-line statements is using implicit continuation in parenthesis, in general
you should refrain from using \ to continue sentences, ie:
Instead of
print "Fancy multi-line statement"+\
"that should be avoided."
You should do
print ("Fancy multi-line statement"
"the preferred way.")
I will omit the comment for further occurrences of ending lines with slash to
avoid cluttering the review, but please fix them all.
http://codereview.appspot.com/183068/diff/1/3#newcode88
client/tests/kvm/tests/ksm_overcommit.py:88:
Mixing up the body of the main function with declaration of the auxiliary
functions didn't work up well. Please make a clear separation between the body
of the function run_ksm_overcommit and the declaration of auxiliary functions.
http://codereview.appspot.com/183068/diff/1/3#newcode600
client/tests/kvm/tests/ksm_overcommit.py:600:
Please don't leave up 4 lines of spacing on the code.
http://codereview.appspot.com/183068/diff/1/2
File client/tests/kvm/unattended/allocator.py (right):
http://codereview.appspot.com/183068/diff/1/2#newcode11
client/tests/kvm/unattended/allocator.py:11:
1) The above imports should be done according to the autotest coding standard,
grouping them into a single line.
2) datetime.timedelta is not being used on the below code, as far as I can see
3) Instead of using datetime.now() use datetime.datetime.now(), I know it's not
exactly pretty but it's the preferred way when writing autotest code.
http://codereview.appspot.com/183068/diff/1/2#newcode13
client/tests/kvm/unattended/allocator.py:13: KVM test definitions.
This summary of the program does not inform what the program is up for. I would
suggest something along the lines "Auxiliary script used for memory allocation
on guests"
http://codereview.appspot.com/183068/diff/1/2#newcode16
client/tests/kvm/unattended/allocator.py:16: Jiri Zupka
Use @author, and your e-mail in parenthesis
@author Jiri Zupka (jzu...@redhat.com)
http://codereview.appspot.com/183068/diff/1/2#newcode205
client/tests/kvm/unattended/allocator.py:205: print "PASS: Start"
Why is that print statement for? It seems out of place
On Mon, Dec 28, 2009 at 2:08 AM, wrote:
> Hi Jiri, thank you very much for your work! I have comments to make
> regarding to coding style as a first pass review. While reading them,
> please keep in mind autotest's coding standards:
>
> http://autotest.kernel.org/browser/trunk/CODING_STYLE
>
> Also, I have noticed lots of trailing spaces on lines. I recommend that
> every time you are done working with the code, you use the very useful
> script utils/reindent.py (see top level autotest directory) that will
> remove all trailing spaces on your code. While I wrote this first pass
> review, I have applied it on the resultant files.
>
>
> http://codereview.appspot.com/183068
>
--
Lucas
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KSM overcommit test review - 1st pass (issue183068)
Hi Jiri, thank you very much for your work! I have comments to make regarding to coding style as a first pass review. While reading them, please keep in mind autotest's coding standards: http://autotest.kernel.org/browser/trunk/CODING_STYLE Also, I have noticed lots of trailing spaces on lines. I recommend that every time you are done working with the code, you use the very useful script utils/reindent.py (see top level autotest directory) that will remove all trailing spaces on your code. While I wrote this first pass review, I have applied it on the resultant files. http://codereview.appspot.com/183068 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Biweekly KVM Test report, kernel 3e0c78... qemu 17e36d...
Hi, all This is KVM biweekly test result against kvm.git: 3e0c78729de88e8d82b5ce1c25b1c75d72dfbbea and qemu-kvm.git: 17e36de28675274e2533f16f19e55fe6acbeabeb. There is no new bugs during the two weeks. Live-Migration and Window7 installation issues was fixed and verified. One Fixed Issue: 1. Guest has no response after migration https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2899788&group_id=180599 2. Window7 debug version installation fail on KVM https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2902983&group_id=180599 Seven Old Issues: 1. Hot-added device is not visible in guest after migration https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2832416&group_id=180599 2. ltp diotest running time is 2.54 times than before https://sourceforge.net/tracker/?func=detail&aid=2723366&group_id=180599&atid=893831 3. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1991647&group_id=180599 4. Fail to Save Restore Guest https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2175042&group_id=180599 5. perfctr wrmsr warning when booting 64bit RHEl5.3 https://sourceforge.net/tracker/?func=detail&aid=2721640&group_id=180599&atid=893831 Test environment Platform A Stoakley/Clovertown CPU 4 Memory size 8G Report Summary on IA32e == Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel 17 13 4 00 gtest 23 21 2 00 = control_panel 17 13 4 00 :KVM_4G_guest_64_g32e 1 1 0 00 :KVM_four_sguest_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_g32e1 1 0 00 :KVM_linux_win_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_gPAE1 1 0 00 :KVM_SR_Continuity_64_gP 1 0 1 00 :KVM_four_sguest_64_g32e 1 1 0 00 :KVM_four_dguest_64_gPAE 1 1 0 00 :KVM_SR_SMP_64_gPAE1 0 1 00 :KVM_LM_Continuity_64_g3 1 1 0 00 :KVM_1500M_guest_64_gPAE 1 1 0 00 :KVM_LM_Continuity_64_gP 1 1 0 00 :KVM_1500M_guest_64_g32e 1 1 0 00 :KVM_SR_Continuity_64_g3 1 0 1 00 :KVM_two_winxp_64_gPAE 1 0 1 00 :KVM_256M_guest_64_gPAE1 1 0 00 :KVM_256M_guest_64_g32e1 1 0 00 gtest 23 21 2 00 :boot_up_acpi_64_gPAE 1 1 0 00 :boot_up_noacpi_xp_64_gP 1 1 0 00 :boot_base_kernel_64_gPA 1 1 0 00 :boot_up_vista_64_g32e 1 1 0 00 :boot_smp_acpi_win2k3_64 1 0 1 00 :kb_nightly_64_gPAE1 1 0 00 :boot_up_acpi_xp_64_g32e 1 1 0 00 :boot_smp_win7_ent_64_g3 1 1 0 00 :boot_smp_acpi_xp_64_gPA 1 0 1 00 :boot_smp_acpi_xp_64_g32 1 1 0 00 :boot_smp_vista_64_gPAE1 1 0 00 :boot_up_acpi_64_g32e 1 1 0 00 :boot_base_kernel_64_g32 1 1 0 00 :kb_nightly_64_g32e1 1 0 00 :boot_up_acpi_win2k3_64_ 1 1 0 00 :boot_up_win2008_64_gPAE 1 1 0 00 :ltp_nightly_64_g32e 1 1 0 00 :boot_smp_win2008_64_g32 1 1 0 00 :boot_up_vista_64_gPAE 1 1 0 00 :ltp_nightly_64_gPAE 1 1 0 00 :boot_smp_acpi_win2k3_64 1 1 0 00 :boot_up_noacpi_win2k3_6 1 1 0 00 :boot_smp_win7_ent_64_gP 1 1 0 00 = Total 40 34 6 00 Test environment ===
[ kvm-Bugs-2902983 ] Window7 debug version installation fail on KVM
Bugs item #2902983, was opened at 2009-11-24 16:17 Message generated for change (Settings changed) made by haoxudong You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2902983&group_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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Xudong Hao (haoxudong) Assigned to: Nobody/Anonymous (nobody) Summary: Window7 debug version installation fail on KVM Initial Comment: Environment: Host OS (ia32/ia32e/IA64): ia32pae ia32e Guest OS (ia32/ia32e/IA64): ia32pae ia32e Guest OS Type (Linux/Windows): Windows7 kvm.git Commit: 212b1ccd9ffb1ed9a7abdcdc57e1d7d31486945b qemu-kvm Commit: 72a56670e2f4a1d905676384fc965ec0bf516b9c Host Kernel Version: 2.6.32-rc7 Hardware: Stoakley Bug detailed description: -- We download Windows7 build iso(debug) and try to install it on KVM, at the begining of install, a blue screen printed "STOP: 0X007E..." (attach the failed screen), no dmesg information print on host. Reproduce steps: 1) download en_windows_7_checked_build_dvd_x64_398741.iso 2) dd one 20G blank image named ia32e_win7_ent_debug.img 3) qemu-system-x86_64 -smp 2 -m 1024 -hda ia32e_win7_ent_debug.img -cdrom en_windows_7_checked_build_dvd_x64_398741.iso -- Comment By: Xudong Hao (haoxudong) Date: 2009-12-28 10:49 Message: Please ignore unrestricted_guest=0. On the commit 2624760bc94d7c93acf2935589406b0937a718ff and qemu 9ad7758c0b5972bf8113be30d54475983056cb67, I tried install window7 debug version with "-net none -no-hpet", and it completed installation. So I think we can close this bug. -- Comment By: Gleb Natapov (glebn) Date: 2009-12-25 17:11 Message: Where it hangs now? Also what happens if you don't specify unrestricted_gues=0? -- Comment By: Xudong Hao (haoxudong) Date: 2009-12-25 16:57 Message: if load module with "modprobe kvm_intel unrestricted_guest=0", win7 did not blue screen, but still can not complete installation. However, I can boot up win7 guest with a worked win7 debug version image -- Comment By: Gleb Natapov (glebn) Date: 2009-11-26 20:58 Message: This commit access memory defined in e820 as ACPI from AML code. According to ACPI spec this memory can be reused after OS process ACPI tables, so Windows is rightfully complains that we can't access this memory from the AML (unfortunately it is impossible to understand what windows is complaining about). Since we are moving away from pc-bios to seabios and seabios doesn't yet have this code I will not fix this in pc-bios, but will remember to do it right in seabios when cpu-hotplug will be added there. -- Comment By: Marcelo Tosatti (mtosatti) Date: 2009-11-26 06:57 Message: Eeh, no. This is the real culprit: ca54075e7802bb5b33edf812b3199860390eeb7b is first bad commit commit ca54075e7802bb5b33edf812b3199860390eeb7b Author: Gleb Natapov Date: Mon Jun 1 12:22:48 2009 +0300 Read MADT entries from memory in processors _MAT method. Also use enable/disable bit from ACPI MADT entries to track CPU hot plug. This removes assumptions about APIC ids from AML code and simplify cpu hotplug handling. Signed-off-by: Gleb Natapov Signed-off-by: Avi Kivity -- Comment By: Avi Kivity (avik) Date: 2009-11-26 00:51 Message: Interesting. Does it work with seabios? -- Comment By: Marcelo Tosatti (mtosatti) Date: 2009-11-26 00:36 Message: Removing the S3,S4,S5 PM entries in acpi-dsdt.dsl makes it happy. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2902983&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Autotest PATCH] KVM test: No need close session when login timeout
On Sat, Dec 26, 2009 at 10:07:58AM -0500, Michael Goldish wrote:
>
> - "Amos Kong" wrote:
>
> > On Fri, Dec 25, 2009 at 08:28:18AM -0500, Michael Goldish wrote:
> > >
> > > - "Amos Kong" wrote:
> > >
> > > > If login timeout, wait_for() returned 'None' and assigned to
> > > > 'session'.
> > > > When call session.close(), this prlblem was caused:
> > > > "AttributeError: 'NoneType' object has no attribute 'close'"
> > > >
> > > > Signed-off-by: Amos Kong
> > > > ---
> > > > client/tests/kvm/tests/timedrift_with_migration.py |3 ++-
> > > > 1 files changed, 2 insertions(+), 1 deletions(-)
> > > >
> > > > diff --git a/client/tests/kvm/tests/timedrift_with_migration.py
> > > > b/client/tests/kvm/tests/timedrift_with_migration.py
> > > > index a012db3..0b93183 100644
> > > > --- a/client/tests/kvm/tests/timedrift_with_migration.py
> > > > +++ b/client/tests/kvm/tests/timedrift_with_migration.py
> > > > @@ -76,7 +76,8 @@ def run_timedrift_with_migration(test, params,
> > > > env):
> > > > time_filter_re,
> > > > time_format)
> > > >
> > > > finally:
> > > > -session.close()
> > > > +if session != None:
> > > > +session.close()
> > >
> > > Agreed, but we can make this simply:
> > >
> > > if session:
> > > session.close()
> >
> > Yes,
> >
> >
> > > There's no need to explicitly check for None (and if there was,
> > > the preferred syntax would be 'is not None' rather than '!= None').
> > >
> > > Also, just to be safe, we should make the same modification to
> > > timedrift_with_reboot.py.
> >
> >
> > In timedrift_with_reboot.py, 'session' has been assigned before 'try'.
> > If re-login timout, kvm_test_utils.reboot() returns nothing, the value
> > of 'session' isn't changed.
> > So session.close() couldn't cause this problem:
> > "AttributeError: 'NoneType' object has no attribute 'close'"
>
> The two tests are nearly identical so I thought we might as well make
> the change in both of them, but I agree that it doesn't matter (unless
> we change the behavior of kvm_test_utils.reboot() in the future).
>
> > In other testcases, if session wasn't assigned before 'try',
> > when calling kvm_test_utils.wait_for_login()/kvm_test_utils.reboot()
> > timeout,
> > It returns nothing, if close 'session' in finally part, Another
> > problem will occur:
> > "NameError: name 'session' is not defined"
> >
> > In this condition,
> > """
> > if session:
> > session.close()
> > """
> > also causes this error.
>
> In what tests exactly does this happen?
>
> 'if session' is preferable to 'if session is not None' because it's
> shorter, not because it's safer.
There is no this kind of test in upstream testcases,
---
I touch this problem, when I write new testcase.
For example,
def run_test_close_session(test, params, env):
vm = kvm_test_utils.get_living_vm(env, params.get("main_vm"))
try:
...
session = kvm_test_utils.reboot(vm, session)
...
finally:
session.close()
> > > We can also consider removing the try..finally clauses altogether
> > > because sessions are now closed automatically when they're no
> > longer
> > > needed.
> > >
> > > >
> > > > # Report results
> > > > host_delta = ht1 - ht0
> > > > --
> > > > 1.5.5.6
> >
> > --
> > Amos Kong
> > Quality Engineer
> > Raycom Office(Beijing), Red Hat Inc.
--
Amos Kong
Quality Engineer
Raycom Office(Beijing), Red Hat Inc.
Phone: +86-10-62608183
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2902983 ] Window7 debug version installation fail on KVM
Bugs item #2902983, was opened at 2009-11-24 16:17 Message generated for change (Comment added) made by haoxudong You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2902983&group_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: Xudong Hao (haoxudong) Assigned to: Nobody/Anonymous (nobody) Summary: Window7 debug version installation fail on KVM Initial Comment: Environment: Host OS (ia32/ia32e/IA64): ia32pae ia32e Guest OS (ia32/ia32e/IA64): ia32pae ia32e Guest OS Type (Linux/Windows): Windows7 kvm.git Commit: 212b1ccd9ffb1ed9a7abdcdc57e1d7d31486945b qemu-kvm Commit: 72a56670e2f4a1d905676384fc965ec0bf516b9c Host Kernel Version: 2.6.32-rc7 Hardware: Stoakley Bug detailed description: -- We download Windows7 build iso(debug) and try to install it on KVM, at the begining of install, a blue screen printed "STOP: 0X007E..." (attach the failed screen), no dmesg information print on host. Reproduce steps: 1) download en_windows_7_checked_build_dvd_x64_398741.iso 2) dd one 20G blank image named ia32e_win7_ent_debug.img 3) qemu-system-x86_64 -smp 2 -m 1024 -hda ia32e_win7_ent_debug.img -cdrom en_windows_7_checked_build_dvd_x64_398741.iso -- >Comment By: Xudong Hao (haoxudong) Date: 2009-12-28 10:49 Message: Please ignore unrestricted_guest=0. On the commit 2624760bc94d7c93acf2935589406b0937a718ff and qemu 9ad7758c0b5972bf8113be30d54475983056cb67, I tried install window7 debug version with "-net none -no-hpet", and it completed installation. So I think we can close this bug. -- Comment By: Gleb Natapov (glebn) Date: 2009-12-25 17:11 Message: Where it hangs now? Also what happens if you don't specify unrestricted_gues=0? -- Comment By: Xudong Hao (haoxudong) Date: 2009-12-25 16:57 Message: if load module with "modprobe kvm_intel unrestricted_guest=0", win7 did not blue screen, but still can not complete installation. However, I can boot up win7 guest with a worked win7 debug version image -- Comment By: Gleb Natapov (glebn) Date: 2009-11-26 20:58 Message: This commit access memory defined in e820 as ACPI from AML code. According to ACPI spec this memory can be reused after OS process ACPI tables, so Windows is rightfully complains that we can't access this memory from the AML (unfortunately it is impossible to understand what windows is complaining about). Since we are moving away from pc-bios to seabios and seabios doesn't yet have this code I will not fix this in pc-bios, but will remember to do it right in seabios when cpu-hotplug will be added there. -- Comment By: Marcelo Tosatti (mtosatti) Date: 2009-11-26 06:57 Message: Eeh, no. This is the real culprit: ca54075e7802bb5b33edf812b3199860390eeb7b is first bad commit commit ca54075e7802bb5b33edf812b3199860390eeb7b Author: Gleb Natapov Date: Mon Jun 1 12:22:48 2009 +0300 Read MADT entries from memory in processors _MAT method. Also use enable/disable bit from ACPI MADT entries to track CPU hot plug. This removes assumptions about APIC ids from AML code and simplify cpu hotplug handling. Signed-off-by: Gleb Natapov Signed-off-by: Avi Kivity -- Comment By: Avi Kivity (avik) Date: 2009-11-26 00:51 Message: Interesting. Does it work with seabios? -- Comment By: Marcelo Tosatti (mtosatti) Date: 2009-11-26 00:36 Message: Removing the S3,S4,S5 PM entries in acpi-dsdt.dsl makes it happy. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2902983&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2907597 ] qemu vnc server clips at 2560x1600
Bugs item #2907597, was opened at 2009-12-02 16:57 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2907597&group_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: qemu Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Matthew Colyer (mcsoccer) Assigned to: Nobody/Anonymous (nobody) Summary: qemu vnc server clips at 2560x1600 Initial Comment: So I am running using the VESA driver to run an Ubuntu 9.10 guest at 2560x1600 (I had to modify the xserver-video-vesa package to remove an internal screen limit of 2048x2048 in the xorg vesa driver) and everything works great except that the qemu vnc server appears to clip at this resolution. The problem goes away if I run 1900x1200 and it doesn't change if I run 16bit depth or 24bit depth. I have attached two screenshots, the first is vncing directly into qemu (which exhibits the problem) and the second is vncing to a vnc server I have running in the guest which doesn't have the problem. I poked around in vnc.c and couldn't see any limits but I feel like its a buffer limit of some kind. Also if you look very closely at the first image you can see that the first row is drawn correctly all the way across but subsequent rows are not. If you need more information doesn't hesitate to ask. -- >Comment By: SourceForge Robot (sf-robot) Date: 2009-12-28 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Matthew Colyer (mcsoccer) Date: 2009-12-17 03:18 Message: The blocks do not show up when run in SDL mode. So I believe the problem is still somehow related to the VNC server. -- Comment By: Avi Kivity (avik) Date: 2009-12-13 10:29 Message: Does it work well with SDL? Maybe the problem is not vnc related. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2907597&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Alacrityvm-devel] [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/27/09 8:49 AM, Avi Kivity wrote: > On 12/27/2009 03:39 PM, Gregory Haskins wrote: >> No, where we are is at the point where we demonstrate that your original >> statement that I did nothing to improve virtio was wrong. >> >> > > I stand by it. virtio + your patch does nothing without a ton more work > (more or less equivalent to vhost-net). > Perhaps, but my work predates vhost-net by months and that has nothing to do with what we are talking about anyway. Since you snipped your original comment that started the thread, here it is again: On 12/23/09 5:22 AM, Avi Kivity wrote: > > > > There was no attempt by Gregory to improve virtio-net. It's not a gray area, nor open to interpretation. That statement was, is, and will always be demonstrably false, so I'm sorry but you are still wrong. -Greg signature.asc Description: OpenPGP digital signature
[PATCH] KVM test: Add PCI device assignment support
Add support to PCI device assignment on the kvm test. It supports
both SR-IOV virtual functions and physical NIC card device
assignment.
Single Root I/O Virtualization (SR-IOV) allows a single PCI device to
be shared amongst multiple virtual machines while retaining the
performance benefit of assigning a PCI device to a virtual machine.
A common example is where a single SR-IOV capable NIC - with perhaps
only a single physical network port - might be shared with multiple
virtual machines by assigning a virtual function to each VM.
SR-IOV support is implemented in the kernel. The core implementation
is contained in the PCI subsystem, but there must also be driver support
for both the Physical Function (PF) and Virtual Function (VF) devices.
With an SR-IOV capable device one can allocate VFs from a PF. The VFs
surface as PCI devices which are backed on the physical PCI device by
resources (queues, and register sets).
Device support:
In 2.6.30, the Intel® 82576 Gigabit Ethernet Controller is the only
SR-IOV capable device supported. The igb driver has PF support and the
igbvf has VF support.
In 2.6.31 the Neterion® X3100™ is supported as well. This device uses
the same vxge driver for the PF as well as the VFs.
In order to configure the test:
* For SR-IOV virtual functions passthrough, we could specify the
module parameter 'max_vfs' in config file.
* For physical NIC card pass through, we should specify the device
name(s).
4th try: Implemented Yolkfull's suggestion of keeping 'max_vfs' and
'assignable_devices' as sepparated parameters. Yolkfull, please test this
on your environment. Thank you!
* Naming is consistent with "PCI assignment" instead of
"PCI passthrough", as it's a more correct term.
* No more device database file, as all information about devices
is stored on an attribute of the VM class (an instance of the
PciAssignable class), so we don't have to bother dumping this
info to a file.
* Code simplified to avoid duplication
As it's a fairly involved feature, the more reviews we get the better.
Signed-off-by: Lucas Meneghel Rodrigues
---
client/tests/kvm/kvm_utils.py | 281
client/tests/kvm/kvm_vm.py | 59 +++
client/tests/kvm/tests_base.cfg.sample | 20 +++
3 files changed, 360 insertions(+), 0 deletions(-)
diff --git a/client/tests/kvm/kvm_utils.py b/client/tests/kvm/kvm_utils.py
index 2bbbe22..59c72a9 100644
--- a/client/tests/kvm/kvm_utils.py
+++ b/client/tests/kvm/kvm_utils.py
@@ -924,3 +924,284 @@ def create_report(report_dir, results_dir):
reporter = os.path.join(report_dir, 'html_report.py')
html_file = os.path.join(results_dir, 'results.html')
os.system('%s -r %s -f %s -R' % (reporter, results_dir, html_file))
+
+
+def get_full_pci_id(pci_id):
+"""
+Get full PCI ID of pci_id.
+
+@param pci_id: PCI ID of a device.
+"""
+cmd = "lspci -D | awk '/%s/ {print $1}'" % pci_id
+status, full_id = commands.getstatusoutput(cmd)
+if status != 0:
+return None
+return full_id
+
+
+def get_vendor_from_pci_id(pci_id):
+"""
+Check out the device vendor ID according to pci_id.
+
+@param pci_id: PCI ID of a device.
+"""
+cmd = "lspci -n | awk '/%s/ {print $3}'" % pci_id
+return re.sub(":", " ", commands.getoutput(cmd))
+
+
+class PciAssignable(object):
+"""
+Request PCI assignable devices on host. It will check whether to request
+PF (physical Functions) or VF (Virtual Functions).
+"""
+def __init__(self, type="nic_vf", driver=None, driver_option=None,
+ names=None, devices_requested=None):
+"""
+Initialize parameter 'type' which could be:
+nic_vf: Virtual Functions
+nic_pf: Physical Function (actual hardware)
+mixed: Both includes VFs and PFs
+
+If pass through Physical NIC cards, we need to specify which devices
+to be assigned, e.g. 'eth1 eth2'.
+
+If pass through Virtual Functions, we need to specify how many vfs
+are going to be assigned, e.g. passthrough_count = 8 and max_vfs in
+config file.
+
+@param type: PCI device type.
+@param driver: Kernel module for the PCI assignable device.
+@param driver_option: Module option to specify the maximum number of
+VFs (eg 'max_vfs=7')
+@param names: Physical NIC cards correspondent network interfaces,
+e.g.'eth1 eth2 ...'
+"""
+self.type = type
+self.driver = driver
+self.driver_option = driver_option
+if names:
+self.name_list = names.split()
+if devices_requested:
+self.devices_requested = int(devices_requested)
+
+
+def _get_pf_pci_id(self, name, search_str):
+"""
+Get the PF PCI ID according to name.
+
+@param name: Name of the PCI device.
+@param search_str: Search string to be used on
Re: [Autotest] [Autotest PATCH] KVM test: physical_resources_check subtest:Fixup `mem_chk_cmd' for rhel3.9
Applied, thanks!
On Wed, Dec 23, 2009 at 6:39 AM, Yolkfull Chow wrote:
> Signed-off-by: Yolkfull Chow
> ---
> client/tests/kvm/tests_base.cfg.sample | 4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/client/tests/kvm/tests_base.cfg.sample
> b/client/tests/kvm/tests_base.cfg.sample
> index a403399..f5a55a0 100644
> --- a/client/tests/kvm/tests_base.cfg.sample
> +++ b/client/tests/kvm/tests_base.cfg.sample
> @@ -535,6 +535,8 @@ variants:
> extra_params += " -bootp /pxelinux.0 -boot n"
> kernel_args = "ks=floppy nicdelay=60"
> unattended_file = unattended/RHEL-3-series.ks
> + physical_resources_check:
> + mem_chk_cmd = dmidecode | awk -F: '/Maximum
> Capacity/ {print $2}'
> - 3.9.x86_64:
> no setup autotest linux_s3
> image_name = rhel3-64
> @@ -551,6 +553,8 @@ variants:
> extra_params += " -bootp /pxelinux.0 -boot n"
> kernel_args = "ks=floppy nicdelay=60"
> unattended_file = unattended/RHEL-3-series.ks
> + physical_resources_check:
> + mem_chk_cmd = dmidecode | awk -F: '/Maximum
> Capacity/ {print $2}'
> # Windows section
> - @Windows:
> no autotest linux_s3 vlan_tag
> --
> 1.6.5.5
>
> ___
> Autotest mailing list
> autot...@test.kernel.org
> http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
>
--
Lucas
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Autotest] [Autotest PATCH] KVM test: No need close session when login timeout
Ok, I have changed statements in both timedrift_with_migration and timedrift_with_reboot to if session! Thanks for your comments, Michael and Amos! On Sat, Dec 26, 2009 at 1:07 PM, Michael Goldish wrote: > > - "Amos Kong" wrote: > >> On Fri, Dec 25, 2009 at 08:28:18AM -0500, Michael Goldish wrote: >> > >> > - "Amos Kong" wrote: >> > >> > > If login timeout, wait_for() returned 'None' and assigned to >> > > 'session'. >> > > When call session.close(), this prlblem was caused: >> > > "AttributeError: 'NoneType' object has no attribute 'close'" >> > > >> > > Signed-off-by: Amos Kong >> > > --- >> > > client/tests/kvm/tests/timedrift_with_migration.py | 3 ++- >> > > 1 files changed, 2 insertions(+), 1 deletions(-) >> > > >> > > diff --git a/client/tests/kvm/tests/timedrift_with_migration.py >> > > b/client/tests/kvm/tests/timedrift_with_migration.py >> > > index a012db3..0b93183 100644 >> > > --- a/client/tests/kvm/tests/timedrift_with_migration.py >> > > +++ b/client/tests/kvm/tests/timedrift_with_migration.py >> > > @@ -76,7 +76,8 @@ def run_timedrift_with_migration(test, params, >> > > env): >> > > time_filter_re, >> > > time_format) >> > > >> > > finally: >> > > - session.close() >> > > + if session != None: >> > > + session.close() >> > >> > Agreed, but we can make this simply: >> > >> > if session: >> > session.close() >> >> Yes, >> >> >> > There's no need to explicitly check for None (and if there was, >> > the preferred syntax would be 'is not None' rather than '!= None'). >> > >> > Also, just to be safe, we should make the same modification to >> > timedrift_with_reboot.py. >> >> >> In timedrift_with_reboot.py, 'session' has been assigned before 'try'. >> If re-login timout, kvm_test_utils.reboot() returns nothing, the value >> of 'session' isn't changed. >> So session.close() couldn't cause this problem: >> "AttributeError: 'NoneType' object has no attribute 'close'" > > The two tests are nearly identical so I thought we might as well make > the change in both of them, but I agree that it doesn't matter (unless > we change the behavior of kvm_test_utils.reboot() in the future). > >> >> >> >> In other testcases, if session wasn't assigned before 'try', >> when calling kvm_test_utils.wait_for_login()/kvm_test_utils.reboot() >> timeout, >> It returns nothing, if close 'session' in finally part, Another >> problem will occur: >> "NameError: name 'session' is not defined" >> >> In this condition, >> """ >> if session: >> session.close() >> """ >> also causes this error. > > In what tests exactly does this happen? > > 'if session' is preferable to 'if session is not None' because it's > shorter, not because it's safer. > >> >> >> >> > We can also consider removing the try..finally clauses altogether >> > because sessions are now closed automatically when they're no >> longer >> > needed. >> > >> > > >> > > # Report results >> > > host_delta = ht1 - ht0 >> > > -- >> > > 1.5.5.6 >> >> -- >> Amos Kong >> Quality Engineer >> Raycom Office(Beijing), Red Hat Inc. > ___ > Autotest mailing list > autot...@test.kernel.org > http://test.kernel.org/cgi-bin/mailman/listinfo/autotest > -- Lucas -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Autotest] [KVM-AUTOTEST PATCH 2/2] KVM test: warn about corrupt PPM files after each test
Patch series applied, thanks!
On Wed, Dec 23, 2009 at 2:32 PM, Michael Goldish wrote:
> Signed-off-by: Michael Goldish
> ---
> client/tests/kvm/kvm_preprocessing.py | 5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/client/tests/kvm/kvm_preprocessing.py
> b/client/tests/kvm/kvm_preprocessing.py
> index 5bae2bd..4e45c76 100644
> --- a/client/tests/kvm/kvm_preprocessing.py
> +++ b/client/tests/kvm/kvm_preprocessing.py
> @@ -270,6 +270,11 @@ def postprocess(test, params, env):
> """
> process(test, params, env, postprocess_image, postprocess_vm)
>
> + # Warn about corrupt PPM files
> + for f in glob.glob(os.path.join(test.debugdir, "*.ppm")):
> + if not ppm_utils.image_verify_ppm_file(f):
> + logging.warn("Found corrupt PPM file: %s", f)
> +
> # Should we convert PPM files to PNG format?
> if params.get("convert_ppm_files_to_png") == "yes":
> logging.debug("'convert_ppm_files_to_png' specified; converting PPM"
> --
> 1.5.4.1
>
> ___
> Autotest mailing list
> autot...@test.kernel.org
> http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
>
--
Lucas
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm 0.12.1.1 multiple definition of mulu64 and muls64
On Sat, Dec 26, 2009 at 11:41:51PM +, Mikolaj Kucharski wrote: > Hi, > > After adding dummy kvm_save_mpstate change from git I would compile all > softmmu targets as expected. Although I found another problem. I cannot > compile some `user' targets: Applied and queued for stable-0.12, thanks. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: Bump maximum vcpu count to 64
On Sun, Dec 27, 2009 at 05:00:46PM +0200, Avi Kivity wrote: > With slots_lock converted to rcu, the entire kvm hotpath on modern processors > (with npt or ept) now scales beautifully. Increase the maximum vcpu count to > 64 to reflect this. > > Signed-off-by: Avi Kivity Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Memory usage with qemu-kvm-0.12.1.1
Hi, Avi. On Sunday, 27 December 2009 19:33:31 +0200, Avi Kivity wrote: Also, qemu might be leaking memory. Please post 'pmap $pid' for all of your guests (do that before any of the other tests, on your swapped-out system). >>> - >>> >>> total 626376K >>> >>> total 626472K >>> >>> total 626396K >>> >>> total 635292K >>> >>> total 625388K >> These all seem sane. So it's a swap regression, hopefully >> 2.6.32.something will have a fix. It draws attention to me that I didn't have this problem with qemu-kvm-0.12.0-rc2 but after updating to qemu-kvm-0.12.1.1. Mmmm... thinking a little, I made the update to see if with 0.12.1.1 no longer had the problem with the e1000 network interface in OpenBSD. Therefore, I only shutdown an boot this VM and not all. Could it have caused that increase in the swap usage? In both cases the used version of kernel was the same. > btw, does your system have ept? > > $ cat /sys/module/kvm_intel/parameters/ept It doesn't have: r...@ubuntu:~# ls /sys/module/kvm_amd/parameters/ nested npt r...@ubuntu:~# uname -a Linux ubuntu 2.6.32-dgb #1 SMP Mon Dec 14 06:18:06 ART 2009 x86_64 GNU/Linux Thanks for your reply. Regards, Daniel -- Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37 Powered by Debian GNU/Linux Lenny - Linux user #188.598 signature.asc Description: Digital signature
Re: Memory usage with qemu-kvm-0.12.1.1
On 12/27/2009 07:20 PM, Avi Kivity wrote: On 12/27/2009 07:00 PM, Daniel Bareiro wrote: Also, qemu might be leaking memory. Please post 'pmap $pid' for all of your guests (do that before any of the other tests, on your swapped-out system). - total 626376K total 626472K total 626396K total 635292K total 625388K These all seem sane. So it's a swap regression, hopefully 2.6.32.something will have a fix. btw, does your system have ept? $ cat /sys/module/kvm_intel/parameters/ept -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] KVM updates for 2.6.33-rc2
Linus, please pull from git://git.kernel.org/pub/scm/virt/kvm/kvm.git kvm-updates/2.6.33 For the following KVM fixes. Alexander Graf (1): KVM: powerpc: Fix mtsrin in book3s_64 mmu Heiko Carstens (1): KVM: get rid of kvm_create_vm() unused label warning on s390 Jan Kiszka (1): KVM: x86: Extend KVM_SET_VCPU_EVENTS with selective updates Marcelo Tosatti (2): KVM: MMU: remove prefault from invlpg handler KVM: LAPIC: make sure IRR bitmap is scanned after vm load Sheng Yang (1): KVM: Fix possible circular locking in kvm_vm_ioctl_assign_device() Tony Luck (1): KVM: ia64: fix build breakage due to host spinlock change Documentation/kvm/api.txt| 10 +- arch/ia64/kvm/vcpu.h |9 ++--- arch/ia64/kvm/vmm.c |4 ++-- arch/ia64/kvm/vtlb.c |2 +- arch/powerpc/kvm/book3s_64_mmu.c | 22 +- arch/x86/include/asm/kvm.h |4 arch/x86/kvm/lapic.c |1 + arch/x86/kvm/paging_tmpl.h | 18 -- arch/x86/kvm/x86.c | 12 virt/kvm/assigned-dev.c |6 +++--- virt/kvm/kvm_main.c |5 - 11 files changed, 59 insertions(+), 34 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Memory usage with qemu-kvm-0.12.1.1
On 12/27/2009 12:12 PM, Avi Kivity wrote: On 12/27/2009 06:45 PM, Rik van Riel wrote: If so, it doesn't copy sta...@kernel.org. Is it queued for -stable? I do not believe that it is queued for -stable. Do performance fixes fit with -stable policy? If it is a serious regression, I believe it fits. It's probably been there since 2.6.28, though it might have been introduced later with a cleanup patch. It seems to go back at least as far as March... -- All rights reversed. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Memory usage with qemu-kvm-0.12.1.1
On 12/27/2009 07:00 PM, Daniel Bareiro wrote: Also, qemu might be leaking memory. Please post 'pmap $pid' for all of your guests (do that before any of the other tests, on your swapped-out system). - total 626376K total 626472K total 626396K total 635292K total 625388K These all seem sane. So it's a swap regression, hopefully 2.6.32.something will have a fix. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Memory usage with qemu-kvm-0.12.1.1
On 12/27/2009 06:45 PM, Rik van Riel wrote: If so, it doesn't copy sta...@kernel.org. Is it queued for -stable? I do not believe that it is queued for -stable. Do performance fixes fit with -stable policy? If it is a serious regression, I believe it fits. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Memory usage with qemu-kvm-0.12.1.1
Hi, Avi. On Sunday, 27 December 2009 18:03:18 +0200, Avi Kivity wrote: >> I installed qemu-kvm-0.12.1.1 in one equipment of my house yesterday >> to test it with Linux 2.6.32 compiled by myself from the source code >> of kernel.org. >> [...] >> >> This is what I obtain with 'free' in the host: >> >> r...@ubuntu:~# free >> total used free sharedbuffers cached >> Mem: 40603403989512 70828 01804272 95212 >> -/+ buffers/cache:20900281970312 >> Swap: 497972 415680 82292 >> >> >> To what that so high use of swap can be due? > Probably a regression in Linux swapping. Rik, Hugh, are you aware of > any? Hugh posted something but it appears to be performance related, > not causing early swap. > Try setting /proc/sys/vm/swappiness to 0, and running your guests with > cache=none (a good idea in any case). Now that you mention "cache=none", I read it in the document of KVM tuning [1], although I didn't apply it yet. I will consider it to future in my other installations with KVM-88 and qemu-kvm-0.12.1.1 after solving this problem. > Also, qemu might be leaking memory. Please post 'pmap $pid' for all of > your guests (do that before any of the other tests, on your swapped-out > system). - r...@ubuntu:~# pmap 3348 3348: /usr/local/qemu-kvm/bin/qemu-system-x86_64 -hda /dev/vm/backup-raiz -hdb /dev/vm/backup-space -m 512 -boot c -net nic,vlan=0,macaddr=00:16:3e:00:00:32 -net tap -daemonize -vnc :1 -k es -localtime -serial telnet:localhost:4002,server,nowait -monitor telnet:localhost:4042,server,nowait 0040 2220K r-x-- /usr/local/qemu-kvm/bin/qemu-system-x86_64 (deleted) 0082b000124K rw--- /usr/local/qemu-kvm/bin/qemu-system-x86_64 (deleted) 0084a000 8060K rw---[ anon ] 4153d000 4K -[ anon ] 4153e000 8192K rw---[ anon ] 41d3e000 4K -[ anon ] 41d3f000 8192K rw---[ anon ] 7f7c104a4000 3012K rw---[ anon ] 7f7c10795000136K rw---[ anon ] 7f7c107b7000 540688K rw---[ anon ] 7f7c317bb000 40K r-x-- /lib/libnss_files-2.7.so 7f7c317c5000 2048K - /lib/libnss_files-2.7.so 7f7c319c5000 8K rw--- /lib/libnss_files-2.7.so 7f7c319c7000 20K r-x-- /usr/lib/libXdmcp.so.6.0.0 7f7c319cc000 2044K - /usr/lib/libXdmcp.so.6.0.0 7f7c31bcb000 4K rw--- /usr/lib/libXdmcp.so.6.0.0 7f7c31bcc000 8K r-x-- /usr/lib/libXau.so.6.0.0 7f7c31bce000 2044K - /usr/lib/libXau.so.6.0.0 7f7c31dcd000 4K rw--- /usr/lib/libXau.so.6.0.0 7f7c31dce000 12K r-x-- /lib/libgpg-error.so.0.3.0 7f7c31dd1000 2044K - /lib/libgpg-error.so.0.3.0 7f7c31fd 4K rw--- /lib/libgpg-error.so.0.3.0 7f7c31fd1000108K r-x-- /usr/lib/libxcb.so.1.0.0 7f7c31fec000 2044K - /usr/lib/libxcb.so.1.0.0 7f7c321eb000 4K rw--- /usr/lib/libxcb.so.1.0.0 7f7c321ec000 4K r-x-- /usr/lib/libxcb-xlib.so.0.0.0 7f7c321ed000 2044K - /usr/lib/libxcb-xlib.so.0.0.0 7f7c323ec000 4K rw--- /usr/lib/libxcb-xlib.so.0.0.0 7f7c323ed000 80K r-x-- /usr/lib/libdirect-1.0.so.0.1.0 7f7c32401000 2044K - /usr/lib/libdirect-1.0.so.0.1.0 7f7c3260 8K rw--- /usr/lib/libdirect-1.0.so.0.1.0 7f7c32602000 32K r-x-- /usr/lib/libfusion-1.0.so.0.1.0 7f7c3260a000 2044K - /usr/lib/libfusion-1.0.so.0.1.0 7f7c32809000 4K rw--- /usr/lib/libfusion-1.0.so.0.1.0 7f7c3280a000428K r-x-- /usr/lib/libdirectfb-1.0.so.0.1.0 7f7c32875000 2048K - /usr/lib/libdirectfb-1.0.so.0.1.0 7f7c32a75000 12K rw--- /usr/lib/libdirectfb-1.0.so.0.1.0 7f7c32a78000860K r-x-- /usr/lib/libasound.so.2.0.0 7f7c32b4f000 2048K - /usr/lib/libasound.so.2.0.0 7f7c32d4f000 28K rw--- /usr/lib/libasound.so.2.0.0 7f7c32d56000304K r-x-- /lib/libgcrypt.so.11.2.3 7f7c32da2000 2044K - /lib/libgcrypt.so.11.2.3 7f7c32fa1000 12K rw--- /lib/libgcrypt.so.11.2.3 7f7c32fa4000 64K r-x-- /usr/lib/libtasn1.so.3.0.12 7f7c32fb4000 2044K - /usr/lib/libtasn1.so.3.0.12 7f7c331b3000 4K rw--- /usr/lib/libtasn1.so.3.0.12 7f7c331b4000 8K r-x-- /lib/libdl-2.7.so 7f7c331b6000 2048K - /lib/libdl-2.7.so 7f7c333b6000 8K rw--- /lib/libdl-2.7.so 7f7c333b8000 1376K r-x-- /lib/libc-2.7.so 7f7c3351 2048K - /lib/libc-2.7.so 7f7c3371 12K r /lib/libc-2.7.so 7f7c33713000 8K rw--- /lib/libc-2.7.so 7f7c33715000 20K rw---[ anon ] 7f7c3371a000512K r-x-- /lib/libm-2.7.so 7f7c3379a000 2044K - /lib/libm-2.7.so 7f7c33999000 8K rw--- /lib/libm-2.7.so 7f7c3399b000 1020K r-x-- /usr/lib/libX11.so.6.2.0 7f7c33a9a000 2044K -
Re: Memory usage with qemu-kvm-0.12.1.1
On 12/27/2009 11:38 AM, Avi Kivity wrote: On 12/27/2009 06:32 PM, Rik van Riel wrote: Probably a regression in Linux swapping. Rik, Hugh, are you aware of any? Hugh posted something but it appears to be performance related, not causing early swap. Yes, it is a smal bug in the VM. A fix has been committed to 2.6.33 already. Is this b39415b273? Indeed it is. If so, it doesn't copy sta...@kernel.org. Is it queued for -stable? I do not believe that it is queued for -stable. Do performance fixes fit with -stable policy? -- All rights reversed. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: unable to assign devices with VT-d in KVM
[I hope I didn't duplicate my response] I tried it, still have kernel-panic, Currently the message is: " MP-BIOS bug: 8254 timer not connected to IO-APIC Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter " Thanks, Erez -Original Message- From: Avi Kivity [mailto:a...@redhat.com] Sent: Sunday, December 27, 2009 4:36 PM To: Erez Shitrit Cc: kvm@vger.kernel.org Subject: Re: unable to assign devices with VT-d in KVM On 12/27/2009 03:51 PM, Avi Kivity wrote: > > Can you try adding -cpu qemu64,vendorid=GenuineIntel? > Sorry, the correct option is -cpu qemu64,vendor=GenuineIntel. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Memory usage with qemu-kvm-0.12.1.1
On 12/27/2009 06:32 PM, Rik van Riel wrote: Probably a regression in Linux swapping. Rik, Hugh, are you aware of any? Hugh posted something but it appears to be performance related, not causing early swap. Yes, it is a smal bug in the VM. A fix has been committed to 2.6.33 already. Is this b39415b273? If so, it doesn't copy sta...@kernel.org. Is it queued for -stable? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Memory usage with qemu-kvm-0.12.1.1
On 12/27/2009 11:03 AM, Avi Kivity wrote: On 12/27/2009 05:51 PM, Daniel Bareiro wrote: Hi, all! I installed qemu-kvm-0.12.1.1 in one equipment of my house yesterday to test it with Linux 2.6.32 compiled by myself from the source code of kernel.org. From the night of yesterday that I am observing a high use of swap. This is the Service Log Entries from Nagios: 12-26-2009 21:57:33 12-26-2009 23:42:33 0d 1h 45m 0s SERVICE WARNING (HARD) SWAP WARNING - 30% free (142 MB out of 486 MB) 12-26-2009 23:42:33 12-27-2009 00:00:00 0d 0h 17m 27s SERVICE CRITICAL (HARD) SWAP CRITICAL - 9% free (41 MB out of 486 MB) 12-27-2009 00:00:00 12-27-2009 06:27:33 0d 6h 27m 33s SERVICE CRITICAL (HARD) SWAP CRITICAL - 5% free (22 MB out of 486 MB) 12-27-2009 06:27:33 12-27-2009 12:49:51 0d 6h 22m 18s+ SERVICE WARNING (HARD) SWAP WARNING - 14% free (67 MB out of 486 MB) The hour has been ART (GMT-3). The VMs running in this host are the following: ++--+--+ | OS | RAM | SWAP | ++==+==+ | Debian Lenny amd64 | 512 MB | 1 GB / 0 used | | Debian Lenny amd64 | 512 MB | 512 MB / 0 used | | Debian Lenny amd64 | 512 MB | 1 GB / 584k used | | Debian Lenny i386 | 512 MB | 512 MB / 0 used | | OpenBSD 4.6 i386 | 512 MB | 1 GB / 0 used | ++--+--+ This is what I obtain with 'free' in the host: r...@ubuntu:~# free total used free shared buffers cached Mem: 4060340 3989512 70828 0 1804272 95212 -/+ buffers/cache: 2090028 1970312 Swap: 497972 415680 82292 To what that so high use of swap can be due? Probably a regression in Linux swapping. Rik, Hugh, are you aware of any? Hugh posted something but it appears to be performance related, not causing early swap. Yes, it is a smal bug in the VM. A fix has been committed to 2.6.33 already. -- All rights reversed. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Memory usage with qemu-kvm-0.12.1.1
On 12/27/2009 05:51 PM, Daniel Bareiro wrote: Hi, all! I installed qemu-kvm-0.12.1.1 in one equipment of my house yesterday to test it with Linux 2.6.32 compiled by myself from the source code of kernel.org. From the night of yesterday that I am observing a high use of swap. This is the Service Log Entries from Nagios: 12-26-2009 21:57:33 12-26-2009 23:42:33 0d 1h 45m 0sSERVICE WARNING (HARD) SWAP WARNING - 30% free (142 MB out of 486 MB) 12-26-2009 23:42:33 12-27-2009 00:00:00 0d 0h 17m 27s SERVICE CRITICAL (HARD) SWAP CRITICAL - 9% free (41 MB out of 486 MB) 12-27-2009 00:00:00 12-27-2009 06:27:33 0d 6h 27m 33s SERVICE CRITICAL (HARD) SWAP CRITICAL - 5% free (22 MB out of 486 MB) 12-27-2009 06:27:33 12-27-2009 12:49:51 0d 6h 22m 18s+ SERVICE WARNING (HARD) SWAP WARNING - 14% free (67 MB out of 486 MB) The hour has been ART (GMT-3). The VMs running in this host are the following: ++--+--+ | OS |RAM | SWAP| ++==+==+ | Debian Lenny amd64 | 512 MB | 1 GB / 0 used| | Debian Lenny amd64 | 512 MB | 512 MB / 0 used | | Debian Lenny amd64 | 512 MB | 1 GB / 584k used | | Debian Lenny i386 | 512 MB | 512 MB / 0 used | | OpenBSD 4.6 i386 | 512 MB | 1 GB / 0 used| ++--+--+ This is what I obtain with 'free' in the host: r...@ubuntu:~# free total used free sharedbuffers cached Mem: 40603403989512 70828 01804272 95212 -/+ buffers/cache:20900281970312 Swap: 497972 415680 82292 To what that so high use of swap can be due? Probably a regression in Linux swapping. Rik, Hugh, are you aware of any? Hugh posted something but it appears to be performance related, not causing early swap. Try setting /proc/sys/vm/swappiness to 0, and running your guests with cache=none (a good idea in any case). Also, qemu might be leaking memory. Please post 'pmap $pid' for all of your guests (do that before any of the other tests, on your swapped-out system). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Memory usage with qemu-kvm-0.12.1.1
Hi, all! I installed qemu-kvm-0.12.1.1 in one equipment of my house yesterday to test it with Linux 2.6.32 compiled by myself from the source code of kernel.org. From the night of yesterday that I am observing a high use of swap. This is the Service Log Entries from Nagios: 12-26-2009 21:57:33 12-26-2009 23:42:33 0d 1h 45m 0sSERVICE WARNING (HARD) SWAP WARNING - 30% free (142 MB out of 486 MB) 12-26-2009 23:42:33 12-27-2009 00:00:00 0d 0h 17m 27s SERVICE CRITICAL (HARD) SWAP CRITICAL - 9% free (41 MB out of 486 MB) 12-27-2009 00:00:00 12-27-2009 06:27:33 0d 6h 27m 33s SERVICE CRITICAL (HARD) SWAP CRITICAL - 5% free (22 MB out of 486 MB) 12-27-2009 06:27:33 12-27-2009 12:49:51 0d 6h 22m 18s+ SERVICE WARNING (HARD) SWAP WARNING - 14% free (67 MB out of 486 MB) The hour has been ART (GMT-3). The VMs running in this host are the following: ++--+--+ | OS |RAM | SWAP| ++==+==+ | Debian Lenny amd64 | 512 MB | 1 GB / 0 used| | Debian Lenny amd64 | 512 MB | 512 MB / 0 used | | Debian Lenny amd64 | 512 MB | 1 GB / 584k used | | Debian Lenny i386 | 512 MB | 512 MB / 0 used | | OpenBSD 4.6 i386 | 512 MB | 1 GB / 0 used| ++--+--+ This is what I obtain with 'free' in the host: r...@ubuntu:~# free total used free sharedbuffers cached Mem: 40603403989512 70828 01804272 95212 -/+ buffers/cache:20900281970312 Swap: 497972 415680 82292 To what that so high use of swap can be due? Thank in advance for your replies. Regards, Daniel -- Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37 Powered by Debian GNU/Linux Lenny - Linux user #188.598 signature.asc Description: Digital signature
[PATCH] KVM: Bump maximum vcpu count to 64
With slots_lock converted to rcu, the entire kvm hotpath on modern processors (with npt or ept) now scales beautifully. Increase the maximum vcpu count to 64 to reflect this. Signed-off-by: Avi Kivity --- arch/x86/include/asm/kvm_host.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 6c8c7c5..741b897 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -25,7 +25,7 @@ #include #include -#define KVM_MAX_VCPUS 16 +#define KVM_MAX_VCPUS 64 #define KVM_MEMORY_SLOTS 32 /* memory slots that does not exposed to userspace */ #define KVM_PRIVATE_MEM_SLOTS 4 -- 1.6.5.3 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unable to assign devices with VT-d in KVM
On 12/27/2009 03:51 PM, Avi Kivity wrote: Can you try adding -cpu qemu64,vendorid=GenuineIntel? Sorry, the correct option is -cpu qemu64,vendor=GenuineIntel. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/27/09 8:49 AM, Avi Kivity wrote: > On 12/27/2009 03:34 PM, Gregory Haskins wrote: >> On 12/27/09 4:33 AM, Avi Kivity wrote: >> >>> On 12/24/2009 11:36 AM, Gregory Haskins wrote: >>> > As a twist on this, the VMware paravirt driver interface is so > hardware-like that they're getting hardware vendors to supply cards > that > implement it. Try that with a pure software approach. > > Any hardware engineer (myself included) will tell you that, generally speaking, what you can do in hardware you can do in software (think of what QEMU does today, for instance). It's purely a cost/performance tradeoff. I can at least tell you that is true of vbus. Anything on the vbus side would be equally eligible for a hardware implementation, though there is not reason to do this today since we have equivalent functionality in baremetal already. >>> There's a huge difference in the probability of vmware getting cards to >>> their spec, or x86 vendors improving interrupt delivery to guests, >>> compared to vbus being implemented in hardware. >>> >> Thats not relevant, however. I said in the original quote that you >> snipped that I made it a software design on purpose, and you tried to >> somehow paint that as a negative because vmware made theirs >> "hardware-like" and you implied it could not be done with my approach >> with the statement "try that with a pure software approach". And the >> bottom line is that the statement is incorrect and/or misleading. >> > > It's not incorrect. At the very best it's misleading. > VMware stuck to the pci specs and as a result they > can have hardware implement their virtual NIC protocol. For vbus this > is much harder Not really. > to do since you need a side-channel between different > cards to coordinate interrupt delivery. In theory you can do eveything > if you don't consider practicalities. pci based designs, such as vmware and virtio-pci arent free of this notion either. They simply rely on APIC emulation for the irq-chip, and it just so happens that vbus implements a different irq-chip (more specifically, the connector that we employ between the guest and vbus does). On one hand, you have the advantage of the guest already supporting the irq-chip ABI, and on other other, you have an optimized (e.g. shared memory based inject/ack) and feature enhanced ABI (interrupt priority, no IDT constraints, etc). The are pros and cons to either direction, but the vbus project charter is to go for maximum performance and features, so that is acceptable to us. > > That's a digression, though, I'm not suggesting we'll see virtio > hardware or that this is a virtio/pci advantage vs. vbus. It's an > anecdote showing that sticking with specs has its advantages. It also has distinct disadvantages. For instance, the PCI spec is gigantic, yet almost none of it is needed to do the job here. When you are talking full-virt, you are left with no choice. With para-virt, you do have a choice, and the vbus-connector for AlacrityVM capitalizes on this. As an example, think about all the work that went into emulating the PCI chipset, the APIC chipset, MSI-X support, irq-routing, etc, when all you needed was a simple event-queue to indicate that an event (e.g. an "interrupt") occurred. This is an example connector in vbus: http://git.kernel.org/?p=linux/kernel/git/ghaskins/alacrityvm/linux-2.6.git;a=blob;f=kernel/vbus/connectors/null.c;h=b6d16cb68b7e49e07528278bc9f5b73e1dac0c2f;hb=HEAD It encapsulates all of hotplug, signal (interrupt) routing, and memory routing for both sides of the "link" in 584 lines of code. And that also implicitly brings in device discovery and configuration since that is covered by the vbus framework. Try doing that with PCI, especially when you are not already under the qemu umbrella, and the "standards based" approach suddenly doesn't look very attractive. > > wrt pci vs vbus, the difference is in the ability to use improvements in > interrupt delivery accelerations in virt hardware. Most of which will also apply to the current vbus design as well since at some point I have to have an underlying IDT mechanism too, btw. > If this happens, > virtio/pci can immediately take advantage of it, while vbus has to stick > with software delivery for backward compatibility, and all that code > becomes a useless support burden. > The shared-memory path will always be the fastest anyway, so I am not too worried about it. But vbus supports feature negotiation, so we can always phase that out if need be, same as anything else. > As an example of what hardware can do when it really sets its mind to > it, s390 can IPI from vcpu to vcpu without exiting to the host. Great! I am just not in the practice of waiting for hardware to cover sloppy software. There is a ton of impracticality in doing so, such as the fact that the hardware, even once
Re: unable to assign devices with VT-d in KVM
On 12/27/2009 03:48 PM, Erez Shitrit wrote: The qemu commandline is: /usr/local/bin/qemu-system-x86_64 -m 1024 -boot c -net none -hda /sdb5/images/test2.img The guest kernel is rh5.4 The cpu type is: Intel(R) Xeon(R) CPU X5550 @ 2.67GHz With VT-d enabled. I loaded kvm and kvm-intel [r...@sw379 2.6.18-179-prep]# lsmod | grep kvm kvm_intel 86248 0 kvm 223520 1 kvm_intel Can you try adding -cpu qemu64,vendorid=GenuineIntel? Also try not top-posting. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Alacrityvm-devel] [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/27/2009 03:39 PM, Gregory Haskins wrote: No, where we are is at the point where we demonstrate that your original statement that I did nothing to improve virtio was wrong. I stand by it. virtio + your patch does nothing without a ton more work (more or less equivalent to vhost-net). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/27/2009 03:34 PM, Gregory Haskins wrote: On 12/27/09 4:33 AM, Avi Kivity wrote: On 12/24/2009 11:36 AM, Gregory Haskins wrote: As a twist on this, the VMware paravirt driver interface is so hardware-like that they're getting hardware vendors to supply cards that implement it. Try that with a pure software approach. Any hardware engineer (myself included) will tell you that, generally speaking, what you can do in hardware you can do in software (think of what QEMU does today, for instance). It's purely a cost/performance tradeoff. I can at least tell you that is true of vbus. Anything on the vbus side would be equally eligible for a hardware implementation, though there is not reason to do this today since we have equivalent functionality in baremetal already. There's a huge difference in the probability of vmware getting cards to their spec, or x86 vendors improving interrupt delivery to guests, compared to vbus being implemented in hardware. Thats not relevant, however. I said in the original quote that you snipped that I made it a software design on purpose, and you tried to somehow paint that as a negative because vmware made theirs "hardware-like" and you implied it could not be done with my approach with the statement "try that with a pure software approach". And the bottom line is that the statement is incorrect and/or misleading. It's not incorrect. VMware stuck to the pci specs and as a result they can have hardware implement their virtual NIC protocol. For vbus this is much harder to do since you need a side-channel between different cards to coordinate interrupt delivery. In theory you can do eveything if you don't consider practicalities. That's a digression, though, I'm not suggesting we'll see virtio hardware or that this is a virtio/pci advantage vs. vbus. It's an anecdote showing that sticking with specs has its advantages. wrt pci vs vbus, the difference is in the ability to use improvements in interrupt delivery accelerations in virt hardware. If this happens, virtio/pci can immediately take advantage of it, while vbus has to stick with software delivery for backward compatibility, and all that code becomes a useless support burden. As an example of what hardware can do when it really sets its mind to it, s390 can IPI from vcpu to vcpu without exiting to the host. The only motiviation is if you wanted to preserve ABI etc, which is what vmware is presumably after. However, I am not advocating this as necessary at this juncture. Maybe AlacrityVM users don't care about compatibility, but my users do. Again, not relevant to this thread. Making your interface "hardware-like" buys you nothing in the end, as you ultimately need to load drivers in the guest either way, and any major OS lets you extend both devices and buses with relative ease. The only counter example would be if you truly were "hardware-exactly" like e1000 emulation, but we already know that this means it is hardware centric and not "exit-rate aware" and would perform poorly. Otherwise "compatible" is purely a point on the time line (for instance, the moment virtio-pci ABI shipped), not an architectural description such as "hardware-like". True, not related to the thread. But it is a problem. The difference between virtio and vbus here is that virtio is already deployed and its users expect not to reinstall drivers [1]. Before virtio existed, people could not deploy performance sensitive applications on kvm. Now that it exists, we have to support it without requiring users to touch their guests. That means that without proof that virtio cannot be scaled, we'll keep supporting and extending it. [1] Another difference is the requirement for writing a "bus driver" for every supported guest, which means dealing with icky bits like hotplug. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: unable to assign devices with VT-d in KVM
The qemu commandline is: /usr/local/bin/qemu-system-x86_64 -m 1024 -boot c -net none -hda /sdb5/images/test2.img The guest kernel is rh5.4 The cpu type is: Intel(R) Xeon(R) CPU X5550 @ 2.67GHz With VT-d enabled. I loaded kvm and kvm-intel [r...@sw379 2.6.18-179-prep]# lsmod | grep kvm kvm_intel 86248 0 kvm 223520 1 kvm_intel Thanks, Erez -Original Message- From: Avi Kivity [mailto:a...@redhat.com] Sent: Sunday, December 27, 2009 3:37 PM To: Erez Shitrit Cc: kvm@vger.kernel.org Subject: Re: unable to assign devices with VT-d in KVM On 12/27/2009 03:09 PM, Erez Shitrit wrote: > Thanks, > Now, it seams that I have a problem with the kvm, whenever I tried to > create a new virtual machine and the kvm module is loaded I got kernel > panic in the virtual machine. > > The panic: > > " ... > Code: 0f 30 b8 76 00 13 00 89 d9 0f 30 48 c7 c6 17 41 2a 80 89 fa RIP > [] setup_k7_watchdog+0x2d/0x7a RSP > <0>Kernel panic - not syncing: Fatal exception ... > " > > (If I remove the kvm module it works) > > The kvm version: > kvm-83-105.el5_4.13 > > The KVM did not arrived with the RH5.4 distribution, I installed it > manually. > From the package: kvm-83-105.el5_4.13.x86_64.rpm > > Do I need specific version of the kvm with that qemu ? > > What guest kernel are you running? What qemu command line? Looks like your guest thinks it's running on an Athlon. What's your host cpu type? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Alacrityvm-devel] [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/27/09 8:27 AM, Avi Kivity wrote: > On 12/27/2009 03:18 PM, Gregory Haskins wrote: >> On 12/27/09 4:15 AM, Avi Kivity wrote: >> >>> On 12/23/2009 11:21 PM, Gregory Haskins wrote: >>> That said, you are still incorrect. With what I proposed, the model will run as an in-kernel vbus device, and no longer run in userspace. It would therefore improve virtio-net as I stated, much in the same way vhost-net or venet-tap do today. >>> That can't work. virtio-net has its own ABI on top of virtio, for >>> example it prepends a header for TSO information. Maybe if you disable >>> all features it becomes compatible with venet, but that cripples it. >>> >>> >> You are confused. The backend would be virtio-net specific, and would >> therefore understand the virtio-net ABI. It would support any feature >> of virtio-net as long as it was implemented and negotiated by both sides >> of the link. >> > > Then we're back to square one. A nice demonstration of vbus > flexibility, but no help for virtio. > No, where we are is at the point where we demonstrate that your original statement that I did nothing to improve virtio was wrong. -Greg signature.asc Description: OpenPGP digital signature
Re: unable to assign devices with VT-d in KVM
On 12/27/2009 03:09 PM, Erez Shitrit wrote: Thanks, Now, it seams that I have a problem with the kvm, whenever I tried to create a new virtual machine and the kvm module is loaded I got kernel panic in the virtual machine. The panic: " ... Code: 0f 30 b8 76 00 13 00 89 d9 0f 30 48 c7 c6 17 41 2a 80 89 fa RIP [] setup_k7_watchdog+0x2d/0x7a RSP <0>Kernel panic - not syncing: Fatal exception ... " (If I remove the kvm module it works) The kvm version: kvm-83-105.el5_4.13 The KVM did not arrived with the RH5.4 distribution, I installed it manually. From the package: kvm-83-105.el5_4.13.x86_64.rpm Do I need specific version of the kvm with that qemu ? What guest kernel are you running? What qemu command line? Looks like your guest thinks it's running on an Athlon. What's your host cpu type? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/27/09 4:33 AM, Avi Kivity wrote: > On 12/24/2009 11:36 AM, Gregory Haskins wrote: >>> As a twist on this, the VMware paravirt driver interface is so >>> hardware-like that they're getting hardware vendors to supply cards that >>> implement it. Try that with a pure software approach. >>> >> Any hardware engineer (myself included) will tell you that, generally >> speaking, what you can do in hardware you can do in software (think of >> what QEMU does today, for instance). It's purely a cost/performance >> tradeoff. >> >> I can at least tell you that is true of vbus. Anything on the vbus side >> would be equally eligible for a hardware implementation, though there is >> not reason to do this today since we have equivalent functionality in >> baremetal already. > > There's a huge difference in the probability of vmware getting cards to > their spec, or x86 vendors improving interrupt delivery to guests, > compared to vbus being implemented in hardware. Thats not relevant, however. I said in the original quote that you snipped that I made it a software design on purpose, and you tried to somehow paint that as a negative because vmware made theirs "hardware-like" and you implied it could not be done with my approach with the statement "try that with a pure software approach". And the bottom line is that the statement is incorrect and/or misleading. > >> The only motiviation is if you wanted to preserve >> ABI etc, which is what vmware is presumably after. However, I am not >> advocating this as necessary at this juncture. >> > > Maybe AlacrityVM users don't care about compatibility, but my users do. Again, not relevant to this thread. Making your interface "hardware-like" buys you nothing in the end, as you ultimately need to load drivers in the guest either way, and any major OS lets you extend both devices and buses with relative ease. The only counter example would be if you truly were "hardware-exactly" like e1000 emulation, but we already know that this means it is hardware centric and not "exit-rate aware" and would perform poorly. Otherwise "compatible" is purely a point on the time line (for instance, the moment virtio-pci ABI shipped), not an architectural description such as "hardware-like". > signature.asc Description: OpenPGP digital signature
Re: [Alacrityvm-devel] [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/27/2009 03:18 PM, Gregory Haskins wrote: On 12/27/09 4:15 AM, Avi Kivity wrote: On 12/23/2009 11:21 PM, Gregory Haskins wrote: That said, you are still incorrect. With what I proposed, the model will run as an in-kernel vbus device, and no longer run in userspace. It would therefore improve virtio-net as I stated, much in the same way vhost-net or venet-tap do today. That can't work. virtio-net has its own ABI on top of virtio, for example it prepends a header for TSO information. Maybe if you disable all features it becomes compatible with venet, but that cripples it. You are confused. The backend would be virtio-net specific, and would therefore understand the virtio-net ABI. It would support any feature of virtio-net as long as it was implemented and negotiated by both sides of the link. Then we're back to square one. A nice demonstration of vbus flexibility, but no help for virtio. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Alacrityvm-devel] [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/27/09 4:15 AM, Avi Kivity wrote: > On 12/23/2009 11:21 PM, Gregory Haskins wrote: >> That said, you are still incorrect. With what I proposed, the model >> will run as an in-kernel vbus device, and no longer run in userspace. >> It would therefore improve virtio-net as I stated, much in the same >> way vhost-net or venet-tap do today. >> > > That can't work. virtio-net has its own ABI on top of virtio, for > example it prepends a header for TSO information. Maybe if you disable > all features it becomes compatible with venet, but that cripples it. > You are confused. The backend would be virtio-net specific, and would therefore understand the virtio-net ABI. It would support any feature of virtio-net as long as it was implemented and negotiated by both sides of the link. -Greg signature.asc Description: OpenPGP digital signature
Re: [patch 00/11] convert slotslock to SRCU
On 12/23/2009 01:38 PM, Marcelo Tosatti wrote: Now that synchronize_srcu_expedited is in the tree, we can continue the convertion of slots_lock to SRCU. Results: up: Without this patchset, -smp 64 is simply unusable. An _idle_ Linux guest generates enough interrupts that the system is unable to make any progress: [r...@monster01 ~]# perf report -g # Samples: 14214748264314 # # Overhead Command Shared Object Symbol # ... . .. # 40.81% qemu-system-x86 [kernel] [k] _raw_spin_lock_irq | --- _raw_spin_lock_irq | |--99.94%-- __down_read | down_read | | | |--99.82%-- 0xa00479c4 | | 0xa003a6c9 | | vfs_ioctl | | do_vfs_ioctl | | sys_ioctl | | system_call | | __GI_ioctl | --0.18%-- [...] --0.06%-- [...] 40.57% qemu-system-x86 [kernel] [k] _raw_spin_lock_irqsave | --- _raw_spin_lock_irqsave | |--99.88%-- __up_read | up_read | | | |--99.82%-- 0xa0047897 | | 0xa003a6c9 | | vfs_ioctl | | do_vfs_ioctl | | sys_ioctl | | system_call | | __GI_ioctl | --0.18%-- [...] --0.12%-- [...] With this patchset, -smp 64 flies. Patch to follow. Amazing work! (and surprising how easy it is to saturate a large system) -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: unable to assign devices with VT-d in KVM
Thanks, Now, it seams that I have a problem with the kvm, whenever I tried to create a new virtual machine and the kvm module is loaded I got kernel panic in the virtual machine. The panic: " ... Code: 0f 30 b8 76 00 13 00 89 d9 0f 30 48 c7 c6 17 41 2a 80 89 fa RIP [] setup_k7_watchdog+0x2d/0x7a RSP <0>Kernel panic - not syncing: Fatal exception ... " (If I remove the kvm module it works) The kvm version: kvm-83-105.el5_4.13 The KVM did not arrived with the RH5.4 distribution, I installed it manually. >From the package: kvm-83-105.el5_4.13.x86_64.rpm Do I need specific version of the kvm with that qemu ? Thanks again, Erez -Original Message- From: Avi Kivity [mailto:a...@redhat.com] Sent: Sunday, December 27, 2009 1:10 PM To: Erez Shitrit Cc: kvm@vger.kernel.org Subject: Re: unable to assign devices with VT-d in KVM On 12/27/2009 12:07 PM, Erez Shitrit wrote: > Hi, > I am KVM newbie, trying to run and use the KVM. > When I tried to assign pci device to new virtual machine I got the > next > error: > > /usr/local/bin/qemu-system-x86_64: invalid option -- '-pcidevice' > > I followed the instructions in the > http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM > page, > I am using RH5_4 with the new kernel for rh5.5: 2.6.18-prep > (2.6.18.197) I run the next command > /usr/local/bin/qemu-system-x86_64 -m 512 -boot c -net none -hda > /sdb5/images/test2.img -pcidevice host=04:00.0 > > And I got > > /usr/local/bin/qemu-system-x86_64: invalid option -- '-pcidevice' > > > The qemu-system-x86_64 version is: > QEMU PC emulator version 0.11.91, Copyright (c) 2003-2008 Fabrice > Bellard > > What I missed? > > You're running the upstream qemu, which doesn't support device assignment. Download qemu-kvm-0.12.1.1 from http://linux-kvm.org. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unable to assign devices with VT-d in KVM
On 12/27/2009 12:07 PM, Erez Shitrit wrote: Hi, I am KVM newbie, trying to run and use the KVM. When I tried to assign pci device to new virtual machine I got the next error: /usr/local/bin/qemu-system-x86_64: invalid option -- '-pcidevice' I followed the instructions in the http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM page, I am using RH5_4 with the new kernel for rh5.5: 2.6.18-prep (2.6.18.197) I run the next command /usr/local/bin/qemu-system-x86_64 -m 512 -boot c -net none -hda /sdb5/images/test2.img -pcidevice host=04:00.0 And I got /usr/local/bin/qemu-system-x86_64: invalid option -- '-pcidevice' The qemu-system-x86_64 version is: QEMU PC emulator version 0.11.91, Copyright (c) 2003-2008 Fabrice Bellard What I missed? You're running the upstream qemu, which doesn't support device assignment. Download qemu-kvm-0.12.1.1 from http://linux-kvm.org. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unable to assign devices with VT-d in KVM
> > > The qemu-system-x86_64 version is: > QEMU PC emulator version 0.11.91, Copyright (c) 2003-2008 > Fabrice Bellard there should be somewhere "kvm" or "qemu-kvm" in it. my version looks like that: QEMU PC emulator version 0.11.0 (qemu-kvm-0.11.0), Copyright (c) 2003-2008 Fabrice Bellard looks like you're using plain qemu. - Thomas -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel memory allocation bug in 2.6.27.32-2.6.27.41 kvm section
On 12/17/2009 05:35 PM, Oscon wrote: Hello! I can't register new account in bugzilla.kernel.org. / my ISP's spamfilter problem (?) maybe./ -- I sent this mail to Greg KH (2.6.27.y maintainer), he sent me: "Can you get the kvm maintainers to agree that this is correct? thanks, greg k-h" --- So the bug : I found a memory allocation bug in kvm/mmu.c& kvm_main.c. /in kvm_destroy_vm()/ Affected kernel: 2.6.27.32-2.6.27.41 Mainline kernel (2.6.32) is not affected. (Modified kvm subsystem.) Cause: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fstable%2Flinux-2.6.27.y.git;a=commitdiff_plain;h=d2127c8300fb1ec54af56faee17170e7a525326d Solution: Revert this patch. This bug can cause local DoS in the host system. Looks like some other patch is missing in 2.6.27.y. Not sure what it is. But it's safer to revert this patch for now. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
unable to assign devices with VT-d in KVM
Hi, I am KVM newbie, trying to run and use the KVM. When I tried to assign pci device to new virtual machine I got the next error: /usr/local/bin/qemu-system-x86_64: invalid option -- '-pcidevice' I followed the instructions in the http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM page, I am using RH5_4 with the new kernel for rh5.5: 2.6.18-prep (2.6.18.197) I run the next command /usr/local/bin/qemu-system-x86_64 -m 512 -boot c -net none -hda /sdb5/images/test2.img -pcidevice host=04:00.0 And I got /usr/local/bin/qemu-system-x86_64: invalid option -- '-pcidevice' The qemu-system-x86_64 version is: QEMU PC emulator version 0.11.91, Copyright (c) 2003-2008 Fabrice Bellard What I missed? Thanks, Erez -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/24/2009 11:36 AM, Gregory Haskins wrote: As a twist on this, the VMware paravirt driver interface is so hardware-like that they're getting hardware vendors to supply cards that implement it. Try that with a pure software approach. Any hardware engineer (myself included) will tell you that, generally speaking, what you can do in hardware you can do in software (think of what QEMU does today, for instance). It's purely a cost/performance tradeoff. I can at least tell you that is true of vbus. Anything on the vbus side would be equally eligible for a hardware implementation, though there is not reason to do this today since we have equivalent functionality in baremetal already. There's a huge difference in the probability of vmware getting cards to their spec, or x86 vendors improving interrupt delivery to guests, compared to vbus being implemented in hardware. The only motiviation is if you wanted to preserve ABI etc, which is what vmware is presumably after. However, I am not advocating this as necessary at this juncture. Maybe AlacrityVM users don't care about compatibility, but my users do. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/24/2009 11:31 AM, Gregory Haskins wrote: On 12/23/09 3:36 PM, Avi Kivity wrote: On 12/23/2009 06:44 PM, Gregory Haskins wrote: - Are a pure software concept By design. In fact, I would describe it as "software to software optimized" as opposed to trying to shoehorn into something that was designed as a software-to-hardware interface (and therefore has assumptions about the constraints in that environment that are not applicable in software-only). And that's the biggest mistake you can make. Sorry, that is just wrong or you wouldn't have virtio either. Things are not black and white. I prefer not to have paravirtualization at all. When there is no alternative, I prefer to limit it to the device level and keep it off the bus level. Look at Xen, for instance. The paravirtualized the fork out of everything that moved in order to get x86 virt going. And where are they now? x86_64 syscalls are slow since they have to trap to the hypervisor and (partially) flush the tlb. With npt or ept capable hosts performance is better for many workloads on fullvirt. And paravirt doesn't support Windows. Their unsung hero Jeremy is still trying to upstream dom0 Xen support. And they get to support it forever. We are only talking about PV-IO here, so not apples to apples to what Xen is going through. The same principles apply. VMware stuck with the hardware defined interfaces. Sure they had to implement binary translation to get there, but as a result, they only have to support one interface, all guests support it, and they can drop it on newer hosts where it doesn't give them anything. Again, you are confusing PV-IO. Not relevant here. Afaict, vmware, kvm, xen, etc, all still do PV-IO and likely will for the foreseeable future. They're all doing it very differently: - pure emulation (qemu e1000, etc.) - pci device (vmware, virtio/pci) - paravirt bus bridged through a pci device (Xen hvm, Hyper-V (I think), venet/vbus) - paravirt bus (Xen pv, early vbus, virtio/lguest, virtio/s390) The higher you are up this scale the easier things are, so once you get reasonable performance there is no need to descend further. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Alacrityvm-devel] [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/23/2009 11:21 PM, Gregory Haskins wrote: That said, you are still incorrect. With what I proposed, the model will run as an in-kernel vbus device, and no longer run in userspace. It would therefore improve virtio-net as I stated, much in the same way vhost-net or venet-tap do today. That can't work. virtio-net has its own ABI on top of virtio, for example it prepends a header for TSO information. Maybe if you disable all features it becomes compatible with venet, but that cripples it. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
