* Biweekly KVM Test report, kernel 7a7ada1b... qemu df85c051...
@ 2011-04-12 7:48 Ren, Yongjie
2011-04-12 8:02 ` Avi Kivity
0 siblings, 1 reply; 6+ messages in thread
From: Ren, Yongjie @ 2011-04-12 7:48 UTC (permalink / raw)
To: kvm@vger.kernel.org
Hi All,
This is KVM test result against kvm.git 7a7ada1bfb958d2ad722d0df9299f1b0136ec1d4 based on kernel 2.6.39-rc2+, and qemu-kvm.git df85c051d780bca0ee2462cfeb8ef6d9552a19b0.
We found 1 bug about "NIC cannot work when it had been used before ".
The VT-d bug 730441 (qemu bugzilla) concerning "nomsi NIC" is fixed.
New issue:
1.[VT-d] NIC cannot work when it had been used before
https://bugs.launchpad.net/qemu/+bug/754591
Fixed issue:
1. [VT-d] NIC doesn't work with "pci=nomsi" configurartion
https://bugs.launchpad.net/qemu/+bug/730441
Old Issues:
================================================
1. ltp diotest running time is 2.54 times than before
https://sourceforge.net/tracker/?func=detail&aid=2723366&group_id=180599&atid=893831
2. perfctr wrmsr warning when booting 64bit RHEl5.3
https://sourceforge.net/tracker/?func=detail&aid=2721640&group_id=180599&atid=893831
Test environment:
==================================================================
Platform Westmere-EP Sandy Bridge
CPU 24 8
Memory size 10G 2G
Report summary of IA32E on Westmere-EP:
Summary Test Report of Last Session
=====================================================================
Total Pass Fail NoResult Crash
=====================================================================
control_panel_ept_vpid 12 12 0 0 0
control_panel_vpid 3 3 0 0 0
control_panel 3 3 0 0 0
control_panel_ept 4 4 0 0 0
gtest_vpid 1 1 0 0 0
gtest_ept 1 1 0 0 0
gtest 3 3 0 0 0
vtd_ept_vpid 14 1 13 0 0
gtest_ept_vpid 11 11 0 0 0
sriov_ept_vpid 5 0 5 0 0
=====================================================================
control_panel_ept_vpid 12 12 0 0 0
:KVM_LM_Continuity_64_g3 1 1 0 0 0
:KVM_four_dguest_64_g32e 1 1 0 0 0
:KVM_1500M_guest_64_gPAE 1 1 0 0 0
:KVM_LM_SMP_64_g32e 1 1 0 0 0
:KVM_SR_SMP_64_g32e 1 1 0 0 0
:KVM_linux_win_64_g32e 1 1 0 0 0
:KVM_1500M_guest_64_g32e 1 1 0 0 0
:KVM_two_winxp_64_g32e 1 1 0 0 0
:KVM_256M_guest_64_gPAE 1 1 0 0 0
:KVM_SR_Continuity_64_g3 1 1 0 0 0
:KVM_256M_guest_64_g32e 1 1 0 0 0
:KVM_four_sguest_64_g32e 1 1 0 0 0
control_panel_vpid 3 3 0 0 0
:KVM_linux_win_64_g32e 1 1 0 0 0
:KVM_1500M_guest_64_g32e 1 1 0 0 0
:KVM_1500M_guest_64_gPAE 1 1 0 0 0
control_panel 3 3 0 0 0
:KVM_1500M_guest_64_g32e 1 1 0 0 0
:KVM_1500M_guest_64_gPAE 1 1 0 0 0
:KVM_LM_SMP_64_g32e 1 1 0 0 0
control_panel_ept 4 4 0 0 0
:KVM_linux_win_64_g32e 1 1 0 0 0
:KVM_1500M_guest_64_g32e 1 1 0 0 0
:KVM_1500M_guest_64_gPAE 1 1 0 0 0
:KVM_LM_SMP_64_g32e 1 1 0 0 0
gtest_vpid 1 1 0 0 0
:boot_smp_win7_ent_64_g3 1 1 0 0 0
gtest_ept 1 1 0 0 0
:boot_smp_win7_ent_64_g3 1 1 0 0 0
gtest 3 3 0 0 0
:boot_smp_win2008_64_g32 1 1 0 0 0
:boot_smp_win7_ent_64_gP 1 1 0 0 0
:boot_smp_vista_64_g32e 1 1 0 0 0
vtd_ept_vpid 14 1 13 0 0
:one_pcie_up_xp_64_g32e 1 0 1 0 0
:hp_pcie_smp_xp_64_g32e 1 0 1 0 0
:two_dev_smp_nomsi_64_g3 1 0 1 0 0
:one_pcie_up_64_g32e 1 1 0 0 0
:hp_pcie_smp_nomsi_64_g3 1 0 1 0 0
:lm_pcie_smp_64_g32e 1 0 1 0 0
:hp_pcie_up_xp_64_g32e 1 0 1 0 0
:two_dev_smp_64_g32e 1 0 1 0 0
:one_pcie_smp_nomsi_64_g 1 0 1 0 0
:one_pcie_scp_64_g32e 1 0 1 0 0
:one_pcie_smp_xp_64_g32e 1 0 1 0 0
:hp_pcie_smp_64_g32e 1 0 1 0 0
:one_pcie_smp_64_g32e 1 0 1 0 0
:hp_pcie_up_64_g32e 1 0 1 0 0
gtest_ept_vpid 11 11 0 0 0
:boot_up_acpi_64_g32e 1 1 0 0 0
:boot_base_kernel_64_g32 1 1 0 0 0
:kb_nightly_64_g32e 1 1 0 0 0
:boot_up_acpi_win2k3_64_ 1 1 0 0 0
:boot_up_vista_64_g32e 1 1 0 0 0
:ltp_nightly_64_g32e 1 1 0 0 0
:boot_smp_win2008_64_g32 1 1 0 0 0
:boot_smp_acpi_win2k3_64 1 1 0 0 0
:boot_smp_win7_ent_64_g3 1 1 0 0 0
:boot_up_acpi_xp_64_g32e 1 1 0 0 0
:boot_smp_acpi_xp_64_g32 1 1 0 0 0
sriov_ept_vpid 5 0 5 0 0
:one_vf_up_64_g32e 1 0 1 0 0
:hp_vf_up_64_g32e 1 0 1 0 0
:hp_vf_smp_64_g32e 1 0 1 0 0
:one_vf_smp_64_g32e 1 0 1 0 0
:two_dev_smp_64_g32e 1 0 1 0 0
=====================================================================
Total 57 39 18 0 0
Report summary of IA32E on Sandy Bridge:
Summary Test Report of Last Session
=====================================================================
Total Pass Fail NoResult Crash
=====================================================================
control_panel_ept_vpid 12 12 0 0 0
control_panel_vpid 3 3 0 0 0
control_panel_ept 4 4 0 0 0
control_panel 3 3 0 0 0
gtest_ept 1 1 0 0 0
gtest_vpid 1 1 0 0 0
gtest 3 3 0 0 0
vtd_ept_vpid 8 1 7 0 0
gtest_ept_vpid 11 11 0 0 0
sriov_ept_vpid 5 5 0 0 0
=====================================================================
control_panel_ept_vpid 12 12 0 0 0
:KVM_LM_Continuity_64_g3 1 1 0 0 0
:KVM_four_dguest_64_g32e 1 1 0 0 0
:KVM_1500M_guest_64_gPAE 1 1 0 0 0
:KVM_LM_SMP_64_g32e 1 1 0 0 0
:KVM_SR_SMP_64_g32e 1 1 0 0 0
:KVM_linux_win_64_g32e 1 1 0 0 0
:KVM_two_winxp_64_g32e 1 1 0 0 0
:KVM_1500M_guest_64_g32e 1 1 0 0 0
:KVM_256M_guest_64_gPAE 1 1 0 0 0
:KVM_SR_Continuity_64_g3 1 1 0 0 0
:KVM_256M_guest_64_g32e 1 1 0 0 0
:KVM_four_sguest_64_g32e 1 1 0 0 0
control_panel_vpid 3 3 0 0 0
:KVM_linux_win_64_g32e 1 1 0 0 0
:KVM_1500M_guest_64_g32e 1 1 0 0 0
:KVM_1500M_guest_64_gPAE 1 1 0 0 0
control_panel_ept 4 4 0 0 0
:KVM_linux_win_64_g32e 1 1 0 0 0
:KVM_1500M_guest_64_g32e 1 1 0 0 0
:KVM_1500M_guest_64_gPAE 1 1 0 0 0
:KVM_LM_SMP_64_g32e 1 1 0 0 0
control_panel 3 3 0 0 0
:KVM_1500M_guest_64_g32e 1 1 0 0 0
:KVM_1500M_guest_64_gPAE 1 1 0 0 0
:KVM_LM_SMP_64_g32e 1 1 0 0 0
gtest_ept 1 1 0 0 0
:boot_smp_win7_ent_64_g3 1 1 0 0 0
gtest_vpid 1 1 0 0 0
:boot_smp_win7_ent_64_g3 1 1 0 0 0
gtest 3 3 0 0 0
:boot_smp_win2008_64_g32 1 1 0 0 0
:boot_smp_win7_ent_64_gP 1 1 0 0 0
:boot_smp_vista_64_g32e 1 1 0 0 0
vtd_ept_vpid 8 1 7 0 0
:one_pcie_up_64_g32e 1 1 0 0 0
:lm_pcie_smp_64_g32e 1 0 1 0 0
:hp_pcie_smp_nomsi_64_g3 1 0 1 0 0
:one_pcie_scp_64_g32e 1 0 1 0 0
:one_pcie_smp_nomsi_64_g 1 0 1 0 0
:hp_pcie_smp_64_g32e 1 0 1 0 0
:one_pcie_smp_64_g32e 1 0 1 0 0
:hp_pcie_up_64_g32e 1 0 1 0 0
gtest_ept_vpid 11 11 0 0 0
:boot_up_acpi_64_g32e 1 1 0 0 0
:boot_base_kernel_64_g32 1 1 0 0 0
:boot_up_acpi_win2k3_64_ 1 1 0 0 0
:kb_nightly_64_g32e 1 1 0 0 0
:boot_up_vista_64_g32e 1 1 0 0 0
:ltp_nightly_64_g32e 1 1 0 0 0
:boot_smp_win2008_64_g32 1 1 0 0 0
:boot_up_acpi_xp_64_g32e 1 1 0 0 0
:boot_smp_acpi_win2k3_64 1 1 0 0 0
:boot_smp_win7_ent_64_g3 1 1 0 0 0
:boot_smp_acpi_xp_64_g32 1 1 0 0 0
sriov_ept_vpid 5 5 0 0 0
:one_vf_up_64_g32e 1 1 0 0 0
:hp_vf_up_64_g32e 1 1 0 0 0
:hp_vf_smp_64_g32e 1 1 0 0 0
:one_vf_smp_64_g32e 1 1 0 0 0
:two_dev_smp_64_g32e 1 1 0 0 0
=====================================================================
Total 51 44 7 0 0
Best Regards,
Yongjie Ren (Jay)
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Biweekly KVM Test report, kernel 7a7ada1b... qemu df85c051... 2011-04-12 7:48 Biweekly KVM Test report, kernel 7a7ada1b... qemu df85c051 Ren, Yongjie @ 2011-04-12 8:02 ` Avi Kivity 2011-04-12 18:22 ` Alex Williamson 0 siblings, 1 reply; 6+ messages in thread From: Avi Kivity @ 2011-04-12 8:02 UTC (permalink / raw) To: Ren, Yongjie; +Cc: kvm@vger.kernel.org, Alex Williamson On 04/12/2011 10:48 AM, Ren, Yongjie wrote: > Hi All, > This is KVM test result against kvm.git 7a7ada1bfb958d2ad722d0df9299f1b0136ec1d4 based on kernel 2.6.39-rc2+, and qemu-kvm.git df85c051d780bca0ee2462cfeb8ef6d9552a19b0. > > We found 1 bug about "NIC cannot work when it had been used before ". > The VT-d bug 730441 (qemu bugzilla) concerning "nomsi NIC" is fixed. > > New issue: > 1.[VT-d] NIC cannot work when it had been used before > https://bugs.launchpad.net/qemu/+bug/754591 > += Alex. -- error compiling committee.c: too many arguments to function ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Biweekly KVM Test report, kernel 7a7ada1b... qemu df85c051... 2011-04-12 8:02 ` Avi Kivity @ 2011-04-12 18:22 ` Alex Williamson 2011-04-12 21:02 ` Jan Kiszka 0 siblings, 1 reply; 6+ messages in thread From: Alex Williamson @ 2011-04-12 18:22 UTC (permalink / raw) To: Avi Kivity, Jan Kiszka; +Cc: Ren, Yongjie, kvm@vger.kernel.org On Tue, 2011-04-12 at 11:02 +0300, Avi Kivity wrote: > On 04/12/2011 10:48 AM, Ren, Yongjie wrote: > > Hi All, > > This is KVM test result against kvm.git 7a7ada1bfb958d2ad722d0df9299f1b0136ec1d4 based on kernel 2.6.39-rc2+, and qemu-kvm.git df85c051d780bca0ee2462cfeb8ef6d9552a19b0. > > > > We found 1 bug about "NIC cannot work when it had been used before ". > > The VT-d bug 730441 (qemu bugzilla) concerning "nomsi NIC" is fixed. > > > > New issue: > > 1.[VT-d] NIC cannot work when it had been used before > > https://bugs.launchpad.net/qemu/+bug/754591 > > > > += Alex. > This is caused by the patch below. When we do a reset via PCI sysfs, the device state is saved and restored around the reset. When the state is restored, the saved state is invalidated. Now when we go to free the device, we call the "I know what I'm doing" __pci_reset_function(), which doesn't save/restore state, then try to do a restore, but there's nothing saved, so the device only has reset values... oops. Jan, do you actually have a test case where you can see a difference restoring the original saved state? I'm tempted to suggest we just revert this patch. Otherwise it seems like we an interface to extract and reload the original saved state for the device. Thanks, Alex commit ed78661f2614d3c9f69c23e280db3bafdabdf5bb Author: Jan Kiszka <jan.kiszka@siemens.com> Date: Tue Nov 16 22:30:05 2010 +0100 KVM: Save/restore state of assigned PCI device The guest may change states that pci_reset_function does not touch. So we better save/restore the assigned device across guest usage. Acked-by: Alex Williamson <alex.williamson@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> diff --git a/virt/kvm/assigned-dev.c b/virt/kvm/assigned-dev.c index 7623408..d389207 100644 --- a/virt/kvm/assigned-dev.c +++ b/virt/kvm/assigned-dev.c @@ -197,7 +197,8 @@ static void kvm_free_assigned_device(struct kvm *kvm, { kvm_free_assigned_irq(kvm, assigned_dev); - pci_reset_function(assigned_dev->dev); + __pci_reset_function(assigned_dev->dev); + pci_restore_state(assigned_dev->dev); pci_release_regions(assigned_dev->dev); pci_disable_device(assigned_dev->dev); @@ -514,6 +515,7 @@ static int kvm_vm_ioctl_assign_device(struct kvm *kvm, } pci_reset_function(dev); + pci_save_state(dev); match->assigned_dev_id = assigned_dev->assigned_dev_id; match->host_segnr = assigned_dev->segnr; @@ -544,6 +546,7 @@ out: mutex_unlock(&kvm->lock); return r; out_list_del: + pci_restore_state(dev); list_del(&match->list); pci_release_regions(dev); out_disable: ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: Biweekly KVM Test report, kernel 7a7ada1b... qemu df85c051... 2011-04-12 18:22 ` Alex Williamson @ 2011-04-12 21:02 ` Jan Kiszka 2011-04-12 21:20 ` Alex Williamson 0 siblings, 1 reply; 6+ messages in thread From: Jan Kiszka @ 2011-04-12 21:02 UTC (permalink / raw) To: Alex Williamson; +Cc: Avi Kivity, Ren, Yongjie, kvm@vger.kernel.org [-- Attachment #1: Type: text/plain, Size: 1991 bytes --] On 2011-04-12 20:22, Alex Williamson wrote: > On Tue, 2011-04-12 at 11:02 +0300, Avi Kivity wrote: >> On 04/12/2011 10:48 AM, Ren, Yongjie wrote: >>> Hi All, >>> This is KVM test result against kvm.git 7a7ada1bfb958d2ad722d0df9299f1b0136ec1d4 based on kernel 2.6.39-rc2+, and qemu-kvm.git df85c051d780bca0ee2462cfeb8ef6d9552a19b0. >>> >>> We found 1 bug about "NIC cannot work when it had been used before ". >>> The VT-d bug 730441 (qemu bugzilla) concerning "nomsi NIC" is fixed. >>> >>> New issue: >>> 1.[VT-d] NIC cannot work when it had been used before >>> https://bugs.launchpad.net/qemu/+bug/754591 >>> >> >> += Alex. >> > > This is caused by the patch below. When we do a reset via PCI sysfs, > the device state is saved and restored around the reset. When the state > is restored, the saved state is invalidated. Now when we go to free the > device, we call the "I know what I'm doing" __pci_reset_function(), > which doesn't save/restore state, then try to do a restore, but there's > nothing saved, so the device only has reset values... oops. > > Jan, do you actually have a test case where you can see a difference > restoring the original saved state? I'm tempted to suggest we just > revert this patch. Otherwise it seems like we an interface to extract > and reload the original saved state for the device. Thanks, I've no test case, but the issue is clear: we used to leak guest manipulations of the config space to the host or the new owner. However, I'm first of all wondering why the heck libvirt should issue a sysfs PCI reset while the device is in KVM/guest hands? Is it clear that this is actually the case? Then it should be fixed independently as it would be a bug (proper pattern would be: deassign, reset, reassign). That said, our way of relying on the consistency of the saved state between assignment and release is in fact a bit fragile. We should probably make it more robust as you suggested. Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 259 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Biweekly KVM Test report, kernel 7a7ada1b... qemu df85c051... 2011-04-12 21:02 ` Jan Kiszka @ 2011-04-12 21:20 ` Alex Williamson 2011-04-12 22:35 ` Jan Kiszka 0 siblings, 1 reply; 6+ messages in thread From: Alex Williamson @ 2011-04-12 21:20 UTC (permalink / raw) To: Jan Kiszka; +Cc: Avi Kivity, Ren, Yongjie, kvm@vger.kernel.org On Tue, 2011-04-12 at 23:02 +0200, Jan Kiszka wrote: > On 2011-04-12 20:22, Alex Williamson wrote: > > On Tue, 2011-04-12 at 11:02 +0300, Avi Kivity wrote: > >> On 04/12/2011 10:48 AM, Ren, Yongjie wrote: > >>> Hi All, > >>> This is KVM test result against kvm.git 7a7ada1bfb958d2ad722d0df9299f1b0136ec1d4 based on kernel 2.6.39-rc2+, and qemu-kvm.git df85c051d780bca0ee2462cfeb8ef6d9552a19b0. > >>> > >>> We found 1 bug about "NIC cannot work when it had been used before ". > >>> The VT-d bug 730441 (qemu bugzilla) concerning "nomsi NIC" is fixed. > >>> > >>> New issue: > >>> 1.[VT-d] NIC cannot work when it had been used before > >>> https://bugs.launchpad.net/qemu/+bug/754591 > >>> > >> > >> += Alex. > >> > > > > This is caused by the patch below. When we do a reset via PCI sysfs, > > the device state is saved and restored around the reset. When the state > > is restored, the saved state is invalidated. Now when we go to free the > > device, we call the "I know what I'm doing" __pci_reset_function(), > > which doesn't save/restore state, then try to do a restore, but there's > > nothing saved, so the device only has reset values... oops. > > > > Jan, do you actually have a test case where you can see a difference > > restoring the original saved state? I'm tempted to suggest we just > > revert this patch. Otherwise it seems like we an interface to extract > > and reload the original saved state for the device. Thanks, > > I've no test case, but the issue is clear: we used to leak guest > manipulations of the config space to the host or the new owner. But is there any state that we care about that isn't flushed by the device reset? Sure there might be some subtle config space changes, but the guest can't change fundamental mappings or anything. > However, I'm first of all wondering why the heck libvirt should issue a > sysfs PCI reset while the device is in KVM/guest hands? Is it clear that > this is actually the case? Then it should be fixed independently as it > would be a bug (proper pattern would be: deassign, reset, reassign). libvirt does it's own weird device resets, but that's prior to handing the device off to qemu, so doesn't come into play. The change is d9488459 where qemu resets the device via PCI sysfs on VM reset. Without this, a device can continue to DMA across the reset, trashing guest memory. I think qemu, as the owner of the device, has every right to do this, and it's the only reasonable way to quiesce the device. > That said, our way of relying on the consistency of the saved state > between assignment and release is in fact a bit fragile. We should > probably make it more robust as you suggested. That may take some time, and since we don't actually have a test case or known issue, I vote to revert ed78661f. Thanks, Alex ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Biweekly KVM Test report, kernel 7a7ada1b... qemu df85c051... 2011-04-12 21:20 ` Alex Williamson @ 2011-04-12 22:35 ` Jan Kiszka 0 siblings, 0 replies; 6+ messages in thread From: Jan Kiszka @ 2011-04-12 22:35 UTC (permalink / raw) To: Alex Williamson; +Cc: Avi Kivity, Ren, Yongjie, kvm@vger.kernel.org [-- Attachment #1: Type: text/plain, Size: 3440 bytes --] On 2011-04-12 23:20, Alex Williamson wrote: > On Tue, 2011-04-12 at 23:02 +0200, Jan Kiszka wrote: >> On 2011-04-12 20:22, Alex Williamson wrote: >>> On Tue, 2011-04-12 at 11:02 +0300, Avi Kivity wrote: >>>> On 04/12/2011 10:48 AM, Ren, Yongjie wrote: >>>>> Hi All, >>>>> This is KVM test result against kvm.git 7a7ada1bfb958d2ad722d0df9299f1b0136ec1d4 based on kernel 2.6.39-rc2+, and qemu-kvm.git df85c051d780bca0ee2462cfeb8ef6d9552a19b0. >>>>> >>>>> We found 1 bug about "NIC cannot work when it had been used before ". >>>>> The VT-d bug 730441 (qemu bugzilla) concerning "nomsi NIC" is fixed. >>>>> >>>>> New issue: >>>>> 1.[VT-d] NIC cannot work when it had been used before >>>>> https://bugs.launchpad.net/qemu/+bug/754591 >>>>> >>>> >>>> += Alex. >>>> >>> >>> This is caused by the patch below. When we do a reset via PCI sysfs, >>> the device state is saved and restored around the reset. When the state >>> is restored, the saved state is invalidated. Now when we go to free the >>> device, we call the "I know what I'm doing" __pci_reset_function(), >>> which doesn't save/restore state, then try to do a restore, but there's >>> nothing saved, so the device only has reset values... oops. >>> >>> Jan, do you actually have a test case where you can see a difference >>> restoring the original saved state? I'm tempted to suggest we just >>> revert this patch. Otherwise it seems like we an interface to extract >>> and reload the original saved state for the device. Thanks, >> >> I've no test case, but the issue is clear: we used to leak guest >> manipulations of the config space to the host or the new owner. > > But is there any state that we care about that isn't flushed by the > device reset? Sure there might be some subtle config space changes, but > the guest can't change fundamental mappings or anything. I haven't written a "malicious" guest driver yet, but one of the easiest ways to confuse the host is to disable the device's INTx before the guest terminates. That would survive the old way of releasing and resetting the device. > >> However, I'm first of all wondering why the heck libvirt should issue a >> sysfs PCI reset while the device is in KVM/guest hands? Is it clear that >> this is actually the case? Then it should be fixed independently as it >> would be a bug (proper pattern would be: deassign, reset, reassign). > > libvirt does it's own weird device resets, but that's prior to handing > the device off to qemu, so doesn't come into play. The change is > d9488459 where qemu resets the device via PCI sysfs on VM reset. > Without this, a device can continue to DMA across the reset, trashing > guest memory. I think qemu, as the owner of the device, has every right > to do this, and it's the only reasonable way to quiesce the device. > >> That said, our way of relying on the consistency of the saved state >> between assignment and release is in fact a bit fragile. We should >> probably make it more robust as you suggested. > > That may take some time, and since we don't actually have a test case or > known issue, I vote to revert ed78661f. Some alternative ways to address the issue in qemu: - save/restore the full config space in qemu (won't help if qemu terminates prematurely) - drop&reacquire the device before/after the reset - export a pure reset service via kvm to userspace Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 259 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-04-12 22:35 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-04-12 7:48 Biweekly KVM Test report, kernel 7a7ada1b... qemu df85c051 Ren, Yongjie 2011-04-12 8:02 ` Avi Kivity 2011-04-12 18:22 ` Alex Williamson 2011-04-12 21:02 ` Jan Kiszka 2011-04-12 21:20 ` Alex Williamson 2011-04-12 22:35 ` Jan Kiszka
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox