Re: [kvm-unit-tests RFC PATCH 00/14] VT-d unit test

[Peter Xu <peterx@redhat.com>]

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@redhat.com>
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