[COMMIT] [WIN-GUEST_DRIVERS] Update viostor drivers (WinXP support, MSI support, new build scripts)
repository: C:/dev/kvm-guest-drivers-windows branch: master commit 70fff68250b1a33e8576c41eaf6e79c13b72730f Author: Yan Vugenfirer yvuge...@redhat.com Date: Wed Mar 31 17:42:35 2010 +0300 [WIN-GUEST_DRIVERS] Update viostor drivers (WinXP support, MSI support, new build scripts) Signed-off-by: Vadim Rozenfeld vroze...@redhat.com diff --git a/viostor/SOURCES b/viostor/SOURCES index edc46ef..5701b78 100644 --- a/viostor/SOURCES +++ b/viostor/SOURCES @@ -6,6 +6,7 @@ C_DEFINES = -DUSE_STORPORT=1 $(C_DEFINES) TARGETLIBS=$(SDK_LIB_PATH)\storport.lib !elseif $(DDK_TARGET_OS) == WinLH C_DEFINES = -DUSE_STORPORT=1 $(C_DEFINES) +C_DEFINES = -DMSI_SUPPORTED=1 $(C_DEFINES) TARGETLIBS=$(SDK_LIB_PATH)\storport.lib !elseif $(DDK_TARGET_OS) == WinXP TARGETLIBS=$(SDK_LIB_PATH)\scsiport.lib diff --git a/viostor/buildAll.bat b/viostor/buildAll.bat index 668efe7..526c368 100644 --- a/viostor/buildAll.bat +++ b/viostor/buildAll.bat @@ -1,90 +1,74 @@ -: -: Set global parameters: -: +...@echo off -: Use Windows 7 DDK -if %DDKVER%== set DDKVER=7600.16385.0 +set SYS_FILE_NAME=viostor -: By default DDK is installed under C:\WINDDK, but it can be installed in different location -if %DDKISNTALLROOT%== set DDKISNTALLROOT=C:\WINDDK\ -set BUILDROOT=%DDKISNTALLROOT%%DDKVER% -set X64ENV=x64 -if %DDKVER%==6000 set X64ENV=amd64 +for %%A in (Win7 Wnet Wlh WXp) do for %%B in (32 64) do call :%%A_%%B +goto :eof -if not %1== goto parameters_here -echo no parameters specified, rebuild all -call clean.bat -call %0 WIN7 WIN7_64 Vista Vista64 Win2003 Win200364 XP +:buildsys +call buildOne.bat %1 %2 goto :eof -:parameters_here -:nextparam -if %1== goto :eof -goto %1 -:continue -shift -goto nextparam - -:Win7 -set DDKBUILDENV= -pushd %BUILDROOT% -call %BUILDROOT%\bin\setenv.bat %BUILDROOT% fre WIN7 -popd -build -cZg - -goto continue - -:Win7_64 -set DDKBUILDENV= -pushd %BUILDROOT% -call %BUILDROOT%\bin\setenv.bat %BUILDROOT% %X64ENV% fre WIN7 -popd -build -cZg - -goto continue - - -:Vista -set DDKBUILDENV= -pushd %BUILDROOT% -call %BUILDROOT%\bin\setenv.bat %BUILDROOT% fre Wlh -popd -build -cZg +:packsys +call packOne.bat %1 %2 %SYS_FILE_NAME% %3 +goto :eof -goto continue +:buildpack +call :buildsys %1 %2 +call :packsys %1 %2 %3 +set BUILD_OS= +set BUILD_ARC= +set INF_FILE_NAME= +goto :eof -:Vista64 -set DDKBUILDENV= -pushd %BUILDROOT% -call %BUILDROOT%\bin\setenv.bat %BUILDROOT% %X64ENV% fre Wlh -popd -build -cZg +:WIN7_32 +set BUILD_OS=Win7 +set BUILD_ARC=x86 +set INF_FILE_NAME=Wlh +call :buildpack %BUILD_OS% %BUILD_ARC% %INF_FILE_NAME% +goto :eof -goto continue +:WIN7_64 +set BUILD_OS=Win7 +set BUILD_ARC=x64 +set INF_FILE_NAME=Wlh +call :buildpack %BUILD_OS% %BUILD_ARC% %INF_FILE_NAME% +goto :eof -:Win2003 -set DDKBUILDENV= -pushd %BUILDROOT% -call %BUILDROOT%\bin\setenv.bat %BUILDROOT% fre WNET -popd -build -cZg +:WLH_32 +set BUILD_OS=Wlh +set BUILD_ARC=x86 +set INF_FILE_NAME=Wlh +call :buildpack %BUILD_OS% %BUILD_ARC% %INF_FILE_NAME% +goto :eof -goto continue +:WLH_64 +set BUILD_OS=Wlh +set BUILD_ARC=x64 +set INF_FILE_NAME=Wlh +call :buildpack %BUILD_OS% %BUILD_ARC% %INF_FILE_NAME% +goto :eof -:Win200364 -set DDKBUILDENV= -pushd %BUILDROOT% -call %BUILDROOT%\bin\setenv.bat %BUILDROOT% %X64ENV% fre WNET -popd -build -cZg +:WNET_32 +set BUILD_OS=Wnet +set BUILD_ARC=x86 +set INF_FILE_NAME=Wnet +call :buildpack %BUILD_OS% %BUILD_ARC% %INF_FILE_NAME% +goto :eof -goto continue +:WNET_64 +set BUILD_OS=Wnet +set BUILD_ARC=x64 +set INF_FILE_NAME=Wnet +call :buildpack %BUILD_OS% %BUILD_ARC% %INF_FILE_NAME% +goto :eof -:XP -set DDKBUILDENV= -pushd %BUILDROOT% -call %BUILDROOT%\bin\setenv.bat %BUILDROOT% fre WXP -popd -build -cZg +:WXP_32 +set BUILD_OS=WXp +set BUILD_ARC=x86 +set INF_FILE_NAME=Wxp +call :buildpack %BUILD_OS% %BUILD_ARC% %INF_FILE_NAME% +goto :eof +:WXP_64 goto :eof diff --git a/viostor/buildDDK.bat b/viostor/buildDDK.bat deleted file mode 100644 index 8c39eee..000 --- a/viostor/buildDDK.bat +++ /dev/null @@ -1,7 +0,0 @@ -set DDKVER=6001.18001 -set BUILDROOT=C:\WINDDK\%DDKVER% -pushd %BUILDROOT% -set X64ENV=x64 -call %BUILDROOT%\bin\setenv.bat %BUILDROOT% fre %1 %2 -popd -build -cZg diff --git a/viostor/buildOne.bat b/viostor/buildOne.bat new file mode 100644 index 000..8ecc35d --- /dev/null +++ b/viostor/buildOne.bat @@ -0,0 +1,13 @@ +...@echo off + +if %DDKVER%== set DDKVER=7600.16385.0 +set BUILDROOT=C:\WINDDK\%DDKVER% + +set DDKBUILDENV= +pushd %BUILDROOT% +call %BUILDROOT%\bin\setenv.bat %BUILDROOT% %2 fre %1 no_oacr +popd +build -cZg + +set DDKVER= +set BUILDROOT= \ No newline at end of file diff --git a/viostor/buildOne_bat b/viostor/buildOne_bat new file mode 100644 index 000..8ecc35d --- /dev/null +++ b/viostor/buildOne_bat @@ -0,0 +1,13 @@ +...@echo off + +if %DDKVER%== set DDKVER=7600.16385.0 +set BUILDROOT=C:\WINDDK\%DDKVER% + +set DDKBUILDENV= +pushd %BUILDROOT% +call %BUILDROOT%\bin\setenv.bat %BUILDROOT% %2 fre %1 no_oacr +popd +build -cZg + +set DDKVER=
Re: [PATCH 1/2] KVM test: Make the profiler could be configurated
Michael Goldish wrote: - Jason Wang jasow...@redhat.com wrote: The patch let the profilers could be specified through configuration file. kvm_stat was kept as the default profiler. Looks good. Some minor style comments: Thanks for the comment, would re-send the patch. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] KVM test: Make the profiler could be configurated
The patch let the profilers could be specified through configuration
file. kvm_stat was kept as the default profiler.
Signed-off-by: Jason Wang jasow...@redhat.com
---
client/tests/kvm/kvm_utils.py | 21 -
client/tests/kvm/tests_base.cfg.sample |2 +-
2 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/client/tests/kvm/kvm_utils.py b/client/tests/kvm/kvm_utils.py
index 8531c79..25f3c8c 100644
--- a/client/tests/kvm/kvm_utils.py
+++ b/client/tests/kvm/kvm_utils.py
@@ -866,24 +866,19 @@ def run_tests(test_list, job):
if dependencies_satisfied:
test_iterations = int(dict.get(iterations, 1))
test_tag = dict.get(shortname)
-# Setting up kvm_stat profiling during test execution.
-# We don't need kvm_stat profiling on the build tests.
-if dict.get(run_kvm_stat) == yes:
-profile = True
-else:
-# None because it's the default value on the base_test class
-# and the value None is specifically checked there.
-profile = None
+# Setting up profilers during test execution.
+profilers = dict.get(profilers, ).split()
+for profiler in profilers:
+job.profilers.add(profiler)
-if profile:
-job.profilers.add('kvm_stat')
# We need only one execution, profiled, hence we're passing
# the profile_only parameter to job.run_test().
current_status = job.run_test(kvm, params=dict, tag=test_tag,
iterations=test_iterations,
- profile_only=profile)
-if profile:
-job.profilers.delete('kvm_stat')
+ profile_only= bool(profilers) or
None)
+
+for profiler in profilers:
+job.profilers.delete(profiler)
if not current_status:
failed = True
diff --git a/client/tests/kvm/tests_base.cfg.sample
b/client/tests/kvm/tests_base.cfg.sample
index d162cf8..0f6721f 100644
--- a/client/tests/kvm/tests_base.cfg.sample
+++ b/client/tests/kvm/tests_base.cfg.sample
@@ -41,7 +41,7 @@ nic_script = scripts/qemu-ifup
address_index = 0
# Misc
-run_kvm_stat = yes
+profilers = kvm_stat
# Tests
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [Autotest PATCH v2] KVM-test: Add a subtest 'qemu_img'
This is designed to test all subcommands of 'qemu-img' however
so far 'commit' is not implemented.
* For 'check' subcommand test, it will 'dd' to create a file with specified
size and see whether it's supported to be checked. Then convert it to be
supported formats ('qcow2' and 'raw' so far) to see whether there's error
after convertion.
* For 'convert' subcommand test, it will convert both to 'qcow2' and 'raw' from
the format specified in config file. And only check 'qcow2' after convertion.
* For 'snapshot' subcommand test, it will create two snapshots and list them.
Finally delete them if no errors found.
* For 'info' subcommand test, it will check image format size according to
output of 'info' subcommand at specified image file.
* For 'rebase' subcommand test, it will create first snapshot 'sn1' based on
original
base_img, and create second snapshot based on sn1. And then rebase sn2 to
base_img.
After rebase check the baking_file of sn2.
This supports two rebase mode: unsafe mode and safe mode:
Unsafe mode:
With -u an unsafe mode is enabled that doesn't require the backing files to
exist.
It merely changes the backing file reference in the COW image. This is useful
for
renaming or moving the backing file. The user is responsible to make sure that
the
new backing file has no changes compared to the old one, or corruption may
occur.
Safe Mode:
Both the current and the new backing file need to exist, and after the rebase,
the
COW image is guaranteed to have the same guest visible content as before.
To achieve this, old and new backing file are compared and, if necessary, data
is
copied from the old backing file into the COW image.
Improvement from v1:
* Add an underscore _ at the beginning of all the auxiliary functions.
Results in:
# ./scan_results.py
TestStatus Seconds Info
-- ---
(Result file: ../../results/default/status)
smp2.RHEL.5.4.i386.qemu_img.check GOOD132
completed successfully
smp2.RHEL.5.4.i386.qemu_img.create GOOD144
completed successfully
smp2.RHEL.5.4.i386.qemu_img.convert.to_qcow2GOOD251
completed successfully
smp2.RHEL.5.4.i386.qemu_img.convert.to_raw GOOD245
completed successfully
smp2.RHEL.5.4.i386.qemu_img.snapshotGOOD140
completed successfully
smp2.RHEL.5.4.i386.qemu_img.commit GOOD146
completed successfully
smp2.RHEL.5.4.i386.qemu_img.infoGOOD133
completed successfully
smp2.RHEL.5.4.i386.qemu_img.rebase TEST_NA 137
Current kvm user space version does not support 'rebase' subcommand
GOOD1392
[r...@afu kvm]#
shows only 'rebase' subtest is not supported currently.
Others runs good from my side.
Signed-off-by: Yolkfull Chow yz...@redhat.com
---
client/tests/kvm/tests/qemu_img.py | 280
client/tests/kvm/tests_base.cfg.sample | 40 +
2 files changed, 320 insertions(+), 0 deletions(-)
create mode 100644 client/tests/kvm/tests/qemu_img.py
diff --git a/client/tests/kvm/tests/qemu_img.py
b/client/tests/kvm/tests/qemu_img.py
new file mode 100644
index 000..7f786c5
--- /dev/null
+++ b/client/tests/kvm/tests/qemu_img.py
@@ -0,0 +1,280 @@
+import re, os, logging, commands
+from autotest_lib.client.common_lib import utils, error
+import kvm_vm, kvm_utils
+
+
+def run_qemu_img(test, params, env):
+
+`qemu-img' functions test:
+1) Judge what subcommand is going to be tested
+2) Run subcommand test
+
+@param test: kvm test object
+@param params: Dictionary with the test parameters
+@param env: Dictionary with test environment.
+
+cmd = kvm_utils.get_path(test.bindir, params.get(qemu_img_binary))
+if not os.path.exists(cmd):
+raise error.TestError(Binary of 'qemu-img' not found)
+image_format = params.get(image_format)
+image_size = params.get(image_size, 10G)
+image_name = kvm_vm.get_image_filename(params, test.bindir)
+
+def _check(cmd, img):
+
+Simple 'qemu-img check' function implementation.
+
+@param cmd: binary of 'qemu_img'
+@param img: image to be checked
+
+cmd += check %s % img
+logging.info(Checking image '%s'... % img)
+o = commands.getoutput(cmd)
+if does not support checks in o or No errors in o:
+return (True, )
+return (False, o)
+
+# Subcommand 'qemu-img check' test
+# This tests will 'dd' to create a specified size file, and check it.
+# Then convert it to supported image_format in each loop and check again.
+def check_test(cmd):
+test_image =
Re: [Qemu-devel] [RFC PATCH 4/7] sparc: rename hw/iommu.c
On 03/30/10 19:06, Blue Swirl wrote: On 3/30/10, Eduard - Gabriel Munteanueduard.munte...@linux360.ro wrote: hw/iommu.c concerns the SPARC IOMMU. However we intend to implement the AMD IOMMU, which could lead to confusion unless we rename the former. I was also thinking of renaming the file some time ago. The correct name would be sun4m_iommu.c. Sun4c (while still Sparc based) had a different architecture (IIRC CPU MMU doubled as IOMMU) and Sun4d had several IO-UNITs instead. All Sun4m machines had an IOMMU. But the qdev name of the device is still iommu and we can't change that. So I'm not so sure it's worth renaming. Can't AMD IOMMU reside in amd_iommu.c? I'd go for the (filename) rename. The qdev name shouldn't cause conflicts due to the different targets. cheers, Gerd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][RFC] x86: remove SMP check/taint for AMD K7 (was Re: KVM warning about uncertified CPU for SMP for AMD model 2, stepping 3)
On Wed, 31 Mar 2010, Andi Kleen wrote:
booting 32bit guest on 32bit host on AMD system gives me the following
warning when KVM is instructed to boot as SMP:
I guess these warnings could be just disabled. With nearly everyone
using multi-core these days they are kind of obsolete anyways.
Why is it there for K7 only anyway? Was that the only product line which
had instances which were explicitly marked as unsuitable for SMP by AMD?
From: Jiri Kosina jkos...@suse.cz
Subject: x86: remove SMP check/taint for AMD K7
Remove code checking of AMD K7 CPU models and warning/tainting kernel if
it doesn't suit given criteria.
The code has been there originally in order to detect systems which were
doing SMP with CPUs that were not oficially cerified by AMD as SMP-safe.
It's not clear whether the checks are either proper or complete. Quoting
Andi Kleen: I guess these warnings could be just disabled. With nearly
everyone using multi-core these days they are kind of obsolete anyways.
Signed-off-by: Jiri Kosina jkos...@suse.cz
---
arch/x86/kernel/cpu/amd.c | 51 -
1 files changed, 0 insertions(+), 51 deletions(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index e485825..6510fe5 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -144,55 +144,6 @@ static void __cpuinit init_amd_k6(struct cpuinfo_x86 *c)
}
}
-static void __cpuinit amd_k7_smp_check(struct cpuinfo_x86 *c)
-{
-#ifdef CONFIG_SMP
- /* calling is from identify_secondary_cpu() ? */
- if (c-cpu_index == boot_cpu_id)
- return;
-
- /*
-* Certain Athlons might work (for various values of 'work') in SMP
-* but they are not certified as MP capable.
-*/
- /* Athlon 660/661 is valid. */
- if ((c-x86_model == 6) ((c-x86_mask == 0) ||
- (c-x86_mask == 1)))
- goto valid_k7;
-
- /* Duron 670 is valid */
- if ((c-x86_model == 7) (c-x86_mask == 0))
- goto valid_k7;
-
- /*
-* Athlon 662, Duron 671, and Athlon model 7 have capability
-* bit. It's worth noting that the A5 stepping (662) of some
-* Athlon XP's have the MP bit set.
-* See http://www.heise.de/newsticker/data/jow-18.10.01-000 for
-* more.
-*/
- if (((c-x86_model == 6) (c-x86_mask = 2)) ||
- ((c-x86_model == 7) (c-x86_mask = 1)) ||
-(c-x86_model 7))
- if (cpu_has_mp)
- goto valid_k7;
-
- /* If we get here, not a certified SMP capable AMD system. */
-
- /*
-* Don't taint if we are running SMP kernel on a single non-MP
-* approved Athlon
-*/
- WARN_ONCE(1, WARNING: This combination of AMD
-processors is not suitable for SMP.\n);
- if (!test_taint(TAINT_UNSAFE_SMP))
- add_taint(TAINT_UNSAFE_SMP);
-
-valid_k7:
- ;
-#endif
-}
-
static void __cpuinit init_amd_k7(struct cpuinfo_x86 *c)
{
u32 l, h;
@@ -228,8 +179,6 @@ static void __cpuinit init_amd_k7(struct cpuinfo_x86 *c)
}
set_cpu_cap(c, X86_FEATURE_K7);
-
- amd_k7_smp_check(c);
}
#endif
--
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
qemu-kvm.git stable requests
Howdy, Apparently there was just the very first case of someone requiring my patch to enable BAR regions 4k. To enable people to use those devices with a released version, I'd suggest cherry-picking these commits into 0.12-stable: commit 8845b72377a42443b249360b9cd3d6f1e8cfb097 Author: Alexander Graf ag...@suse.de Date: Thu Dec 17 16:04:44 2009 +0100 commit be5a9efb3359cac07217d477b44f6bd0e17658f0 Author: Michael S. Tsirkin m...@redhat.com Date: Wed Dec 23 12:07:47 2009 +0200 While at it, I realized that the friendly help output if a device is currently in use by a driver is not available. So I'd also suggest taking those in to -stable: commit 0cbd39044aa9f6c4462b7783376c894786f8de77 Author: Alexander Graf ag...@suse.de Date: Thu Dec 17 16:04:45 2009 +0100 commit 27a3fa20f302e64fe10d5c2f0f5c73d73e336166 Author: Alexander Graf ag...@suse.de Date: Thu Dec 17 16:04:46 2009 +0100 Alex-- 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] [Autotest PATCH v2] KVM-test: Add a subtest 'qemu_img'
On 3/31/2010 10:23 AM, Yolkfull Chow wrote:
This is designed to test all subcommands of 'qemu-img' however
so far 'commit' is not implemented.
* For 'check' subcommand test, it will 'dd' to create a file with specified
size and see whether it's supported to be checked. Then convert it to be
supported formats ('qcow2' and 'raw' so far) to see whether there's error
after convertion.
This does not really test the 'check' command. I'd feed it some
malformed qcow2 files and make sure it does find the intended errors.
Y.
* For 'convert' subcommand test, it will convert both to 'qcow2' and 'raw' from
the format specified in config file. And only check 'qcow2' after convertion.
* For 'snapshot' subcommand test, it will create two snapshots and list them.
Finally delete them if no errors found.
* For 'info' subcommand test, it will check image format size according to
output of 'info' subcommand at specified image file.
* For 'rebase' subcommand test, it will create first snapshot 'sn1' based on
original
base_img, and create second snapshot based on sn1. And then rebase sn2 to
base_img.
After rebase check the baking_file of sn2.
This supports two rebase mode: unsafe mode and safe mode:
Unsafe mode:
With -u an unsafe mode is enabled that doesn't require the backing files to
exist.
It merely changes the backing file reference in the COW image. This is useful
for
renaming or moving the backing file. The user is responsible to make sure that
the
new backing file has no changes compared to the old one, or corruption may
occur.
Safe Mode:
Both the current and the new backing file need to exist, and after the rebase,
the
COW image is guaranteed to have the same guest visible content as before.
To achieve this, old and new backing file are compared and, if necessary, data
is
copied from the old backing file into the COW image.
Improvement from v1:
* Add an underscore _ at the beginning of all the auxiliary functions.
Results in:
# ./scan_results.py
TestStatus Seconds Info
-- ---
(Result file: ../../results/default/status)
smp2.RHEL.5.4.i386.qemu_img.check GOOD132
completed successfully
smp2.RHEL.5.4.i386.qemu_img.create GOOD144
completed successfully
smp2.RHEL.5.4.i386.qemu_img.convert.to_qcow2GOOD251
completed successfully
smp2.RHEL.5.4.i386.qemu_img.convert.to_raw GOOD245
completed successfully
smp2.RHEL.5.4.i386.qemu_img.snapshotGOOD140
completed successfully
smp2.RHEL.5.4.i386.qemu_img.commit GOOD146
completed successfully
smp2.RHEL.5.4.i386.qemu_img.infoGOOD133
completed successfully
smp2.RHEL.5.4.i386.qemu_img.rebase TEST_NA 137
Current kvm user space version does not support 'rebase' subcommand
GOOD1392
[r...@afu kvm]#
shows only 'rebase' subtest is not supported currently.
Others runs good from my side.
Signed-off-by: Yolkfull Chowyz...@redhat.com
---
client/tests/kvm/tests/qemu_img.py | 280
client/tests/kvm/tests_base.cfg.sample | 40 +
2 files changed, 320 insertions(+), 0 deletions(-)
create mode 100644 client/tests/kvm/tests/qemu_img.py
diff --git a/client/tests/kvm/tests/qemu_img.py
b/client/tests/kvm/tests/qemu_img.py
new file mode 100644
index 000..7f786c5
--- /dev/null
+++ b/client/tests/kvm/tests/qemu_img.py
@@ -0,0 +1,280 @@
+import re, os, logging, commands
+from autotest_lib.client.common_lib import utils, error
+import kvm_vm, kvm_utils
+
+
+def run_qemu_img(test, params, env):
+
+`qemu-img' functions test:
+1) Judge what subcommand is going to be tested
+2) Run subcommand test
+
+@param test: kvm test object
+@param params: Dictionary with the test parameters
+@param env: Dictionary with test environment.
+
+cmd = kvm_utils.get_path(test.bindir, params.get(qemu_img_binary))
+if not os.path.exists(cmd):
+raise error.TestError(Binary of 'qemu-img' not found)
+image_format = params.get(image_format)
+image_size = params.get(image_size, 10G)
+image_name = kvm_vm.get_image_filename(params, test.bindir)
+
+def _check(cmd, img):
+
+Simple 'qemu-img check' function implementation.
+
+@param cmd: binary of 'qemu_img'
+@param img: image to be checked
+
+cmd += check %s % img
+logging.info(Checking image '%s'... % img)
+o = commands.getoutput(cmd)
+if does not support checks in o or No errors in o:
+return (True, )
+return (False, o)
+
+# Subcommand 'qemu-img check' test
+# This tests will 'dd' to
Re: [PATCH v3 1/1] Shared memory uio_pci driver
On Mon, Mar 29, 2010 at 11:59:24PM +0300, Avi Kivity wrote: On 03/28/2010 10:48 PM, Cam Macdonell wrote: On Sat, Mar 27, 2010 at 11:48 AM, Avi Kivitya...@redhat.com wrote: On 03/26/2010 07:14 PM, Cam Macdonell wrote: I'm not familiar with the uio internals, but for the interface, an ioctl() on the fd to assign an eventfd to an MSI vector. Similar to ioeventfd, but instead of mapping a doorbell to an eventfd, it maps a real MSI to an eventfd. uio will never support ioctls. Why not? Perhaps I spoke too strongly, but it was rejected before http://thread.gmane.org/gmane.linux.kernel/756481 With a compelling case perhaps it could be added. Ah, the usual ioctls are ugly, go away. It could be done via sysfs: $ cat /sys/.../msix/max-interrupts 256 This one can be discovered with existing sysfs. $ echo 4 /sys/.../msix/allocate $ # subdirectories 0 1 2 3 magically appear $ # bind fd 13 to msix There's no way to know, when qemu starts, how many vectors will be used by driver. So I think we can just go ahead and allocate as many vectors as supported by device at the moment when the first eventfd is bound. $ echo 13 /sys/.../msix/2/bind-fd I think that this one can't work, both fd 13 and sysfs file will get closed when /bin/echo process exits. $ # from now on, msix interrupt 2 will call eventfd_signal() on fd 13 Call me old fashioned, but I prefer ioctls. I think we will have to use ioctl or irqcontrol because of lifetime issues outlines above. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- 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: Increase NR_IOBUS_DEVS limit to 200
On Tue, Mar 30, 2010 at 04:48:25PM -0700, Sridhar Samudrala wrote:
This patch increases the current hardcoded limit of NR_IOBUS_DEVS
from 6 to 200. We are hitting this limit when creating a guest with more
than 1 virtio-net device using vhost-net backend. Each virtio-net
device requires 2 such devices to service notifications from rx/tx queues.
Signed-off-by: Sridhar Samudrala s...@us.ibm.com
I tried this, but observed a measurable performance
degradation with vhost net and this patch. Did not
investigate yet. Do you see this as well?
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index a3fd0f9..7fb48d3 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -54,7 +54,7 @@ extern struct kmem_cache *kvm_vcpu_cache;
*/
struct kvm_io_bus {
int dev_count;
-#define NR_IOBUS_DEVS 6
+#define NR_IOBUS_DEVS 200
struct kvm_io_device *devs[NR_IOBUS_DEVS];
};
--
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: PCI passthrough resource remapping
2010/3/31 Chris Wright chr...@redhat.com: * Kenni Lund (ke...@kelu.dk) wrote: 2010/3/31 Chris Wright chr...@redhat.com: So I suppose I'll need to get rid of this shared IRQ before I can conclude anything on the patch in git. Hmm, is there some cleaver way of fixing this in Linux, or do I have to fix it by changing BIOS IRQ settings, disabling hardware and/or moving the hardware around in various PCI slots? The way I typically work around this is simply unbinding the driver from the device in the host (and thus freeing the irq). Doh...anyway, I went all the way, found a USB-PS2 adaptor, disabled the onboard USB controller and PATA controller in BIOS, and now got kvm_assigned_intx_device for all 4 IRQs :) A little extreme...but hey, that works ;-) I'm still curious what's going on w/ your PCI card and the irq routing. Something is suspect. I'll not be able to do any further testing for the next two weeks, but if you want me to perform some tests, test patches etc., just write what you want me to do and I'll do it in two weeks. Best Regards Kenni -- 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][QEMU][VHOST]fix feature bit handling for mergeable rx buffers
On Tue, Mar 30, 2010 at 12:21:05PM -0700, David L Stevens wrote:
This patch adds mergeable receive buffer support to qemu-kvm,
to allow enabling it when vhost_net supports it.
It also adds a missing call to vhost_net_ack_features() to
push acked features to vhost_net.
The patch is relative to Michael Tsirkin's qemu-kvm git tree.
+-DLS
Signed-off-by: David L Stevens dlstev...@us.ibm.com
Patch is well-formed, thanks!
BTW, where qemu-km and qemu share code, it is better
to send patch against qemu.
Since qemu-kvm generally carries kernel headers it needs, it might also
be a good idea to add if_tun to the kvm header directory.
diff -ruNp qemu-kvm.mst/hw/vhost_net.c qemu-kvm.dls/hw/vhost_net.c
--- qemu-kvm.mst/hw/vhost_net.c 2010-03-03 13:39:07.0 -0800
+++ qemu-kvm.dls/hw/vhost_net.c 2010-03-29 20:37:34.0 -0700
@@ -5,6 +5,7 @@
#include sys/ioctl.h
#include linux/vhost.h
#include linux/virtio_ring.h
+#include linux/if_tun.h
#include netpacket/packet.h
#include net/ethernet.h
#include net/if.h
@@ -38,15 +39,6 @@ unsigned vhost_net_get_features(struct v
return features;
}
-void vhost_net_ack_features(struct vhost_net *net, unsigned features)
-{
- net-dev.acked_features = net-dev.backend_features;
- if (features (1 VIRTIO_F_NOTIFY_ON_EMPTY))
- net-dev.acked_features |= (1 VIRTIO_F_NOTIFY_ON_EMPTY);
- if (features (1 VIRTIO_RING_F_INDIRECT_DESC))
- net-dev.acked_features |= (1 VIRTIO_RING_F_INDIRECT_DESC);
-}
-
static int vhost_net_get_fd(VLANClientState *backend)
{
switch (backend-info-type) {
@@ -58,6 +50,25 @@ static int vhost_net_get_fd(VLANClientSt
}
}
+void vhost_net_ack_features(struct vhost_net *net, unsigned features)
+{
+ int vnet_hdr_sz = sizeof(struct virtio_net_hdr);
+
+ net-dev.acked_features = net-dev.backend_features;
+ if (features (1 VIRTIO_F_NOTIFY_ON_EMPTY))
+ net-dev.acked_features |= (1 VIRTIO_F_NOTIFY_ON_EMPTY);
+ if (features (1 VIRTIO_RING_F_INDIRECT_DESC))
+ net-dev.acked_features |= (1 VIRTIO_RING_F_INDIRECT_DESC);
+ if (features (1 VIRTIO_NET_F_MRG_RXBUF)) {
+ net-dev.acked_features |= (1 VIRTIO_NET_F_MRG_RXBUF);
+ vnet_hdr_sz = sizeof(struct virtio_net_hdr_mrg_rxbuf);
+ }
+#ifdef TUNSETVNETHDRSZ
+ if (ioctl(vhost_net_get_fd(net-vc), TUNSETVNETHDRSZ, vnet_hdr_sz) 0)
+ perror(TUNSETVNETHDRSZ);
+#endif /* TUNSETVNETHDRSZ */
Note that this will break injecting raw packets after migration
(that code assumes header size is sizeof(struct virtio_net_hdr)).
Need to fix it.
So I think we are better off adding tap_set_vnet_header_size.
That function would:
- Remember current value, return success and do nothing
if value is not changed.
- Try to change and return error if not.
- To get doubly sure, we can call TUNSETVNETHDRSZ with
sizeof(struct virtio_net_hdr) at startup. If we get success
once we should further on as well, otherwise we can exit.
An additional benefit is that tap driver will stay
localized in one file.
+}
+
struct vhost_net *vhost_net_init(VLANClientState *backend, int devfd)
{
int r;
diff -ruNp qemu-kvm.mst/hw/virtio-net.c qemu-kvm.dls/hw/virtio-net.c
--- qemu-kvm.mst/hw/virtio-net.c 2010-03-03 13:39:07.0 -0800
+++ qemu-kvm.dls/hw/virtio-net.c 2010-03-29 16:15:46.0 -0700
@@ -211,12 +211,16 @@ static void virtio_net_set_features(Virt
n-mergeable_rx_bufs = !!(features (1 VIRTIO_NET_F_MRG_RXBUF));
if (n-has_vnet_hdr) {
+ struct vhost_net *vhost_net = tap_get_vhost_net(n-nic-nc.peer);
+
tap_set_offload(n-nic-nc.peer,
(features VIRTIO_NET_F_GUEST_CSUM) 1,
(features VIRTIO_NET_F_GUEST_TSO4) 1,
(features VIRTIO_NET_F_GUEST_TSO6) 1,
(features VIRTIO_NET_F_GUEST_ECN) 1,
(features VIRTIO_NET_F_GUEST_UFO) 1);
+ if (vhost_net)
+ vhost_net_ack_features(vhost_net, features);
Good catch, thanks! I'll apply this separately.
}
}
--
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: [questions] savevm|loadvm
Wenhao Xu xuwenhao2...@gmail.com wrote: Hi, Juan, I am fresh to both QEMU and KVM. But so far, I notice that QEMU uses KVM_SET_USER_MEMORY_REGION to set memory region that KVM can use and uses cpu_register_physical_memory_offset to register the same memory to QEMU emulator, which means QEMU and KVM use the same host virtual memory. And therefore the memory KVM modified could be directly reflected to QEMU. I don't quite understand the different memory layout problem between the two. So I don't know exactly what you mean to fix it? 1st. qemu-kvm.git and qemu.git memory layouts are different, indeed with qemu.git kvm mode. (yes it is complex and weird). kvm vs qemu initialization is different. Expecting to stop kvm, and run tcg from there is not going to work. I guess it would need a lot of changes, but I haven't looked at it myself. For why switching is useful? Actually, I am a master student now and doing a course project. What am I arguing is that QEMU could be potentially useful to do many instrumentation analysis, but it is a bit slow. So by combing with KVM, when the os runs to some place where we are interested in, switch it to QEMU emulator mode and do the analysis and then switch back. idea is good, but I don't think that it is _so_ easy at this point. tcg and kvm basically live in a different world. Not sure of what needs to be done to make them back on sync. FYI, there is a paper doing so in Xen, Practical taint-based protection using demand emulation. I want to do the same demand emulation for KVM. I am trying to patch some code. When kvm_run returns, I tried to synchronize the CPU state and memory dirty map, and then run into QEMU emulator mode. However, I got an error, qemu: fatal: invalid tss type. I don't know exactly where is the problem. I guess you need to look at tcg startup, and see how it initializes vcpus, and hack something around that when you try to run tcg at kvm_run exit. Have Fun :) Later, Juan. -- 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: PCI passthrough resource remapping
2010/3/31 Kenni Lund ke...@kelu.dk: Booting the guest and tuning to a DVB-T channel _works_ !!! :-D Thanks a lot for your help...I have one more question, though: If I have two devices (like the ivtv tuner and the USB card) and they share an IRQ, if I then assign BOTH of them to the same guest, will it then work? Alexander, the patch works, I hope to see it in a stable release in the near future ;) Unfortunately, I have a correction to this :( It _almost_ works. I had some video/audio artifacts which I though was caused by bad reception, but after switching the DVB-T tuner back and forth between the PCI USB card and a laptop, it got clear to me, that this was a passthrough issue. I get no errors in dmesg on the host or in the guest. I recorded a short videoclip which illustrates the issue: https://docs.google.com/leaf?id=0B-_nZameGeN-NDk4YzQ3N2EtMmEzMi00NTU4LWFjMjgtNzkxMzcxYzg2MTM1hl=en Best Regards Kenni -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Add Mergeable RX buffer feature to vhost_net
On Tue, Mar 30, 2010 at 07:23:48PM -0600, David Stevens wrote:
This patch adds support for the Mergeable Receive Buffers feature to
vhost_net.
Changes:
1) generalize descriptor allocation functions to allow multiple
descriptors per packet
2) add socket peek to know datalen at buffer allocation time
3) change notification to enable a multi-buffer max packet, rather
than the single-buffer run until completely empty
Changes from previous revision:
1) incorporate review comments from Michael Tsirkin
2) assume use of TUNSETVNETHDRSZ ioctl by qemu, which simplifies vnet
header
processing
3) fixed notification code to only affect the receive side
Signed-Off-By: David L Stevens dlstev...@us.ibm.com
[in-line for review, attached for applying w/o whitespace mangling]
attached patch seems to be whiespace damaged as well.
Does the origin pass checkpatch.pl for you?
diff -ruNp net-next-p0/drivers/vhost/net.c net-next-p3/drivers/vhost/net.c
--- net-next-p0/drivers/vhost/net.c 2010-03-22 12:04:38.0
-0700
+++ net-next-p3/drivers/vhost/net.c 2010-03-30 12:50:57.0
-0700
@@ -54,26 +54,6 @@ struct vhost_net {
enum vhost_net_poll_state tx_poll_state;
};
-/* Pop first len bytes from iovec. Return number of segments used. */
-static int move_iovec_hdr(struct iovec *from, struct iovec *to,
- size_t len, int iov_count)
-{
- int seg = 0;
- size_t size;
- while (len seg iov_count) {
- size = min(from-iov_len, len);
- to-iov_base = from-iov_base;
- to-iov_len = size;
- from-iov_len -= size;
- from-iov_base += size;
- len -= size;
- ++from;
- ++to;
- ++seg;
- }
- return seg;
-}
-
/* Caller must have TX VQ lock */
static void tx_poll_stop(struct vhost_net *net)
{
@@ -97,7 +77,8 @@ static void tx_poll_start(struct vhost_n
static void handle_tx(struct vhost_net *net)
{
struct vhost_virtqueue *vq = net-dev.vqs[VHOST_NET_VQ_TX];
- unsigned head, out, in, s;
+ unsigned out, in;
+ struct iovec head;
struct msghdr msg = {
.msg_name = NULL,
.msg_namelen = 0,
@@ -108,8 +89,8 @@ static void handle_tx(struct vhost_net *
};
size_t len, total_len = 0;
int err, wmem;
- size_t hdr_size;
struct socket *sock = rcu_dereference(vq-private_data);
+
if (!sock)
return;
@@ -127,22 +108,19 @@ static void handle_tx(struct vhost_net *
if (wmem sock-sk-sk_sndbuf / 2)
tx_poll_stop(net);
- hdr_size = vq-hdr_size;
for (;;) {
- head = vhost_get_vq_desc(net-dev, vq, vq-iov,
-ARRAY_SIZE(vq-iov),
-out, in,
-NULL, NULL);
+ head.iov_base = (void *)vhost_get_vq_desc(net-dev, vq,
+ vq-iov, ARRAY_SIZE(vq-iov), out, in, NULL,
NULL);
I this casting confusing.
Is it really expensive to add an array of heads so that
we do not need to cast?
/* Nothing new? Wait for eventfd to tell us they
refilled. */
- if (head == vq-num) {
+ if (head.iov_base == (void *)vq-num) {
wmem = atomic_read(sock-sk-sk_wmem_alloc);
if (wmem = sock-sk-sk_sndbuf * 3 / 4) {
tx_poll_start(net, sock);
set_bit(SOCK_ASYNC_NOSPACE, sock-flags);
break;
}
- if (unlikely(vhost_enable_notify(vq))) {
+ if (unlikely(vhost_enable_notify(vq, 0))) {
vhost_disable_notify(vq);
continue;
}
@@ -154,27 +132,30 @@ static void handle_tx(struct vhost_net *
break;
}
/* Skip header. TODO: support TSO. */
- s = move_iovec_hdr(vq-iov, vq-hdr, hdr_size, out);
msg.msg_iovlen = out;
- len = iov_length(vq-iov, out);
+ head.iov_len = len = iov_length(vq-iov, out);
+
/* Sanity check */
if (!len) {
- vq_err(vq, Unexpected header len for TX:
- %zd expected %zd\n,
- iov_length(vq-hdr, s), hdr_size);
+ vq_err(vq, Unexpected buffer len for TX: %zd ,
len);
break;
}
- /* TODO: Check specific error and bomb out unless ENOBUFS?
*/
err =
Re: KVM warning about uncertified CPU for SMP for AMD model 2, stepping 3
Andi Kleen wrote: On Wed, Mar 31, 2010 at 01:03:02AM +0200, Jiri Kosina wrote: Hi, booting 32bit guest on 32bit host on AMD system gives me the following warning when KVM is instructed to boot as SMP: I guess these warnings could be just disabled. With nearly everyone using multi-core these days they are kind of obsolete anyways. Well, the warning refers to an old single-core only CPU model. Most of those were able to run in SMP boards, but only a subset of them was officially certified to do so (Athlon-MP instead of Athlon-XP). To avoid complaints about instability of such systems, the warning was introduced. If you consider these systems still supported, I wouldn't disable this warning, at least the check should be disabled only if the hypervisor CPUID bit is set. But the far better solution is to instruct QEMU/KVM to inject a better CPU model (as it was suggested by some people two weeks ago). I am about to test various guests with respect to their behavior regarding different family/model/stepping settings (one issue is already fixed). If this goes well, I will send out the patch to inject the host's CPUID F/M/S into the guest by default (which has other advantages, but denies migration mostly). BTW.: I encourage people to test their KVM guests with -cpu host (on newer QEMUs) and send me any crash logs. Regards, Andre. -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany Tel: +49 351 448-3567-12 -- 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: PCI passthrough resource remapping
Kenni Lund wrote: 2010/3/31 Kenni Lund ke...@kelu.dk: Booting the guest and tuning to a DVB-T channel _works_ !!! :-D Thanks a lot for your help...I have one more question, though: If I have two devices (like the ivtv tuner and the USB card) and they share an IRQ, if I then assign BOTH of them to the same guest, will it then work? Alexander, the patch works, I hope to see it in a stable release in the near future ;) Unfortunately, I have a correction to this :( It _almost_ works. I had some video/audio artifacts which I though was caused by bad reception, but after switching the DVB-T tuner back and forth between the PCI USB card and a laptop, it got clear to me, that this was a passthrough issue. I get no errors in dmesg on the host or in the guest. I recorded a short videoclip which illustrates the issue: https://docs.google.com/leaf?id=0B-_nZameGeN-NDk4YzQ3N2EtMmEzMi00NTU4LWFjMjgtNzkxMzcxYzg2MTM1hl=en Hrm, I'm not sure these would be related to the small BAR region patch. It looks more like a timing issue. Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM warning about uncertified CPU for SMP for AMD model 2, stepping 3
I guess these warnings could be just disabled. With nearly everyone using multi-core these days they are kind of obsolete anyways. Well, the warning refers to an old single-core only CPU model. Most of those were able to run in SMP boards, but only a subset of them was officially certified to do so (Athlon-MP instead of Athlon-XP). Thanks for pointing out the obvious. To avoid complaints about instability of such systems, the warning was introduced. If you consider these systems still supported, I wouldn't disable this warning, at least the check should be disabled only if the hypervisor CPUID bit is set. The point was that everyone can have a multi-core system for cheap these days, no real motivation for anyone anymore to use old unsupported configurations to get one. -Andi -- 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][RFC] x86: remove SMP check/taint for AMD K7 (was Re: KVM warning about uncertified CPU for SMP for AMD model 2, stepping 3)
On Wed, Mar 31, 2010 at 10:15:28AM +0200, Jiri Kosina wrote: On Wed, 31 Mar 2010, Andi Kleen wrote: booting 32bit guest on 32bit host on AMD system gives me the following warning when KVM is instructed to boot as SMP: I guess these warnings could be just disabled. With nearly everyone using multi-core these days they are kind of obsolete anyways. Why is it there for K7 only anyway? Was that the only product line which had instances which were explicitly marked as unsuitable for SMP by AMD? Later ones were fused, so even if you wanted to you couldn't cheat this way. Earlier CPUs didn't support SMP. -Andi -- 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: PCI passthrough resource remapping
2010/3/31 Alexander Graf ag...@suse.de: Kenni Lund wrote: 2010/3/31 Kenni Lund ke...@kelu.dk: Booting the guest and tuning to a DVB-T channel _works_ !!! :-D Thanks a lot for your help...I have one more question, though: If I have two devices (like the ivtv tuner and the USB card) and they share an IRQ, if I then assign BOTH of them to the same guest, will it then work? Alexander, the patch works, I hope to see it in a stable release in the near future ;) Unfortunately, I have a correction to this :( It _almost_ works. I had some video/audio artifacts which I though was caused by bad reception, but after switching the DVB-T tuner back and forth between the PCI USB card and a laptop, it got clear to me, that this was a passthrough issue. I get no errors in dmesg on the host or in the guest. I recorded a short videoclip which illustrates the issue: https://docs.google.com/leaf?id=0B-_nZameGeN-NDk4YzQ3N2EtMmEzMi00NTU4LWFjMjgtNzkxMzcxYzg2MTM1hl=en Hrm, I'm not sure these would be related to the small BAR region patch. It looks more like a timing issue. For what it's worth, I quickly tried to passthrough one of the onboard USB controllers instead (Intel Corporation 82801JD/DO (ICH10 Family), which is also affected by the 4k limitation). It improves the artifact problems, bringing the artifacts down to one artifact every 5 seconds. I'll be back in ~1½ week, please tell me if you want me to test something when I get back. Thanks for your help :) Best Regards Kenni -- 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: Clocksource tsc unstable (delta = -4398046474878 ns)
On Wednesday 31 March 2010 21:32:18 you wrote: On 03/30/10 07:04, Beinicke, Thomas wrote: On Tuesday 30 March 2010 10:08:28 Sebastian Hetze wrote: On Mon, Mar 29, 2010 at 11:31:13AM +0100, Athanasius wrote: On Sun, Mar 28, 2010 at 01:46:35PM +0200, Sebastian Hetze wrote: this message appeared in the KVM guest kern.log last night: Mar 27 22:35:30 guest kernel: [260041.559462] Clocksource tsc unstable (delta = -4398046474878 ns) The guest is running a 2.6.31-20-generic-pae ubuntu kernel with hrtimer-tune-hrtimer_interrupt-hang-logic.patch applied. If I understand things correct, in kernel/time/clocksource.c clocksource_watchdog() checks all the /sys/devices/system/clocksource/clocksource0/available_clocksource every 0.5sec for an delta of more than 0.0625s. So the tsc must have changed more than one hour within two subsequent calls of clocksource_watchdog. No event in the host nor anything in the guest gives reasonable cause for this step. However, the number 4398046474878 is only 36226 ns away from 4*1024*1024*1024*1024 I didn't see any such messages but I've had a recent experience with the time on one KVM host leaping *forwards* approx. 5 and 2.5 hours in two separate incidents. Eerily the exact jumps, as best I can tell from logs are of 17592 and 8796 seconds, give or take a second or two. If you look at these as nanoseconds then that's 'exactly' 2^44 and 2^43 nanoseconds. What I've done that seems to have avoided this happening again is drop KVM_CLOCK kernel option from the kvm guests' kernel. To my understanding, kvm-clock is the best and most reliable clocksource available, so I do not think it is a good idea to disable it. There is a lot of bit shift operation happening with the clocksources, so there may be a real bug hidden somewhere in the code. Somehow ntp adjustment is involved, can this cause such huge steps? Im my case, I actually have NTP running in the guest. However, the statistics show a pretty stable timing here. -- 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 I am having the same problem occasional. It only occurs if the VM is under heavy IO or CPU Load but I can't reproduce it 100%. It just never occurs on VMs that only serve a few web pages though. I also noticed that on a machine which has this problem even an ssh shell is *very* laggy so it's not just a cosmetic problem. Would removing the hrtimer from the kernel config solve it or is it necessary for KVM? I remember this problem has been posted her before though there wasn't any real conclusion or solution for it. Are you also running a 32-bit kernel? I have the problem on 32-bit and 64-bit clients. The host machines are all 64-bit. Thanks, Zach -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM warning about uncertified CPU for SMP for AMD model 2, stepping 3
On Wed, 31 Mar 2010, Andre Przywara wrote: But the far better solution is to instruct QEMU/KVM to inject a better CPU model (as it was suggested by some people two weeks ago). I am about to test various guests with respect to their behavior regarding different family/model/stepping settings (one issue is already fixed). If this goes well, I will send out the patch to inject the host's CPUID F/M/S into the guest by default (which has other advantages, but denies migration mostly). BTW.: I encourage people to test their KVM guests with -cpu host (on newer QEMUs) and send me any crash logs. I just quickly checked ... [0.048001] Pid: 0, comm: swapper Not tainted (2.6.32.9-0.5-pae #1) Bochs [0.048001] EIP: 0060:[c0528a80] EFLAGS: 00010246 CPU: 0 [0.048001] EIP is at init_amd+0x249/0x279 [0.048001] EAX: EBX: ECX: 00a21000 EDX: [0.048001] ESI: c077de80 EDI: c077de98 EBP: c07e1a14 ESP: c0749f8c [0.048001] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 [0.048001] Process swapper (pid: 0, ti=c0748000 task=c074fca0 task.ti=c0748000) [0.048001] Stack: [0.048001] 00e8 c07b9720 c077de80 c077debc c077de98 c0527d74 [0.048001] 0 de816448 de816440 de840580 80d0 c07b9720 00099d00 [0.048001] 0 c074c000 00bfc003 c078822d c07882c8 c028e762 c07b9720 c0781a05 0062 [0.048001] Call Trace: [0.048001] [c0527d74] identify_cpu+0xc2/0x223 [0.048001] [c078822d] identify_boot_cpu+0xa/0x22 [0.048001] [c07882c8] check_bugs+0x8/0xd2 [0.048001] [c0781a05] start_kernel+0x32e/0x3a9 [0.048001] Code: 00 00 39 44 24 08 0f 96 c0 0f b6 d0 0f b7 86 b6 00 00 00 8b 0c 9d 80 e4 77 c0 8d 04 42 31 d2 66 89 44 0d 00 0f b7 86 b8 00 00 00 f7 74 24 08 66 89 96 b8 00 00 00 e9 77 fe ff ff 66 c7 05 00 1d [0.048001] EIP: [c0528a80] init_amd+0x249/0x279 SS:ESP 0068:c0749f8c [0.116025] ---[ end trace 4eaa2a86a8e2da22 ]--- [0.117661] Kernel panic - not syncing: Attempted to kill the idle task! [0.120008] Pid: 0, comm: swapper Tainted: G D 2.6.32.9-0.5-pae #1 [0.122115] Call Trace: [0.124032] [c02069a1] try_stack_unwind+0x1b1/0x1f0 [0.125821] [c020596f] dump_trace+0x3f/0xe0 [0.132019] [c02065ab] show_trace_log_lvl+0x4b/0x60 [0.136012] [c02065d8] show_trace+0x18/0x20 [0.137572] [c052dc19] dump_stack+0x6d/0x74 [0.139120] [c052dc62] panic+0x42/0x145 [0.140018] [c0242936] do_exit+0x236/0x310 [0.141550] [c0531063] oops_end+0xc3/0xd0 [0.144012] [c020455c] do_divide_error+0x7c/0x90 [0.145643] [c05304ee] error_code+0x66/0x6c [0.147235] [c0528a80] init_amd+0x249/0x279 [0.148011] [c0527d74] identify_cpu+0xc2/0x223 [0.149649] [c078822d] identify_boot_cpu+0xa/0x22 [0.152010] [c07882c8] check_bugs+0x8/0xd2 [0.153573] [c0781a05] start_kernel+0x32e/0x3a9 But I admit that this isn't the most up-to-date version, so perhaps it's already fixed ... -- Jiri Kosina SUSE Labs, Novell Inc. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM warning about uncertified CPU for SMP for AMD model 2, stepping 3
On Wed 2010-03-31 14:51:35, Andi Kleen wrote: I guess these warnings could be just disabled. With nearly everyone using multi-core these days they are kind of obsolete anyways. Well, the warning refers to an old single-core only CPU model. Most of those were able to run in SMP boards, but only a subset of them was officially certified to do so (Athlon-MP instead of Athlon-XP). Thanks for pointing out the obvious. To avoid complaints about instability of such systems, the warning was introduced. If you consider these systems still supported, I wouldn't disable this warning, at least the check should be disabled only if the hypervisor CPUID bit is set. The point was that everyone can have a multi-core system for cheap these days, no real motivation for anyone anymore to use old unsupported configurations to get one. It still seems better to fix kvm to emulate smp-capable cpu... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM warning about uncertified CPU for SMP for AMD model 2, stepping 3
Jiri Kosina wrote: On Wed, 31 Mar 2010, Andre Przywara wrote: BTW.: I encourage people to test their KVM guests with -cpu host (on newer QEMUs) and send me any crash logs. I just quickly checked ... snip [0.147235] [c0528a80] init_amd+0x249/0x279 [0.148011] [c0527d74] identify_cpu+0xc2/0x223 [0.149649] [c078822d] identify_boot_cpu+0xa/0x22 [0.152010] [c07882c8] check_bugs+0x8/0xd2 [0.153573] [c0781a05] start_kernel+0x32e/0x3a9 But I admit that this isn't the most up-to-date version, so perhaps it's already fixed ... No, that is something new. I dug out the kernel (SLES 11.1?) and booted with my script, it crashed on FMS 16/9/0, so I guess this machine was a Magny-Cours, right? Anyway, many thanks for the report, I will investigate this. Regards, Andre. -- Andre Przywara AMD-OSRC (Dresden) Tel: x29712 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM warning about uncertified CPU for SMP for AMD model 2, stepping 3
On Wed, 31 Mar 2010, Andre Przywara wrote: BTW.: I encourage people to test their KVM guests with -cpu host (on newer QEMUs) and send me any crash logs. I just quickly checked ... snip [0.147235] [c0528a80] init_amd+0x249/0x279 [0.148011] [c0527d74] identify_cpu+0xc2/0x223 [0.149649] [c078822d] identify_boot_cpu+0xa/0x22 [0.152010] [c07882c8] check_bugs+0x8/0xd2 [0.153573] [c0781a05] start_kernel+0x32e/0x3a9 But I admit that this isn't the most up-to-date version, so perhaps it's already fixed ... No, that is something new. I dug out the kernel (SLES 11.1?) and booted with my script, it crashed on FMS 16/9/0, so I guess this machine was a Magny-Cours, right? Yup, it's cpu family 10h. Anyway, many thanks for the report, I will investigate this. Thanks, -- Jiri Kosina SUSE Labs, Novell Inc. -- 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: PCI passthrough resource remapping
* Kenni Lund (ke...@kelu.dk) wrote: 2010/3/31 Chris Wright chr...@redhat.com: * Kenni Lund (ke...@kelu.dk) wrote: 2010/3/31 Chris Wright chr...@redhat.com: So I suppose I'll need to get rid of this shared IRQ before I can conclude anything on the patch in git. Hmm, is there some cleaver way of fixing this in Linux, or do I have to fix it by changing BIOS IRQ settings, disabling hardware and/or moving the hardware around in various PCI slots? The way I typically work around this is simply unbinding the driver from the device in the host (and thus freeing the irq). Doh...anyway, I went all the way, found a USB-PS2 adaptor, disabled the onboard USB controller and PATA controller in BIOS, and now got kvm_assigned_intx_device for all 4 IRQs :) A little extreme...but hey, that works ;-) I'm still curious what's going on w/ your PCI card and the irq routing. Something is suspect. I'll not be able to do any further testing for the next two weeks, but if you want me to perform some tests, test patches etc., just write what you want me to do and I'll do it in two weeks. Thanks for your willingness to do some tests. I'll poke around a bit and see if I can come up w/ something useful for you to try out. thanks, -chris -- 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: PCI passthrough resource remapping
* Alexander Graf (ag...@suse.de) wrote: Kenni Lund wrote: 2010/3/31 Kenni Lund ke...@kelu.dk: Booting the guest and tuning to a DVB-T channel _works_ !!! :-D Thanks a lot for your help...I have one more question, though: If I have two devices (like the ivtv tuner and the USB card) and they share an IRQ, if I then assign BOTH of them to the same guest, will it then work? Alexander, the patch works, I hope to see it in a stable release in the near future ;) Unfortunately, I have a correction to this :( It _almost_ works. I had some video/audio artifacts which I though was caused by bad reception, but after switching the DVB-T tuner back and forth between the PCI USB card and a laptop, it got clear to me, that this was a passthrough issue. I get no errors in dmesg on the host or in the guest. I recorded a short videoclip which illustrates the issue: https://docs.google.com/leaf?id=0B-_nZameGeN-NDk4YzQ3N2EtMmEzMi00NTU4LWFjMjgtNzkxMzcxYzg2MTM1hl=en Hrm, I'm not sure these would be related to the small BAR region patch. It looks more like a timing issue. small BAR == slow path == timing issue? thanks, -chris -- 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: PCI passthrough resource remapping
Chris Wright wrote: * Alexander Graf (ag...@suse.de) wrote: Kenni Lund wrote: 2010/3/31 Kenni Lund ke...@kelu.dk: Booting the guest and tuning to a DVB-T channel _works_ !!! :-D Thanks a lot for your help...I have one more question, though: If I have two devices (like the ivtv tuner and the USB card) and they share an IRQ, if I then assign BOTH of them to the same guest, will it then work? Alexander, the patch works, I hope to see it in a stable release in the near future ;) Unfortunately, I have a correction to this :( It _almost_ works. I had some video/audio artifacts which I though was caused by bad reception, but after switching the DVB-T tuner back and forth between the PCI USB card and a laptop, it got clear to me, that this was a passthrough issue. I get no errors in dmesg on the host or in the guest. I recorded a short videoclip which illustrates the issue: https://docs.google.com/leaf?id=0B-_nZameGeN-NDk4YzQ3N2EtMmEzMi00NTU4LWFjMjgtNzkxMzcxYzg2MTM1hl=en Hrm, I'm not sure these would be related to the small BAR region patch. It looks more like a timing issue. small BAR == slow path == timing issue? Could be, yeah. The only chance I see to avoid that is to have in-kernel small BAR code that would issue the MMIO accesses without the userspace churn. One thing I could imagine would be PAGE_SIZE memory slots. Then userspace just maps the 4K to the BAR, but passes only a part of it on as slot. Alex -- 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
Some Code for Performance Profiling
Hi,
We have some code about performance profiling in KVM. They are outputs
of a school project. Previous discussions in KVM, Perfmon2, and Xen
mailing lists helped us a lot. The code are NOT in a good shape and
are only used to demonstrated the feasibility of doing performance
profiling in KVM. Feel free to use it if you want.
We categorize performance profiling in a virtualized environment into
two types: *guest-wide profiling* and *system-wide profiling*. For
guest-wide profiling, only the guest is profiled. KVM virtualizes the
PMU and the user runs a profiler directly in the guest. It requires no
modifications to the guest OS and the profiler running in the guest.
For system-wide profiling, both KVM and the guest OS are profiled. The
results are similar to what XenOprof outputs. In this case, one
profiler running in the host and one profiler running in the guest.
Still it requires no modifications to the guest and the profiler
running in it.
For guest-wide profiling, there are two possible places to save and
restore the related MSRs. One is where the CPU switches between guest
mode and host mode. We call this *CPU-switch*. Profiling with this
enabled reflects how the guest behaves on the physical CPU, plus other
virtualized, not emulated, devices. The other place is where the CPU
switches between the KVM context and others. Here KVM context means
the CPU is executing guest code or KVM code, both kernel space and
user space. We call this *domain-switch*. Profiling with this enabled
discloses how the guest behaves on both the physical CPU and KVM.
(Some emulated operations are really expensive in a virtualized
environment.)
More details can be found at http://jiaqing.org/download/profiling_kvm.tgz
=Guest-wide profiling with domain-switch, for
Linux-2.6.32==
diff --git a/arch/x86/include/asm/thread_info.h
b/arch/x86/include/asm/thread_info.h
index d27d0a2..b749b5d 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -96,6 +96,7 @@ struct thread_info {
#define TIF_DS_AREA_MSR26 /* uses
thread_struct.ds_area_msr */
#define TIF_LAZY_MMU_UPDATES 27 /* task is updating the mmu lazily */
#define TIF_SYSCALL_TRACEPOINT 28 /* syscall tracepoint instrumentation */
+#define TIF_VPMU_CTXSW 29 /* KVM thread tag */
#define _TIF_SYSCALL_TRACE (1 TIF_SYSCALL_TRACE)
#define _TIF_NOTIFY_RESUME (1 TIF_NOTIFY_RESUME)
@@ -119,6 +120,7 @@ struct thread_info {
#define _TIF_DS_AREA_MSR (1 TIF_DS_AREA_MSR)
#define _TIF_LAZY_MMU_UPDATES (1 TIF_LAZY_MMU_UPDATES)
#define _TIF_SYSCALL_TRACEPOINT(1 TIF_SYSCALL_TRACEPOINT)
+#define _TIF_VPMU_CTXSW (1 TIF_VPMU_CTXSW)
/* work to do in syscall_trace_enter() */
#define _TIF_WORK_SYSCALL_ENTRY\
@@ -146,8 +148,9 @@ struct thread_info {
/* flags to check in __switch_to() */
#define _TIF_WORK_CTXSW
\
- (_TIF_IO_BITMAP|_TIF_DEBUGCTLMSR|_TIF_DS_AREA_MSR|_TIF_NOTSC)
-
+ (_TIF_IO_BITMAP|_TIF_DEBUGCTLMSR|_TIF_DS_AREA_MSR|_TIF_NOTSC| \
+ _TIF_VPMU_CTXSW)
+
#define _TIF_WORK_CTXSW_PREV _TIF_WORK_CTXSW
#define _TIF_WORK_CTXSW_NEXT (_TIF_WORK_CTXSW|_TIF_DEBUG)
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 5284cd2..d5269d8 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -178,6 +178,53 @@ int set_tsc_mode(unsigned int val)
return 0;
}
+static const u32 vmx_pmu_msr_index[] = {
+ MSR_P6_EVNTSEL0, MSR_P6_EVNTSEL1, MSR_P6_PERFCTR0, MSR_P6_PERFCTR1,
+};
+#define NR_VMX_PMU_MSR ARRAY_SIZE(vmx_pmu_msr_index)
+static u64 vpmu_msr_list[NR_VMX_PMU_MSR];
+
+static void vpmu_load_msrs(u64 *msr_list)
+{
+u64 *p = msr_list;
+int i;
+
+ for (i = 0; i NR_VMX_PMU_MSR; ++i) {
+ wrmsrl(vmx_pmu_msr_index[i], *p);
+ p++;
+ }
+}
+
+static void vpmu_save_msrs(u64 *msr_list)
+{
+u64 *p = msr_list;
+int i;
+
+ for (i = 0; i NR_VMX_PMU_MSR; ++i) {
+ rdmsrl(vmx_pmu_msr_index[i], *p);
+ p++;
+ }
+}
+
+#define P6_EVENTSEL0_ENABLE (1 22)
+static void enable_perf(void)
+{
+u64 val;
+
+rdmsrl(MSR_P6_EVNTSEL0, val);
+val |= P6_EVENTSEL0_ENABLE;
+wrmsrl(MSR_P6_EVNTSEL0, val);
+}
+
+static void disable_perf(void)
+{
+u64 val;
+
+rdmsrl(MSR_P6_EVNTSEL0, val);
+val = ~P6_EVENTSEL0_ENABLE;
+wrmsrl(MSR_P6_EVNTSEL0, val);
+}
+
void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p,
struct tss_struct *tss)
{
@@ -186,6 +233,21 @@ void __switch_to_xtra(struct task_struct *prev_p,
struct task_struct *next_p,
prev = prev_p-thread;
next = next_p-thread;
+if (test_tsk_thread_flag(prev_p, TIF_VPMU_CTXSW)
+test_tsk_thread_flag(next_p, TIF_VPMU_CTXSW)) {
+/* do nothing, still in KVM context */
+} else {
+if
Re: can't start qemu-kvm on 2.6.34-rc3
With qemu-kvm 0.12.3 used on 2.6.34-rc3, this command: qemu-kvm -m 1500 -drive file=/srv/kvm/images/im1.qcow2,if=virtio,cache=none,index=0,boot=on -drive file=/srv/kvm/images/im1-backup.qcow2,if=virtio,cache=none,index=1 -net nic,vlan=0,model=virtio,macaddr=F2:4A:51:41:B1:AA -net tap,vlan=0,script=/etc/qemu-ifup -localtime -nographic Renders the below - is it a known issue, or something particular with my configuration? [ 282.364859] BUG: unable to handle kernel paging request at 00020001 [ 282.364863] IP: [8111c805] __kmalloc_node+0x125/0x200 [ 282.364869] PGD 17d967067 PUD 0 [ 282.364871] Oops: [#1] SMP [ 282.364873] last sysfs file: /sys/devices/system/cpu/cpu7/cache/index2/shared_cpu_map (...) If it's interesting to anyone, kvm starts fine here if I start it _before_ starting X. If I first start X, then kvm - machines starts to Oops. -- Tomasz Chmielewski http://wpkg.org -- 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: Increase NR_IOBUS_DEVS limit to 200
On Wed, 2010-03-31 at 12:51 +0300, Michael S. Tsirkin wrote:
On Tue, Mar 30, 2010 at 04:48:25PM -0700, Sridhar Samudrala wrote:
This patch increases the current hardcoded limit of NR_IOBUS_DEVS
from 6 to 200. We are hitting this limit when creating a guest with more
than 1 virtio-net device using vhost-net backend. Each virtio-net
device requires 2 such devices to service notifications from rx/tx queues.
Signed-off-by: Sridhar Samudrala s...@us.ibm.com
I tried this, but observed a measurable performance
degradation with vhost net and this patch. Did not
investigate yet. Do you see this as well?
No. I am not seeing any degradation that is not within the range of
variation seen with kvm networking.
For ex: On a Nehalem 2 socket, 8 core system, running netperf TCP_STREAM
with 64K size packets, i am getting 12-13Gb/s guest to host and
11-12Gb/s host to guest with and without this patch.
Thanks
Sridhar
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index a3fd0f9..7fb48d3 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -54,7 +54,7 @@ extern struct kmem_cache *kvm_vcpu_cache;
*/
struct kvm_io_bus {
int dev_count;
-#define NR_IOBUS_DEVS 6
+#define NR_IOBUS_DEVS 200
struct kvm_io_device *devs[NR_IOBUS_DEVS];
};
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Add Mergeable RX buffer feature to vhost_net
Michael S. Tsirkin m...@redhat.com wrote on 03/31/2010 05:02:28 AM:
attached patch seems to be whiespace damaged as well.
Does the origin pass checkpatch.pl for you?
Yes, but I probably broke it in the transfer -- will be more
careful with the next revision.
+ head.iov_base = (void *)vhost_get_vq_desc(net-dev,
vq,
+ vq-iov, ARRAY_SIZE(vq-iov), out, in, NULL,
NULL);
I this casting confusing.
Is it really expensive to add an array of heads so that
we do not need to cast?
It needs the heads and the lengths, which looks a lot
like an iovec. I was trying to resist adding a new
struct XXX { unsigned head; unsigned len; } just for this,
but I could make these parallel arrays, one with head index and
the other with length.
+ if (vq-rxmaxheadcount headcount)
+ vq-rxmaxheadcount = headcount;
This seems the only place where we set the rxmaxheadcount
value. Maybe it can be moved out of vhost.c to net.c?
If vhost library needs this it can get it as function
parameter.
I can move it to vhost_get_heads(), sure.
+ /* Skip header. TODO: support TSO. */
You seem to have removed the code that skips the header.
Won't this break non-GSO backends such as raw?
From our prior discussion, what I had in mind was that
we'd remove all special-header processing by using the ioctl
you added for TUN and later, an equivalent ioctl for raw (when
supported in qemu-kvm). Qemu would arrange headers with tap
(and later raw) to get what the guest expects, and vhost then
just passes all data as-is between the socket and the ring.
That not only removes the different-header-len code
for mergeable buffers, but also eliminates making a copy of the
header for every packet as before. Vhost has no need to do
anything with the header, or even know its length. It also
doesn't have to care what the type of the backend is-- raw or
tap.
I think that simplifies everything, but it does mean that
raw socket support requires a header ioctl for the different
vnethdr sizes if the guest wants a vnethdr with and without
mergeable buffers. Actually, I thought this was your idea and
the point of the TUNSETVNETHDRSZ ioctl, but I guess you had
something else in mind?
- /* TODO: Check specific error and bomb out unless
EAGAIN?
*/
Do you think it's not a good idea?
EAGAIN is not possible after the change, because we don't
even enter the loop unless we have an skb on the read queue; the
other cases bomb out, so I figured the comment for future work is
now done. :-)
if (err 0) {
- vhost_discard_vq_desc(vq);
+ vhost_discard_vq_desc(vq, headcount);
break;
}
I think we should detect and discard truncated messages,
since len might not be reliable if userspace pulls
a packet from under us. Also, if new packet is
shorter than the old one, there's no truncation but
headcount is wrong.
So simplest fix IMO would be to compare err with expected len.
If there's a difference, we hit the race and so
we would discard the packet.
Sure.
/* TODO: Should check and handle checksum. */
+ if (vhost_has_feature(net-dev,
VIRTIO_NET_F_MRG_RXBUF))
{
+ struct virtio_net_hdr_mrg_rxbuf *vhdr =
+ (struct virtio_net_hdr_mrg_rxbuf *)
+ vq-iov[0].iov_base;
+ /* add num_bufs */
+ if (put_user(headcount, vhdr-num_buffers)) {
+ vq_err(vq, Failed to write
num_buffers);
+ vhost_discard_vq_desc(vq, headcount);
Let's do memcpy_to_iovecend etc so that we do not assume layout.
This is also why we need move_iovec: sendmsg might modify the iovec.
It would also be nice not to corrupt memory and
get a reasonable error if buffer size
that we get is smaller than expected header size.
I wanted to avoid the header copy here, with the reasonable
restriction
that the guest gives you a buffer at least big enough for the vnet_hdr. A
length check alone (on iov[0].iov_len) could enforce that without copying
headers back and forth to support silly cases like 8-byte buffers or
num_buffers spanning multiple iovecs, and I think paying the price of the
copy on every packet to support guests that broken isn't worth it.
So, my preference here would be to add:
if (vhost_has_feature(net-dev, VIRTIO_NET_F_MRG_RXBUF))
struct virtio_net_mrg_rxbuf *vhdr...
if (vq-iov[0].iov_len sizeof(*vhdr)) {
vq_err(vq, tiny buffers (len %d %d) are not
supported,
vq-iov[0].iov_len, sizeof(*vhdr));
break;
}
[PATCH 1/1] uio_pci_generic: extensions to allow access for non-privileged processes
diff -rupN linux-2.6.33/drivers/uio/uio.c uio-2.6.33/drivers/uio/uio.c
--- linux-2.6.33/drivers/uio/uio.c 2010-02-24 10:52:17.0 -0800
+++ uio-2.6.33/drivers/uio/uio.c2010-03-31 12:26:24.0 -0700
@@ -730,12 +730,24 @@ static int uio_mmap(struct file *filep,
}
}
+static int uio_ioctl(struct inode *inode, struct file *filep,
+ unsigned int cmd, unsigned long arg)
+{
+ struct uio_listener *listener = filep-private_data;
+ struct uio_device *idev = listener-dev;
+
+ if (idev == NULL || idev-info == NULL || idev-info-ioctl == NULL)
+ return -EINVAL;
+ return idev-info-ioctl(idev-info, cmd, arg);
+}
+
static const struct file_operations uio_fops = {
.owner = THIS_MODULE,
.open = uio_open,
.release= uio_release,
.read = uio_read,
.write = uio_write,
+ .ioctl = uio_ioctl,
.mmap = uio_mmap,
.poll = uio_poll,
.fasync = uio_fasync,
diff -rupN linux-2.6.33/drivers/uio/uio_pci_generic.c
uio-2.6.33/drivers/uio/uio_pci_generic.c
--- linux-2.6.33/drivers/uio/uio_pci_generic.c 2010-02-24
10:52:17.0 -0800
+++ uio-2.6.33/drivers/uio/uio_pci_generic.c2010-03-31
16:28:33.0 -0700
@@ -1,4 +1,7 @@
-/* uio_pci_generic - generic UIO driver for PCI 2.3 devices
+/* uio_pci_generic - generic UIO driver for PCI 2.3 and PCIe devices
+ *
+ * Copyright (C) 2010 Cisco Systems, Inc.
+ * Extensions by Tom Lyon p...@cisco.com
*
* Copyright (C) 2009 Red Hat, Inc.
* Author: Michael S. Tsirkin m...@redhat.com
@@ -14,25 +17,35 @@
* # ls -l /sys/bus/pci/devices/:00:19.0/driver
* .../:00:19.0/driver - ../../../bus/pci/drivers/uio_pci_generic
*
- * Driver won't bind to devices which do not support the Interrupt Disable
Bit
+ * Driver won't bind to devices which do not support MSI, MSI-x, or the
Interrupt Disable Bit
* in the command register. All devices compliant to PCI 2.3 (circa 2002) and
- * all compliant PCI Express devices should support this bit.
+ * all compliant PCI Express devices should support one of these.
*/
#include linux/device.h
#include linux/module.h
#include linux/pci.h
+#include linux/list.h
+#include linux/mm.h
+#include linux/mmu_notifier.h
#include linux/uio_driver.h
#include linux/spinlock.h
+#include linux/iommu.h
-#define DRIVER_VERSION 0.01.0
+#define DRIVER_VERSION 0.02.0
#define DRIVER_AUTHOR Michael S. Tsirkin m...@redhat.com
-#define DRIVER_DESCGeneric UIO driver for PCI 2.3 devices
+#define DRIVER_DESCGeneric UIO driver for PCI devices
struct uio_pci_generic_dev {
struct uio_info info;
struct pci_dev *pdev;
spinlock_t lock; /* guards command register accesses */
+ int msi;
+ struct msix_entry *msix;
+ int nvec;
+ struct mm_struct *mm;
+ struct mmu_notifier mmu_notifier;
+ struct list_head dm_list;
};
static inline struct uio_pci_generic_dev *
@@ -41,6 +54,51 @@ to_uio_pci_generic_dev(struct uio_info *
return container_of(info, struct uio_pci_generic_dev, info);
}
+/* Read/modify/write command register to disable interrupts.
+ * Note: we could cache the value and optimize the read if there was a way to
+ * get notified of user changes to command register through sysfs.
+ * */
+static void irqtoggle(struct uio_pci_generic_dev *gdev, int irq_on)
+{
+ struct pci_dev *pdev = gdev-pdev;
+ unsigned long flags;
+ u16 orig, new;
+
+ spin_lock_irqsave(gdev-lock, flags);
+ pci_block_user_cfg_access(pdev);
+ pci_read_config_word(pdev, PCI_COMMAND, orig);
+ new = irq_on ? (orig ~PCI_COMMAND_INTX_DISABLE)
+ : (orig | PCI_COMMAND_INTX_DISABLE);
+ if (new != orig)
+ pci_write_config_word(gdev-pdev, PCI_COMMAND, new);
+ pci_unblock_user_cfg_access(pdev);
+ spin_unlock_irqrestore(gdev-lock, flags);
+}
+
+/* irqcontrol is use by userspace to enable/disable interrupts. */
+/* A privileged app can write the PCI_COMMAND register directly,
+ * but we need this for normal apps
+ */
+static int irqcontrol(struct uio_info *info, s32 irq_on)
+{
+ struct uio_pci_generic_dev *gdev = to_uio_pci_generic_dev(info);
+
+ irqtoggle(gdev, irq_on);
+ return 0;
+}
+
+/* MSI and MSI-X Interrupt handler.
+ * For bad devices, we may get an interrupt per event/packet, but most
+ * devices will self-throttle until user driver wants more
+ */
+static irqreturn_t msihandler(int irq, void *arg)
+{
+ struct uio_info *info = arg;
+
+ uio_event_notify(info);
+ return IRQ_HANDLED;
+}
+
/* Interrupt handler. Read/modify/write the command register to disable
* the interrupt. */
static irqreturn_t irqhandler(int irq, struct uio_info *info)
@@ -89,7 +147,7 @@ done:
/* Verify that the device supports Interrupt Disable bit in command
Re: [Autotest] [PATCH] Update sar command and handle OSError error.
On Tue, Mar 30, 2010 at 2:24 AM, Feng Yang fy...@redhat.com wrote: This patch do following things: 1. Update sar command in start function in /profilers/sar/sar.py, because when i manual run '/usr/bin/sar -o %s %d 0' command, help message is show up. Sames count number could not be 0, so use default count. The problem here is that the sar command changed its behavior: if you check man pages for older versions of sar (see http://linux.die.net/man/1/sar), you'll see: The default value for the count parameter is 1. If its value is set to zero, then reports are generated continuously. For newer versions of sar like the ones shipped in recent Fedoras, the behavior is conflicting. From the man page: If the interval parameter is specified without the count parameter, then reports are generated continuously. So, it's clear here that we have to handle the differences, otherwise the profiler won't work on older systems. 2. Put os.kill in sar.py into try block to avoid traceback. Sometimes it tried to kill an already terminated process which can cause a traceback. It just occurred to me that since we're using subprocess, we can use the terminate() method of the subprocess object, that doesn't raise exceptions when the process already returned, instead of just picking the PID and sending a sigterm on that PID. I just sent a version of this patch that does things the way I explained, and plan on change the subprocess part for the kvm_stat test profiler as well. Signed-off-by: Feng Yang fy...@redhat.com --- client/profilers/sar/sar.py | 7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/client/profilers/sar/sar.py b/client/profilers/sar/sar.py index fbe0639..e10156f 100644 --- a/client/profilers/sar/sar.py +++ b/client/profilers/sar/sar.py @@ -21,14 +21,17 @@ class sar(profiler.profiler): logfile = open(os.path.join(test.profdir, sar), 'w') # Save the sar data as binary, convert to text after the test. raw = os.path.join(test.profdir, sar.raw) - cmd = /usr/bin/sar -o %s %d 0 % (raw, self.interval) + cmd = /usr/bin/sar -o %s %d % (raw, self.interval) p = subprocess.Popen(cmd, shell=True, stdout=logfile, \ stderr=subprocess.STDOUT) self.pid = p.pid def stop(self, test): - os.kill(self.pid, 15) + try: + os.kill(self.pid, 15) + except OSError: + pass def report(self, test): -- 1.5.5.6 ___ 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] [PATCH 1/2] KVM test: Make the profiler could be configurated
On Tue, Mar 30, 2010 at 2:02 PM, Michael Goldish mgold...@redhat.com wrote:
- Jason Wang jasow...@redhat.com wrote:
The patch let the profilers could be specified through configuration
file. kvm_stat was kept as the default profiler.
Looks good. Some minor style comments:
Signed-off-by: Jason Wang jasow...@redhat.com
---
client/tests/kvm/kvm_utils.py | 23
++-
client/tests/kvm/tests_base.cfg.sample | 2 +-
2 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/client/tests/kvm/kvm_utils.py
b/client/tests/kvm/kvm_utils.py
index 8531c79..a73d5d4 100644
--- a/client/tests/kvm/kvm_utils.py
+++ b/client/tests/kvm/kvm_utils.py
@@ -866,24 +866,21 @@ def run_tests(test_list, job):
if dependencies_satisfied:
test_iterations = int(dict.get(iterations, 1))
test_tag = dict.get(shortname)
- # Setting up kvm_stat profiling during test execution.
- # We don't need kvm_stat profiling on the build tests.
- if dict.get(run_kvm_stat) == yes:
- profile = True
- else:
- # None because it's the default value on the base_test class
- # and the value None is specifically checked there.
- profile = None
+ # Setting up profilers during test execution.
+ profilers = dict.get(profilers)
+ if profilers is not None:
I think it's nicer and shorter to say if profilers instead of
if profilers is not None.
Better yet, use 'profilers = dict.get(profilers, )' so that if
profilers isn't defined, or if the user said 'profilers = ', you can
still call profilers.split(), i.e.:
profilers = dict.get(profilers, )
for profiler in profilers.split():
job.profilers.add(profiler)
and then you don't need the 'if'.
This is also relevant to the job.profilers.delete() code below.
+ for profiler in profilers.split():
+ job.profilers.add(profiler)
- if profile:
- job.profilers.add('kvm_stat')
# We need only one execution, profiled, hence we're passing
# the profile_only parameter to job.run_test().
current_status = job.run_test(kvm, params=dict, tag=test_tag,
iterations=test_iterations,
- profile_only=profile)
- if profile:
- job.profilers.delete('kvm_stat')
+ profile_only= profilers is not
None)
AFAIK, profile_only needs to be either True or None (Lucas, please correct
me if I'm wrong).
You're right, Michael, the test class code checks specifically for
None. I have just reviewed the 2nd version of the patch and it looks
good. Applied:
http://autotest.kernel.org/changeset/4365
--
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
