From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: [kvm-unit-tests RFC PATCH 00/14] VT-d unit test Date: Thu, 20 Oct 2016 13:08:59 +0200 Message-ID: <20161020110858.GE8573@potion> References: <1476448852-30062-1-git-send-email-peterx@redhat.com> <20161019202110.GB8573@potion> <20161020060551.GG15168@pxdev.xzpeter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: kvm@vger.kernel.org, jan.kiszka@web.de, agordeev@redhat.com, drjones@redhat.com, pbonzini@redhat.com To: Peter Xu Return-path: Received: from mx1.redhat.com ([209.132.183.28]:55726 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755990AbcJTLJC (ORCPT ); Thu, 20 Oct 2016 07:09:02 -0400 Content-Disposition: inline In-Reply-To: <20161020060551.GG15168@pxdev.xzpeter.org> Sender: kvm-owner@vger.kernel.org List-ID: 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.