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:
signature.asc
Description: OpenPGP digital signature
