[PATCH] KVM test: Fix two typos in config file
Signed-off-by: Yolkfull Chow yz...@redhat.com --- client/tests/kvm/kvm_tests.cfg.sample |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/client/tests/kvm/kvm_tests.cfg.sample b/client/tests/kvm/kvm_tests.cfg.sample index ac9ef66..7f37994 100644 --- a/client/tests/kvm/kvm_tests.cfg.sample +++ b/client/tests/kvm/kvm_tests.cfg.sample @@ -840,7 +840,7 @@ variants: only up only WinXP.32 no install setup -no kvm_hugepages +no hugepages only unattended_install setup boot shutdown only rtl8139 - @fc11_kickstart: @@ -850,7 +850,7 @@ variants: only up only Fedora.11.64 no install setup -no kvm_hugepages +no hugepages only unattended_install boot shutdown only rtl8139 -- 1.6.5.2 -- 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 bug in kvm_intel
Hello, 11/01/2009 08:31 PM, Avi Kivity wrote: Here is the code in question: 3ae7: 75 05 jne 3aeevmx_vcpu_run+0x26a 3ae9: 0f 01 c2vmlaunch 3aec: eb 03 jmp 3af1vmx_vcpu_run+0x26d 3aee: 0f 01 c3vmresume 3af1: 48 87 0c 24 xchg %rcx,(%rsp) ^^^ fault, but not at (%rsp) Can you please post the full oops (including kernel debug messages during boot) or give me a pointer to the original message? http://www.mail-archive.com/kvm@vger.kernel.org/msg23458.html Also, does the faulting address coincide with any symbol? No (at least, not in System.map). Has there been any progress? Is kvm + oprofile still broken? Thanks. -- tejun -- 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
guest gets stuck on the migration from AMD to Intel
Hi folks, If I migrate a virtual machine (2.6.31.6, amd64) from a host with AMD cpu to an Intel host, then the guest is terminated on the old host as expected, but it gets stuck on the new host. Every 60 seconds it prints a message on the virtual console saying BUG: soft lockup - CPU#0 got stuck for 61s! If I reset the guest, then it boots (without problems, as it seems). There is no migration problem for AMD -- AMD and Intel -- AMD. I didn't had a chance to test Intel -- Intel yet. The virtual disk is on a common NFSv3 partition. All hosts are running 2.6.31.6 (amd64). Can anybody reproduce this? I saw the error message several times on Google, but not together with a migration from AMD to Intel. Any helpful comment would be highly appreciated. Regards Harri === processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 67 model name : Dual-Core AMD Opteron(tm) Processor 1210 stepping: 2 cpu MHz : 1795.378 cache size : 1024 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy bogomips: 3590.75 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc : : processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU E5420 @ 2.50GHz stepping: 10 cpu MHz : 2500.605 cache size : 6144 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority bogomips: 5001.21 clflush size: 64 cache_alignment : 64 address sizes : 38 bits physical, 48 bits virtual power management: : : -- 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: [RFC][PATCH] qemu-kvm: Introduce writeback scope for cpu_synchronize_state
Avi Kivity wrote: On 11/17/2009 06:50 PM, Jan Kiszka wrote: I think we're not on the same page here. As I see it, no interface change is needed at all. It's true that existing kernels don't handle this properly, which is why I said I'm willing to treat it as a bug (and thus the -stable treatment etc.). I admit it's a stretch since this is not going to be trivial (though I think less complex that you believe). Putting mp_state into the events structure is reasonable regardless of this issue (and doable since we haven't pushed it to 2.6.33 yet). But I want to understand why you think it's needed. That wouldn't be required anymore with the always queue policy. It makes sense from a grouping point of view... maybe. But what would you queue at all? Only mp_state, nmi_pending and sipi_vector? INIT, too. INIT should be handled by queuing up the next mp_state. BTW, as we do not inject mp_state changes from user space during runtime, the issue I saw with the current interface is not existing. We just need to add that queuing feature to asynchronous in-kernel mp_state changes, and we should be fine. Let's assume we will have such changes in future kernels: should qemu-kvm and qemu upstream also bother about older kernels and establish workarounds? Because then we need to find a cleaner approach than the current one, and my proposed patch comes into the game again. Jan signature.asc Description: OpenPGP digital signature
Re: [PATCH] KVM test: Fix two typos in config file
Ok, applied, thanks! On Wed, Nov 18, 2009 at 6:55 AM, Yolkfull Chow yz...@redhat.com wrote: Signed-off-by: Yolkfull Chow yz...@redhat.com --- client/tests/kvm/kvm_tests.cfg.sample | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/client/tests/kvm/kvm_tests.cfg.sample b/client/tests/kvm/kvm_tests.cfg.sample index ac9ef66..7f37994 100644 --- a/client/tests/kvm/kvm_tests.cfg.sample +++ b/client/tests/kvm/kvm_tests.cfg.sample @@ -840,7 +840,7 @@ variants: only up only WinXP.32 no install setup - no kvm_hugepages + no hugepages only unattended_install setup boot shutdown only rtl8139 - @fc11_kickstart: @@ -850,7 +850,7 @@ variants: only up only Fedora.11.64 no install setup - no kvm_hugepages + no hugepages only unattended_install boot shutdown only rtl8139 -- 1.6.5.2 -- 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 -- 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
KVM autotest patch queue report - 11-18-2009
Hi folks, I am resuming sending patch queue reports for the KVM test framework. I will heavily base it on the latest autotest's patchwork status. At any time you can see the status of the incoming patches by checking http://patchwork.test.kernel.org/project/autotest/list/ Summary: 4 patches pending work PCI device assignment http://patchwork.test.kernel.org/patch/1417/ Status: Need some work (coding style issues) before it can be integrated. Test 802.1Q vlan of nic http://patchwork.test.kernel.org/patch/1461/ Status: Some iterations of the test were spin, need a last check before it can be commited. KSM-overcommit test v.2 (python version) http://patchwork.test.kernel.org/patch/1529/ Status: Jiri sent an updated version of the KSM overcommit test according to reviewer's requirements. Pending review. KVM test: Major control file cleanup http://patchwork.test.kernel.org/patch/1464/ Status: Pending because we need to work out on a way to parse configuration from the data present on the control file before we can actually implement the cleanup. -- 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: [RFC] KVM Fault Tolerance: Kemari for KVM
2009/11/17 Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp: Avi Kivity wrote: On 11/16/2009 04:18 PM, Fernando Luis Vázquez Cao wrote: Avi Kivity wrote: On 11/09/2009 05:53 AM, Fernando Luis Vázquez Cao wrote: Kemari runs paired virtual machines in an active-passive configuration and achieves whole-system replication by continuously copying the state of the system (dirty pages and the state of the virtual devices) from the active node to the passive node. An interesting implication of this is that during normal operation only the active node is actually executing code. Can you characterize the performance impact for various workloads? I assume you are running continuously in log-dirty mode. Doesn't this make memory intensive workloads suffer? Yes, we're running continuously in log-dirty mode. We still do not have numbers to show for KVM, but the snippets below from several runs of lmbench using Xen+Kemari will give you an idea of what you can expect in terms of overhead. All the tests were run using a fully virtualized Debian guest with hardware nested paging enabled. fork exec sh P/F C/S [us] -- Base 114 349 1197 1.2845 8.2 Kemari(10GbE) + FC 141 403 1280 1.2835 11.6 Kemari(10GbE) + DRBD 161 415 1388 1.3145 11.6 Kemari(1GbE) + FC 151 410 1335 1.3370 11.5 Kemari(1GbE) + DRBD 162 413 1318 1.3239 11.6 * P/F=page fault, C/S=context switch The benchmarks above are memory intensive and, as you can see, the overhead varies widely from 7% to 40%. We also measured CPU bound operations, but, as expected, Kemari incurred almost no overhead. Is lmbench fork that memory intensive? Do you have numbers for benchmarks that use significant anonymous RSS? Say, a parallel kernel build. Note that scaling vcpus will increase a guest's memory-dirtying power but snapshot rate will not scale in the same way. I don't think lmbench is intensive but it's sensitive to memory latency. We'll measure kernel build time with minimum config, and post it later. Here are some quick numbers of parallel kernel compile time. The number of vcpu is 1, just for convenience. time make -j 2 all - Base:real 1m13.950s (user 1m2.742s, sys 0m10.446s) Kemari: real 1m22.720s (user 1m5.882s, sys 0m10.882s) time make -j 4 all - Base:real 1m11.234s (user 1m2.582s, sys 0m8.643s) Kemari: real 1m26.964s (user 1m6.530s, sys 0m12.194s) The result of Kemari includes everything, meaning dirty pages tracking and synchronization upon I/O operations to the disk. The compile time using j=4 under Kemari was worse than that of j=2, but I'm not sure this is due to dirty pages tracking or sync interval. Thanks, Yoshi -- 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 cb59a... qemu c04b2...
Hi All, This Weekly KVM Testing Report against latest kvm.git cb59a30c417e6cb45f6522e550307dfe4f6e6836 and qemu-kvm.git c04b2aebf50c7d8cba883b86d1b872ccfc8f2249. The build failure issue is fixed. The VF IRQ source exhausted error is fixed. Live Migration in latest commit cannot work. One New issue: 1. Guest has no response after migration https://sourceforge.net/tracker/?func=detailatid=893831aid=2899788group_id=180599 One Fixed Issue: 1. Guest hang with exhausted IRQ sources error if 8 VFs assigned https://sourceforge.net/tracker/?func=detailaid=2847560group_id=180599atid=893831 Seven Old Issues: 1. NIC device assignment can not work in guest with INTx mode https://sourceforge.net/tracker/?func=detailaid=2889486group_id=180599atid=893831 2. Hot-added device is not visible in guest after migration https://sourceforge.net/tracker/?func=detailatid=893831aid=2832416group_id=180599 3. ltp diotest running time is 2.54 times than before https://sourceforge.net/tracker/?func=detailaid=2723366group_id=180599atid=893831 4. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detailatid=893831aid=1991647group_id=180599 5. OpenSuse10.2 can not be installed http://sourceforge.net/tracker/index.php?func=detailaid=2088475group_id=180599atid=893831 6. Fail to Save Restore Guest https://sourceforge.net/tracker/?func=detailatid=893831aid=2175042group_id=180599 7. perfctr wrmsr warning when booting 64bit RHEl5.3 https://sourceforge.net/tracker/?func=detailaid=2721640group_id=180599atid=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 12 5 00 gtest 23 21 2 00 = control_panel 17 12 5 00 :KVM_4G_guest_64_g32e 1 1 0 00 :KVM_four_sguest_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_g32e1 0 1 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 0 1 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 1 0 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
Re: [RFC][PATCH] qemu-kvm: Introduce writeback scope for cpu_synchronize_state
On 11/18/2009 11:50 AM, Jan Kiszka wrote: INIT, too. INIT should be handled by queuing up the next mp_state. And clearing the previous queue; otherwise our queue is unbounded. BTW, as we do not inject mp_state changes from user space during runtime, the issue I saw with the current interface is not existing. We just need to add that queuing feature to asynchronous in-kernel mp_state changes, and we should be fine. Let's assume we will have such changes in future kernels: should qemu-kvm and qemu upstream also bother about older kernels and establish workarounds? Because then we need to find a cleaner approach than the current one, and my proposed patch comes into the game again. If we treat this as a bug, then we fix the older kernels too. -- 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: [RFC][PATCH] qemu-kvm: Introduce writeback scope for cpu_synchronize_state
On 11/17/2009 06:58 PM, Jan Kiszka wrote: That wouldn't be required anymore with the always queue policy. Hmm, unless we need mp_state manipulation analogously to KVM_NMI vs. KVM_SET_VCPU_STATE: The former will queue, the latter write, but may be overwritten by anything queued. If you just queue KVM_SET_MP_STATE, you still have a conflict between concurrent manipulations from user space, something we want to resolve automagically. The idea is to queue. But queueing INIT state clears the queue (we're pretending to send an INIT signal over the apic bus). -- 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: [RFC] KVM Fault Tolerance: Kemari for KVM
On 11/18/2009 03:28 PM, Yoshiaki Tamura wrote: I don't think lmbench is intensive but it's sensitive to memory latency. We'll measure kernel build time with minimum config, and post it later. Here are some quick numbers of parallel kernel compile time. The number of vcpu is 1, just for convenience. time make -j 2 all - Base:real 1m13.950s (user 1m2.742s, sys 0m10.446s) Kemari: real 1m22.720s (user 1m5.882s, sys 0m10.882s) time make -j 4 all - Base:real 1m11.234s (user 1m2.582s, sys 0m8.643s) Kemari: real 1m26.964s (user 1m6.530s, sys 0m12.194s) The result of Kemari includes everything, meaning dirty pages tracking and synchronization upon I/O operations to the disk. The compile time using j=4 under Kemari was worse than that of j=2, but I'm not sure this is due to dirty pages tracking or sync interval. Do disk writes trigger synchronization? Otherwise this is a very relaxed test. I'm surprised the degradation is so low running continuously in log-dirty. Is this an npt or ept system? Without npt or ept I'd expect less degradation since the page tables are heavily manipulated anyway. -- 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] qemu-kvm: clear only essential parts of VirtIOBlockReq on object allocation - RESUBMIT
ok,
Below is the patch. This time resent with mutt and hopefully without whitespace
changes.
This patch reduces the amount of memory being cleared on every virtio-blk IO
operation.
Improve number of IOPS when using avirtio-blk device.
On every virtio-blk IO command passed to QEMU, virtio_blk_alloc_request()
allocates and clears (with qemu_mallocz()) a VirtIOBlockReq object.
The sizeof(VirtIOBlockReq) equals 41040 bytes on my x86-64 machine.
By moving the 'elem' variable to the end of VirtIOBlockReq and
clearing only upto the address of the 'elem.in_addr' field, the
memset() call now clears only 80 bytes.
Signed-off-by: Saul Tamari stam...@gmail.com
-
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index 2630b99..de74b00 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -79,12 +79,13 @@ static inline void virtio_identify_template(struct
virtio_blk_config *bc)
typedef struct VirtIOBlockReq
{
VirtIOBlock *dev;
-VirtQueueElement elem;
struct virtio_blk_inhdr *in;
struct virtio_blk_outhdr *out;
struct virtio_scsi_inhdr *scsi;
QEMUIOVector qiov;
struct VirtIOBlockReq *next;
+/* Members that need clearing, must be added prior to elem */
+VirtQueueElement elem;
} VirtIOBlockReq;
static void virtio_blk_req_complete(VirtIOBlockReq *req, int status)
@@ -139,7 +140,8 @@ static void virtio_blk_flush_complete(void *opaque, int ret)
static VirtIOBlockReq *virtio_blk_alloc_request(VirtIOBlock *s)
{
-VirtIOBlockReq *req = qemu_mallocz(sizeof(*req));
+VirtIOBlockReq *req = qemu_malloc(sizeof(*req));
+memset(req, 0, offsetof(VirtIOBlockReq, elem.in_addr[0]));
req-dev = s;
return req;
}
--
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 2/3] Make a standalone client to be able to use global_config.ini
Almost there. Just a couple of minor things. On Tue, Nov 17, 2009 at 5:04 PM, Lucas Meneghel Rodrigues l...@redhat.com wrote: In order to make it possible the autotest client to use the global_config.ini configuration files: * Modified global_config.py to support verifying if the configuration file is under autotest's root directory, or the client directory * Extended the autotest run method to copy over the configuration files to the client. Notes for revisors (changes from previous patchset and other stuff): * The ugly create_aux_file was turned into a generic function that shows consistent behavior regardless of the parameters passed in, then 2 wrapper functions, create_state_file and create_config_file are being used, both calling create_aux_file. * Fixed spelling errors on the get_section_values docstring, as well as the function name, making them all consistent with 'section'. --- client/common_lib/global_config.py | 61 + client/common_lib/host_protections.py | 26 -- global_config.ini | 3 ++ server/autotest.py | 51 +--- 4 files changed, 118 insertions(+), 23 deletions(-) diff --git a/client/common_lib/global_config.py b/client/common_lib/global_config.py index 2bbeca0..6c801ba 100644 --- a/client/common_lib/global_config.py +++ b/client/common_lib/global_config.py @@ -8,12 +8,6 @@ __author__ = 'raph...@google.com (Travis Miller)' import os, sys, ConfigParser from autotest_lib.client.common_lib import error -dirname = os.path.dirname(sys.modules[__name__].__file__) -DEFAULT_CONFIG_FILE = os.path.abspath(os.path.join(dirname, - ../../global_config.ini)) -DEFAULT_SHADOW_FILE = os.path.abspath(os.path.join(dirname, - ../../shadow_config.ini)) - class ConfigError(error.AutotestError): pass @@ -23,12 +17,50 @@ class ConfigValueError(ConfigError): pass + +common_lib_dir = os.path.dirname(sys.modules[__name__].__file__) +client_dir = os.path.dirname(common_lib_dir) +root_dir = os.path.dirname(client_dir) + +# Check if the config files are at autotest's root dir +# This will happen if client is executing inside a full autotest tree, or if +# other entry points are being executed +global_config_path_root = os.path.join(root_dir, 'global_config.ini') +shadow_config_path_root = os.path.join(root_dir, 'shadow_config.ini') +config_in_root = (os.path.exists(global_config_path_root) and + os.path.exists(shadow_config_path_root)) + +# Check if the config files are at autotest's client dir +# This will happen if a client stand alone execution is happening +global_config_path_client = os.path.join(client_dir, 'global_config.ini') +config_in_client = os.path.exists(global_config_path_client) + +if config_in_root: + DEFAULT_CONFIG_FILE = global_config_path_root + DEFAULT_SHADOW_FILE = shadow_config_path_root + RUNNING_STAND_ALONE_CLIENT = False +elif config_in_client: + DEFAULT_CONFIG_FILE = global_config_path_client + DEFAULT_SHADOW_FILE = None + RUNNING_STAND_ALONE_CLIENT = True +else: + raise ConfigError(Could not find configuration files + needed for this program to function. Please refer to + http://autotest.kernel.org/wiki/GlobalConfig + for more info.) + + class global_config(object): _NO_DEFAULT_SPECIFIED = object() config = None config_file = DEFAULT_CONFIG_FILE shadow_file = DEFAULT_SHADOW_FILE + running_stand_alone_client = RUNNING_STAND_ALONE_CLIENT + + + def check_stand_alone_client_run(self): + return self.running_stand_alone_client def set_config_files(self, config_file=DEFAULT_CONFIG_FILE, @@ -47,6 +79,21 @@ class global_config(object): return default + def get_section_values(self, section): + + Return a config parser object containing a single session of the + global configuration, that can be later written to a file object. + + �...@param section: Section we want to turn into a config parser object. + �...@return: ConfigParser() object containing all the contents of session. + This docstring still mentions session a couple times. + cfgparser = ConfigParser.ConfigParser() + cfgparser.add_section(section) + for option, value in self.config.items(section): + cfgparser.set(section, option, value) + return cfgparser + + def get_config_value(self, section, key, type=str, default=_NO_DEFAULT_SPECIFIED, allow_blank=False): self._ensure_config_parsed() @@ -106,7 +153,7 @@ class global_config(object): # now also read the shadow file if there is one # this will
[PATCH 2/3] Make a standalone client to be able to use global_config.ini
In order to make it possible the autotest client to use the global_config.ini configuration files: * Modified global_config.py to support verifying if the configuration file is under autotest's root directory, or the client directory * Extended the autotest run method to copy over the configuration files to the client. Notes for revisors (changes from previous patchset and other stuff): * Latest comments from John adressed Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com --- client/common_lib/global_config.py| 61 + client/common_lib/host_protections.py | 26 -- global_config.ini |3 ++ server/autotest.py| 52 +--- 4 files changed, 119 insertions(+), 23 deletions(-) diff --git a/client/common_lib/global_config.py b/client/common_lib/global_config.py index 2bbeca0..04ab7ff 100644 --- a/client/common_lib/global_config.py +++ b/client/common_lib/global_config.py @@ -8,12 +8,6 @@ __author__ = 'raph...@google.com (Travis Miller)' import os, sys, ConfigParser from autotest_lib.client.common_lib import error -dirname = os.path.dirname(sys.modules[__name__].__file__) -DEFAULT_CONFIG_FILE = os.path.abspath(os.path.join(dirname, -../../global_config.ini)) -DEFAULT_SHADOW_FILE = os.path.abspath(os.path.join(dirname, -../../shadow_config.ini)) - class ConfigError(error.AutotestError): pass @@ -23,12 +17,50 @@ class ConfigValueError(ConfigError): pass + +common_lib_dir = os.path.dirname(sys.modules[__name__].__file__) +client_dir = os.path.dirname(common_lib_dir) +root_dir = os.path.dirname(client_dir) + +# Check if the config files are at autotest's root dir +# This will happen if client is executing inside a full autotest tree, or if +# other entry points are being executed +global_config_path_root = os.path.join(root_dir, 'global_config.ini') +shadow_config_path_root = os.path.join(root_dir, 'shadow_config.ini') +config_in_root = (os.path.exists(global_config_path_root) and + os.path.exists(shadow_config_path_root)) + +# Check if the config files are at autotest's client dir +# This will happen if a client stand alone execution is happening +global_config_path_client = os.path.join(client_dir, 'global_config.ini') +config_in_client = os.path.exists(global_config_path_client) + +if config_in_root: +DEFAULT_CONFIG_FILE = global_config_path_root +DEFAULT_SHADOW_FILE = shadow_config_path_root +RUNNING_STAND_ALONE_CLIENT = False +elif config_in_client: +DEFAULT_CONFIG_FILE = global_config_path_client +DEFAULT_SHADOW_FILE = None +RUNNING_STAND_ALONE_CLIENT = True +else: +raise ConfigError(Could not find configuration files + needed for this program to function. Please refer to + http://autotest.kernel.org/wiki/GlobalConfig + for more info.) + + class global_config(object): _NO_DEFAULT_SPECIFIED = object() config = None config_file = DEFAULT_CONFIG_FILE shadow_file = DEFAULT_SHADOW_FILE +running_stand_alone_client = RUNNING_STAND_ALONE_CLIENT + + +def check_stand_alone_client_run(self): +return self.running_stand_alone_client def set_config_files(self, config_file=DEFAULT_CONFIG_FILE, @@ -47,6 +79,21 @@ class global_config(object): return default +def get_section_values(self, section): + +Return a config parser object containing a single section of the +global configuration, that can be later written to a file object. + +@param section: Section we want to turn into a config parser object. +@return: ConfigParser() object containing all the contents of section. + +cfgparser = ConfigParser.ConfigParser() +cfgparser.add_section(section) +for option, value in self.config.items(section): +cfgparser.set(section, option, value) +return cfgparser + + def get_config_value(self, section, key, type=str, default=_NO_DEFAULT_SPECIFIED, allow_blank=False): self._ensure_config_parsed() @@ -106,7 +153,7 @@ class global_config(object): # now also read the shadow file if there is one # this will overwrite anything that is found in the # other config -if os.path.exists(self.shadow_file): +if self.shadow_file and os.path.exists(self.shadow_file): shadow_config = ConfigParser.ConfigParser() shadow_config.read(self.shadow_file) # now we merge shadow into global diff --git a/client/common_lib/host_protections.py b/client/common_lib/host_protections.py index 9457114..7c9e6a0 100644 --- a/client/common_lib/host_protections.py +++ b/client/common_lib/host_protections.py @@ -22,19 +22,23 @@ Protection
Re: [PATCH 2/3] Make a standalone client to be able to use global_config.ini
Looks good. On Wed, Nov 18, 2009 at 8:09 AM, Lucas Meneghel Rodrigues l...@redhat.com wrote: In order to make it possible the autotest client to use the global_config.ini configuration files: * Modified global_config.py to support verifying if the configuration file is under autotest's root directory, or the client directory * Extended the autotest run method to copy over the configuration files to the client. Notes for revisors (changes from previous patchset and other stuff): * Latest comments from John adressed Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com --- client/common_lib/global_config.py | 61 + client/common_lib/host_protections.py | 26 -- global_config.ini | 3 ++ server/autotest.py | 52 +--- 4 files changed, 119 insertions(+), 23 deletions(-) diff --git a/client/common_lib/global_config.py b/client/common_lib/global_config.py index 2bbeca0..04ab7ff 100644 --- a/client/common_lib/global_config.py +++ b/client/common_lib/global_config.py @@ -8,12 +8,6 @@ __author__ = 'raph...@google.com (Travis Miller)' import os, sys, ConfigParser from autotest_lib.client.common_lib import error -dirname = os.path.dirname(sys.modules[__name__].__file__) -DEFAULT_CONFIG_FILE = os.path.abspath(os.path.join(dirname, - ../../global_config.ini)) -DEFAULT_SHADOW_FILE = os.path.abspath(os.path.join(dirname, - ../../shadow_config.ini)) - class ConfigError(error.AutotestError): pass @@ -23,12 +17,50 @@ class ConfigValueError(ConfigError): pass + +common_lib_dir = os.path.dirname(sys.modules[__name__].__file__) +client_dir = os.path.dirname(common_lib_dir) +root_dir = os.path.dirname(client_dir) + +# Check if the config files are at autotest's root dir +# This will happen if client is executing inside a full autotest tree, or if +# other entry points are being executed +global_config_path_root = os.path.join(root_dir, 'global_config.ini') +shadow_config_path_root = os.path.join(root_dir, 'shadow_config.ini') +config_in_root = (os.path.exists(global_config_path_root) and + os.path.exists(shadow_config_path_root)) + +# Check if the config files are at autotest's client dir +# This will happen if a client stand alone execution is happening +global_config_path_client = os.path.join(client_dir, 'global_config.ini') +config_in_client = os.path.exists(global_config_path_client) + +if config_in_root: + DEFAULT_CONFIG_FILE = global_config_path_root + DEFAULT_SHADOW_FILE = shadow_config_path_root + RUNNING_STAND_ALONE_CLIENT = False +elif config_in_client: + DEFAULT_CONFIG_FILE = global_config_path_client + DEFAULT_SHADOW_FILE = None + RUNNING_STAND_ALONE_CLIENT = True +else: + raise ConfigError(Could not find configuration files + needed for this program to function. Please refer to + http://autotest.kernel.org/wiki/GlobalConfig + for more info.) + + class global_config(object): _NO_DEFAULT_SPECIFIED = object() config = None config_file = DEFAULT_CONFIG_FILE shadow_file = DEFAULT_SHADOW_FILE + running_stand_alone_client = RUNNING_STAND_ALONE_CLIENT + + + def check_stand_alone_client_run(self): + return self.running_stand_alone_client def set_config_files(self, config_file=DEFAULT_CONFIG_FILE, @@ -47,6 +79,21 @@ class global_config(object): return default + def get_section_values(self, section): + + Return a config parser object containing a single section of the + global configuration, that can be later written to a file object. + + �...@param section: Section we want to turn into a config parser object. + �...@return: ConfigParser() object containing all the contents of section. + + cfgparser = ConfigParser.ConfigParser() + cfgparser.add_section(section) + for option, value in self.config.items(section): + cfgparser.set(section, option, value) + return cfgparser + + def get_config_value(self, section, key, type=str, default=_NO_DEFAULT_SPECIFIED, allow_blank=False): self._ensure_config_parsed() @@ -106,7 +153,7 @@ class global_config(object): # now also read the shadow file if there is one # this will overwrite anything that is found in the # other config - if os.path.exists(self.shadow_file): + if self.shadow_file and os.path.exists(self.shadow_file): shadow_config = ConfigParser.ConfigParser() shadow_config.read(self.shadow_file) # now we merge shadow into global diff --git a/client/common_lib/host_protections.py
Re: [Autotest] [PATCH 2/3] Make a standalone client to be able to use global_config.ini
Greg, would you mind giving a last review on the patchset before I check this in? On Wed, Nov 18, 2009 at 2:09 PM, Lucas Meneghel Rodrigues l...@redhat.com wrote: In order to make it possible the autotest client to use the global_config.ini configuration files: * Modified global_config.py to support verifying if the configuration file is under autotest's root directory, or the client directory * Extended the autotest run method to copy over the configuration files to the client. Notes for revisors (changes from previous patchset and other stuff): * Latest comments from John adressed Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com --- client/common_lib/global_config.py | 61 + client/common_lib/host_protections.py | 26 -- global_config.ini | 3 ++ server/autotest.py | 52 +--- 4 files changed, 119 insertions(+), 23 deletions(-) diff --git a/client/common_lib/global_config.py b/client/common_lib/global_config.py index 2bbeca0..04ab7ff 100644 --- a/client/common_lib/global_config.py +++ b/client/common_lib/global_config.py @@ -8,12 +8,6 @@ __author__ = 'raph...@google.com (Travis Miller)' import os, sys, ConfigParser from autotest_lib.client.common_lib import error -dirname = os.path.dirname(sys.modules[__name__].__file__) -DEFAULT_CONFIG_FILE = os.path.abspath(os.path.join(dirname, - ../../global_config.ini)) -DEFAULT_SHADOW_FILE = os.path.abspath(os.path.join(dirname, - ../../shadow_config.ini)) - class ConfigError(error.AutotestError): pass @@ -23,12 +17,50 @@ class ConfigValueError(ConfigError): pass + +common_lib_dir = os.path.dirname(sys.modules[__name__].__file__) +client_dir = os.path.dirname(common_lib_dir) +root_dir = os.path.dirname(client_dir) + +# Check if the config files are at autotest's root dir +# This will happen if client is executing inside a full autotest tree, or if +# other entry points are being executed +global_config_path_root = os.path.join(root_dir, 'global_config.ini') +shadow_config_path_root = os.path.join(root_dir, 'shadow_config.ini') +config_in_root = (os.path.exists(global_config_path_root) and + os.path.exists(shadow_config_path_root)) + +# Check if the config files are at autotest's client dir +# This will happen if a client stand alone execution is happening +global_config_path_client = os.path.join(client_dir, 'global_config.ini') +config_in_client = os.path.exists(global_config_path_client) + +if config_in_root: + DEFAULT_CONFIG_FILE = global_config_path_root + DEFAULT_SHADOW_FILE = shadow_config_path_root + RUNNING_STAND_ALONE_CLIENT = False +elif config_in_client: + DEFAULT_CONFIG_FILE = global_config_path_client + DEFAULT_SHADOW_FILE = None + RUNNING_STAND_ALONE_CLIENT = True +else: + raise ConfigError(Could not find configuration files + needed for this program to function. Please refer to + http://autotest.kernel.org/wiki/GlobalConfig + for more info.) + + class global_config(object): _NO_DEFAULT_SPECIFIED = object() config = None config_file = DEFAULT_CONFIG_FILE shadow_file = DEFAULT_SHADOW_FILE + running_stand_alone_client = RUNNING_STAND_ALONE_CLIENT + + + def check_stand_alone_client_run(self): + return self.running_stand_alone_client def set_config_files(self, config_file=DEFAULT_CONFIG_FILE, @@ -47,6 +79,21 @@ class global_config(object): return default + def get_section_values(self, section): + + Return a config parser object containing a single section of the + global configuration, that can be later written to a file object. + + �...@param section: Section we want to turn into a config parser object. + �...@return: ConfigParser() object containing all the contents of section. + + cfgparser = ConfigParser.ConfigParser() + cfgparser.add_section(section) + for option, value in self.config.items(section): + cfgparser.set(section, option, value) + return cfgparser + + def get_config_value(self, section, key, type=str, default=_NO_DEFAULT_SPECIFIED, allow_blank=False): self._ensure_config_parsed() @@ -106,7 +153,7 @@ class global_config(object): # now also read the shadow file if there is one # this will overwrite anything that is found in the # other config - if os.path.exists(self.shadow_file): + if self.shadow_file and os.path.exists(self.shadow_file): shadow_config = ConfigParser.ConfigParser() shadow_config.read(self.shadow_file) # now we merge shadow
[ty...@mit.edu: Need a way disable gPXE boot]
---BeginMessage--- I recently updated to the latest qemu-kvm git tree (commit c04b2ae) and I ran into the following problem. I want to do a direct Linux boot for some of my testing work, using the -kernel option. Apparently the the gPXE boot code corrupts something in memory or other CPU state which causes the loaded kernel to hang after the gPXE code gives up. I can suppress this using -net none, but of course then I don't have any networking access. I was ultimately able to work around the solution by deleting the /usr/local/share/qemu/pxe-*.bin files, but that's a bit of a botch. It would be nice if there was a way to disable the gPXE boot option roms; if you know you are booting off of a passed in hard drive image or passed in a kernel for a direct boot, there's no reason why we might want to do a gPXE boot. It would be nice if there was a way to disable option roms automatically if -kernel is specified, or if -boot order doesn't include 'n', or perhaps with an explicit option to suppress all boot option roms (or all networking options). What sort of approach would be considered acceptable? Did I miss some way of making the right thing happen other than deleting the installed pxe-*.bin files? Thanks, - Ted ---End Message---
Re: Windows XP Bluescreen when unplugging printer
Jim Paris wrote: Erik Rull wrote: Hi all, I want to run an epson inkjet within my windows xp guest. my host has enabled usb 2.0, the USB flashdrive works without any problems. When I plug in the printer (works with the same drivers on a native windows xp!), it is recognized and the status monitor shows also the ink levels. Until I start printing. Then the ink level disappears and the status monitor hangs. The printer itself doesn't do anything, no LED blinks, no printing starts. When I shut down windows or unplug the printer I get a bluescreen in XP on usbuhci.sys Interesting: When I switch off USB 2.0 and enable only USB 1.x in the host BIOS, everything related to USB is SLOW (usb flash drive, too!) but the printer works (also slow, but it prints). Any ideas what could cause that behaviour? Comes up with kvm-88 and kvm-77 as well. I tested it on two different systems both the same behaviour. You might try this usb fix: http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=c4c0e236beabb9de5ff472f77aeb811ec5484615 It's been around for a while but hasn't made it into any qemu or kvm releases yet. -jim -- 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 Hi Jim, sorry, still a bluescreen - but another one :-) BUGCODE_USBDRIVER is its name. Any other ideas? With USB 1.1 on the host everything is fine, after enabling USB 2.0 in BIOS on the host, USB is faster within the guest, but I have the given Bluescreen problem. Best regards, Erik -- 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: Windows XP Bluescreen when unplugging printer
Erik Rull wrote: Jim Paris wrote: Erik Rull wrote: Hi all, I want to run an epson inkjet within my windows xp guest. my host has enabled usb 2.0, the USB flashdrive works without any problems. When I plug in the printer (works with the same drivers on a native windows xp!), it is recognized and the status monitor shows also the ink levels. Until I start printing. Then the ink level disappears and the status monitor hangs. The printer itself doesn't do anything, no LED blinks, no printing starts. When I shut down windows or unplug the printer I get a bluescreen in XP on usbuhci.sys Interesting: When I switch off USB 2.0 and enable only USB 1.x in the host BIOS, everything related to USB is SLOW (usb flash drive, too!) but the printer works (also slow, but it prints). Any ideas what could cause that behaviour? Comes up with kvm-88 and kvm-77 as well. I tested it on two different systems both the same behaviour. You might try this usb fix: http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=c4c0e236beabb9de5ff472f77aeb811ec5484615 It's been around for a while but hasn't made it into any qemu or kvm releases yet. -jim -- 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 Hi Jim, sorry, still a bluescreen - but another one :-) BUGCODE_USBDRIVER is its name. Any other ideas? With USB 1.1 on the host everything is fine, after enabling USB 2.0 in BIOS on the host, USB is faster within the guest, but I have the given Bluescreen problem. Best regards, No ideas, sorry. It might be a Windows driver problem triggered by qemu timing differences (try reinstalling the printer drivers?) You might also try enabling DEBUG in usb-linux.c and compare the output you get there with a usbmon capture on the host, and a usbsnoopy capture on the guest, to see if there are any discrepencies. Not sure what kind of thing you'd be looking for, though. -jim -- 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: Windows XP Bluescreen when unplugging printer
Jim Paris wrote: Erik Rull wrote: Hi Jim, sorry, still a bluescreen - but another one :-) BUGCODE_USBDRIVER is its name. Any other ideas? With USB 1.1 on the host everything is fine, after enabling USB 2.0 in BIOS on the host, USB is faster within the guest, but I have the given Bluescreen problem. Best regards, No ideas, sorry. It might be a Windows driver problem triggered by qemu timing differences (try reinstalling the printer drivers?) You might also try enabling DEBUG in usb-linux.c and compare the output you get there with a usbmon capture on the host, and a usbsnoopy capture on the guest, to see if there are any discrepencies. Not sure what kind of thing you'd be looking for, though. -jim Hm, what I forgot to say: Now the bluescreen comes up directly after trying to print, before it only appeared on unplugging or shutdown. And: It seems to be a USB 2.0 issue. When I plug in a USB 1.1 printer everything is fine?? Can you recommend a usb sniffer tool? Hope this helps when getting a bluescreen :-) Best regards, Erik -- 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: Windows XP Bluescreen when unplugging printer
Erik Rull wrote: Jim Paris wrote: Erik Rull wrote: Hi Jim, sorry, still a bluescreen - but another one :-) BUGCODE_USBDRIVER is its name. Any other ideas? With USB 1.1 on the host everything is fine, after enabling USB 2.0 in BIOS on the host, USB is faster within the guest, but I have the given Bluescreen problem. Best regards, No ideas, sorry. It might be a Windows driver problem triggered by qemu timing differences (try reinstalling the printer drivers?) You might also try enabling DEBUG in usb-linux.c and compare the output you get there with a usbmon capture on the host, and a usbsnoopy capture on the guest, to see if there are any discrepencies. Not sure what kind of thing you'd be looking for, though. -jim Hm, what I forgot to say: Now the bluescreen comes up directly after trying to print, before it only appeared on unplugging or shutdown. And: It seems to be a USB 2.0 issue. When I plug in a USB 1.1 printer everything is fine?? Can you recommend a usb sniffer tool? Hope this helps when getting a bluescreen :-) usbmon (e.g. with wireshark) on the Linux host should work. usbsnoopy is a tool you can use on the Windows guest side. Of course, if the guest OS is crashing it's going to be hard to get any useful data out of that after the crash. -jim -- 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-devel] Re: SeaBIOS cdrom regression with Vista
On Wed, Nov 18, 2009 at 12:19:20AM -0500, Kevin O'Connor wrote: On Tue, Nov 17, 2009 at 03:21:31PM +0200, Avi Kivity wrote: qemu-kvm's switch to seabios uncovered a regression with cdrom handling. Vista x64 no longer recognizes the cdrom, while pc-bios still works. Installing works, but that uses int 13, not the native driver. Haven't investigated further yet. Thanks for reporting Avi. I will take a look as well. I'm able to reproduce this problem on my machine with a 32bit vista install. I'll let you know what I find. -Kevin -- 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: [RFC] KVM Fault Tolerance: Kemari for KVM
2009/11/18 Avi Kivity a...@redhat.com: On 11/18/2009 03:28 PM, Yoshiaki Tamura wrote: I don't think lmbench is intensive but it's sensitive to memory latency. We'll measure kernel build time with minimum config, and post it later. Here are some quick numbers of parallel kernel compile time. The number of vcpu is 1, just for convenience. time make -j 2 all - Base: real 1m13.950s (user 1m2.742s, sys 0m10.446s) Kemari: real 1m22.720s (user 1m5.882s, sys 0m10.882s) time make -j 4 all - Base: real 1m11.234s (user 1m2.582s, sys 0m8.643s) Kemari: real 1m26.964s (user 1m6.530s, sys 0m12.194s) The result of Kemari includes everything, meaning dirty pages tracking and synchronization upon I/O operations to the disk. The compile time using j=4 under Kemari was worse than that of j=2, but I'm not sure this is due to dirty pages tracking or sync interval. Do disk writes trigger synchronization? Otherwise this is a very relaxed test. I'm surprised the degradation is so low running continuously in log-dirty. They do. I double checked the traffic on the synchronization network. Attached file is a graph that shows the traffic during kernel compiling under Kemari. It seems j=4 produces more traffic than j=2, and after finishing compilation, both of the traffic drop to the normal rate. Is this an npt or ept system? Without npt or ept I'd expect less degradation since the page tables are heavily manipulated anyway. This is an ept system indeed. If properly implemented, Kemari should work not only on x86 but also on other archs, and I'm interested in how the numbers would differ. Thanks, Yoshi -- 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 kernel-compile-traffic.pdf Description: Adobe PDF document
[PATCH] viostor driver. Xp driver performance.
repository: /home/vadimr/shares/kvm-guest-drivers-windows
branch: XP
commit 3b2926a281a769499944a23cc3c9b905593e6838
Author: Vadim Rozenfeldvroze...@redhat.com
Date: Thu Nov 19 09:14:38 2009 +0200
[PATCH] viostor driver. Xp driver performance.
Signed-off-by: Vadim Rozenfeldvroze...@redhat.com
diff --git a/viostor/virtio_stor.c b/viostor/virtio_stor.c
index c36b85b..e674dff 100644
--- a/viostor/virtio_stor.c
+++ b/viostor/virtio_stor.c
@@ -215,6 +215,7 @@ VirtIoFindAdapter(
ConfigInfo-Dma32BitAddresses = TRUE;
ConfigInfo-Dma64BitAddresses = TRUE;
ConfigInfo-WmiDataProvider= FALSE;
+
#ifdef USE_STORPORT
ConfigInfo-MapBuffers = STOR_MAP_NON_READ_WRITE_BUFFERS;
ConfigInfo-SynchronizationModel = StorSynchronizeFullDuplex;
@@ -286,7 +287,7 @@ VirtIoFindAdapter(
if(adaptExt-dump_mode) {
ConfigInfo-NumberOfPhysicalBreaks = 8;
} else {
-ConfigInfo-NumberOfPhysicalBreaks = 16;
+ConfigInfo-NumberOfPhysicalBreaks = MAX_PHYS_SEGMENTS-1;
}
ConfigInfo-MaximumTransferLength = ConfigInfo-NumberOfPhysicalBreaks *
PAGE_SIZE;
@@ -316,7 +317,6 @@ VirtIoFindAdapter(
InitializeListHead(adaptExt-list_head);
InitializeListHead(adaptExt-complete_list);
-
return SP_RETURN_FOUND;
}
@@ -470,9 +470,7 @@ VirtIoStartIo(
{
PCDB cdb = (PCDB)Srb-Cdb[0];
-PADAPTER_EXTENSION adaptExt;
-
-adaptExt = (PADAPTER_EXTENSION)DeviceExtension;
+PADAPTER_EXTENSION adaptExt = (PADAPTER_EXTENSION)DeviceExtension;
switch (Srb-Function) {
case SRB_FUNCTION_EXECUTE_SCSI:
@@ -591,7 +589,6 @@ VirtIoStartIo(
return TRUE;
}
-
BOOLEAN
VirtIoInterrupt(
IN PVOID DeviceExtension
@@ -600,12 +597,10 @@ VirtIoInterrupt(
pblk_reqvbr;
unsigned intlen;
unsigned long flags;
-PADAPTER_EXTENSION adaptExt;
+PADAPTER_EXTENSION adaptExt = (PADAPTER_EXTENSION)DeviceExtension;
BOOLEAN isInterruptServiced = FALSE;
PSCSI_REQUEST_BLOCK Srb;
-adaptExt = (PADAPTER_EXTENSION)DeviceExtension;
-
RhelDbgPrint(TRACE_LEVEL_VERBOSE, (%s (%d)\n, __FUNCTION__,
KeGetCurrentIrql()));
if (VirtIODeviceISR(DeviceExtension) 0) {
@@ -1019,7 +1014,6 @@ RhelGetLba(
PCDB Cdb
)
{
-
EIGHT_BYTE lba;
switch (Cdb-CDB6GENERIC.OperationCode) {
@@ -1094,7 +1088,7 @@ CompleteDPC(
{
PSCSI_REQUEST_BLOCK Srb = (PSCSI_REQUEST_BLOCK)vbr-req;
PADAPTER_EXTENSION adaptExt = (PADAPTER_EXTENSION)DeviceExtension;
-
+PRHEL_SRB_EXTENSION srbExt = (PRHEL_SRB_EXTENSION)Srb-SrbExtension;
RemoveEntryList(vbr-list_entry);
#ifdef USE_STORPORT
@@ -1106,13 +1100,22 @@ CompleteDPC(
NULL);
return;
}
-#endif
CompleteSRB(DeviceExtension, Srb);
-#ifndef USE_STORPORT
---adaptExt-requests;
+#else
+ScsiPortNotification(RequestComplete,
+ DeviceExtension,
+ Srb);
+if(srbExt-call_next) {
+ScsiPortNotification(NextLuRequest,
+ DeviceExtension,
+ Srb-PathId,
+ Srb-TargetId,
+ Srb-Lun);
+}
#endif
}
+
#ifdef USE_STORPORT
VOID
CompleteDpcRoutine(
diff --git a/viostor/virtio_stor.h b/viostor/virtio_stor.h
index c00600c..ac143ea 100644
--- a/viostor/virtio_stor.h
+++ b/viostor/virtio_stor.h
@@ -52,7 +52,7 @@ typedef struct VirtIOBufferDescriptor VIO_SG, *PVIO_SG;
#define VIRTIO_BLK_S_UNSUPP2
#define SECTOR_SIZE 512
-#define MAX_PHYS_SEGMENTS 128
+#define MAX_PHYS_SEGMENTS 17 //128
#define VIRTIO_MAX_SG (3+MAX_PHYS_SEGMENTS)
#define IO_PORT_LENGTH 0x40
@@ -105,8 +105,6 @@ typedef struct _ADAPTER_EXTENSION {
LIST_ENTRYcomplete_list;
#ifdef USE_STORPORT
STOR_DPC completion_dpc;
-#else
-ULONG requests;
#endif
BOOLEAN has_sn;
ULONG msix_vectors;
@@ -116,6 +114,10 @@ typedef struct _RHEL_SRB_EXTENSION {
blk_req vbr;
ULONG out;
ULONG in;
+PSCSI_REQUEST_BLOCK srb;
+#ifndef USE_STORPORT
+BOOLEAN call_next;
+#endif
}RHEL_SRB_EXTENSION, *PRHEL_SRB_EXTENSION;
ULONGLONG
diff --git a/viostor/virtio_stor.c b/viostor/virtio_stor.c
index c36b85b..e674dff 100644
--- a/viostor/virtio_stor.c
+++ b/viostor/virtio_stor.c
@@ -215,6 +215,7 @@ VirtIoFindAdapter(
ConfigInfo-Dma32BitAddresses = TRUE;
ConfigInfo-Dma64BitAddresses = TRUE;
ConfigInfo-WmiDataProvider= FALSE;
+
#ifdef USE_STORPORT
ConfigInfo-MapBuffers = STOR_MAP_NON_READ_WRITE_BUFFERS;
ConfigInfo-SynchronizationModel = StorSynchronizeFullDuplex;
@@ -286,7 +287,7 @@ VirtIoFindAdapter(
if(adaptExt-dump_mode) {
ConfigInfo-NumberOfPhysicalBreaks = 8;
} else {
-
Re: [PATCH 0/3] Split up pv-ops
On 11/18/2009 02:13 AM, Alexander Graf wrote: Paravirt ops is currently only capable of either replacing a lot of Linux internal code or none at all. The are users that don't need all of the possibilities pv-ops delivers though. On KVM for example we're perfectly fine not using the PV MMU, thus not touching any MMU code. That way we don't have to improve pv-ops to become fast, we just don't compile the MMU parts in! This patchset splits pv-ops into several smaller config options split by feature category and then converts the KVM pv-ops code to use only the bits that are required, lowering overhead. Alexander Graf (3): Split paravirt ops by functionality Only export selected pv-ops feature structs Split the KVM pv-ops support by feature The whole thing looks good to me. Let's wait for Jeremy to ack though. -- 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
[PATCH] viostor driver. small fix in startio routine (storport related path).
repository: /home/vadimr/shares/kvm-guest-drivers-windows
branch: XP
commit 7f637876e7f8ef9a18d3baac31a4648034dcedaf
Author: Vadim Rozenfeldvroze...@redhat.com
Date: Thu Nov 19 09:50:32 2009 +0200
[PATCH] viostor driver. small fix in startio routine (storport related
path).
Signed-off-by: Vadim Rozenfeldvroze...@redhat.com
diff --git a/viostor/virtio_stor_hw_helper.c b/viostor/virtio_stor_hw_helper.c
index 2e61b30..fac9792 100644
--- a/viostor/virtio_stor_hw_helper.c
+++ b/viostor/virtio_stor_hw_helper.c
@@ -27,7 +27,7 @@ SynchronizedAccessRoutine(
if (adaptExt-pci_vq_info.vq-vq_ops-add_buf(adaptExt-pci_vq_info.vq,
srbExt-vbr.sg[0],
srbExt-out, srbExt-in,
-srbExt-vbr) == 0){
+srbExt-vbr)= 0){
InsertTailList(adaptExt-list_head,srbExt-vbr.list_entry);
adaptExt-pci_vq_info.vq-vq_ops-kick(adaptExt-pci_vq_info.vq);
return TRUE;
diff --git a/viostor/virtio_stor_hw_helper.c b/viostor/virtio_stor_hw_helper.c
index 2e61b30..fac9792 100644
--- a/viostor/virtio_stor_hw_helper.c
+++ b/viostor/virtio_stor_hw_helper.c
@@ -27,7 +27,7 @@ SynchronizedAccessRoutine(
if (adaptExt-pci_vq_info.vq-vq_ops-add_buf(adaptExt-pci_vq_info.vq,
srbExt-vbr.sg[0],
srbExt-out, srbExt-in,
- srbExt-vbr) == 0){
+ srbExt-vbr) = 0){
InsertTailList(adaptExt-list_head, srbExt-vbr.list_entry);
adaptExt-pci_vq_info.vq-vq_ops-kick(adaptExt-pci_vq_info.vq);
return TRUE;
