On Thu, Oct 20, 2016 at 01:08:59PM +0200, Radim Krčmář wrote:
> 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.)
Yeah, though my original goal was not for this, but this is a good
point.
>
> > 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?
Nop. Actually...
> 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.
... here the assertion should be failing at msi_offset == 0, since MSI
support for hw/misc/edu.c device is just added days ago in commit:
commit eabb5782f70b4a10975b24ccd7129929a05ac932
Author: Peter Xu <peterx@xxxxxxxxxx>
Date: Wed Sep 28 21:03:39 2016 +0800
hw/misc/edu: support MSI interrupt
I should mention this in the cover letter that we need the latest QEMU
with at least above commit to run the tests. Will do it in v2.
Thanks,
-- peterx
--
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
