2016-10-20 14:05+0800, Peter Xu:
> On Wed, Oct 19, 2016 at 10:21:11PM +0200, Radim Krčmář wrote:
>> 2016-10-14 20:40+0800, Peter Xu:
>> > The problem is, there are many IOMMU error conditions which are
>> > very hard to be triggered in a real guest (IOMMU has merely no
>> > interface for guest user, and it's totally running in the background).
>>
>> I gracefully skipped most of VT-d error handling ... how many of those
>> errors are not a result of a misconfiguration?
>
> Do you mean the error handling codes in hw/i386/intel_iommu.c?
Yes, I meant the error codes that IOMMU will pass to the OS.
> IMHO
> most of those errors will be triggered only if there is bug in guest
> OS IOMMU driver.
We can't know what the OS wanted, so there are no OS bugs for us. :)
If an OS (mis)configures the device, then it should get an expected
error code -- these paths are rarely exercised, so unit tests for them
would be useful too. (Very low priority, though, so I don't expect that
anyone will every write them.)
> Here when I talked about error conditions, I mostly meant potential
> QEMU IOMMU bugs, not guest OS bugs (of course, AFAICT kvm-unit-tests
> are not for guest OS bugs). For example, there are still bugs in IOMMU
> IR, and some of the bugs can hardly be triggered by guest OS. In that
> case, we need this unit test to reproduce the bug, and re-run it to
> verify when I have a fix. Otherwise even if I fixed the bug one day, I
> can never reproduce it, nor can I know whether the fix works.
I see, thanks, this is a great goal for unit tests.
Btw. isn't this series already testing one fixed QEMU bug?
When I run this test with old QEMU (qemu-2.7.0-3.fc26), then I get this
output:
[...]
INTR: setup IRTE index 0
lib/pci.c:52: assert failed: dev && dev->inited && dev->msi_offset
STACK: 40344c 402fd1 400567 40028f
new QEMU works fine, so I assume that we should test it and not assert.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
