Re: Biweekly KVM Test report, kernel 7a7ada1b... qemu df85c051...

[Jan Kiszka <jan.kiszka@web.de>]

[-- 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 --]