[PATCH] KVM: Fix EPT identity IOCTL on 32pae
Copy u64 from guest result in chaos.
Also fix a mistake of still using old macro rather than new variable().
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
arch/x86/kvm/vmx.c |2 +-
arch/x86/kvm/x86.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 7931c72..c5aaa1b 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2199,7 +2199,7 @@ static int alloc_identity_pagetable(struct kvm *kvm)
goto out;
kvm-arch.ept_identity_pagetable = gfn_to_page(kvm,
- VMX_EPT_IDENTITY_PAGETABLE_ADDR PAGE_SHIFT);
+ kvm-arch.ept_identity_map_addr PAGE_SHIFT);
out:
up_write(kvm-slots_lock);
return r;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 2539e9a..977b705 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2178,7 +2178,7 @@ long kvm_arch_vm_ioctl(struct file *filp,
goto out;
break;
case KVM_SET_IDENTITY_MAP_ADDR: {
- u64 ident_addr;
+ unsigned long ident_addr;
r = -EFAULT;
if (copy_from_user(ident_addr, argp, sizeof ident_addr))
--
1.5.4.5
--
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-AUTOTEST PATCH 12/12] KVM test: make stress_boot work properly with TAP networking
- Yolkfull Chow yz...@redhat.com wrote: Hi Michael, I just have some comments on what you changed on stress_boot. :-) On Mon, Aug 03, 2009 at 02:58:21AM +0300, Michael Goldish wrote: Take an additional parameter 'clone_address_index_base' which indicates the initial value for 'address_index' for the cloned VMs. This value is incremented after each clone is created. I assume the original VM has a single NIC; otherwise NICs will end up sharing MAC addresses, which is bad. Also, make a few small corrections: - Take the params for the clones from the original VM's params, not from the test's params, because the test's params contain information about several VMs, only one of which is the original VM. The original VM's params, on the other hand, describe just a single VM (which we want to clone). - Change the way kill_vm.* parameters are sent to the postprocessor. (The postprocessor doesn't read params from the VM objects but rather from the test's params dict.) - Replace 'if get_command_status(...)' with 'if get_command_status(...) != 0'. - Replace the test command 'ps aux' with 'uname -a'. The silly reason for this is that DSL-4.2.5 doesn't like 'ps aux'. Since 'uname -a' is just as good (AFAIK), use it instead. Signed-off-by: Michael Goldish mgold...@redhat.com --- client/tests/kvm/kvm_tests.cfg.sample |7 ++- client/tests/kvm/kvm_tests.py | 14 ++ 2 files changed, 12 insertions(+), 9 deletions(-) diff --git a/client/tests/kvm/kvm_tests.cfg.sample b/client/tests/kvm/kvm_tests.cfg.sample index 3c23432..3a4bf64 100644 --- a/client/tests/kvm/kvm_tests.cfg.sample +++ b/client/tests/kvm/kvm_tests.cfg.sample @@ -117,7 +117,12 @@ variants: - stress_boot: install setup type = stress_boot max_vms = 5 -alive_test_cmd = ps aux +alive_test_cmd = uname -a +clone_address_index_base = 10 +kill_vm = yes +kill_vm_vm1 = no Actually, there are two methods to deal with started VMs via framework, one is as soon as the current test finished and the other is just before next test going to be started. In this case both methods equal somewhat between each other I think, and I had chosen the later one. But if you had done some testing and proved the previous one is better, I would agree. It's not that I tested and found the former to be better, it's just that if a user runs only stress_boot, it makes sense to clean up at the end of the test, not at the beginning of the next one (because there's no next one). Since you're adding VMs to the postprocessor's params (params['vms'] += + vm_name) I thought we might as well use that. (In order to clean up the VMs automatically when the next test starts, we don't need to add the VM to those params -- only to 'env'.) +kill_vm_gracefully = no This has been specified within code during cloning. Right, but the postprocessor is supposed to ignore that, because it doesn't look at the params inside the VM -- it looks at test params that get to the postprocessor. +extra_params += -snapshot If you add this option '-snapshot' here, the first VM will be in snapshot mode as well which will affect next test. Which is good in my opinion, because I don't want the first VM writing to the same image that others are reading from. It sounds like it might Let me know what you think. Thanks, Michael - shutdown: install setup type = shutdown diff --git a/client/tests/kvm/kvm_tests.py b/client/tests/kvm/kvm_tests.py index 9784ec9..308db97 100644 --- a/client/tests/kvm/kvm_tests.py +++ b/client/tests/kvm/kvm_tests.py @@ -541,8 +541,8 @@ def run_stress_boot(tests, params, env): raise error.TestFail(Could not log into first guest) num = 2 -vms = [] sessions = [session] +address_index = int(params.get(clone_address_index_base, 10)) # boot the VMs while num = int(params.get(max_vms)): @@ -550,15 +550,12 @@ def run_stress_boot(tests, params, env): vm_name = vm + str(num) # clone vm according to the first one -vm_params = params.copy() -vm_params['image_snapshot'] = yes -vm_params['kill_vm'] = yes -vm_params['kill_vm_gracefully'] = no +vm_params = vm.get_params().copy() +vm_params[address_index] = str(address_index) curr_vm = vm.clone(vm_name, vm_params) kvm_utils.env_register_vm(env, vm_name, curr_vm) params['vms'] += + vm_name -#vms.append(curr_vm) logging.info(Booting guest #%d % num) if not curr_vm.create(): raise error.TestFail(Cannot create VM #%d % num) @@ -571,10 +568,11 @@ def run_stress_boot(tests, params,
Re: recommended clock source
On 08/03/2009 04:52 AM, Kent Tong wrote: Hi, It seems to be an unsettled issue, but, would any kind soul suggest the current best practice for setting the clock in Ubuntu Linux and Windows guests? For Linux the best source clock is the kvm pv clock (exist from 2.6.27 and above). For windows, standard acpi HAL uses the rtc clock by default. As long as you use the -rtc-td-hack it won't drift. When the tsc is not stable on the host or the host cpu might get into deep sleep state (c2), you better use another source clock in the guest - for windows it should be the pmtimer (using the boot.ini). Thanks! -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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-AUTOTEST PATCH 12/12] KVM test: make stress_boot work properly with TAP networking
On Mon, Aug 03, 2009 at 02:45:23AM -0400, Michael Goldish wrote: - Yolkfull Chow yz...@redhat.com wrote: Hi Michael, I just have some comments on what you changed on stress_boot. :-) On Mon, Aug 03, 2009 at 02:58:21AM +0300, Michael Goldish wrote: Take an additional parameter 'clone_address_index_base' which indicates the initial value for 'address_index' for the cloned VMs. This value is incremented after each clone is created. I assume the original VM has a single NIC; otherwise NICs will end up sharing MAC addresses, which is bad. Also, make a few small corrections: - Take the params for the clones from the original VM's params, not from the test's params, because the test's params contain information about several VMs, only one of which is the original VM. The original VM's params, on the other hand, describe just a single VM (which we want to clone). - Change the way kill_vm.* parameters are sent to the postprocessor. (The postprocessor doesn't read params from the VM objects but rather from the test's params dict.) - Replace 'if get_command_status(...)' with 'if get_command_status(...) != 0'. - Replace the test command 'ps aux' with 'uname -a'. The silly reason for this is that DSL-4.2.5 doesn't like 'ps aux'. Since 'uname -a' is just as good (AFAIK), use it instead. Signed-off-by: Michael Goldish mgold...@redhat.com --- client/tests/kvm/kvm_tests.cfg.sample |7 ++- client/tests/kvm/kvm_tests.py | 14 ++ 2 files changed, 12 insertions(+), 9 deletions(-) diff --git a/client/tests/kvm/kvm_tests.cfg.sample b/client/tests/kvm/kvm_tests.cfg.sample index 3c23432..3a4bf64 100644 --- a/client/tests/kvm/kvm_tests.cfg.sample +++ b/client/tests/kvm/kvm_tests.cfg.sample @@ -117,7 +117,12 @@ variants: - stress_boot: install setup type = stress_boot max_vms = 5 -alive_test_cmd = ps aux +alive_test_cmd = uname -a +clone_address_index_base = 10 +kill_vm = yes +kill_vm_vm1 = no Actually, there are two methods to deal with started VMs via framework, one is as soon as the current test finished and the other is just before next test going to be started. In this case both methods equal somewhat between each other I think, and I had chosen the later one. But if you had done some testing and proved the previous one is better, I would agree. It's not that I tested and found the former to be better, it's just that if a user runs only stress_boot, it makes sense to clean up at the end of the test, not at the beginning of the next one (because there's no next one). Since you're adding VMs to the postprocessor's params (params['vms'] += + vm_name) I thought we might as well use that. (In order to clean up the VMs automatically when the next test starts, we don't need to add the VM to those params -- only to 'env'.) Hmm...yes, if users only want to run stress_boot, cleaning up should be implemented at the end of the test. +kill_vm_gracefully = no This has been specified within code during cloning. Right, but the postprocessor is supposed to ignore that, because it doesn't look at the params inside the VM -- it looks at test params that get to the postprocessor. +extra_params += -snapshot If you add this option '-snapshot' here, the first VM will be in snapshot mode as well which will affect next test. Which is good in my opinion, because I don't want the first VM writing to the same image that others are reading from. It sounds like it might Let me know what you think. My opinion is, since the scenario that the first VM using non-snapshot mode while the others do has not caused any problem, why not just keep the first VM in non-snapshot mode and let it to be used in next test which really save booting time? What do you think? Please let me know if there is a trap in such scenario. Thanks. :-) Thanks, Michael - shutdown: install setup type = shutdown diff --git a/client/tests/kvm/kvm_tests.py b/client/tests/kvm/kvm_tests.py index 9784ec9..308db97 100644 --- a/client/tests/kvm/kvm_tests.py +++ b/client/tests/kvm/kvm_tests.py @@ -541,8 +541,8 @@ def run_stress_boot(tests, params, env): raise error.TestFail(Could not log into first guest) num = 2 -vms = [] sessions = [session] +address_index = int(params.get(clone_address_index_base, 10)) # boot the VMs while num = int(params.get(max_vms)): @@ -550,15 +550,12 @@ def run_stress_boot(tests, params, env): vm_name = vm + str(num) # clone vm according to the first one -vm_params = params.copy() -
Re: [KVM-AUTOTEST PATCH 12/12] KVM test: make stress_boot work properly with TAP networking
- Yolkfull Chow yz...@redhat.com wrote: On Mon, Aug 03, 2009 at 02:45:23AM -0400, Michael Goldish wrote: - Yolkfull Chow yz...@redhat.com wrote: Hi Michael, I just have some comments on what you changed on stress_boot. :-) On Mon, Aug 03, 2009 at 02:58:21AM +0300, Michael Goldish wrote: Take an additional parameter 'clone_address_index_base' which indicates the initial value for 'address_index' for the cloned VMs. This value is incremented after each clone is created. I assume the original VM has a single NIC; otherwise NICs will end up sharing MAC addresses, which is bad. Also, make a few small corrections: - Take the params for the clones from the original VM's params, not from the test's params, because the test's params contain information about several VMs, only one of which is the original VM. The original VM's params, on the other hand, describe just a single VM (which we want to clone). - Change the way kill_vm.* parameters are sent to the postprocessor. (The postprocessor doesn't read params from the VM objects but rather from the test's params dict.) - Replace 'if get_command_status(...)' with 'if get_command_status(...) != 0'. - Replace the test command 'ps aux' with 'uname -a'. The silly reason for this is that DSL-4.2.5 doesn't like 'ps aux'. Since 'uname -a' is just as good (AFAIK), use it instead. Signed-off-by: Michael Goldish mgold...@redhat.com --- client/tests/kvm/kvm_tests.cfg.sample |7 ++- client/tests/kvm/kvm_tests.py | 14 ++ 2 files changed, 12 insertions(+), 9 deletions(-) diff --git a/client/tests/kvm/kvm_tests.cfg.sample b/client/tests/kvm/kvm_tests.cfg.sample index 3c23432..3a4bf64 100644 --- a/client/tests/kvm/kvm_tests.cfg.sample +++ b/client/tests/kvm/kvm_tests.cfg.sample @@ -117,7 +117,12 @@ variants: - stress_boot: install setup type = stress_boot max_vms = 5 -alive_test_cmd = ps aux +alive_test_cmd = uname -a +clone_address_index_base = 10 +kill_vm = yes +kill_vm_vm1 = no Actually, there are two methods to deal with started VMs via framework, one is as soon as the current test finished and the other is just before next test going to be started. In this case both methods equal somewhat between each other I think, and I had chosen the later one. But if you had done some testing and proved the previous one is better, I would agree. It's not that I tested and found the former to be better, it's just that if a user runs only stress_boot, it makes sense to clean up at the end of the test, not at the beginning of the next one (because there's no next one). Since you're adding VMs to the postprocessor's params (params['vms'] += + vm_name) I thought we might as well use that. (In order to clean up the VMs automatically when the next test starts, we don't need to add the VM to those params -- only to 'env'.) Hmm...yes, if users only want to run stress_boot, cleaning up should be implemented at the end of the test. +kill_vm_gracefully = no This has been specified within code during cloning. Right, but the postprocessor is supposed to ignore that, because it doesn't look at the params inside the VM -- it looks at test params that get to the postprocessor. +extra_params += -snapshot If you add this option '-snapshot' here, the first VM will be in snapshot mode as well which will affect next test. Which is good in my opinion, because I don't want the first VM writing to the same image that others are reading from. It sounds like it might Let me know what you think. My opinion is, since the scenario that the first VM using non-snapshot mode while the others do has not caused any problem, why not just keep the first VM in non-snapshot mode and let it to be used in next test which really save booting time? What do you think? Please let me know if there is a trap in such scenario. Thanks. :-) I'm not sure if it really will cause trouble, but it sounds like it might, since we're modifying an image that's being used by another VM, if I understand correctly. I don't think we actually have to see a test fail before we decide to avoid doing something -- it's enough just to know that something is bad practice. I'm not even sure this is bad practice, but I want to be on the safe side anyway. Can anyone shed some light on this? (Is it risky to start a VM without -snapshot, and in parallel start other VMs using the same image with -snapshot?) Thanks, Michael - shutdown: install setup type = shutdown diff --git
Re: recommended clock source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Dor Laor wrote: On 08/03/2009 04:52 AM, Kent Tong wrote: Hi, It seems to be an unsettled issue, but, would any kind soul suggest the current best practice for setting the clock in Ubuntu Linux and Windows guests? For Linux the best source clock is the kvm pv clock (exist from 2.6.27 and above). # qemu-system-x86_64 -clock ? Available alarm timers, in order of precedence: dynticks hpet rtc unix I see no pv clock... Which one should I use then? Did I miss a ./configure or .config option? Cheers Antoine For windows, standard acpi HAL uses the rtc clock by default. As long as you use the -rtc-td-hack it won't drift. When the tsc is not stable on the host or the host cpu might get into deep sleep state (c2), you better use another source clock in the guest - for windows it should be the pmtimer (using the boot.ini). Thanks! -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkp2m8AACgkQGK2zHPGK1rtQmACeM7UQJZS8TqVjqixZANKBm2gJ kzMAnAxNjQj73tgRyxhP99dpQ0CpWXLW =HWG8 -END PGP SIGNATURE- -- 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: recommended clock source
On 08/03/2009 11:11 AM, Antoine Martin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Dor Laor wrote: On 08/03/2009 04:52 AM, Kent Tong wrote: Hi, It seems to be an unsettled issue, but, would any kind soul suggest the current best practice for setting the clock in Ubuntu Linux and Windows guests? For Linux the best source clock is the kvm pv clock (exist from 2.6.27 and above). # qemu-system-x86_64 -clock ? Available alarm timers, in order of precedence: dynticks hpet rtc unix I see no pv clock... Which one should I use then? Did I miss a ./configure or .config option? No, we were talking about different clocks. I was explaining the guest source clock while you wanted some info for the host-qemu clock. You can use the default - dynticks. hpet and rtc might be good if you need a fine grain granularity on older 2.6.24 host kernels. Cheers Antoine For windows, standard acpi HAL uses the rtc clock by default. As long as you use the -rtc-td-hack it won't drift. When the tsc is not stable on the host or the host cpu might get into deep sleep state (c2), you better use another source clock in the guest - for windows it should be the pmtimer (using the boot.ini). Thanks! -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkp2m8AACgkQGK2zHPGK1rtQmACeM7UQJZS8TqVjqixZANKBm2gJ kzMAnAxNjQj73tgRyxhP99dpQ0CpWXLW =HWG8 -END PGP SIGNATURE- -- 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] qemu-kvm: Fix CONFIG_signalfd/eventfd generation
Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- configure |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configure b/configure index 2a6faa2..c743186 100755 --- a/configure +++ b/configure @@ -1818,10 +1818,10 @@ if test $fdt = yes ; then echo FDT_LIBS=$fdt_libs $config_host_mak fi if test $signalfd = yes ; then - echo #define CONFIG_signalfd 1 $config_host_h + echo CONFIG_signalfd=y $config_host_mak fi if test $eventfd = yes ; then - echo #define CONFIG_eventfd 1 $config_host_h + echo CONFIG_eventfd=y $config_host_mak fi # XXX: suppress that -- 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: recommended clock source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 It seems to be an unsettled issue, but, would any kind soul suggest the current best practice for setting the clock in Ubuntu Linux and Windows guests? For Linux the best source clock is the kvm pv clock (exist from 2.6.27 and above). # qemu-system-x86_64 -clock ? Available alarm timers, in order of precedence: dynticks hpet rtc unix I see no pv clock... Which one should I use then? Did I miss a ./configure or .config option? No, we were talking about different clocks. I was explaining the guest source clock while you wanted some info for the host-qemu clock. Hah, gotcha. You're talking about the guest kernel as in: clocksource=[hpet|pit|tsc|acpi_pm|cyclone|scx200_hrt|kvm-clock] # cat /sys/devices/system/clocksource/clocksource0/current_clocksource kvm-clock So all good, thanks. You can use the default - dynticks. hpet and rtc might be good if you need a fine grain granularity on older 2.6.24 host kernels. (I'm on dynticks) I guess dynticks reduces context switches on the host, but I still get hundreds per second on guests that are otherwise idle. How would I go about finding what makes them tick? Thanks Antoine Cheers Antoine For windows, standard acpi HAL uses the rtc clock by default. As long as you use the -rtc-td-hack it won't drift. When the tsc is not stable on the host or the host cpu might get into deep sleep state (c2), you better use another source clock in the guest - for windows it should be the pmtimer (using the boot.ini). Thanks! -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkp2qT0ACgkQGK2zHPGK1rsSRQCfdGzkV8Gu+pTkZcnpXivXKQlt IrsAmwZAbfLzdyiWckoi80iwqc/k+0uA =Qt5o -END PGP SIGNATURE- -- 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] kvm: fix kvm_init()
Remove debugfs file if kvm_arch_init() return error Signed-off-by: Xiao Guangrong xiaoguangr...@cn.fujitsu.com --- virt/kvm/kvm_main.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 2884baf..6299208 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -2679,8 +2679,8 @@ out_free_0: __free_page(bad_page); out: kvm_arch_exit(); - kvm_exit_debug(); out_fail: + kvm_exit_debug(); return r; } EXPORT_SYMBOL_GPL(kvm_init); -- 1.6.1.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: [PATCH] Add a subtest pci_hotplug in kvm test
On 06/30/2009 09:58 PM, Dor Laor wrote: On 06/30/2009 02:11 PM, Yolkfull Chow wrote: Signed-off-by: Yolkfull Chowyz...@redhat.com --- client/tests/kvm/kvm.py |1 + client/tests/kvm/kvm_tests.cfg.sample | 56 client/tests/kvm/kvm_tests.py | 93 + client/tests/kvm/kvm_vm.py|2 + 4 files changed, 152 insertions(+), 0 deletions(-) diff --git a/client/tests/kvm/kvm.py b/client/tests/kvm/kvm.py index 4c7bae4..4fbce5b 100644 --- a/client/tests/kvm/kvm.py +++ b/client/tests/kvm/kvm.py @@ -55,6 +55,7 @@ class kvm(test.test): kvm_install: test_routine(kvm_install, run_kvm_install), linux_s3: test_routine(kvm_tests, run_linux_s3), stress_boot: test_routine(kvm_tests, run_stress_boot), +pci_hotplug: test_routine(kvm_tests, run_pci_hotplug), Cool! It's very good since it tends to break. } # Make it possible to import modules from the test's bindir diff --git a/client/tests/kvm/kvm_tests.cfg.sample b/client/tests/kvm/kvm_tests.cfg.sample index 2f864de..50b5765 100644 --- a/client/tests/kvm/kvm_tests.cfg.sample +++ b/client/tests/kvm/kvm_tests.cfg.sample @@ -94,6 +94,52 @@ variants: max_vms = 5 alive_test_cmd = ps aux + +- nic_hotplug: +type = pci_hotplug +pci_type = nic +modprobe_acpiphp = yes +reference_cmd = lspci +find_pci_cmd = 'lspci | tail -n1' +pci_test_cmd = 'nslookup www.redhat.com' +variants: +- @nic_8139: +pci_model = rtl8139 +match_string = 8139 +- nic_virtio: +pci_model = virtio +match_string = Virtio network device +- nic_e1000: +pci_model = e1000 +match_string = Gigabit Ethernet Controller + +- block_hotplug: +type = pci_hotplug +pci_type = block +modprobe_acpiphp = yes +reference_cmd = lspci +find_pci_cmd = 'lspci | tail -n1' +images += stg +boot_drive_stg = no +image_name_stg = storage +image_size = 1G +force_create_image_stg = yes +pci_test_cmd = 'dir' +no Windows +variants: +- block_virtio: +pci_model = virtio +match_string = Virtio block device +- block_scsi: +pci_model = scsi +match_string = SCSI storage controller +variants: There is no need to test qcow2/raw here since it shouldn't matter. You can test qcow2 only, it is enough. Hi Glauber, according to Dor's comments on this, I did some testing and got an interesting result for block_hotplug: 1) hotplug storage of raw + SCSI will always fail on Windows 2) hotplug storage of Raw + Virtio will always fail on Fedora 3) hotplug storage with image format Raw will also fail often on RHEL Does block_hotplug relate to image format? Would you give me any clue on this? Thanks in advance. +- fmt_qcow2: +image_format_stg = qcow2 +- fmt_raw: +image_format_stg = raw + + # NICs variants: - @rtl8139: @@ -306,6 +352,12 @@ variants: migration_test_command = ver vol stress_boot: alive_test_cmd = systeminfo +nic_hotplug: +modprobe_acpiphp = no +reference_cmd = systeminfo +find_pci_cmd = ipconfig /all | find Description +nic_e1000: +match_string = Intel(R) PRO/1000 MT Network Connection variants: - Win2000: @@ -530,6 +582,10 @@ virtio|virtio_blk|e1000: only Fedora.9 openSUSE-11 Ubuntu-8.10-server +nic_hotplug.nic_virtio|block_hotplug: +no Windows + + variants: - @qcow2: image_format = qcow2 diff --git a/client/tests/kvm/kvm_tests.py b/client/tests/kvm/kvm_tests.py index 2d11fed..21280b9 100644 --- a/client/tests/kvm/kvm_tests.py +++ b/client/tests/kvm/kvm_tests.py @@ -585,3 +585,96 @@ def run_stress_boot(tests, params, env): for se in sessions: se.close() logging.info(Total number booted: %d % (num -1)) + + +def run_pci_hotplug(test, params, env): + +Test pci devices' hotplug +1) pci_add a deivce (nic or storage) +2) Compare 'info pci' output +3) Compare $reference_cmd output +4) Verify whether pci_model is shown in $pci_find_cmd +5) pci_del the device, verify whether could remove the pci device + +@param test: kvm test object +@param params: Dictionary with the test parameters +@param env:Dictionary with test environment. + +vm = kvm_utils.env_get_vm(env, params.get(main_vm)) +if not vm: +raise error.TestError(VM object not found in environment) +if not vm.is_alive(): +raise
Re: [KVM-AUTOTEST PATCH 0/12] TAP support (and a few other small things)
tcpOn 08/03/2009 02:58 AM, Michael Goldish wrote: Here's my proposed TAP solution: - The user specifies MAC ranges and may or may not specify corresponding IP ranges. - VMs are always given MAC addresses from the user specified MAC ranges. - MAC address ranges must be unique to each host running KVM tests -- there must be no overlap between them. - If corresponding IP ranges are specified as well, the system will use them when trying to communicate with guests. - If corresponding IP ranges are not specified, tcpdump will be used to listen to DHCP traffic and dynamically detect the right IP addresses. There's also a flag that can force this behavior. This is pretty nice patch set and it's nice and friendly to hook the assigned ip address. Maybe instead of using tcpdump you can add a specific ip tables rule to trap dhcp replies and log them? - tcpdump will run in the background at all times, and collect MAC-IP pairs as soon as they are assigned by the DHCP server. This is useful for NIC hotplugging (where IP addresses are assigned during the test itself) and generally for misbehaving guests or DHCP servers (restarting network services during the test, using very short lease times). - It is up to the user to create the actual bridge for TAP devices; the qemu-ifup script included in one of the patches only adds the TAP interface to an existing bridge. The user should modify this script or create a bridge some other way. This works very well on two hosts I tried, but I'm not entirely sure it will work in all cases -- please let me know what you think. (I remember Jason Wang mentioned that tcpdump doesn't always catch all the required traffic, or that it might somehow depend on the DHCP server -- anyone willing to comment on that?) The following patches have been tested with a few KVM tests (boot, reboot, stress_boot, migration) with both TAP and user mode, but they could probably use more testing (maybe with Python 2.6?), so if anyone is willing to help with that I'd appreciate it very much. -- 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 -- 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: recommended clock source
On 08/03/2009 12:09 PM, Antoine Martin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 It seems to be an unsettled issue, but, would any kind soul suggest the current best practice for setting the clock in Ubuntu Linux and Windows guests? For Linux the best source clock is the kvm pv clock (exist from 2.6.27 and above). # qemu-system-x86_64 -clock ? Available alarm timers, in order of precedence: dynticks hpet rtc unix I see no pv clock... Which one should I use then? Did I miss a ./configure or .config option? No, we were talking about different clocks. I was explaining the guest source clock while you wanted some info for the host-qemu clock. Hah, gotcha. You're talking about the guest kernel as in: clocksource=[hpet|pit|tsc|acpi_pm|cyclone|scx200_hrt|kvm-clock] # cat /sys/devices/system/clocksource/clocksource0/current_clocksource kvm-clock So all good, thanks. You can use the default - dynticks. hpet and rtc might be good if you need a fine grain granularity on older 2.6.24 host kernels. (I'm on dynticks) I guess dynticks reduces context switches on the host, but I still get hundreds per second on guests that are otherwise idle. How would I go about finding what makes them tick? You can use the kvm_stat script to check the guest activity. As for host timers, you can use sudo strace -e trace=signal -c -p `pgrep qemu` to get the number of SIGALRM calls. You can reduce this number since there is a threshold in qemu for the dyntick. My winXp guest does the following: sudo strace -c -p `pgrep qemu` Process 14241 attached - interrupt to quit ^CProcess 14241 detached % time seconds usecs/call callserrors syscall -- --- --- - - 82.460.089660 19 4801 select 14.510.015775 33 480 futex 1.700.001847 0 9511 4804 read 0.720.000787 1 824 ioctl 0.230.000246 0 2361 write 0.190.000211 0 2463 timer_gettime 0.130.000144 0 2361 rt_sigaction 0.060.66 0 2377 timer_settime 0.000.00 0 3 poll 0.000.00 0 3 writev -- --- --- - - 100.000.108736 25184 4804 total Thanks Antoine Cheers Antoine For windows, standard acpi HAL uses the rtc clock by default. As long as you use the -rtc-td-hack it won't drift. When the tsc is not stable on the host or the host cpu might get into deep sleep state (c2), you better use another source clock in the guest - for windows it should be the pmtimer (using the boot.ini). Thanks! -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkp2qT0ACgkQGK2zHPGK1rsSRQCfdGzkV8Gu+pTkZcnpXivXKQlt IrsAmwZAbfLzdyiWckoi80iwqc/k+0uA =Qt5o -END PGP SIGNATURE- -- 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 -- 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-AUTOTEST PATCH 0/12] TAP support (and a few other small things)
- Dor Laor dl...@redhat.com wrote: tcpOn 08/03/2009 02:58 AM, Michael Goldish wrote: Here's my proposed TAP solution: - The user specifies MAC ranges and may or may not specify corresponding IP ranges. - VMs are always given MAC addresses from the user specified MAC ranges. - MAC address ranges must be unique to each host running KVM tests -- there must be no overlap between them. - If corresponding IP ranges are specified as well, the system will use them when trying to communicate with guests. - If corresponding IP ranges are not specified, tcpdump will be used to listen to DHCP traffic and dynamically detect the right IP addresses. There's also a flag that can force this behavior. This is pretty nice patch set and it's nice and friendly to hook the assigned ip address. Maybe instead of using tcpdump you can add a specific ip tables rule to trap dhcp replies and log them? What are the advantages compared to tcpdump? Is it easier? If you look at the tcpdump patch you'll see it's quite short. Most of the code in this set is not related to tcpdump but rather to host specific static MAC-IP mapping and other related things. To me the iptables idea sounds a little more complex especially since we'll have to deal with host specific configuration -- I'm not even sure all hosts run a firewall. What do you think? - tcpdump will run in the background at all times, and collect MAC-IP pairs as soon as they are assigned by the DHCP server. This is useful for NIC hotplugging (where IP addresses are assigned during the test itself) and generally for misbehaving guests or DHCP servers (restarting network services during the test, using very short lease times). - It is up to the user to create the actual bridge for TAP devices; the qemu-ifup script included in one of the patches only adds the TAP interface to an existing bridge. The user should modify this script or create a bridge some other way. This works very well on two hosts I tried, but I'm not entirely sure it will work in all cases -- please let me know what you think. (I remember Jason Wang mentioned that tcpdump doesn't always catch all the required traffic, or that it might somehow depend on the DHCP server -- anyone willing to comment on that?) The following patches have been tested with a few KVM tests (boot, reboot, stress_boot, migration) with both TAP and user mode, but they could probably use more testing (maybe with Python 2.6?), so if anyone is willing to help with that I'd appreciate it very much. -- 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 -- 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] Add a subtest pci_hotplug in kvm test
On 08/03/2009 12:19 PM, Yolkfull Chow wrote: On 06/30/2009 09:58 PM, Dor Laor wrote: On 06/30/2009 02:11 PM, Yolkfull Chow wrote: Signed-off-by: Yolkfull Chowyz...@redhat.com --- client/tests/kvm/kvm.py | 1 + client/tests/kvm/kvm_tests.cfg.sample | 56 client/tests/kvm/kvm_tests.py | 93 + client/tests/kvm/kvm_vm.py | 2 + 4 files changed, 152 insertions(+), 0 deletions(-) diff --git a/client/tests/kvm/kvm.py b/client/tests/kvm/kvm.py index 4c7bae4..4fbce5b 100644 --- a/client/tests/kvm/kvm.py +++ b/client/tests/kvm/kvm.py @@ -55,6 +55,7 @@ class kvm(test.test): kvm_install: test_routine(kvm_install, run_kvm_install), linux_s3: test_routine(kvm_tests, run_linux_s3), stress_boot: test_routine(kvm_tests, run_stress_boot), + pci_hotplug: test_routine(kvm_tests, run_pci_hotplug), Cool! It's very good since it tends to break. } # Make it possible to import modules from the test's bindir diff --git a/client/tests/kvm/kvm_tests.cfg.sample b/client/tests/kvm/kvm_tests.cfg.sample index 2f864de..50b5765 100644 --- a/client/tests/kvm/kvm_tests.cfg.sample +++ b/client/tests/kvm/kvm_tests.cfg.sample @@ -94,6 +94,52 @@ variants: max_vms = 5 alive_test_cmd = ps aux + + - nic_hotplug: + type = pci_hotplug + pci_type = nic + modprobe_acpiphp = yes + reference_cmd = lspci + find_pci_cmd = 'lspci | tail -n1' + pci_test_cmd = 'nslookup www.redhat.com' + variants: + - @nic_8139: + pci_model = rtl8139 + match_string = 8139 + - nic_virtio: + pci_model = virtio + match_string = Virtio network device + - nic_e1000: + pci_model = e1000 + match_string = Gigabit Ethernet Controller + + - block_hotplug: + type = pci_hotplug + pci_type = block + modprobe_acpiphp = yes + reference_cmd = lspci + find_pci_cmd = 'lspci | tail -n1' + images += stg + boot_drive_stg = no + image_name_stg = storage + image_size = 1G + force_create_image_stg = yes + pci_test_cmd = 'dir' + no Windows + variants: + - block_virtio: + pci_model = virtio + match_string = Virtio block device + - block_scsi: + pci_model = scsi + match_string = SCSI storage controller + variants: There is no need to test qcow2/raw here since it shouldn't matter. You can test qcow2 only, it is enough. Hi Glauber, according to Dor's comments on this, I did some testing and got an interesting result for block_hotplug: 1) hotplug storage of raw + SCSI will always fail on Windows 2) hotplug storage of Raw + Virtio will always fail on Fedora 3) hotplug storage with image format Raw will also fail often on RHEL Does block_hotplug relate to image format? Would you give me any clue on this? It shouldn't matter. In case the test is sensitive for timeout, it might. Can you describe what's working and what's not on each combination? As for scsi, it is not reliable so it might be scsi's fault. Can you provide the fdisk -l ouput on Fedora when it is not working? From the test below, there is not time/event for letting the guest hook up the new block device. Maybe you need to do several retries in a loop or check a real event in the guest (better one) Thanks in advance. + - fmt_qcow2: + image_format_stg = qcow2 + - fmt_raw: + image_format_stg = raw + + # NICs variants: - @rtl8139: @@ -306,6 +352,12 @@ variants: migration_test_command = ver vol stress_boot: alive_test_cmd = systeminfo + nic_hotplug: + modprobe_acpiphp = no + reference_cmd = systeminfo + find_pci_cmd = ipconfig /all | find Description + nic_e1000: + match_string = Intel(R) PRO/1000 MT Network Connection variants: - Win2000: @@ -530,6 +582,10 @@ virtio|virtio_blk|e1000: only Fedora.9 openSUSE-11 Ubuntu-8.10-server +nic_hotplug.nic_virtio|block_hotplug: + no Windows + + variants: - @qcow2: image_format = qcow2 diff --git a/client/tests/kvm/kvm_tests.py b/client/tests/kvm/kvm_tests.py index 2d11fed..21280b9 100644 --- a/client/tests/kvm/kvm_tests.py +++ b/client/tests/kvm/kvm_tests.py @@ -585,3 +585,96 @@ def run_stress_boot(tests, params, env): for se in sessions: se.close() logging.info(Total number booted: %d % (num -1)) + + +def run_pci_hotplug(test, params, env): + + Test pci devices' hotplug + 1) pci_add a deivce (nic or storage) + 2) Compare 'info pci' output + 3) Compare $reference_cmd output + 4) Verify whether pci_model is shown in $pci_find_cmd + 5) pci_del the device, verify whether could remove the pci device + + @param test: kvm test object + @param params: Dictionary with the test parameters + @param env: Dictionary with test environment. + + vm = kvm_utils.env_get_vm(env, params.get(main_vm)) + if not vm: + raise error.TestError(VM object not found in environment) + if not vm.is_alive(): + raise error.TestError(VM seems to be dead; Test requires a living VM) + + logging.info(Waiting for guest to be up...) + + session = kvm_utils.wait_for(vm.ssh_login, 240, 0, 2) + if not session: + raise error.TestFail(Could not log into guest) + + logging.info(Logged in) + + # modprobe the module that enable hotplug + if params.get(modprobe_acpiphp) ==
Re: [PATCH] KVM: Fix EPT identity IOCTL on 32pae
Sheng Yang wrote:
Copy u64 from guest result in chaos.
Not doing so, while the ABI as been defined as u64, will surely result
in chaos as well - just different one. I'm recalling the problems Alex
recently ran into on big-endian PowerPC and sizeof(userland_long) !=
sizeof(kernel_long).
Also fix a mistake of still using old macro rather than new variable().
Two patches then?
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
arch/x86/kvm/vmx.c |2 +-
arch/x86/kvm/x86.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 7931c72..c5aaa1b 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2199,7 +2199,7 @@ static int alloc_identity_pagetable(struct kvm *kvm)
goto out;
kvm-arch.ept_identity_pagetable = gfn_to_page(kvm,
- VMX_EPT_IDENTITY_PAGETABLE_ADDR PAGE_SHIFT);
+ kvm-arch.ept_identity_map_addr PAGE_SHIFT);
out:
up_write(kvm-slots_lock);
return r;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 2539e9a..977b705 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2178,7 +2178,7 @@ long kvm_arch_vm_ioctl(struct file *filp,
goto out;
break;
case KVM_SET_IDENTITY_MAP_ADDR: {
- u64 ident_addr;
+ unsigned long ident_addr;
r = -EFAULT;
if (copy_from_user(ident_addr, argp, sizeof ident_addr))
I don't know what as to be fixed here, but you must stick to the ABI.
Maybe you just want to convert u64 - ulong afterwards?
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
--
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] use upstream cpuid code
On 07/28/2009 11:05 PM, Glauber Costa wrote: use cpuid code from upstream. By doing that, we lose the following snippet in kvm_get_supported_cpuid(): ret |= 1 12; /* MTRR */ ret |= 1 16; /* PAT */ ret |= 1 7; /* MCE */ ret |= 1 14; /* MCA */ A quick search in mailing lists says this code is not really necessary, and we're keeping it just for backwards compatibility. This is not that important, because we'd lose it anyway in the golden day in which we totally merge with qemu. Anyway, if it do _is_ important, we can send a patch to qemu with it. It is important. Please don't introduce regressions (if you do, introduce them in separate patches). The procedure to drop such workarounds for kernel bugs is to verify that major distros have the kernel fixes in their supported kernels. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Autotest] autotest exception in windows 2003 guest (ValueError: invalid literal for int() with base 10: '%errorlevel%)
On 7/27/09, Michael Goldish mgold...@redhat.com wrote: It looks like you're using opensshd with cygwin -- not the one we normally install on guests, but rather one that outputs colorful text. Is that right? Which server are you using exactly? There's not much I can do against colorful text, because it's difficult to automatically strip the weird formatting characters from the output. I suggest that you: - Use another server, like the cygwin+opensshd we normally use for Windows guests (http://sshwindows.webheat.co.uk/), or if you're not using SCP with This does not install the server on my win2k8 Datacentre 64. Though client works fine. Windows, you can use rss.exe which I posted recently -- it's the easiest to install and works with all Windows versions (ssh doesn't always work). If Can you please share the binary? I wana give it a try. you use rss.exe make sure you use telnet as a client (not ssh) by setting use_telnet = yes for the relevant guest in kvm_tests.cfg. The best client is actually raw nc, which I'll post patches to support soon, but telnet should work too (though it will produce a double echo for each command). - Use a more recent version of KVM-Autotest. kvm_subprocess recently got into the tree, and it handles weird responses to echo %errorlevel% better (especially double echo), but as long as the output is colored, it still won't work. If you upgrade, make sure you also apply the patch that fixes kvm_subprocess on Python 2.6 (if you use 2.6), or just wait until Lucas applies the patch to the tree. I know this seems a little messy, but if you wait a little while everything will sort itself out -- if I understand correctly, we are moving towards using rss.exe on all Windows guests, with nc as a client, and with kvm_subprocess controlling the client, and then most of the problems should go away (hopefully). I will be so happy. At present autotes is almost of no use for windows with copssh and openssh. boot reboot code works fine but migrate code cause problem due to the colorful text of the prompt. I wana get out of this issue as soon as possible. please share the binaries with me so that we can come to know of issues if any and make this ssh server more robust. thanks in advance. Thanks, Michael - Original Message - From: sudhir kumar smalik...@gmail.com To: Autotest mailing list autot...@test.kernel.org Cc: Lucas Meneghel Rodrigues mrodr...@redhat.com, kvm-devel kvm@vger.kernel.org Sent: Monday, July 27, 2009 2:16:06 PM (GMT+0200) Auto-Detected Subject: [Autotest] autotest exception in windows 2003 guest (ValueError: invalid literal for int() with base 10: '%errorlevel%) Hi I have been getting the following exception in autotest for windows 2003 datacenter. status = int(\n.join(status.splitlines()[1:-1]).strip()) ValueError: invalid literal for int() with base 10: '%errorlevel%\n\x1b]0;~\x07\n\x1b[32madministra...@ibm-n81hj962hdx \x1b[33m~\x1b[0m' Is there any other command with which we can replace ssh_status_test_command = echo %errorlevel% echo $? also does not work in windows. -- Sudhir Kumar ___ Autotest mailing list autot...@test.kernel.org http://test.kernel.org/cgi-bin/mailman/listinfo/autotest -- Sudhir Kumar -- 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: Drop polling property from qemu_cond_wait
On 07/28/2009 12:32 PM, Jan Kiszka wrote: No caller of qemu_cond_wait makes use of this polling anymore. Remove it. Applied, thanks. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [KVM-AUTOTEST PATCH 0/12] TAP support (and a few other small things)
On 08/03/2009 12:39 PM, Michael Goldish wrote: - Dor Laordl...@redhat.com wrote: tcpOn 08/03/2009 02:58 AM, Michael Goldish wrote: Here's my proposed TAP solution: - The user specifies MAC ranges and may or may not specify corresponding IP ranges. - VMs are always given MAC addresses from the user specified MAC ranges. - MAC address ranges must be unique to each host running KVM tests -- there must be no overlap between them. - If corresponding IP ranges are specified as well, the system will use them when trying to communicate with guests. - If corresponding IP ranges are not specified, tcpdump will be used to listen to DHCP traffic and dynamically detect the right IP addresses. There's also a flag that can force this behavior. This is pretty nice patch set and it's nice and friendly to hook the assigned ip address. Maybe instead of using tcpdump you can add a specific ip tables rule to trap dhcp replies and log them? What are the advantages compared to tcpdump? Is it easier? If you look at the tcpdump patch you'll see it's quite short. Most of the code in this set is not related to tcpdump but rather to host specific static MAC-IP mapping and other related things. To me the iptables idea sounds a little more complex especially since we'll have to deal with host specific configuration -- I'm not even sure all hosts run a firewall. What do you think? iptables config might be a bit harder but on the same scale.. If you plan to constantly run tcpdump in the background iptables hook will be much cheaper. - tcpdump will run in the background at all times, and collect MAC-IP pairs as soon as they are assigned by the DHCP server. This is useful for NIC hotplugging (where IP addresses are assigned during the test itself) and generally for misbehaving guests or DHCP servers (restarting network services during the test, using very short lease times). - It is up to the user to create the actual bridge for TAP devices; the qemu-ifup script included in one of the patches only adds the TAP interface to an existing bridge. The user should modify this script or create a bridge some other way. This works very well on two hosts I tried, but I'm not entirely sure it will work in all cases -- please let me know what you think. (I remember Jason Wang mentioned that tcpdump doesn't always catch all the required traffic, or that it might somehow depend on the DHCP server -- anyone willing to comment on that?) The following patches have been tested with a few KVM tests (boot, reboot, stress_boot, migration) with both TAP and user mode, but they could probably use more testing (maybe with Python 2.6?), so if anyone is willing to help with that I'd appreciate it very much. -- 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 -- 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 -- 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: MMU: limit rmap chain length
On 07/28/2009 05:40 AM, Marcelo Tosatti wrote: Otherwise the host can spend too long traversing an rmap chain, which happens under a spinlock. Applied, thanks. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM: limit lapic periodic timer frequency
On 07/28/2009 05:41 AM, Marcelo Tosatti wrote: Otherwise its possible to starve the host by programming lapic timer with a very high frequency. Applied, thanks. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm: Drop obsolete cpu_get/put in make_all_cpus_request
On 07/21/2009 03:00 AM, Marcelo Tosatti wrote: Jan, This was suggested but we thought it might be safer to keep the get_cpu/put_cpu pair in case -rt kernels require it (which might be bullshit, but nobody verified). Thinking about it, it is bullshit: - me = get_cpu(); spin_lock(kvm-requests_lock); + me = smp_processor_id(); The -rt kernel cannot substitute a mutex for the spinlock here, since we are pinned to a single cpu. It will have to use a raw spinlock here. However, the 'me' variable is completely spurious. It only affects the statistics gathering, I think we can safely drop it. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: Fix EPT identity IOCTL on 32pae
On 08/03/2009 09:17 AM, Sheng Yang wrote:
Copy u64 from guest result in chaos.
Also fix a mistake of still using old macro rather than new variable().
Signed-off-by: Sheng Yangsh...@linux.intel.com
---
arch/x86/kvm/vmx.c |2 +-
arch/x86/kvm/x86.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 7931c72..c5aaa1b 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2199,7 +2199,7 @@ static int alloc_identity_pagetable(struct kvm *kvm)
goto out;
kvm-arch.ept_identity_pagetable = gfn_to_page(kvm,
- VMX_EPT_IDENTITY_PAGETABLE_ADDR PAGE_SHIFT);
+ kvm-arch.ept_identity_map_addr PAGE_SHIFT);
This is a fix, but as Jan says, separate patch.
out:
up_write(kvm-slots_lock);
return r;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 2539e9a..977b705 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2178,7 +2178,7 @@ long kvm_arch_vm_ioctl(struct file *filp,
goto out;
break;
case KVM_SET_IDENTITY_MAP_ADDR: {
- u64 ident_addr;
+ unsigned long ident_addr;
r = -EFAULT;
if (copy_from_user(ident_addr, argp, sizeof ident_addr))
This doesn't look right. Consider 32-bit userspace running on a 32-bit
kernel and the same userspace running on a 64-bit kernel. We need to
copy the same size in both cases.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm: fix kvm_init()
On 08/03/2009 12:10 PM, Xiao Guangrong wrote: Remove debugfs file if kvm_arch_init() return error Applied, thanks. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] unbreak booting with virtio
On 07/31/2009 09:19 PM, Glauber Costa wrote: Since commit 89e671e3, extboot is broken due to wrong checksum The problem is that printf \\$sum syntax will require an octal representation, so the fix I'm proposing is to convert it first. Whichever way this gets resolved, please send it upstream since the bug exists there. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: slow responsiveness of kvm guests
On 07/31/2009 05:15 PM, Kai Zimmer wrote:
qemu-kvm -hda xyz.qcow2 -daemonize -net nic,model=virtio -net tap -k de -m 3584
-smp 2 -mem-path /hugepages -vnc :2
Any ideas what goes wrong here?
All three guests have the same MAC address, so when one talks, you can't
hear the others.
Use -net nic,model=virtio,macaddr=00:11:22:33:44:0{1,2,3} (different
addresses for different guests).
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qemu-kvm: Fix CONFIG_signalfd/eventfd generation
On 08/03/2009 11:39 AM, Jan Kiszka wrote: Signed-off-by: Jan Kiszkajan.kis...@siemens.com Applied, thanks. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remove unused function.
On 07/28/2009 04:49 AM, Glauber Costa wrote: not a single in-tree user. Applied, thanks. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add a subtest pci_hotplug in kvm test
On Mon, Aug 03, 2009 at 05:19:17PM +0800, Yolkfull Chow wrote: On 06/30/2009 09:58 PM, Dor Laor wrote: On 06/30/2009 02:11 PM, Yolkfull Chow wrote: Signed-off-by: Yolkfull Chowyz...@redhat.com --- client/tests/kvm/kvm.py |1 + client/tests/kvm/kvm_tests.cfg.sample | 56 client/tests/kvm/kvm_tests.py | 93 + client/tests/kvm/kvm_vm.py|2 + 4 files changed, 152 insertions(+), 0 deletions(-) diff --git a/client/tests/kvm/kvm.py b/client/tests/kvm/kvm.py index 4c7bae4..4fbce5b 100644 --- a/client/tests/kvm/kvm.py +++ b/client/tests/kvm/kvm.py @@ -55,6 +55,7 @@ class kvm(test.test): kvm_install: test_routine(kvm_install, run_kvm_install), linux_s3: test_routine(kvm_tests, run_linux_s3), stress_boot: test_routine(kvm_tests, run_stress_boot), +pci_hotplug: test_routine(kvm_tests, run_pci_hotplug), Cool! It's very good since it tends to break. } # Make it possible to import modules from the test's bindir diff --git a/client/tests/kvm/kvm_tests.cfg.sample b/client/tests/kvm/kvm_tests.cfg.sample index 2f864de..50b5765 100644 --- a/client/tests/kvm/kvm_tests.cfg.sample +++ b/client/tests/kvm/kvm_tests.cfg.sample @@ -94,6 +94,52 @@ variants: max_vms = 5 alive_test_cmd = ps aux + +- nic_hotplug: +type = pci_hotplug +pci_type = nic +modprobe_acpiphp = yes +reference_cmd = lspci +find_pci_cmd = 'lspci | tail -n1' +pci_test_cmd = 'nslookup www.redhat.com' +variants: +- @nic_8139: +pci_model = rtl8139 +match_string = 8139 +- nic_virtio: +pci_model = virtio +match_string = Virtio network device +- nic_e1000: +pci_model = e1000 +match_string = Gigabit Ethernet Controller + +- block_hotplug: +type = pci_hotplug +pci_type = block +modprobe_acpiphp = yes +reference_cmd = lspci +find_pci_cmd = 'lspci | tail -n1' +images += stg +boot_drive_stg = no +image_name_stg = storage +image_size = 1G +force_create_image_stg = yes +pci_test_cmd = 'dir' +no Windows +variants: +- block_virtio: +pci_model = virtio +match_string = Virtio block device +- block_scsi: +pci_model = scsi +match_string = SCSI storage controller +variants: There is no need to test qcow2/raw here since it shouldn't matter. You can test qcow2 only, it is enough. Hi Glauber, according to Dor's comments on this, I did some testing and got an interesting result for block_hotplug: 1) hotplug storage of raw + SCSI will always fail on Windows 2) hotplug storage of Raw + Virtio will always fail on Fedora 3) hotplug storage with image format Raw will also fail often on RHEL Does block_hotplug relate to image format? Would you give me any clue on this? Hi, hotplugging a pci device should have nothing to do with the underlying format. However, if we are using a format that is more racy and subject to breaks, the hotplug window may make easy for race conditions to happen. For example, qcow2 with writeback caching. As for the failures you describe, I'd like to see details. They surely sound like a bug. -- 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] use upstream cpuid code
On Mon, Aug 03, 2009 at 02:57:47PM +0300, Avi Kivity wrote: On 07/28/2009 11:05 PM, Glauber Costa wrote: use cpuid code from upstream. By doing that, we lose the following snippet in kvm_get_supported_cpuid(): ret |= 1 12; /* MTRR */ ret |= 1 16; /* PAT */ ret |= 1 7; /* MCE */ ret |= 1 14; /* MCA */ A quick search in mailing lists says this code is not really necessary, and we're keeping it just for backwards compatibility. This is not that important, because we'd lose it anyway in the golden day in which we totally merge with qemu. Anyway, if it do _is_ important, we can send a patch to qemu with it. It is important. Please don't introduce regressions (if you do, introduce them in separate patches). The procedure to drop such workarounds for kernel bugs is to verify that major distros have the kernel fixes in their supported kernels. Since this was introduced to fix a bug that did not even existed in Windows, I can't see what you mean by distro kernels 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
Re: [PATCH] KVM: Fix EPT identity IOCTL on 32pae
On Monday 03 August 2009 20:25:43 Avi Kivity wrote:
On 08/03/2009 09:17 AM, Sheng Yang wrote:
Copy u64 from guest result in chaos.
Also fix a mistake of still using old macro rather than new variable().
Signed-off-by: Sheng Yangsh...@linux.intel.com
---
arch/x86/kvm/vmx.c |2 +-
arch/x86/kvm/x86.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 7931c72..c5aaa1b 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2199,7 +2199,7 @@ static int alloc_identity_pagetable(struct kvm
*kvm) goto out;
kvm-arch.ept_identity_pagetable = gfn_to_page(kvm,
- VMX_EPT_IDENTITY_PAGETABLE_ADDR PAGE_SHIFT);
+ kvm-arch.ept_identity_map_addr PAGE_SHIFT);
This is a fix, but as Jan says, separate patch.
Sure. (and thanks Jan's comment :) )
out:
up_write(kvm-slots_lock);
return r;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 2539e9a..977b705 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2178,7 +2178,7 @@ long kvm_arch_vm_ioctl(struct file *filp,
goto out;
break;
case KVM_SET_IDENTITY_MAP_ADDR: {
- u64 ident_addr;
+ unsigned long ident_addr;
r = -EFAULT;
if (copy_from_user(ident_addr, argp, sizeof ident_addr))
This doesn't look right. Consider 32-bit userspace running on a 32-bit
kernel and the same userspace running on a 64-bit kernel. We need to
copy the same size in both cases.
Yeah... Then I think I should fix the userspace. Would update the patch.
--
regards
Yang, Sheng
--
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] KVM: x86: Disallow hypercalls for guest callers in rings 0
So far unprivileged guest callers running in ring 3 can issue, e.g., MMU
hypercalls. Normally, such callers cannot provide any hand-crafted MMU
command structure as it has to be passed by its physical address, but
they can still crash the guest kernel by passing random addresses.
To close the hole, this patch considers hypercalls valid only if issued
from guest ring 0. This may still be relaxed on a per-hypercall base in
the future once required.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
arch/x86/kvm/x86.c |8
include/linux/kvm_para.h |1 +
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 2539e9a..966d309 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3190,6 +3190,7 @@ static inline gpa_t hc_gpa(struct kvm_vcpu *vcpu,
unsigned long a0,
int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
{
unsigned long nr, a0, a1, a2, a3, ret;
+ struct kvm_segment cs;
int r = 1;
nr = kvm_register_read(vcpu, VCPU_REGS_RAX);
@@ -3208,6 +3209,12 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
a3 = 0x;
}
+ kvm_get_segment(vcpu, cs, VCPU_SREG_CS);
+ if (cs.dpl != 0) {
+ ret = -KVM_EPERM;
+ goto out;
+ }
+
switch (nr) {
case KVM_HC_VAPIC_POLL_IRQ:
ret = 0;
@@ -3219,6 +3226,7 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
ret = -KVM_ENOSYS;
break;
}
+out:
kvm_register_write(vcpu, VCPU_REGS_RAX, ret);
++vcpu-stat.hypercalls;
return r;
diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h
index 3ddce03..d731092 100644
--- a/include/linux/kvm_para.h
+++ b/include/linux/kvm_para.h
@@ -13,6 +13,7 @@
#define KVM_ENOSYS 1000
#define KVM_EFAULT EFAULT
#define KVM_E2BIG E2BIG
+#define KVM_EPERM EPERM
#define KVM_HC_VAPIC_POLL_IRQ 1
#define KVM_HC_MMU_OP 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: [KVM-AUTOTEST PATCH 0/12] TAP support (and a few other small things)
- Dor Laor dl...@redhat.com wrote:
On 08/03/2009 12:39 PM, Michael Goldish wrote:
- Dor Laordl...@redhat.com wrote:
tcpOn 08/03/2009 02:58 AM, Michael Goldish wrote:
Here's my proposed TAP solution:
- The user specifies MAC ranges and may or may not specify
corresponding IP
ranges.
- VMs are always given MAC addresses from the user specified MAC
ranges.
- MAC address ranges must be unique to each host running KVM
tests
-- there
must be no overlap between them.
- If corresponding IP ranges are specified as well, the system
will
use them
when trying to communicate with guests.
- If corresponding IP ranges are not specified, tcpdump will be
used
to listen
to DHCP traffic and dynamically detect the right IP addresses.
There's also a
flag that can force this behavior.
This is pretty nice patch set and it's nice and friendly to hook
the
assigned ip address.
Maybe instead of using tcpdump you can add a specific ip tables
rule
to
trap dhcp replies and log them?
What are the advantages compared to tcpdump? Is it easier?
If you look at the tcpdump patch you'll see it's quite short.
Most of the code in this set is not related to tcpdump but rather
to
host specific static MAC-IP mapping and other related things.
To me the iptables idea sounds a little more complex especially
since
we'll have to deal with host specific configuration -- I'm not even
sure
all hosts run a firewall. What do you think?
iptables config might be a bit harder but on the same scale..
If you plan to constantly run tcpdump in the background iptables hook
will be much cheaper.
I run tcpdump with a filter ('dst port 68') that makes it output packets
only very rarely (only when some NIC is assigned an IP address).
To make sure tcpdump doesn't significantly impact performance I ran a
few benchmarks (the host is a core 2 duo machine):
- Local iperf: 8.5 Gbits/sec
- Local iperf with tcpdump running (filtered): 8.5 Gbits/sec
- Local iperf with tcpdump running (unfiltered): 6 Gbits/sec
- Local iperf with 4 instances of tcpdump (filtered): 7.3 Gbits/sec
- Local iperf with 4 instances of tcpdump (unfiltered): 3.3 Gbits/sec
- iperf between a Windows VM (virtio) and a host: 240 Mbits/sec (is that
normal?)
- Same thing, with tcpdump (filtered): 240 Mbits/sec
- Same thing, with tcpdump (unfiltered): 240 Mbits/sec
- Same thing, with 4 instances of tcpdump (filtered): 240 Mbits/sec
- Same thing, with 4 instances of tcpdump (unfiltered): 200 Mbits/sec
If I understand correctly, this means that running tcpdump with a filter
minimizes the performance penalty involved.
(Note that for KVM tests we only need a single instance of tcpdump, even
when several VMs run at the same time.)
In light of this, do you still fear tcpdump will involve a significant
performance penalty? Do you think these benchmarks mean anything or
did I make a mistake somewhere that rendered them meaningless?
- tcpdump will run in the background at all times, and collect
MAC-IP pairs
as soon as they are assigned by the DHCP server. This is useful
for
NIC hotplugging (where IP addresses are assigned during the test
itself) and
generally for misbehaving guests or DHCP servers (restarting
network
services
during the test, using very short lease times).
- It is up to the user to create the actual bridge for TAP
devices;
the
qemu-ifup script included in one of the patches only adds the TAP
interface to
an existing bridge. The user should modify this script or create
a
bridge
some other way.
This works very well on two hosts I tried, but I'm not entirely
sure
it will
work in all cases -- please let me know what you think.
(I remember Jason Wang mentioned that tcpdump doesn't always
catch
all the
required traffic, or that it might somehow depend on the DHCP
server
-- anyone
willing to comment on that?)
The following patches have been tested with a few KVM tests
(boot,
reboot,
stress_boot, migration) with both TAP and user mode, but they
could
probably
use more testing (maybe with Python 2.6?), so if anyone is
willing
to help
with that I'd appreciate it very much.
--
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
--
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
--
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
[ANNOUNCE] AlacrityVM hypervisor project
We are pleased to announce the formation of the AlacrityVM project and the availability of v0.1 of the code. AlacrityVM is a hypervisor based on KVM targeted specifically at performance sensitive workloads such as HPC and real-time. You can find more information on the AlacrityVM wiki, available here: http://developer.novell.com/wiki/index.php/AlacrityVM Anyone who may be interested in further developments surrounding this project is encouraged to subscribe to one or both of the following lists: https://lists.sourceforge.net/lists/listinfo/alacrityvm-users https://lists.sourceforge.net/lists/listinfo/alacrityvm-devel Regards, -Greg signature.asc Description: OpenPGP digital signature
Re: [PATCH] use upstream cpuid code
On 08/03/2009 04:22 PM, Glauber Costa wrote: On Mon, Aug 03, 2009 at 02:57:47PM +0300, Avi Kivity wrote: On 07/28/2009 11:05 PM, Glauber Costa wrote: use cpuid code from upstream. By doing that, we lose the following snippet in kvm_get_supported_cpuid(): ret |= 1 12; /* MTRR */ ret |= 1 16; /* PAT */ ret |= 1 7; /* MCE */ ret |= 1 14; /* MCA */ A quick search in mailing lists says this code is not really necessary, and we're keeping it just for backwards compatibility. This is not that important, because we'd lose it anyway in the golden day in which we totally merge with qemu. Anyway, if it do _is_ important, we can send a patch to qemu with it. It is important. Please don't introduce regressions (if you do, introduce them in separate patches). The procedure to drop such workarounds for kernel bugs is to verify that major distros have the kernel fixes in their supported kernels. Since this was introduced to fix a bug that did not even existed in Windows, I can't see what you mean by distro kernels here. If qemu-kvm with this patch works on Fedora 10 (latest kernel) and the equivalent opensuse and Ubuntu kernels, then we can safely remove the bug workaround. If not, if we apply the patch we just cause users needless pain. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: x86: Disallow hypercalls for guest callers in rings 0
Jan Kiszka wrote: So far unprivileged guest callers running in ring 3 can issue, e.g., MMU hypercalls. Normally, such callers cannot provide any hand-crafted MMU command structure as it has to be passed by its physical address, but they can still crash the guest kernel by passing random addresses. To close the hole, this patch considers hypercalls valid only if issued from guest ring 0. This may still be relaxed on a per-hypercall base in the future once required. Actually, VT mandates that vmcalls can only be done from CPL=0. SVM allows hypercalls from CPL0 unfortunately. Regards, Anthony Liguori -- 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] use upstream cpuid code
On Mon, Aug 03, 2009 at 05:06:28PM +0300, Avi Kivity wrote: On 08/03/2009 04:22 PM, Glauber Costa wrote: On Mon, Aug 03, 2009 at 02:57:47PM +0300, Avi Kivity wrote: On 07/28/2009 11:05 PM, Glauber Costa wrote: use cpuid code from upstream. By doing that, we lose the following snippet in kvm_get_supported_cpuid(): ret |= 1 12; /* MTRR */ ret |= 1 16; /* PAT */ ret |= 1 7; /* MCE */ ret |= 1 14; /* MCA */ A quick search in mailing lists says this code is not really necessary, and we're keeping it just for backwards compatibility. This is not that important, because we'd lose it anyway in the golden day in which we totally merge with qemu. Anyway, if it do _is_ important, we can send a patch to qemu with it. It is important. Please don't introduce regressions (if you do, introduce them in separate patches). The procedure to drop such workarounds for kernel bugs is to verify that major distros have the kernel fixes in their supported kernels. Since this was introduced to fix a bug that did not even existed in Windows, I can't see what you mean by distro kernels here. If qemu-kvm with this patch works on Fedora 10 (latest kernel) and the equivalent opensuse and Ubuntu kernels, then we can safely remove the bug workaround. If not, if we apply the patch we just cause users needless pain. Again, since it was reported to fix a problem (that did not even existed in the first place) with Windows Vista, I don't really know why shouldn'it it work with any of the Linux guests (since they were not affected, to begin with) However, if you point me to a simple test case, I can definitely test it to make sure no weird condition is taking place. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Autotest] [KVM-AUTOTEST PATCH 0/12] TAP support (and a few other small things)
On Sun, Aug 2, 2009 at 8:58 PM, Michael Goldishmgold...@redhat.com wrote: Here's my proposed TAP solution: - The user specifies MAC ranges and may or may not specify corresponding IP ranges. - VMs are always given MAC addresses from the user specified MAC ranges. - MAC address ranges must be unique to each host running KVM tests -- there must be no overlap between them. - If corresponding IP ranges are specified as well, the system will use them when trying to communicate with guests. - If corresponding IP ranges are not specified, tcpdump will be used to listen to DHCP traffic and dynamically detect the right IP addresses. There's also a flag that can force this behavior. - tcpdump will run in the background at all times, and collect MAC-IP pairs as soon as they are assigned by the DHCP server. Â This is useful for NIC hotplugging (where IP addresses are assigned during the test itself) and generally for misbehaving guests or DHCP servers (restarting network services during the test, using very short lease times). - It is up to the user to create the actual bridge for TAP devices; the qemu-ifup script included in one of the patches only adds the TAP interface to an existing bridge. Â The user should modify this script or create a bridge some other way. This works very well on two hosts I tried, but I'm not entirely sure it will work in all cases -- please let me know what you think. (I remember Jason Wang mentioned that tcpdump doesn't always catch all the required traffic, or that it might somehow depend on the DHCP server -- anyone willing to comment on that?) The following patches have been tested with a few KVM tests (boot, reboot, stress_boot, migration) with both TAP and user mode, but they could probably use more testing (maybe with Python 2.6?), so if anyone is willing to help with that I'd appreciate it very much. No problem, since my development machine have python 2.6 and that's where I develop, I will test while I review your patches! -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Autotest] autotest exception in windows 2003 guest (ValueError: invalid literal for int() with base 10: '%errorlevel%)
On Mon, Aug 3, 2009 at 8:54 AM, sudhir kumarsmalik...@gmail.com wrote: On 7/27/09, Michael Goldish mgold...@redhat.com wrote: I know this seems a little messy, but if you wait a little while everything will sort itself out -- if I understand correctly, we are moving towards using rss.exe on all Windows guests, with nc as a client, and with kvm_subprocess controlling the client, and then most of the problems should go away (hopefully). I will be so happy. At present autotes is almost of no use for windows with copssh and openssh. boot reboot code works fine  but migrate code cause problem due to the colorful text of the prompt. I wana get out of this issue as soon as possible. please share the binaries with me so that we can come to know of issues if any and make this ssh server more robust. thanks in advance. No problem, I have just compiled rss.exe, will send you the binary on a separate message. -- 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: x86: Disallow hypercalls for guest callers in rings 0
On 08/03/2009 04:47 PM, Jan Kiszka wrote:
So far unprivileged guest callers running in ring 3 can issue, e.g., MMU
hypercalls. Normally, such callers cannot provide any hand-crafted MMU
command structure as it has to be passed by its physical address, but
they can still crash the guest kernel by passing random addresses.
To close the hole, this patch considers hypercalls valid only if issued
from guest ring 0. This may still be relaxed on a per-hypercall base in
the future once required.
Signed-off-by: Jan Kiszkajan.kis...@siemens.com
---
arch/x86/kvm/x86.c |8
include/linux/kvm_para.h |1 +
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 2539e9a..966d309 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3190,6 +3190,7 @@ static inline gpa_t hc_gpa(struct kvm_vcpu *vcpu,
unsigned long a0,
int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
{
unsigned long nr, a0, a1, a2, a3, ret;
+ struct kvm_segment cs;
int r = 1;
nr = kvm_register_read(vcpu, VCPU_REGS_RAX);
@@ -3208,6 +3209,12 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
a3= 0x;
}
+ kvm_get_segment(vcpu,cs, VCPU_SREG_CS);
+ if (cs.dpl != 0) {
+ ret = -KVM_EPERM;
+ goto out;
+ }
+
I think kvm_x86_ops-get_cpl() is more accurate (and we can optimize it
to avoid a ton of vmcs_read()s).
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] use upstream cpuid code
On 08/03/2009 05:12 PM, Glauber Costa wrote: If qemu-kvm with this patch works on Fedora 10 (latest kernel) and the equivalent opensuse and Ubuntu kernels, then we can safely remove the bug workaround. If not, if we apply the patch we just cause users needless pain. Again, since it was reported to fix a problem (that did not even existed in the first place) with Windows Vista, I don't really know why shouldn'it it work with any of the Linux guests (since they were not affected, to begin with) We aim to support more than just Linux guests. I don't understand what you mean by the problem did not even existed in the first place. I assure you it existed. However, if you point me to a simple test case, I can definitely test it to make sure no weird condition is taking place Install Windows Vista x64 on a host running a distro kernel. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: x86: Disallow hypercalls for guest callers in rings 0
On 08/03/2009 05:04 PM, Anthony Liguori wrote: Actually, VT mandates that vmcalls can only be done from CPL=0. That's exactly how I misremembered it. However the docs say IF not in VMX operation THEN #UD; ELSIF in VMX non-root operation THEN VM exit; ELSIF (RFLAGS.VM = 1) OR (IA32_EFER.LMA = 1 and CS.L = 0) THEN #UD; ELSIF CPL 0 THEN #GP(0); So CPL 0 is only enforced on VMCALL from the hypervisor, not the guest (tip: don't ask what VMCALL in the hypervisor means). SVM allows hypercalls from CPL0 unfortunately. Yeah. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: stopping the system clock
On 07/30/2009 08:02 PM, Roman Steiner wrote: hej hej, i've a question about the virtual time implementation in kvm/qemu. with the monitor commands stop / continue you can stop and start the guest system, but the system clock is still running. i\ve done the following experiment: * start the guest system * display the system time by running 'date' in the guest system * stop via the monitor * way for a minute or so * continue via the monitor * display the system time with 'date' in the guest system result: the system clock of the guest system was running the whole time for what i need it: i'm working on a simulation of a wireless network with at least 100 nodes (routers). each node should be represented by a kvm instance with a minimal os and some daemons (mainyl routing deamons). because the system gets overloaded some processes (kvm instances) are starving and the simulation is not working any more. so i would like to stop and start the guest system by the simulation program to keep them in order. therefore stopping and starting must be fast and it must be a full stop. Essentially, the scheduler is also stopping and starting the guests. So I think that instead of writing another scheduler to pause and unpause guests, you can adjust qemu to run time in slow motion. That should reduce the interrupt rate and therefore the system load. Not sure where exactly this needs to change, probably where qemu reads the host time and sets host timers. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
bios hinders KVM
Hello, This was initially a complaint about kvm-amd Operation not supported. However I decided to reflash my bios to an earlier version and ... problem solved, so far. If there is someway I can further things by supplying specifics about what might have changed please let me know what sort of tracing I can turn on to give a report. I have: MSI k9n2g-NEO (nvidia chip set) AMD athlon X2 4800e @ 2.5 G (says on the box it has SVM) 4G DDR2 ram 800Mhz bios 1.2 works; bios 1.3 introduced the problem The hardware is not being overclocked. Thanks in advance and for the hard work, John Sims -- 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 2/2] eventfd: EFD_STATE flag
On 07/28/2009 08:55 PM, Michael S. Tsirkin wrote:
This implements a new EFD_STATE flag for eventfd.
When set, this flag changes eventfd behaviour in the following way:
- write simply stores the value written, and is always non-blocking
- read unblocks when the value written changes, and
returns the value written
Motivation: we'd like to use eventfd in qemu to pass interrupts from
(emulated or assigned) devices to guest. For level interrupts, the
counter supported currently by eventfd is not a good match: we really
need to set interrupt to a level, typically 0 or 1, and give the guest
ability to see the last value written.
@@ -31,37 +31,59 @@ struct eventfd_ctx {
* issue a wakeup.
*/
__u64 count;
+ /*
+* When EF_STATE flag is set, eventfd behaves differently:
+* value written gets stored in count, read will copy
+* count to state.
+*/
+ __u64 state;
unsigned int flags;
};
Why not write the new value into -count directly?
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: x86: Disallow hypercalls for guest callers in rings 0
Avi Kivity wrote: On 08/03/2009 05:04 PM, Anthony Liguori wrote: Actually, VT mandates that vmcalls can only be done from CPL=0. That's exactly how I misremembered it. However the docs say IF not in VMX operation THEN #UD; ELSIF in VMX non-root operation THEN VM exit; ELSIF (RFLAGS.VM = 1) OR (IA32_EFER.LMA = 1 and CS.L = 0) THEN #UD; ELSIF CPL 0 THEN #GP(0); So CPL 0 is only enforced on VMCALL from the hypervisor, not the guest (tip: don't ask what VMCALL in the hypervisor means). Ah, it's used to call SMM peer mode... awesome :-) Regards, Anthony Liguori -- 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 0/3] Allow larger BIOS image
On 07/27/2009 03:23 AM, Jordan Justen wrote: From: Jordan Justenjljus...@gmail.com These changes are similar to my patches sent July 16, except they now are based on Yang Sheng's recent changes to enable a new ioctl for controlling the EPT identity mapping page location. Applied, thanks. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-RFC 2/2] eventfd: EFD_STATE flag
On Mon, Aug 03, 2009 at 06:09:38PM +0300, Avi Kivity wrote:
On 07/28/2009 08:55 PM, Michael S. Tsirkin wrote:
This implements a new EFD_STATE flag for eventfd.
When set, this flag changes eventfd behaviour in the following way:
- write simply stores the value written, and is always non-blocking
- read unblocks when the value written changes, and
returns the value written
Motivation: we'd like to use eventfd in qemu to pass interrupts from
(emulated or assigned) devices to guest. For level interrupts, the
counter supported currently by eventfd is not a good match: we really
need to set interrupt to a level, typically 0 or 1, and give the guest
ability to see the last value written.
@@ -31,37 +31,59 @@ struct eventfd_ctx {
* issue a wakeup.
*/
__u64 count;
+/*
+ * When EF_STATE flag is set, eventfd behaves differently:
+ * value written gets stored in count, read will copy
+ * count to state.
+ */
+__u64 state;
unsigned int flags;
};
Why not write the new value into -count directly?
That's what it says. state is ther to detect that value was changed
after last read. Makes sense?
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-RFC 2/2] eventfd: EFD_STATE flag
On 08/03/2009 06:14 PM, Michael S. Tsirkin wrote:
On Mon, Aug 03, 2009 at 06:09:38PM +0300, Avi Kivity wrote:
On 07/28/2009 08:55 PM, Michael S. Tsirkin wrote:
This implements a new EFD_STATE flag for eventfd.
When set, this flag changes eventfd behaviour in the following way:
- write simply stores the value written, and is always non-blocking
- read unblocks when the value written changes, and
returns the value written
Motivation: we'd like to use eventfd in qemu to pass interrupts from
(emulated or assigned) devices to guest. For level interrupts, the
counter supported currently by eventfd is not a good match: we really
need to set interrupt to a level, typically 0 or 1, and give the guest
ability to see the last value written.
@@ -31,37 +31,59 @@ struct eventfd_ctx {
* issue a wakeup.
*/
__u64 count;
+ /*
+* When EF_STATE flag is set, eventfd behaves differently:
+* value written gets stored in count, read will copy
+* count to state.
+*/
+ __u64 state;
unsigned int flags;
};
Why not write the new value into -count directly?
That's what it says. state is ther to detect that value was changed
after last read. Makes sense?
Why not do it at the point of the write?
if (value != ctx-count) {
ctx-count = value;
wake_things_up();
}
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bios hinders KVM
On 08/03/2009 05:55 PM, John wrote: Hello, This was initially a complaint about kvm-amd Operation not supported. However I decided to reflash my bios to an earlier version and ... problem solved, so far. If there is someway I can further things by supplying specifics about what might have changed please let me know what sort of tracing I can turn on to give a report. I have: MSI k9n2g-NEO (nvidia chip set) AMD athlon X2 4800e @ 2.5 G (says on the box it has SVM) 4G DDR2 ram 800Mhz bios 1.2 works; bios 1.3 introduced the problem Complain to your hardware vendor; they've messed up the bios code. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: x86: Disallow hypercalls for guest callers in rings 0
On 08/03/2009 06:04 PM, Anthony Liguori wrote: So CPL 0 is only enforced on VMCALL from the hypervisor, not the guest (tip: don't ask what VMCALL in the hypervisor means). Ah, it's used to call SMM peer mode... awesome :-) Now you'll never be able to sleep at night. Well I did try to warn you. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kvm: fix set_ept_identity_addr() in pae
The argument to kernel space should be u64 rather than unsigned long.
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
qemu-kvm-x86.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index 492dbc5..5fa89e8 100644
--- a/qemu-kvm-x86.c
+++ b/qemu-kvm-x86.c
@@ -73,7 +73,7 @@ static int kvm_init_tss(kvm_context_t kvm)
return 0;
}
-static int kvm_set_identity_map_addr(kvm_context_t kvm, unsigned long addr)
+static int kvm_set_identity_map_addr(kvm_context_t kvm, uint64_t addr)
{
#ifdef KVM_CAP_SET_IDENTITY_MAP_ADDR
int r;
--
1.5.4.5
--
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] KVM: Fix EPT identity page location
Should be new ept_identity_map_addr rather than old macro. Signed-off-by: Sheng Yang sh...@linux.intel.com --- arch/x86/kvm/vmx.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 7931c72..c5aaa1b 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -2199,7 +2199,7 @@ static int alloc_identity_pagetable(struct kvm *kvm) goto out; kvm-arch.ept_identity_pagetable = gfn_to_page(kvm, - VMX_EPT_IDENTITY_PAGETABLE_ADDR PAGE_SHIFT); + kvm-arch.ept_identity_map_addr PAGE_SHIFT); out: up_write(kvm-slots_lock); return r; -- 1.5.4.5 -- 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: Re: slow responsiveness of kvm guests
On Aug 3, 2009, Avi Kivity a...@redhat.com wrote:
On 07/31/2009 05:15 PM, Kai Zimmer wrote:
qemu-kvm -hda xyz.qcow2 -daemonize -net nic,model=virtio -net tap -k de -m
3584 -smp 2 -mem-path /hugepages -vnc :2
Any ideas what goes wrong here?
All three guests have the same MAC address, so when one talks, you can't
hear the others.
Use -net nic,model=virtio,macaddr=00:11:22:33:44:0{1,2,3} (different
addresses for different guests).
Yes - that fixed it.
Thanks a lot!
Kai
--
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
Bandwith limitation with KVM VMs
Hi all! I have a KVM VM that it has installed a MRTG on the network interface and that it doesn't register more than 10 Mbps, seeming that per moments it is saturated in this value. Has KVM some bandwidth limitation of the virtualized network interfaces? In such case, exists some way to increase that limitation? Thanks in advance. Regards, Daniel -- Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37 Powered by Debian GNU/Linux Squeeze - Linux user #188.598 signature.asc Description: Digital signature
[PATCH v2] KVM: x86: Disallow hypercalls for guest callers in rings 0
Avi Kivity wrote:
On 08/03/2009 04:47 PM, Jan Kiszka wrote:
So far unprivileged guest callers running in ring 3 can issue, e.g., MMU
hypercalls. Normally, such callers cannot provide any hand-crafted MMU
command structure as it has to be passed by its physical address, but
they can still crash the guest kernel by passing random addresses.
To close the hole, this patch considers hypercalls valid only if issued
from guest ring 0. This may still be relaxed on a per-hypercall base in
the future once required.
Signed-off-by: Jan Kiszkajan.kis...@siemens.com
---
arch/x86/kvm/x86.c |8
include/linux/kvm_para.h |1 +
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 2539e9a..966d309 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3190,6 +3190,7 @@ static inline gpa_t hc_gpa(struct kvm_vcpu
*vcpu, unsigned long a0,
int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
{
unsigned long nr, a0, a1, a2, a3, ret;
+struct kvm_segment cs;
int r = 1;
nr = kvm_register_read(vcpu, VCPU_REGS_RAX);
@@ -3208,6 +3209,12 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
a3= 0x;
}
+kvm_get_segment(vcpu,cs, VCPU_SREG_CS);
+if (cs.dpl != 0) {
+ret = -KVM_EPERM;
+goto out;
+}
+
I think kvm_x86_ops-get_cpl() is more accurate (and we can optimize it
to avoid a ton of vmcs_read()s).
Yes, that's much nicer.
-
So far unprivileged guest callers running in ring 3 can issue, e.g., MMU
hypercalls. Normally, such callers cannot provide any hand-crafted MMU
command structure as it has to be passed by its physical address, but
they can still crash the guest kernel by passing random addresses.
To close the hole, this patch considers hypercalls valid only if issued
from guest ring 0. This may still be relaxed on a per-hypercall base in
the future once required.
Changes v1 - v2:
- use kvm_x86_ops-get_cpl() in favor of kvm_get_segment()
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
arch/x86/kvm/x86.c |6 ++
include/linux/kvm_para.h |1 +
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 2539e9a..1c17105 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3208,6 +3208,11 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
a3 = 0x;
}
+ if (kvm_x86_ops-get_cpl(vcpu) != 0) {
+ ret = -KVM_EPERM;
+ goto out;
+ }
+
switch (nr) {
case KVM_HC_VAPIC_POLL_IRQ:
ret = 0;
@@ -3219,6 +3224,7 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
ret = -KVM_ENOSYS;
break;
}
+out:
kvm_register_write(vcpu, VCPU_REGS_RAX, ret);
++vcpu-stat.hypercalls;
return r;
diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h
index 3ddce03..d731092 100644
--- a/include/linux/kvm_para.h
+++ b/include/linux/kvm_para.h
@@ -13,6 +13,7 @@
#define KVM_ENOSYS 1000
#define KVM_EFAULT EFAULT
#define KVM_E2BIG E2BIG
+#define KVM_EPERM EPERM
#define KVM_HC_VAPIC_POLL_IRQ 1
#define KVM_HC_MMU_OP 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: [PATCH] KVM: Fix EPT identity IOCTL on 32pae
On Tuesday 04 August 2009 00:47:16 Marcelo Tosatti wrote:
On Mon, Aug 03, 2009 at 02:17:27PM +0800, Sheng Yang wrote:
Copy u64 from guest result in chaos.
Why?
My fault in userspace...
--
regards
Yang, Sheng
Also fix a mistake of still using old macro rather than new variable().
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
arch/x86/kvm/vmx.c |2 +-
arch/x86/kvm/x86.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 7931c72..c5aaa1b 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2199,7 +2199,7 @@ static int alloc_identity_pagetable(struct kvm
*kvm) goto out;
kvm-arch.ept_identity_pagetable = gfn_to_page(kvm,
- VMX_EPT_IDENTITY_PAGETABLE_ADDR PAGE_SHIFT);
+ kvm-arch.ept_identity_map_addr PAGE_SHIFT);
out:
up_write(kvm-slots_lock);
return r;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 2539e9a..977b705 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2178,7 +2178,7 @@ long kvm_arch_vm_ioctl(struct file *filp,
goto out;
break;
case KVM_SET_IDENTITY_MAP_ADDR: {
- u64 ident_addr;
+ unsigned long ident_addr;
r = -EFAULT;
if (copy_from_user(ident_addr, argp, sizeof ident_addr))
--
1.5.4.5
--
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: Bandwith limitation with KVM VMs
Daniel Bareiro wrote: Hi all! I have a KVM VM that it has installed a MRTG on the network interface and that it doesn't register more than 10 Mbps, seeming that per moments it is saturated in this value. Has KVM some bandwidth limitation of the virtualized network interfaces? In such case, exists some way to increase that limitation? There is no set artificial limit afaict, though there are a large number of factors that can affect performance. Of course, everything has an ultimate ceiling (KVM included) but I have found this limit in KVM to be orders of magnitude faster than 10Mbps. Properly tuned, you should easily be able to saturate a GE link at line rate, or even 4Gbps-5Gpbs of a 10GE link. If you need even more than that, I would suggest taking a look at my recently announced project which focuses on IO performance: http://developer.novell.com/wiki/index.php/AlacrityVM However, since you are only hitting 10Mb/s now, there is ton of headroom left even on upstream KVM so you might find it to be satisfactory as is, once you address the current bottleneck in your setup. Things to check: What linkspeed does the host see to the next hop? How much bandwidth does the host see to the same end-point? What is your overall topology, especially for the VM (are you using -net tap, etc). What MTU are you using. Etc. Good luck! -Greg signature.asc Description: OpenPGP digital signature
Re: [PATCH-RFC 2/2] eventfd: EFD_STATE flag
On Mon, Aug 03, 2009 at 06:29:36PM +0300, Avi Kivity wrote:
On 08/03/2009 06:14 PM, Michael S. Tsirkin wrote:
On Mon, Aug 03, 2009 at 06:09:38PM +0300, Avi Kivity wrote:
On 07/28/2009 08:55 PM, Michael S. Tsirkin wrote:
This implements a new EFD_STATE flag for eventfd.
When set, this flag changes eventfd behaviour in the following way:
- write simply stores the value written, and is always non-blocking
- read unblocks when the value written changes, and
returns the value written
Motivation: we'd like to use eventfd in qemu to pass interrupts from
(emulated or assigned) devices to guest. For level interrupts, the
counter supported currently by eventfd is not a good match: we really
need to set interrupt to a level, typically 0 or 1, and give the guest
ability to see the last value written.
@@ -31,37 +31,59 @@ struct eventfd_ctx {
* issue a wakeup.
*/
__u64 count;
+ /*
+ * When EF_STATE flag is set, eventfd behaves differently:
+ * value written gets stored in count, read will copy
+ * count to state.
+ */
+ __u64 state;
unsigned int flags;
};
Why not write the new value into -count directly?
That's what it says. state is ther to detect that value was changed
after last read. Makes sense?
Why not do it at the point of the write?
if (value != ctx-count) {
ctx-count = value;
wake_things_up();
}
What if write comes before read?
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm userspace: ksm support
If someone wanted to play around with ksm in qemu-kvm-0.x.x would it be as
simple as adding the below additions to kvm_setup_guest_memory in kvm-all.c
(and adding the necessary kernel changes of course)?
On Tuesday 28 July 2009 11:39:59 am Izik Eidus wrote:
This patch is not for inclusion just rfc.
Thanks.
From 1297b86aa257100b3d819df9f9f0932bf4f7f49d Mon Sep 17 00:00:00 2001
From: Izik Eidus iei...@redhat.com
Date: Tue, 28 Jul 2009 19:14:26 +0300
Subject: [PATCH] kvm userspace: ksm support
rfc for ksm support to kvm userpsace.
thanks
Signed-off-by: Izik Eidus iei...@redhat.com
---
exec.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/exec.c b/exec.c
index f6d9ec9..375cc18 100644
--- a/exec.c
+++ b/exec.c
@@ -2595,6 +2595,9 @@ ram_addr_t qemu_ram_alloc(ram_addr_t size)
new_block-host = file_ram_alloc(size, mem_path);
if (!new_block-host) {
new_block-host = qemu_vmalloc(size);
+#ifdef MADV_MERGEABLE
+madvise(new_block-host, size, MADV_MERGEABLE);
+#endif
}
new_block-offset = last_ram_offset;
new_block-length = size;
--
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 userspace: ksm support
Brian Jackson wrote:
If someone wanted to play around with ksm in qemu-kvm-0.x.x would it be as
simple as adding the below additions to kvm_setup_guest_memory in kvm-all.c
qemu-kvm-0.x.x doesnt tell me much, but if it is the function that
register the memory than yes...
(I just remember that qemu used to have something called phys_ram_base,
in that case it would be just making madvise on phys_ram_base with the
same of phys_ram_size)
(and adding the necessary kernel changes of course)?
On Tuesday 28 July 2009 11:39:59 am Izik Eidus wrote:
This patch is not for inclusion just rfc.
Thanks.
From 1297b86aa257100b3d819df9f9f0932bf4f7f49d Mon Sep 17 00:00:00 2001
From: Izik Eidus iei...@redhat.com
Date: Tue, 28 Jul 2009 19:14:26 +0300
Subject: [PATCH] kvm userspace: ksm support
rfc for ksm support to kvm userpsace.
thanks
Signed-off-by: Izik Eidus iei...@redhat.com
---
exec.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/exec.c b/exec.c
index f6d9ec9..375cc18 100644
--- a/exec.c
+++ b/exec.c
@@ -2595,6 +2595,9 @@ ram_addr_t qemu_ram_alloc(ram_addr_t size)
new_block-host = file_ram_alloc(size, mem_path);
if (!new_block-host) {
new_block-host = qemu_vmalloc(size);
+#ifdef MADV_MERGEABLE
+madvise(new_block-host, size, MADV_MERGEABLE);
+#endif
}
new_block-offset = last_ram_offset;
new_block-length = size;
--
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 userspace: ksm support
On Monday 03 August 2009 01:09:38 pm Izik Eidus wrote:
Brian Jackson wrote:
If someone wanted to play around with ksm in qemu-kvm-0.x.x would it be
as simple as adding the below additions to kvm_setup_guest_memory in
kvm-all.c
qemu-kvm-0.x.x doesnt tell me much, but if it is the function that
register the memory than yes...
(I just remember that qemu used to have something called phys_ram_base,
in that case it would be just making madvise on phys_ram_base with the
same of phys_ram_size)
Sorry, I'm using qemu-kvm-0.10.6
This is what qemu_ram_alloc looks like:
/* XXX: better than nothing */
ram_addr_t qemu_ram_alloc(ram_addr_t size)
{
ram_addr_t addr;
if ((phys_ram_alloc_offset + size) phys_ram_size) {
fprintf(stderr, Not enough memory (requested_size = % PRIu64 , max
memory = % PRIu64 )\n,
(uint64_t)size, (uint64_t)phys_ram_size);
abort();
}
addr = phys_ram_alloc_offset;
phys_ram_alloc_offset = TARGET_PAGE_ALIGN(phys_ram_alloc_offset + size);
if (kvm_enabled())
kvm_setup_guest_memory(phys_ram_base + addr, size);
return addr;
}
And this is what my new kvm_setup_guest_memory looks like:
void kvm_setup_guest_memory(void *start, size_t size)
{
if (!kvm_has_sync_mmu()) {
#ifdef MADV_DONTFORK
int ret = madvise(start, size, MADV_DONTFORK);
if (ret) {
perror(madvice);
exit(1);
}
#else
fprintf(stderr,
Need MADV_DONTFORK in absence of synchronous KVM MMU\n);
exit(1);
#endif
}
#ifdef MADV_MERGEABLE
madvise(start, size, MADV_MERGEABLE);
#endif
}
Look okay?
(and adding the necessary kernel changes of course)?
On Tuesday 28 July 2009 11:39:59 am Izik Eidus wrote:
This patch is not for inclusion just rfc.
Thanks.
From 1297b86aa257100b3d819df9f9f0932bf4f7f49d Mon Sep 17 00:00:00 2001
From: Izik Eidus iei...@redhat.com
Date: Tue, 28 Jul 2009 19:14:26 +0300
Subject: [PATCH] kvm userspace: ksm support
rfc for ksm support to kvm userpsace.
thanks
Signed-off-by: Izik Eidus iei...@redhat.com
---
exec.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/exec.c b/exec.c
index f6d9ec9..375cc18 100644
--- a/exec.c
+++ b/exec.c
@@ -2595,6 +2595,9 @@ ram_addr_t qemu_ram_alloc(ram_addr_t size)
new_block-host = file_ram_alloc(size, mem_path);
if (!new_block-host) {
new_block-host = qemu_vmalloc(size);
+#ifdef MADV_MERGEABLE
+madvise(new_block-host, size, MADV_MERGEABLE);
+#endif
}
new_block-offset = last_ram_offset;
new_block-length = size;
--
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
--
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 userspace: ksm support
Brian Jackson wrote:
On Monday 03 August 2009 01:09:38 pm Izik Eidus wrote:
Brian Jackson wrote:
If someone wanted to play around with ksm in qemu-kvm-0.x.x would it be
as simple as adding the below additions to kvm_setup_guest_memory in
kvm-all.c
qemu-kvm-0.x.x doesnt tell me much, but if it is the function that
register the memory than yes...
(I just remember that qemu used to have something called phys_ram_base,
in that case it would be just making madvise on phys_ram_base with the
same of phys_ram_size)
Sorry, I'm using qemu-kvm-0.10.6
This is what qemu_ram_alloc looks like:
/* XXX: better than nothing */
ram_addr_t qemu_ram_alloc(ram_addr_t size)
{
ram_addr_t addr;
if ((phys_ram_alloc_offset + size) phys_ram_size) {
fprintf(stderr, Not enough memory (requested_size = % PRIu64 , max memory = %
PRIu64 )\n,
(uint64_t)size, (uint64_t)phys_ram_size);
abort();
}
addr = phys_ram_alloc_offset;
phys_ram_alloc_offset = TARGET_PAGE_ALIGN(phys_ram_alloc_offset + size);
if (kvm_enabled())
kvm_setup_guest_memory(phys_ram_base + addr, size);
return addr;
}
And this is what my new kvm_setup_guest_memory looks like:
void kvm_setup_guest_memory(void *start, size_t size)
{
if (!kvm_has_sync_mmu()) {
#ifdef MADV_DONTFORK
int ret = madvise(start, size, MADV_DONTFORK);
if (ret) {
perror(madvice);
exit(1);
}
#else
fprintf(stderr,
Need MADV_DONTFORK in absence of synchronous KVM MMU\n);
exit(1);
#endif
}
#ifdef MADV_MERGEABLE
madvise(start, size, MADV_MERGEABLE);
#endif
}
Look okay?
Yes.
--
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: virtio-serial: An interface for host-guest communication
Richard W.M. Jones wrote: On Mon, Jul 27, 2009 at 06:44:28PM -0500, Anthony Liguori wrote: It really suggests that you need _one_ vmchannel that's exposed to userspace with a single userspace daemon that consumes it. ... or a more flexible API. I don't like having fixed /dev/vmch* devices either. Have you considered using a usb serial device? Something attractive about it is that a productid/vendorid can be specified which means that you can use that as a method of enumerating devices. Hot add/remove is supported automagically. Regards, Anthony Liguori -- 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 test: Unattended install support
This patchset introduces unattended install to autotest. This is a first-pass implementation for reviewers, and actually we don't have much else to say, except that we need to: * Create unattended install files for all our supported os (that will be a large task) * Implement simple templating system for answer files so we can replace the host IP address on the end stage, where the guest reports the end of installation to the host OS. I would like to thank Yaniv Kaul, Michael Goldish, Eduardo Habkost for the ideas and help to resolve some nitty-gritty issues and for David Huff, who sent an initial implementation of this test. -- 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 1/6] KVM test: Added floppy and tftp options to qemu command
This allows you to not specify the full path in the
config file, appends to the image dir.
Signed-off-by: David Huff dh...@redhat.com
---
client/tests/kvm/kvm_vm.py | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/client/tests/kvm/kvm_vm.py b/client/tests/kvm/kvm_vm.py
index 2ea6681..f65b78c 100644
--- a/client/tests/kvm/kvm_vm.py
+++ b/client/tests/kvm/kvm_vm.py
@@ -256,6 +256,18 @@ class VM:
iso = os.path.join(iso_dir, iso)
qemu_cmd += -cdrom %s % iso
+# We may want to add {floppy_otps} parameter for -fda
+# {fat:floppy:}/path/. However vvfat is not usually recommended
+floppy = params.get(floppy)
+if floppy:
+floppy = os.path.join(image_dir, floppy)
+qemu_cmd += -fda %s % floppy
+
+tftp = params.get(tftp)
+if tftp:
+tftp = os.path.join(image_dir, tftp)
+qemu_cmd += -tftp %s % tftp
+
extra_params = params.get(extra_params)
if extra_params:
qemu_cmd += %s % extra_params
--
1.6.2.5
--
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 2/6] KVM test: Introducing unattended install subtest
In order to resolve the question, 'how will the guest
operating system tell the host operating system that
the unattended install process finish', we took the
simple approach and created a simple socket communication
ack process: The test instantiates a server tcp socket
on port 12323, and waits during a specified amount of time.
For guests, the vast majority of the unattended install
processes can deal with executing commands at the end of
the install process. Let's take advantage of that and
make clients tell the server about the end of the process
using simple programs that can do that. The implementation
of that strategy varies trough different operating systems.
This is the kvm test implementation code, client programs
will follow on later patches.
Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com
---
client/tests/kvm/kvm.py |2 +
client/tests/kvm/kvm_tests.py | 81 -
2 files changed, 82 insertions(+), 1 deletions(-)
diff --git a/client/tests/kvm/kvm.py b/client/tests/kvm/kvm.py
index 070e463..db6899b 100644
--- a/client/tests/kvm/kvm.py
+++ b/client/tests/kvm/kvm.py
@@ -56,6 +56,8 @@ class kvm(test.test):
linux_s3: test_routine(kvm_tests, run_linux_s3),
stress_boot: test_routine(kvm_tests, run_stress_boot),
timedrift:test_routine(kvm_tests, run_timedrift),
+unattended_install: test_routine(kvm_tests,
+run_unattended_install),
}
# Make it possible to import modules from the test's bindir
diff --git a/client/tests/kvm/kvm_tests.py b/client/tests/kvm/kvm_tests.py
index 9784ec9..f45fefc 100644
--- a/client/tests/kvm/kvm_tests.py
+++ b/client/tests/kvm/kvm_tests.py
@@ -1,4 +1,4 @@
-import time, os, logging, re, commands
+import time, os, logging, re, commands, socket
from autotest_lib.client.common_lib import utils, error
import kvm_utils, kvm_subprocess, ppm_utils, scan_results
@@ -9,6 +9,85 @@ KVM test definitions.
+class UnattendedInstallWatcher:
+
+Mechanism to verify whether an unattended guest install actually did
finish.
+It opens a TCP socket and waits until it receives a message. If it does get
+the expected message from the guest, it will finish gracefully.
+
+def __init__(self, timeout, msg):
+self.port = 12323
+self.buf_size = 1024
+self.timeout = timeout
+self.msg = msg
+
+
+def check_answer(self, connection):
+
+Verify if client has sent the correct ACK message.
+
+@param connection: Tuple with client socket connection and address.
+@return: True, in case the client has responded accordingly; False if
+the string doesn't match the server expectations.
+
+(client, addr) = connection
+msg = client.recv(self.buf_size)
+logging.debug(Received '%s' from %s, msg, addr)
+if msg == self.msg:
+logging.info('Guest reported successful installation')
+return True
+else:
+logging.error('Got invalid string from client: %s.' % msg)
+return False
+
+
+def run_server(self):
+
+Initializes and runs the server socket and listens for connections.
+
+server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
+address = ('', self.port)
+server.bind(address)
+server.listen(1)
+
+while True:
+try:
+server.settimeout(self.timeout)
+connection = server.accept()
+if self.check_answer(connection):
+break
+except:
+server.close()
+raise
+
+
+def run_unattended_install(test, params, env):
+
+Unattended install test:
+1) Starts a VM with an appropriated setup to start an unattended OS
install.
+2) Wait until the install reports to the install watcher its end.
+
+@param test: KVM test object.
+@param params: Dictionary with the test parameters.
+@param env: Dictionary with test environment.
+
+vm = kvm_utils.env_get_vm(env, params.get(main_vm))
+if not vm:
+raise error.TestError(VM object not found in environment)
+if not vm.is_alive():
+raise error.TestError(VM seems to be dead; Test requires a living VM)
+
+logging.info(Starting unattended install watch process)
+watcher = UnattendedInstallWatcher(timeout=3000, msg='done')
+try:
+watcher.run_server()
+except socket.timeout:
+raise error.TestFail('Timeout elapsed while waiting for install to '
+ 'finish.')
+
+logging.info(Unattended install finished successfuly)
+
+
def run_boot(test, params, env):
KVM reboot test:
--
1.6.2.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
[PATCH 3/6] KVM test: Add unattended install files for F11 and WinXP
For the purpose of developing the test, 2 operating systems
were used, Fedora 11 and Windows XP 32 bit. This patch adds
the unattended install files for each OS:
* Fedora 11: Fedora-11.ks
* Win XP: winnt.bat and winxp32.sif
Attention: Actually those 2 files *should* be templates that
would have the IP replaced by the current Host IP, but
I wanted to get the patchset reviewed before I implement
the templating functionality. For now, just replace your
server IP on the unattended file and it will work fine.
On the final version we will already have answer file
templating implemented appropriately.
Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com
---
client/tests/kvm/unattended/Fedora-11.ks | 36 +++
client/tests/kvm/unattended/winnt.bat| 12 +
client/tests/kvm/unattended/winxp32.sif | 72 ++
3 files changed, 120 insertions(+), 0 deletions(-)
create mode 100644 client/tests/kvm/unattended/Fedora-11.ks
create mode 100644 client/tests/kvm/unattended/winnt.bat
create mode 100644 client/tests/kvm/unattended/winxp32.sif
diff --git a/client/tests/kvm/unattended/Fedora-11.ks
b/client/tests/kvm/unattended/Fedora-11.ks
new file mode 100644
index 000..3bfa355
--- /dev/null
+++ b/client/tests/kvm/unattended/Fedora-11.ks
@@ -0,0 +1,36 @@
+install
+cdrom
+text
+reboot
+lang en_US
+keyboard us
+network --bootproto dhcp
+rootpw 123456
+firewall --enabled --ssh
+selinux --enforcing
+timezone --utc America/New_York
+firstboot --disable
+bootloader --location=mbr
+zerombr
+
+clearpart --all --initlabel
+part /boot --fstype=ext3 --size=100
+part / --fstype=ext3 --size=2000
+part swap --fstype=swap --size=512
+
+%packages
+@ Base
+%end
+
+%post --interpreter /usr/bin/python
+import socket, os
+os.system('iptables -F')
+os.system('echo 0 /selinux/enforce')
+port = 12323
+buf = 1024
+addr = ('192.168.1.3', port)
+client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
+client.connect(addr)
+client.sendto('done', addr)
+client.close()
+%end
\ No newline at end of file
diff --git a/client/tests/kvm/unattended/winnt.bat
b/client/tests/kvm/unattended/winnt.bat
new file mode 100644
index 000..59aa2b6
--- /dev/null
+++ b/client/tests/kvm/unattended/winnt.bat
@@ -0,0 +1,12 @@
+...@rem SetupMgrTag
+...@echo off
+
+rem
+rem This is a SAMPLE batch script generated by Setup Manager.
+rem If this script is moved from the location where it was generated, it may
have to be modified.
+rem
+
+set AnswerFile=.\winnt.sif
+set SetupFiles=D:\i386
+
+D:\i386\winnt32 /s:%SetupFiles% /unattend:%AnswerFile%
diff --git a/client/tests/kvm/unattended/winxp32.sif
b/client/tests/kvm/unattended/winxp32.sif
new file mode 100644
index 000..2bc62b2
--- /dev/null
+++ b/client/tests/kvm/unattended/winxp32.sif
@@ -0,0 +1,72 @@
+;SetupMgrTag
+[Data]
+AutoPartition=1
+MsDosInitiated=0
+UnattendedInstall=Yes
+
+[Unattended]
+Repartition=Yes
+UnattendMode=FullUnattended
+OemSkipEula=Yes
+OemPreinstall=No
+TargetPath=\WINDOWS
+UnattendSwitch=Yes
+CrashDumpSetting=1
+DriverSigningPolicy=ignore
+WaitForReboot=no
+
+[GuiUnattended]
+AdminPassword=123456
+EncryptedAdminPassword=NO
+TimeZone=85
+OemSkipWelcome=1
+AutoLogon=Yes
+AutoLogonCount=1
+OEMSkipRegional=1
+
+[UserData]
+ProductKey=MC938-F98CQ-3HHB6-2MYC9-KQJ8G
+FullName=Lucas Meneghel Rodrigues
+OrgName=Red Hat
+ComputerName=*
+
+[Identification]
+JoinWorkgroup=WORKGROUP
+
+[Networking]
+InstallDefaultComponents=Yes
+
+[Proxy]
+Proxy_Enable=0
+Use_Same_Proxy=0
+
+[Components]
+dialer=off
+media_clips=off
+media_utopia=off
+msnexplr=off
+netoc=off
+OEAccess=off
+templates=off
+WMAccess=off
+zonegames=off
+
+[TerminalServices]
+AllowConnections=1
+
+[WindowsFirewall]
+Profiles=WindowsFirewall.TurnOffFirewall
+
+[WindowsFirewall.TurnOffFirewall]
+Mode=0
+
+[Branding]
+BrandIEUsingUnattended=Yes
+
+[GuiRunOnce]
+Command0=cmd /c A:\finish.exe 192.168.1.4
+
+[Display]
+Xresolution=1024
+YResolution=768
+
--
1.6.2.5
--
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 5/6] KVM test: Utility to make windows guests ACK end of install
In order to make windows guests to tell the unattended install
server that the install process ended, a simple C++ program
using the winsock 2 API had to be developed. The program was
based on an MSDN article. Its usage is
finish.exe [host-ip]
The test expect this to be compiled under deps. This can be
accomplished on linux hosts that support the mingw cross
compiling environment (or you can just compile it under your
windows guest). For Fedora 11, the instructions are:
yum install mingw32-w32api mingw32-gcc-c++
i686-pc-mingw32-g++ finish.cpp -lws2_32 -o finish.exe
Binaries produced by this process work just fine on my tests.
I still haven't made my mind about shipping binaries, with
the test, so in the meantime you want to check this compile
the code as you wish and put it under the same deps dir.
Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com
---
client/tests/kvm/deps/finish.cpp | 121 ++
1 files changed, 121 insertions(+), 0 deletions(-)
create mode 100644 client/tests/kvm/deps/finish.cpp
diff --git a/client/tests/kvm/deps/finish.cpp b/client/tests/kvm/deps/finish.cpp
new file mode 100644
index 000..9c2867c
--- /dev/null
+++ b/client/tests/kvm/deps/finish.cpp
@@ -0,0 +1,121 @@
+// Simple app that only sends an ack string to the KVM unattended install
+// watch code.
+//
+// You must link this code with Ws2_32.lib, Mswsock.lib, and Advapi32.lib
+//
+// Author: Lucas Meneghel Rodrigues l...@redhat.com
+// Code was adapted from an MSDN sample.
+
+// Usage: finish.exe [Host OS IP]
+
+// MinGW's ws2tcpip.h only defines getaddrinfo and other functions only for
+// the case _WIN32_WINNT = 0x0501.
+#ifdef __MINGW32__
+#undef _WIN32_WINNT
+#define _WIN32_WINNT 0x501
+#endif
+
+#include windows.h
+#include winsock2.h
+#include ws2tcpip.h
+#include stdlib.h
+#include stdio.h
+
+#define DEFAULT_BUFLEN 512
+#define DEFAULT_PORT 12323
+
+int main(int argc, char **argv)
+{
+WSADATA wsaData;
+SOCKET ConnectSocket = INVALID_SOCKET;
+struct addrinfo *result = NULL,
+*ptr = NULL,
+hints;
+char *sendbuf = done;
+char recvbuf[DEFAULT_BUFLEN];
+int iResult;
+int recvbuflen = DEFAULT_BUFLEN;
+
+// Validate the parameters
+if (argc != 2) {
+printf(usage: %s server-name\n, argv[0]);
+return 1;
+}
+
+// Initialize Winsock
+iResult = WSAStartup(MAKEWORD(2,2), wsaData);
+if (iResult != 0) {
+printf(WSAStartup failed: %d\n, iResult);
+return 1;
+}
+
+ZeroMemory( hints, sizeof(hints) );
+hints.ai_family = AF_UNSPEC;
+hints.ai_socktype = SOCK_STREAM;
+hints.ai_protocol = IPPROTO_TCP;
+
+// Resolve the server address and port
+iResult = getaddrinfo(argv[1], DEFAULT_PORT, hints, result);
+if ( iResult != 0 ) {
+printf(getaddrinfo failed: %d\n, iResult);
+WSACleanup();
+return 1;
+}
+
+// Attempt to connect to an address until one succeeds
+for(ptr=result; ptr != NULL ;ptr=ptr-ai_next) {
+
+// Create a SOCKET for connecting to server
+ConnectSocket = socket(ptr-ai_family, ptr-ai_socktype,
+ptr-ai_protocol);
+if (ConnectSocket == INVALID_SOCKET) {
+printf(Error at socket(): %ld\n, WSAGetLastError());
+freeaddrinfo(result);
+WSACleanup();
+return 1;
+}
+
+// Connect to server.
+iResult = connect( ConnectSocket, ptr-ai_addr, (int)ptr-ai_addrlen);
+if (iResult == SOCKET_ERROR) {
+closesocket(ConnectSocket);
+ConnectSocket = INVALID_SOCKET;
+continue;
+}
+break;
+}
+
+freeaddrinfo(result);
+
+if (ConnectSocket == INVALID_SOCKET) {
+printf(Unable to connect to server!\n);
+WSACleanup();
+return 1;
+}
+
+// Send the ACK buffer
+iResult = send( ConnectSocket, sendbuf, (int)strlen(sendbuf), 0 );
+if (iResult == SOCKET_ERROR) {
+printf(send failed: %d\n, WSAGetLastError());
+closesocket(ConnectSocket);
+WSACleanup();
+return 1;
+}
+
+printf(Bytes Sent: %ld\n, iResult);
+
+// shutdown the connection since no more data will be sent
+iResult = shutdown(ConnectSocket, SD_SEND);
+if (iResult == SOCKET_ERROR) {
+printf(shutdown failed: %d\n, WSAGetLastError());
+closesocket(ConnectSocket);
+WSACleanup();
+return 1;
+}
+
+// cleanup
+closesocket(ConnectSocket);
+WSACleanup();
+
+return 0;
+}
--
1.6.2.5
--
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 6/6] KVM test: kvm_tests.cfg.sample changes for unattended
In order to accomodate the unattended install test, some changes had to be made: * Now cd isos and md5 sum values don't belong only to the step file install only * introduced the needed variables for the unattended install test * Created 2 test sets, winxp_unattended and fc11_unattended. I am sure this change could get a very good cleanup, it is intended for people reviewing and testing this patchset. Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com --- client/tests/kvm/kvm_tests.cfg.sample | 126 +--- 1 files changed, 98 insertions(+), 28 deletions(-) diff --git a/client/tests/kvm/kvm_tests.cfg.sample b/client/tests/kvm/kvm_tests.cfg.sample index 7cd12cb..30d2e9a 100644 --- a/client/tests/kvm/kvm_tests.cfg.sample +++ b/client/tests/kvm/kvm_tests.cfg.sample @@ -44,6 +44,14 @@ variants: kill_vm_on_error = yes keep_screendump_history = yes +- unattended_install: +type = unattended_install +kill_vm_on_error = yes +force_create_image = yes +pre_command = scripts/unattended.py +floppy = floppy.img +extra_params = -boot d + - boot: install setup type = boot kill_vm_on_error = yes @@ -150,36 +158,74 @@ variants: - 8.32: no setup image_name = fc8-32 +cdrom = linux/Fedora-8-i386-DVD.iso +md5sum = dd6c79fddfff36d409d02242e7b10189 +md5sum_1m = dabae451bb69fbbad0e505b25144b1f9 install: steps = Fedora-8-i386.steps -cdrom = linux/Fedora-8-i386-DVD.iso -md5sum = dd6c79fddfff36d409d02242e7b10189 -md5sum_1m = dabae451bb69fbbad0e505b25144b1f9 - 8.64: no setup image_name = fc8-64 +cdrom = linux/Fedora-8-x86_64-DVD.iso +md5sum = 2cb231a86709dec413425fd2f8bf5295 +md5sum_1m = 145f6414e19492649a56c89f0a45e719 install: steps = Fedora-8-64.steps -cdrom = linux/Fedora-8-x86_64-DVD.iso -md5sum = 2cb231a86709dec413425fd2f8bf5295 -md5sum_1m = 145f6414e19492649a56c89f0a45e719 - 9.32: image_name = fc9-32 +cdrom = linux/Fedora-9-i386-DVD.iso +md5sum = 72601f685ea8c808c303353d8bf4d307 +md5sum_1m = f24fa25689e5863f1b99984c6feb787f install: steps = Fedora-9-i386.steps -cdrom = linux/Fedora-9-i386-DVD.iso -md5sum = 72601f685ea8c808c303353d8bf4d307 -md5sum_1m = f24fa25689e5863f1b99984c6feb787f - 9.64: image_name = fc9-64 +cdrom = linux/Fedora-9-x86_64-DVD.iso +md5sum = 05b2ebeed273ec54d6f9ed3d61ea4c96 +md5sum_1m = 9822ab5097e37e8fe306ef2192727db4 install: steps = Fedora-9-64.steps -cdrom = linux/Fedora-9-x86_64-DVD.iso -md5sum = 05b2ebeed273ec54d6f9ed3d61ea4c96 -md5sum_1m = 9822ab5097e37e8fe306ef2192727db4 + +- 10.32: +image_name = fc10-32 +cdrom = linux/Fedora-10-i386-DVD.iso +md5sum = 27e581edb392728c4a07d00d3fc5ced0 +md5sum_1m = bd67c68bdf595e4ba7131ec702159181 +install: +steps = +unattended_install: +tftp = tftpboot +extra_params = -bootp /pxelinux.0 -boot n +kernel_args = ks=floppy nicdelay=60 +unattended_file = unattended/Fedora-10.ks + +- 11.32: +image_name = fc11-32 +cdrom = linux/Fedora-11-i386-DVD.iso +md5sum = e3b1e2d1ba42aa4705fa5f41771b3927 +md5sum_1m = dc8ddf90648c247339c721395aa49714 +install: +steps = +unattended_install: +tftp = tftpboot +extra_params = -bootp /pxelinux.0 -boot n +kernel_args = ks=floppy nicdelay=60 +unattended_file = unattended/Fedora-11.ks + +- 11.64: +image_name
Re: KVM test: Unattended install support
- Lucas Meneghel Rodrigues l...@redhat.com wrote: This patchset introduces unattended install to autotest. This is a first-pass implementation for reviewers, and actually we don't have much else to say, except that we need to: * Create unattended install files for all our supported os (that will be a large task) * Implement simple templating system for answer files so we can replace the host IP address on the end stage, where the guest reports the end of installation to the host OS. It'll probably take me a little while to read all the code (there's a lot of it!) but let's start with the easy stuff: AFAIK the builtin tftp and bootp servers only work when using user mode networking, so we already know the host's address is 10.0.2.2. Another implication of this is that in kvm_tests.cfg we should specify 'nic_mode = user' for unattended install tests (the TAP patches make TAP the default mode). I would like to thank Yaniv Kaul, Michael Goldish, Eduardo Habkost for the ideas and help to resolve some nitty-gritty issues and for David Huff, who sent an initial implementation of this test. -- 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 -- 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: Bandwith limitation with KVM VMs
Hi Gregory. On Monday, 03 August 2009 12:52:28 -0400, Gregory Haskins wrote: I have a KVM VM that it has installed a MRTG on the network interface and that it doesn't register more than 10 Mbps, seeming that per moments it is saturated in this value. Has KVM some bandwidth limitation of the virtualized network interfaces? In such case, exists some way to increase that limitation? There is no set artificial limit afaict, though there are a large number of factors that can affect performance. Of course, everything has an ultimate ceiling (KVM included) but I have found this limit in KVM to be orders of magnitude faster than 10Mbps. Properly tuned, you should easily be able to saturate a GE link at line rate, or even 4Gbps-5Gpbs of a 10GE link. However, since you are only hitting 10Mb/s now, there is ton of headroom left even on upstream KVM so you might find it to be satisfactory as is, once you address the current bottleneck in your setup. Things to check: What linkspeed does the host see to the next hop? How much bandwidth does the host see to the same end-point? What is your overall topology, especially for the VM (are you using -net tap, etc). What MTU are you using. Etc. It draws attention that when executing 'cfgmaker' from MRTG server against the IP of the VM, it returns max speed of 1250 kBytes/s, that is to say 10 Mbps: sparky:~# /usr/bin/cfgmaker --global 'WorkDir: /tmp' --global \ 'Options[_]: bits,growright' xxx...@10.1.0.42 [...] MaxBytes[10.1.0.42_2]: 125 But nevertheless from within of the VM I see the following thing: aps2:~# ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 32 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: d Current message level: 0x0007 (7) Link detected: yes do you think that can give some indication? Thanks for your reply. Regards, Daniel -- Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37 Powered by Debian GNU/Linux Squeeze - Linux user #188.598 signature.asc Description: Digital signature
Re: [PATCH 6/6] KVM test: kvm_tests.cfg.sample changes for unattended
- Lucas Meneghel Rodrigues l...@redhat.com wrote: In order to accomodate the unattended install test, some changes had to be made: * Now cd isos and md5 sum values don't belong only to the step file install only * introduced the needed variables for the unattended install test * Created 2 test sets, winxp_unattended and fc11_unattended. I am sure this change could get a very good cleanup, it is intended for people reviewing and testing this patchset. Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com --- client/tests/kvm/kvm_tests.cfg.sample | 126 +--- 1 files changed, 98 insertions(+), 28 deletions(-) diff --git a/client/tests/kvm/kvm_tests.cfg.sample b/client/tests/kvm/kvm_tests.cfg.sample index 7cd12cb..30d2e9a 100644 --- a/client/tests/kvm/kvm_tests.cfg.sample +++ b/client/tests/kvm/kvm_tests.cfg.sample @@ -44,6 +44,14 @@ variants: kill_vm_on_error = yes keep_screendump_history = yes +- unattended_install: +type = unattended_install +kill_vm_on_error = yes +force_create_image = yes +pre_command = scripts/unattended.py +floppy = floppy.img +extra_params = -boot d + ^ You should add 'nic_mode = user' here, especially if you plan to apply the TAP patches before the unattended install patches. (The TAP patches make TAP the default mode.) If you don't, we can add the parameter later. - boot: install setup type = boot kill_vm_on_error = yes You might want to add unattended_install to the dependency list of the tests following it. If B depends on A it means 'skip B if A fails'. So if A isn't selected to run at all, B will run anyway. So if you run 'only unattended_install boot shutdown', boot and shutdown will run even though they also depend on the regular 'install'. So you can do something like: - boot: install setup unattended_install (and for all tests following boot too) The question is what happens when we run both install and unattended_install (when we want to test rendering and user interaction) and install fails. We shouldn't skip all tests for the guest in that case. I'll have to think about this a little. @@ -150,36 +158,74 @@ variants: - 8.32: no setup image_name = fc8-32 +cdrom = linux/Fedora-8-i386-DVD.iso +md5sum = dd6c79fddfff36d409d02242e7b10189 +md5sum_1m = dabae451bb69fbbad0e505b25144b1f9 install: steps = Fedora-8-i386.steps -cdrom = linux/Fedora-8-i386-DVD.iso -md5sum = dd6c79fddfff36d409d02242e7b10189 -md5sum_1m = dabae451bb69fbbad0e505b25144b1f9 - 8.64: no setup image_name = fc8-64 +cdrom = linux/Fedora-8-x86_64-DVD.iso +md5sum = 2cb231a86709dec413425fd2f8bf5295 +md5sum_1m = 145f6414e19492649a56c89f0a45e719 install: steps = Fedora-8-64.steps -cdrom = linux/Fedora-8-x86_64-DVD.iso -md5sum = 2cb231a86709dec413425fd2f8bf5295 -md5sum_1m = 145f6414e19492649a56c89f0a45e719 - 9.32: image_name = fc9-32 +cdrom = linux/Fedora-9-i386-DVD.iso +md5sum = 72601f685ea8c808c303353d8bf4d307 +md5sum_1m = f24fa25689e5863f1b99984c6feb787f install: steps = Fedora-9-i386.steps -cdrom = linux/Fedora-9-i386-DVD.iso -md5sum = 72601f685ea8c808c303353d8bf4d307 -md5sum_1m = f24fa25689e5863f1b99984c6feb787f - 9.64: image_name = fc9-64 +cdrom = linux/Fedora-9-x86_64-DVD.iso +md5sum = 05b2ebeed273ec54d6f9ed3d61ea4c96 +md5sum_1m = 9822ab5097e37e8fe306ef2192727db4 install: steps = Fedora-9-64.steps -cdrom = linux/Fedora-9-x86_64-DVD.iso -md5sum = 05b2ebeed273ec54d6f9ed3d61ea4c96 -md5sum_1m = 9822ab5097e37e8fe306ef2192727db4 + +- 10.32: +image_name = fc10-32 +cdrom = linux/Fedora-10-i386-DVD.iso +md5sum = 27e581edb392728c4a07d00d3fc5ced0 +md5sum_1m =
[ kvm-Bugs-2823765 ] about KVM-88 ?
Bugs item #2823765, was opened at 2009-07-19 01:59 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2823765group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: amd Group: None Status: Closed Resolution: None Priority: 5 Private: No Submitted By: z axis (sw2wolf) Assigned to: Nobody/Anonymous (nobody) Summary: about KVM-88 ? Initial Comment: $./configure --prefix=/usr/local --audio-drv-list=alsa oss --enable-mixemu $make $sudo make insatll WARNING: Loop detected: /lib/modules/2.6.30-ARCH/extra/kvm.ko which needs kvm.ko again! WARNING: Module /lib/modules/2.6.30-ARCH/extra/kvm.ko ignored, due to loop WARNING: Module /lib/modules/2.6.30-ARCH/extra/kvm-amd.ko ignored, due to loop WARNING: Module /lib/modules/2.6.30-ARCH/extra/kvm-intel.ko ignored, due to loop %sudo modprobe kvm-amd FATAL: Module kvm_amd not found. -- Comment By: SourceForge Robot (sf-robot) Date: 2009-08-04 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Marcelo Tosatti (mtosatti) Date: 2009-07-20 15:41 Message: sw2wolf, Please use the patch found at http://patchwork.kernel.org/patch/36141/ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2823765group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] KVM test: Introducing unattended install subtest
The test code looks nice and simple. However, I don't think putting some
of the code in a class helps much (it doesn't hurt either).
What do you think about this alternative, replacing from 'watcher = ...':
server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind(('', 12323))
server.listen(1)
end_time = time.time() + float(params.get(timeout, 3000))
while True:
server.settimeout(end_time - time.time())
try:
(client, addr) = server.accept()
except socket.timeout:
server.close()
raise error.TestFail('Timeout elapsed while waiting for install to '
'finish.')
msg = client.recv(1024)
logging.debug(Received '%s' from %s, msg, addr)
if msg == 'done':
logging.info('Guest reported successful installation')
server.close()
break
else:
logging.error('Got invalid string from client: %s.' % msg)
It's not necessarily shorter, but I find it a bit simpler.
The only meaningful difference here is the timeout handling.
In your original code, if a client sends anything other than 'done'
(very unlikely), the server will wait another 3000 secs.
With this code, the server will wait up to a total of 'timeout' secs
(user specified).
I find this code short and simple enough to leave outside a class,
but it's a matter of personal preference, so it's up to you.
- Original Message -
From: Lucas Meneghel Rodrigues l...@redhat.com
To: autot...@test.kernel.org
Cc: kvm@vger.kernel.org, dh...@redhat.com, Lucas Meneghel Rodrigues
l...@redhat.com
Sent: Tuesday, August 4, 2009 1:38:50 AM (GMT+0200) Auto-Detected
Subject: [PATCH 2/6] KVM test: Introducing unattended install subtest
In order to resolve the question, 'how will the guest
operating system tell the host operating system that
the unattended install process finish', we took the
simple approach and created a simple socket communication
ack process: The test instantiates a server tcp socket
on port 12323, and waits during a specified amount of time.
For guests, the vast majority of the unattended install
processes can deal with executing commands at the end of
the install process. Let's take advantage of that and
make clients tell the server about the end of the process
using simple programs that can do that. The implementation
of that strategy varies trough different operating systems.
This is the kvm test implementation code, client programs
will follow on later patches.
Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com
---
client/tests/kvm/kvm.py |2 +
client/tests/kvm/kvm_tests.py | 81 -
2 files changed, 82 insertions(+), 1 deletions(-)
diff --git a/client/tests/kvm/kvm.py b/client/tests/kvm/kvm.py
index 070e463..db6899b 100644
--- a/client/tests/kvm/kvm.py
+++ b/client/tests/kvm/kvm.py
@@ -56,6 +56,8 @@ class kvm(test.test):
linux_s3: test_routine(kvm_tests, run_linux_s3),
stress_boot: test_routine(kvm_tests, run_stress_boot),
timedrift:test_routine(kvm_tests, run_timedrift),
+unattended_install: test_routine(kvm_tests,
+run_unattended_install),
}
# Make it possible to import modules from the test's bindir
diff --git a/client/tests/kvm/kvm_tests.py b/client/tests/kvm/kvm_tests.py
index 9784ec9..f45fefc 100644
--- a/client/tests/kvm/kvm_tests.py
+++ b/client/tests/kvm/kvm_tests.py
@@ -1,4 +1,4 @@
-import time, os, logging, re, commands
+import time, os, logging, re, commands, socket
from autotest_lib.client.common_lib import utils, error
import kvm_utils, kvm_subprocess, ppm_utils, scan_results
@@ -9,6 +9,85 @@ KVM test definitions.
+class UnattendedInstallWatcher:
+
+Mechanism to verify whether an unattended guest install actually did
finish.
+It opens a TCP socket and waits until it receives a message. If it does get
+the expected message from the guest, it will finish gracefully.
+
+def __init__(self, timeout, msg):
+self.port = 12323
+self.buf_size = 1024
+self.timeout = timeout
+self.msg = msg
+
+
+def check_answer(self, connection):
+
+Verify if client has sent the correct ACK message.
+
+@param connection: Tuple with client socket connection and address.
+@return: True, in case the client has responded accordingly; False if
+the string doesn't match the server expectations.
+
+(client, addr) = connection
+msg = client.recv(self.buf_size)
+logging.debug(Received '%s' from %s, msg, addr)
+if msg == self.msg:
+logging.info('Guest reported successful installation')
+return True
+else:
+logging.error('Got invalid string from client: %s.' % msg)
+return False
+
+
+def run_server(self):
+
+
Re: Bandwith limitation with KVM VMs
Daniel Bareiro wrote: Hi Gregory. On Monday, 03 August 2009 12:52:28 -0400, Gregory Haskins wrote: I have a KVM VM that it has installed a MRTG on the network interface and that it doesn't register more than 10 Mbps, seeming that per moments it is saturated in this value. Has KVM some bandwidth limitation of the virtualized network interfaces? In such case, exists some way to increase that limitation? There is no set artificial limit afaict, though there are a large number of factors that can affect performance. Of course, everything has an ultimate ceiling (KVM included) but I have found this limit in KVM to be orders of magnitude faster than 10Mbps. Properly tuned, you should easily be able to saturate a GE link at line rate, or even 4Gbps-5Gpbs of a 10GE link. However, since you are only hitting 10Mb/s now, there is ton of headroom left even on upstream KVM so you might find it to be satisfactory as is, once you address the current bottleneck in your setup. Things to check: What linkspeed does the host see to the next hop? How much bandwidth does the host see to the same end-point? What is your overall topology, especially for the VM (are you using -net tap, etc). What MTU are you using. Etc. It draws attention that when executing 'cfgmaker' from MRTG server against the IP of the VM, it returns max speed of 1250 kBytes/s, that is to say 10 Mbps: sparky:~# /usr/bin/cfgmaker --global 'WorkDir: /tmp' --global \ 'Options[_]: bits,growright' xxx...@10.1.0.42 [...] MaxBytes[10.1.0.42_2]: 125 But nevertheless from within of the VM I see the following thing: aps2:~# ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 32 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: d Current message level: 0x0007 (7) Link detected: yes do you think that can give some indication? Hmm.. I am not familiar with MRTG/cfgmaker, but from your ethtool output I suspect you are not using virtio. How do you launch the guest? Have you actually run something like netperf or an rsync to see what type of bandwidth you actually get? Perhaps this is just the mrtg tool getting confused about the actual interface capabilities. -Greg signature.asc Description: OpenPGP digital signature
Re: [PATCH] Add a subtest pci_hotplug in kvm test
On Mon, Aug 03, 2009 at 02:37:29PM +0300, Dor Laor wrote: On 08/03/2009 12:19 PM, Yolkfull Chow wrote: On 06/30/2009 09:58 PM, Dor Laor wrote: On 06/30/2009 02:11 PM, Yolkfull Chow wrote: Signed-off-by: Yolkfull Chowyz...@redhat.com --- client/tests/kvm/kvm.py | 1 + client/tests/kvm/kvm_tests.cfg.sample | 56 client/tests/kvm/kvm_tests.py | 93 + client/tests/kvm/kvm_vm.py | 2 + 4 files changed, 152 insertions(+), 0 deletions(-) diff --git a/client/tests/kvm/kvm.py b/client/tests/kvm/kvm.py index 4c7bae4..4fbce5b 100644 --- a/client/tests/kvm/kvm.py +++ b/client/tests/kvm/kvm.py @@ -55,6 +55,7 @@ class kvm(test.test): kvm_install: test_routine(kvm_install, run_kvm_install), linux_s3: test_routine(kvm_tests, run_linux_s3), stress_boot: test_routine(kvm_tests, run_stress_boot), + pci_hotplug: test_routine(kvm_tests, run_pci_hotplug), Cool! It's very good since it tends to break. } # Make it possible to import modules from the test's bindir diff --git a/client/tests/kvm/kvm_tests.cfg.sample b/client/tests/kvm/kvm_tests.cfg.sample index 2f864de..50b5765 100644 --- a/client/tests/kvm/kvm_tests.cfg.sample +++ b/client/tests/kvm/kvm_tests.cfg.sample @@ -94,6 +94,52 @@ variants: max_vms = 5 alive_test_cmd = ps aux + + - nic_hotplug: + type = pci_hotplug + pci_type = nic + modprobe_acpiphp = yes + reference_cmd = lspci + find_pci_cmd = 'lspci | tail -n1' + pci_test_cmd = 'nslookup www.redhat.com' + variants: + - @nic_8139: + pci_model = rtl8139 + match_string = 8139 + - nic_virtio: + pci_model = virtio + match_string = Virtio network device + - nic_e1000: + pci_model = e1000 + match_string = Gigabit Ethernet Controller + + - block_hotplug: + type = pci_hotplug + pci_type = block + modprobe_acpiphp = yes + reference_cmd = lspci + find_pci_cmd = 'lspci | tail -n1' + images += stg + boot_drive_stg = no + image_name_stg = storage + image_size = 1G + force_create_image_stg = yes + pci_test_cmd = 'dir' + no Windows + variants: + - block_virtio: + pci_model = virtio + match_string = Virtio block device + - block_scsi: + pci_model = scsi + match_string = SCSI storage controller + variants: There is no need to test qcow2/raw here since it shouldn't matter. You can test qcow2 only, it is enough. Hi Glauber, according to Dor's comments on this, I did some testing and got an interesting result for block_hotplug: 1) hotplug storage of raw + SCSI will always fail on Windows 2) hotplug storage of Raw + Virtio will always fail on Fedora 3) hotplug storage with image format Raw will also fail often on RHEL Does block_hotplug relate to image format? Would you give me any clue on this? It shouldn't matter. In case the test is sensitive for timeout, it might. Can you describe what's working and what's not on each combination? As for scsi, it is not reliable so it might be scsi's fault. Can you provide the fdisk -l ouput on Fedora when it is not working? From the test below, there is not time/event for letting the guest hook up the new block device. Maybe you need to do several retries in a loop or check a real event in the guest (better one) I can make sure now there is a bug in block hotplug feature since segfault has been found in dmesg on my laptop Fedora. Also, both guest RHEL.5.3-i386 and Windows 2008 have crashed during running block_hotplug test. For example, for Windows 2008-32 guest, sometimes issue command 'systeminfo' during block_hotplug can crash the guest. I had added a loop wait for the PCI device hooked up, before this, I used sleep(some_seconds) wait for module installed. Thanks in advance. + - fmt_qcow2: + image_format_stg = qcow2 + - fmt_raw: + image_format_stg = raw + + # NICs variants: - @rtl8139: @@ -306,6 +352,12 @@ variants: migration_test_command = ver vol stress_boot: alive_test_cmd = systeminfo + nic_hotplug: + modprobe_acpiphp = no + reference_cmd = systeminfo + find_pci_cmd = ipconfig /all | find Description + nic_e1000: + match_string = Intel(R) PRO/1000 MT Network Connection variants: - Win2000: @@ -530,6 +582,10 @@ virtio|virtio_blk|e1000: only Fedora.9 openSUSE-11 Ubuntu-8.10-server +nic_hotplug.nic_virtio|block_hotplug: + no Windows + + variants: - @qcow2: image_format = qcow2 diff --git a/client/tests/kvm/kvm_tests.py b/client/tests/kvm/kvm_tests.py index 2d11fed..21280b9 100644 --- a/client/tests/kvm/kvm_tests.py +++ b/client/tests/kvm/kvm_tests.py @@ -585,3 +585,96 @@ def run_stress_boot(tests, params, env): for se in sessions: se.close() logging.info(Total number booted: %d % (num -1)) + + +def run_pci_hotplug(test, params, env): + + Test pci devices' hotplug + 1) pci_add a deivce (nic or storage) + 2) Compare 'info pci' output + 3) Compare $reference_cmd output + 4) Verify whether pci_model is shown in $pci_find_cmd + 5) pci_del the device, verify whether could remove the pci
[AUTOTEST]telnet login fails in win2k8 DC 64. here are debug and other info
Hi, I am seeing a telnet failure in autotest to a win2k8 DC 64 bit guest. I have tried some debugging and came to a conclusion that read_nonblocking() is reading only 3 lines. let me first print the output of manual login # telnet -l Administrator 10.0.99.100 23 Trying 10.0.99.100... Connected to ichigo-dom100.linuxperf9025.net (10.0.99.100). Escape character is '^]'. Welcome to Microsoft Telnet Service password: *=== Microsoft Telnet Server. *=== C:\Users\Administrator Now autotest only reads the first 3 lines(upto Escape.). It seems windows is doing something nasty here. I have put some debug prints in the code and here is the output. let me first put the code snippet from kvm_utils.py with added debug prints. def read_until_output_matches(self, patterns, filter=lambda(x):x, timeout=30.0, internal_timeout=3.0, print_func=None): snip end_time = time.time() + timeout while time.time() end_time: # Read data from child newdata = self.read_nonblocking(internal_timeout) print(DEBUG: Printing data read by read_nonblocking from output:) print(DEBUG: data read from output is %s % newdata) print(DEBUG: Printing data read by read_nonblocking from output done.) # Print it if necessary if print_func and newdata: map(print_func, newdata.splitlines()) data += newdata print(DEBUG: Printing accumulated data read from output:) print(DEBUG: accumulated data read from output is %s % data) print(DEBUG: Printing accumulated data read from output done.) done = False # Look for patterns print(DEBUG: Printing data after filter:) print(DEBUG: filtered data is %s % filter(data)) print(DEBUG: Printing data after filter done:) match = self.match_patterns(filter(data), patterns) if match != None: done = True # Check if child has died if self.poll() != None: logging.debug(Process terminated with status %d, self.poll()) done = True # Are we done? if done: break snip Here is the output once the guest comes up. 12:27:25 INFO | DEBUG: Printing data read by read_nonblocking from output: 12:27:25 INFO | DEBUG: data read from output is Trying 10.0.99.100... 12:27:25 INFO | Connected to ichigo-dom100.linuxperf9025.net (10.0.99.100). 12:27:25 INFO | Escape character is '^]'. 12:27:25 INFO | 12:27:25 INFO | DEBUG: Printing data read by read_nonblocking from output done. 12:27:25 INFO | DEBUG: Printing accumulated data read from output: 12:27:25 INFO | DEBUG: accumulated data read from output is Trying 10.0.99.100... 12:27:25 INFO | Connected to ichigo-dom100.linuxperf9025.net (10.0.99.100). 12:27:25 INFO | Escape character is '^]'. 12:27:25 INFO | 12:27:25 INFO | DEBUG: Printing accumulated data read from output done. 12:27:25 INFO | DEBUG: Printing data after filter: 12:27:25 INFO | DEBUG: filtered data is Escape character is '^]'. 12:27:25 INFO | DEBUG: Printing data after filter done: 12:27:29 INFO | DEBUG: Printing data read by read_nonblocking from output: 12:27:29 INFO | DEBUG: data read from output is 12:27:29 INFO | DEBUG: Printing data read by read_nonblocking from output done. 12:27:29 INFO | DEBUG: Printing accumulated data read from output: 12:27:29 INFO | DEBUG: accumulated data read from output is Trying 10.0.99.100... 12:27:29 INFO | Connected to ichigo-dom100.linuxperf9025.net (10.0.99.100). 12:27:29 INFO | Escape character is '^]'. 12:27:29 INFO | 12:27:29 INFO | DEBUG: Printing accumulated data read from output done. 12:27:29 INFO | DEBUG: Printing data after filter: 12:27:29 INFO | DEBUG: filtered data is Escape character is '^]'. 12:27:29 INFO | DEBUG: Printing data after filter done: and so on... timeout elapses and test fails. I am not able to find out why read_nonblocking() is reading only 3 lines. I have tried increasing the timeouts and internal_timeouts as well. But no luck. Here is how my kvm_tests.cfg looks like. # colorful prompt, so migration_test_command will fail, try with telnet ssh_prompt = C:\Users\Administrator ssh_port = 23 use_telnet = yes Any clues ? -- Sudhir Kumar -- 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]telnet login fails in win2k8 DC 64. here are debug and other info
Looks like there really are only 3 lines to read. Telnet is printing those lines, not windows. It's just indicating that it successfully connected. Windows is saying nothing. This is a little weird, because: - It can happen when the telnet server isn't running at all, but it seemed to be running fine when you connected manually. - It can happen when trying to connect to the wrong port, but I see you set the port to 23. It can also happen due to the short default timeout of 10 seconds. Windows can take longer than that to send something. Are you sure you increased the timeout? You only sent a log of 4 seconds (starting at 12:27:25). How long does read_until_output_matches() wait before it gives up? - Original Message - From: sudhir kumar smalik...@gmail.com To: kvm-devel kvm@vger.kernel.org Cc: Lucas Meneghel Rodrigues mrodr...@redhat.com, Michael Goldish mgold...@redhat.com, Ryan Harper ry...@us.ibm.com Sent: Tuesday, August 4, 2009 8:06:32 AM (GMT+0200) Auto-Detected Subject: [AUTOTEST]telnet login fails in win2k8 DC 64. here are debug and other info Hi, I am seeing a telnet failure in autotest to a win2k8 DC 64 bit guest. I have tried some debugging and came to a conclusion that read_nonblocking() is reading only 3 lines. let me first print the output of manual login # telnet -l Administrator 10.0.99.100 23 Trying 10.0.99.100... Connected to ichigo-dom100.linuxperf9025.net (10.0.99.100). Escape character is '^]'. Welcome to Microsoft Telnet Service password: *=== Microsoft Telnet Server. *=== C:\Users\Administrator Now autotest only reads the first 3 lines(upto Escape.). It seems windows is doing something nasty here. I have put some debug prints in the code and here is the output. let me first put the code snippet from kvm_utils.py with added debug prints. def read_until_output_matches(self, patterns, filter=lambda(x):x, timeout=30.0, internal_timeout=3.0, print_func=None): snip end_time = time.time() + timeout while time.time() end_time: # Read data from child newdata = self.read_nonblocking(internal_timeout) print(DEBUG: Printing data read by read_nonblocking from output:) print(DEBUG: data read from output is %s % newdata) print(DEBUG: Printing data read by read_nonblocking from output done.) # Print it if necessary if print_func and newdata: map(print_func, newdata.splitlines()) data += newdata print(DEBUG: Printing accumulated data read from output:) print(DEBUG: accumulated data read from output is %s % data) print(DEBUG: Printing accumulated data read from output done.) done = False # Look for patterns print(DEBUG: Printing data after filter:) print(DEBUG: filtered data is %s % filter(data)) print(DEBUG: Printing data after filter done:) match = self.match_patterns(filter(data), patterns) if match != None: done = True # Check if child has died if self.poll() != None: logging.debug(Process terminated with status %d, self.poll()) done = True # Are we done? if done: break snip Here is the output once the guest comes up. 12:27:25 INFO | DEBUG: Printing data read by read_nonblocking from output: 12:27:25 INFO | DEBUG: data read from output is Trying 10.0.99.100... 12:27:25 INFO | Connected to ichigo-dom100.linuxperf9025.net (10.0.99.100). 12:27:25 INFO | Escape character is '^]'. 12:27:25 INFO | 12:27:25 INFO | DEBUG: Printing data read by read_nonblocking from output done. 12:27:25 INFO | DEBUG: Printing accumulated data read from output: 12:27:25 INFO | DEBUG: accumulated data read from output is Trying 10.0.99.100... 12:27:25 INFO | Connected to ichigo-dom100.linuxperf9025.net (10.0.99.100). 12:27:25 INFO | Escape character is '^]'. 12:27:25 INFO | 12:27:25 INFO | DEBUG: Printing accumulated data read from output done. 12:27:25 INFO | DEBUG: Printing data after filter: 12:27:25 INFO | DEBUG: filtered data is Escape character is '^]'. 12:27:25 INFO | DEBUG: Printing data after filter done: 12:27:29 INFO | DEBUG: Printing data read by read_nonblocking from output: 12:27:29 INFO | DEBUG: data read from output is 12:27:29 INFO | DEBUG: Printing data read by read_nonblocking from output done. 12:27:29 INFO | DEBUG: Printing accumulated data read from output: 12:27:29 INFO | DEBUG: accumulated data read from output is Trying 10.0.99.100... 12:27:29 INFO | Connected to ichigo-dom100.linuxperf9025.net (10.0.99.100). 12:27:29 INFO | Escape character is '^]'. 12:27:29 INFO | 12:27:29 INFO | DEBUG: Printing accumulated data read from output done.
[PATCH v2 0/5] kvmppc: Add guest debug support
This patchset add guest debug support for BOOKE. patch 1: fix current e500 broken patch 2: guest debug definitions patch 3: switch shadow/host debug register on guest enter/exit path patch 4: guest debug support patch 5: exitnr fixup in single step mode [v2] 1. move code from 2.6.30 to current head 2. move the debug registers updating code to guest enter/exit path 3. some cleanup. -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] Fix the trace broken for e500 kvm
Remove the broken trace. Will get them cleanup in future. Signed-off-by: Liu Yu yu@freescale.com --- arch/powerpc/kvm/e500_tlb.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kvm/e500_tlb.c b/arch/powerpc/kvm/e500_tlb.c index fb1e1dc..a344be6 100644 --- a/arch/powerpc/kvm/e500_tlb.c +++ b/arch/powerpc/kvm/e500_tlb.c @@ -225,8 +225,6 @@ static void kvmppc_e500_stlbe_invalidate(struct kvmppc_vcpu_e500 *vcpu_e500, kvmppc_e500_shadow_release(vcpu_e500, tlbsel, esel); stlbe-mas1 = 0; - trace_kvm_stlb_inval(index_of(tlbsel, esel), stlbe-mas1, stlbe-mas2, -stlbe-mas3, stlbe-mas7); } static void kvmppc_e500_tlb1_invalidate(struct kvmppc_vcpu_e500 *vcpu_e500, -- 1.5.4 -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] kvmppc guest debug definitions
Signed-off-by: Liu Yu yu@freescale.com
---
arch/powerpc/include/asm/kvm.h | 20
arch/powerpc/include/asm/kvm_host.h | 18 ++
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index bb2de6a..804df17 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -22,6 +22,9 @@
#include linux/types.h
+/* Select powerpc specific features in linux/kvm.h */
+#define __KVM_HAVE_GUEST_DEBUG
+
struct kvm_regs {
__u64 pc;
__u64 cr;
@@ -53,10 +56,27 @@ struct kvm_fpu {
};
struct kvm_debug_exit_arch {
+ __u32 exception;
+ __u32 pc;
+ __u32 status;
};
+#define KVM_INST_GUESTGDB 0x4422
+
+#define KVM_GUESTDBG_USE_SW_BP 0x0001
+#define KVM_GUESTDBG_USE_HW_BP 0x0002
+
+#define KVMPPC_DEBUG_NOTYPE 0x0
+#define KVMPPC_DEBUG_BREAKPOINT (1UL 1)
+#define KVMPPC_DEBUG_WATCH_WRITE(1UL 2)
+#define KVMPPC_DEBUG_WATCH_READ (1UL 3)
+
/* for KVM_SET_GUEST_DEBUG */
struct kvm_guest_debug_arch {
+ struct {
+ __u32 addr;
+ __u32 type;
+ } bp[6];
};
#endif /* __LINUX_KVM_POWERPC_H */
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index c9c930e..6caabfc 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -109,9 +109,22 @@ struct kvmppc_exit_timing {
struct kvm_arch {
};
+struct kvmppc_debug_reg {
+ u32 dbcr0;
+ u32 iac[0];
+ u32 iac1;
+ u32 iac2;
+ u32 iac3;
+ u32 iac4;
+ u32 dac[0];
+ u32 dac1;
+ u32 dac2;
+};
+
struct kvm_vcpu_arch {
u32 host_stack;
u32 host_pid;
+ u32 host_msr;
u64 fpr[32];
ulong gpr[32];
@@ -160,6 +173,10 @@ struct kvm_vcpu_arch {
u32 dbcr1;
u32 dbsr;
+ struct kvmppc_debug_reg shadow_dbg_reg;
+ struct kvmppc_debug_reg host_dbg_reg;
+ bool has_load_host_dbg;
+
#ifdef CONFIG_KVM_EXIT_TIMING
struct kvmppc_exit_timing timing_exit;
struct kvmppc_exit_timing timing_last_enter;
@@ -187,6 +204,7 @@ struct kvm_vcpu_arch {
struct timer_list dec_timer;
unsigned long pending_exceptions;
+ struct kvm_guest_debug_arch dbg;
};
#endif /* __POWERPC_KVM_HOST_H__ */
--
1.5.4
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] Switch shadow/host debug registers on guest enter/exit path
So that we don't give any chance for host to trigger the debug event. Also the debug ability in guest can be implemented based on this. Signed-off-by: Liu Yu yu@freescale.com --- arch/powerpc/kernel/asm-offsets.c |3 ++ arch/powerpc/kvm/booke_interrupts.S | 58 +++ 2 files changed, 61 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c index 561b646..643ee15 100644 --- a/arch/powerpc/kernel/asm-offsets.c +++ b/arch/powerpc/kernel/asm-offsets.c @@ -379,6 +379,9 @@ int main(void) DEFINE(VCPU_LAST_INST, offsetof(struct kvm_vcpu, arch.last_inst)); DEFINE(VCPU_FAULT_DEAR, offsetof(struct kvm_vcpu, arch.fault_dear)); DEFINE(VCPU_FAULT_ESR, offsetof(struct kvm_vcpu, arch.fault_esr)); + DEFINE(VCPU_SHADOW_DBG, offsetof(struct kvm_vcpu, arch.shadow_dbg_reg)); + DEFINE(VCPU_HOST_DBG, offsetof(struct kvm_vcpu, arch.host_dbg_reg)); + DEFINE(VCPU_GUEST_DEBUG, offsetof(struct kvm_vcpu, guest_debug)); #endif #ifdef CONFIG_44x DEFINE(PGD_T_LOG2, PGD_T_LOG2); diff --git a/arch/powerpc/kvm/booke_interrupts.S b/arch/powerpc/kvm/booke_interrupts.S index d0c6f84..52592fe 100644 --- a/arch/powerpc/kvm/booke_interrupts.S +++ b/arch/powerpc/kvm/booke_interrupts.S @@ -168,6 +168,26 @@ _GLOBAL(kvmppc_resume_host) stw r9, VCPU_FAULT_ESR(r4) ..skip_esr: + lwz r6, VCPU_GUEST_DEBUG(r4) + or. r6, r6, r6 + beq ..skip_host_debug + addir7, r4, VCPU_HOST_DBG - 4 + lwzur9, 4(r7) + mtspr SPRN_DBCR0, r9 + lwzur9, 4(r7) + mtspr SPRN_IAC1, r9 + lwzur9, 4(r7) + mtspr SPRN_IAC2, r9 + lwzur9, 4(r7) + mtspr SPRN_IAC3, r9 + lwzur9, 4(r7) + mtspr SPRN_IAC4, r9 + lwzur9, 4(r7) + mtspr SPRN_DAC1, r9 + lwzur9, 4(r7) + mtspr SPRN_DAC2, r9 +..skip_host_debug: + /* Save remaining volatile guest register state to vcpu. */ stw r0, VCPU_GPR(r0)(r4) stw r1, VCPU_GPR(r1)(r4) @@ -392,6 +412,44 @@ lightweight_exit: lwz r3, VCPU_SPRG7(r4) mtspr SPRN_SPRG7, r3 + lwz r6, VCPU_GUEST_DEBUG(r4) + or. r6, r6, r6 + beq ..skip_guest_debug + mfmsr r7 + rlwinm r7, r7, 0, ~MSR_DE + mtmsr r7 + addir7, r4, VCPU_HOST_DBG - 4 + mfspr r8, SPRN_DBCR0 + stwur8, 4(r7) + mfspr r8, SPRN_IAC1 + stwur8, 4(r7) + mfspr r8, SPRN_IAC2 + stwur8, 4(r7) + mfspr r8, SPRN_IAC3 + stwur8, 4(r7) + mfspr r8, SPRN_IAC4 + stwur8, 4(r7) + mfspr r8, SPRN_DAC1 + stwur8, 4(r7) + mfspr r8, SPRN_DAC2 + stwur8, 4(r7) + addir7, r4, VCPU_SHADOW_DBG - 4 + lwzur8, 4(r7) + mtspr SPRN_DBCR0, r8 + lwzur8, 4(r7) + mtspr SPRN_IAC1, r8 + lwzur8, 4(r7) + mtspr SPRN_IAC2, r8 + lwzur8, 4(r7) + mtspr SPRN_IAC3, r8 + lwzur8, 4(r7) + mtspr SPRN_IAC4, r8 + lwzur8, 4(r7) + mtspr SPRN_DAC1, r8 + lwzur8, 4(r7) + mtspr SPRN_DAC2, r8 +..skip_guest_debug: + #ifdef CONFIG_KVM_EXIT_TIMING /* save enter time */ 1: -- 1.5.4 -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] kvmppc guest debug support
Signed-off-by: Liu Yu yu@freescale.com
---
arch/powerpc/include/asm/kvm_ppc.h |5 ++
arch/powerpc/kvm/booke.c | 97 ++--
arch/powerpc/kvm/e500.c|8 ---
arch/powerpc/kvm/powerpc.c |2 +-
4 files changed, 99 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index 2c6ee34..4f3656b 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -89,6 +89,11 @@ extern int kvmppc_core_emulate_op(struct kvm_run *run,
struct kvm_vcpu *vcpu,
extern int kvmppc_core_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, int rs);
extern int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn, int rt);
+extern void kvmppc_core_load_host_debugstate(struct kvm_vcpu *vcpu);
+extern void kvmppc_core_load_guest_debugstate(struct kvm_vcpu *vcpu);
+extern int kvmppc_core_set_guest_debug(struct kvm_vcpu *vcpu,
+ struct kvm_guest_debug *dbg);
+
extern int kvmppc_booke_init(void);
extern void kvmppc_booke_exit(void);
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index e7bf4d0..4e7954f 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -16,6 +16,9 @@
*
* Authors: Hollis Blanchard holl...@us.ibm.com
* Christian Ehrhardt ehrha...@linux.vnet.ibm.com
+ *
+ * Copyright (C) 2009 Freescale Semiconductor, Inc. All rights reserved.
+ * Yu Liu yu@freescale.com
*/
#include linux/errno.h
@@ -230,6 +233,16 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
kvm_vcpu *vcpu,
break;
}
+ if (unlikely(vcpu-guest_debug KVM_GUESTDBG_ENABLE)
+(vcpu-arch.last_inst == KVM_INST_GUESTGDB)) {
+ run-exit_reason = KVM_EXIT_DEBUG;
+ run-debug.arch.pc = vcpu-arch.pc;
+ run-debug.arch.exception = exit_nr;
+ kvmppc_account_exit(vcpu, DEBUG_EXITS);
+ r = RESUME_HOST;
+ break;
+ }
+
er = kvmppc_emulate_instruction(run, vcpu);
switch (er) {
case EMULATE_DONE:
@@ -256,6 +269,12 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
kvm_vcpu *vcpu,
default:
BUG();
}
+
+ if (unlikely(vcpu-guest_debug KVM_GUESTDBG_ENABLE)
+ (vcpu-guest_debug KVM_GUESTDBG_SINGLESTEP)) {
+ run-exit_reason = KVM_EXIT_DEBUG;
+ r = RESUME_HOST;
+ }
break;
case BOOKE_INTERRUPT_FP_UNAVAIL:
@@ -386,12 +405,27 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
kvm_vcpu *vcpu,
u32 dbsr;
vcpu-arch.pc = mfspr(SPRN_CSRR0);
-
- /* clear IAC events in DBSR register */
dbsr = mfspr(SPRN_DBSR);
- dbsr = DBSR_IAC1 | DBSR_IAC2 | DBSR_IAC3 | DBSR_IAC4;
- mtspr(SPRN_DBSR, dbsr);
+ run-debug.arch.pc = vcpu-arch.pc;
+ run-debug.arch.status = 0;
+
+ if (dbsr (DBSR_IAC1 | DBSR_IAC2 | DBSR_IAC3 | DBSR_IAC4)) {
+ run-debug.arch.status |= KVMPPC_DEBUG_BREAKPOINT;
+ } else {
+ if (dbsr (DBSR_DAC1W | DBSR_DAC2W))
+ run-debug.arch.status |=
KVMPPC_DEBUG_WATCH_WRITE;
+ else if (dbsr (DBSR_DAC1R | DBSR_DAC2R))
+ run-debug.arch.status |=
KVMPPC_DEBUG_WATCH_READ;
+ if (dbsr (DBSR_DAC1R | DBSR_DAC1W))
+ run-debug.arch.pc =
vcpu-arch.shadow_dbg_reg.dac1;
+ else if (dbsr (DBSR_DAC2R | DBSR_DAC2W))
+ run-debug.arch.pc =
vcpu-arch.shadow_dbg_reg.dac2;
+ }
+ /* clear events in DBSR register */
+ mtspr(SPRN_DBSR, ~0);
+
+ run-debug.arch.exception = exit_nr;
run-exit_reason = KVM_EXIT_DEBUG;
kvmppc_account_exit(vcpu, DEBUG_EXITS);
r = RESUME_HOST;
@@ -463,6 +497,7 @@ int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu,
struct kvm_regs *regs)
for (i = 0; i ARRAY_SIZE(regs-gpr); i++)
regs-gpr[i] = vcpu-arch.gpr[i];
+
return 0;
}
@@ -520,6 +555,60 @@ int kvm_arch_vcpu_ioctl_translate(struct kvm_vcpu *vcpu,
return kvmppc_core_vcpu_translate(vcpu, tr);
}
+int kvmppc_core_set_guest_debug(struct kvm_vcpu *vcpu,
+struct kvm_guest_debug *dbg)
+{
+ if (!(dbg-control KVM_GUESTDBG_ENABLE)) {
+ vcpu-guest_debug = 0;
+ return 0;
+ }
+
+ vcpu-guest_debug = dbg-control;
+
[PATCH 5/5] kvmppc: exit_nr fixup for guest debug single step
As BOOKE doesn't have hardware support for virtualization,
hardware never know guest and host.
So when enable hardware single step for guest,
it cannot be disabled timely if guest want to exit.
Thus, we'll see that an single step interrupt happens at
the beginning of guest exit path.
Then we need to recognize this kind of single step interrupt
and fix the exit_nr to the corret value.
Signed-off-by: Liu Yu yu@freescale.com
---
arch/powerpc/kvm/booke.c| 82 +++
arch/powerpc/kvm/booke_interrupts.S |9 ++--
2 files changed, 87 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 4e7954f..d3cfd85 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -27,6 +27,7 @@
#include linux/module.h
#include linux/vmalloc.h
#include linux/fs.h
+#include linux/highmem.h
#include asm/cputable.h
#include asm/uaccess.h
@@ -37,6 +38,8 @@
#include booke.h
unsigned long kvmppc_booke_handlers;
+unsigned long kvmppc_booke_handler_addr[16];
+#define handler_vector_num
(sizeof(kvmppc_booke_handler_addr)/sizeof(kvmppc_booke_handler_addr[0]))
#define VM_STAT(x) offsetof(struct kvm, stat.x), KVM_STAT_VM
#define VCPU_STAT(x) offsetof(struct kvm_vcpu, stat.x), KVM_STAT_VCPU
@@ -179,6 +182,80 @@ void kvmppc_core_deliver_interrupts(struct kvm_vcpu *vcpu)
}
}
+int kvmppc_read_guest(struct kvm_vcpu *vcpu, unsigned long geaddr,
+ void *data, int len)
+{
+ int gtlb_index;
+ gpa_t gpa;
+ gfn_t gfn;
+ struct page *page;
+ void *headdr, *from;
+
+ /* Check the guest TLB. */
+ gtlb_index = kvmppc_mmu_itlb_index(vcpu, geaddr);
+ if (gtlb_index 0)
+ return -EFAULT;
+
+ gpa = kvmppc_mmu_xlate(vcpu, gtlb_index, geaddr);
+ gfn = gpa PAGE_SHIFT;
+
+ page = gfn_to_page(vcpu-kvm, gfn);
+ if (page == bad_page)
+ return -EFAULT;
+
+ headdr = kmap_atomic(page, KM_USER0);
+ if (!headdr)
+ return -EFAULT;
+ from = headdr + (geaddr (PAGE_SIZE - 1));
+ memcpy(data, from, len);
+ kunmap_atomic(headdr, KM_USER0);
+
+ return 0;
+}
+
+static unsigned int kvmppc_guest_debug_exit_fixup(struct kvm_vcpu *vcpu,
+ unsigned int exit_nr)
+{
+ unsigned int ret = exit_nr;
+
+ u32 csrr0 = mfspr(SPRN_CSRR0);
+ u32 dbsr = mfspr(SPRN_DBSR);
+
+ if ((dbsr | DBSR_IC)
+ csrr0 = kvmppc_booke_handlers
+ csrr0 kvmppc_booke_handlers + (PAGE_SIZE VCPU_SIZE_ORDER)) {
+ int i = 0;
+
+ for (i = 0; i handler_vector_num; i++) {
+ if (kvmppc_booke_handler_addr[i]
+ csrr0 == kvmppc_booke_handler_addr[i] + 4) {
+ mtspr(SPRN_DBSR, ~0);
+ ret = i;
+ break;
+ }
+ }
+
+ }
+
+ switch (ret) {
+ case BOOKE_INTERRUPT_DEBUG:
+ case BOOKE_INTERRUPT_ITLB_MISS:
+ case BOOKE_INTERRUPT_EXTERNAL:
+ case BOOKE_INTERRUPT_DECREMENTER:
+ break;
+
+ case BOOKE_INTERRUPT_PROGRAM:
+ case BOOKE_INTERRUPT_DTLB_MISS:
+ /* Need to save the last instruction */
+ kvmppc_read_guest(vcpu, vcpu-arch.pc, vcpu-arch.last_inst,
4);
+ break;
+ default:
+ printk(Unhandled debug after interrupt:%d\n, ret);
+ }
+
+ return ret;
+}
+
/**
* kvmppc_handle_exit
*
@@ -198,6 +275,9 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu
*vcpu,
run-exit_reason = KVM_EXIT_UNKNOWN;
run-ready_for_interrupt_injection = 1;
+ if (exit_nr == BOOKE_INTERRUPT_DEBUG)
+ exit_nr = kvmppc_guest_debug_exit_fixup(vcpu, exit_nr);
+
switch (exit_nr) {
case BOOKE_INTERRUPT_MACHINE_CHECK:
printk(MACHINE CHECK: %lx\n, mfspr(SPRN_MCSR));
@@ -650,6 +730,8 @@ int __init kvmppc_booke_init(void)
memcpy((void *)kvmppc_booke_handlers + ivor[i],
kvmppc_handlers_start + i * kvmppc_handler_len,
kvmppc_handler_len);
+ kvmppc_booke_handler_addr[i] =
+ (unsigned long)kvmppc_booke_handlers + ivor[i];
}
flush_icache_range(kvmppc_booke_handlers,
kvmppc_booke_handlers + max_ivor +
kvmppc_handler_len);
diff --git a/arch/powerpc/kvm/booke_interrupts.S
b/arch/powerpc/kvm/booke_interrupts.S
index 52592fe..d7cd37e 100644
--- a/arch/powerpc/kvm/booke_interrupts.S
+++ b/arch/powerpc/kvm/booke_interrupts.S
@@ -42,16 +42,17 @@
#define HOST_STACK_LR (HOST_STACK_SIZE + 4) /* In caller stack frame. */
#define NEED_INST_MASK ((1BOOKE_INTERRUPT_PROGRAM) | \
-(1BOOKE_INTERRUPT_DTLB_MISS) | \
-
RE: [PATCH 2/5] kvmppc guest debug definitions
-Original Message-
From: Liu Yu-B13201
Sent: Monday, August 03, 2009 7:08 PM
To: kvm-ppc@vger.kernel.org
Cc: holl...@us.ibm.com; a...@redhat.com; Liu Yu-B13201
Subject: [PATCH 2/5] kvmppc guest debug definitions
Signed-off-by: Liu Yu yu@freescale.com
---
arch/powerpc/include/asm/kvm.h | 20
arch/powerpc/include/asm/kvm_host.h | 18 ++
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index c9c930e..6caabfc 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -160,6 +173,10 @@ struct kvm_vcpu_arch {
u32 dbcr1;
u32 dbsr;
+ struct kvmppc_debug_reg shadow_dbg_reg;
+ struct kvmppc_debug_reg host_dbg_reg;
+ bool has_load_host_dbg;
Forgot to remove this variable for debug
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
