From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59227) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bonuH-0004RY-1n for qemu-devel@nongnu.org; Tue, 27 Sep 2016 04:38:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bonuE-0001Tt-JS for qemu-devel@nongnu.org; Tue, 27 Sep 2016 04:38:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57956) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bonuE-0001Tk-Cq for qemu-devel@nongnu.org; Tue, 27 Sep 2016 04:38:26 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C0A34693F2 for ; Tue, 27 Sep 2016 08:38:25 +0000 (UTC) Date: Tue, 27 Sep 2016 16:38:19 +0800 From: Peter Xu Message-ID: <20160927083819.GD10363@pxdev.xzpeter.org> References: <1474524908-18716-1-git-send-email-peterx@redhat.com> <20160922182305.hulm7yfx24gor5fg@redhat.com> <20160927063744.GC10363@pxdev.xzpeter.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160927063744.GC10363@pxdev.xzpeter.org> Subject: Re: [Qemu-devel] [PATCH] pci-testdev: enhance to support new testcases List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org, pbonzini@redhat.com, marcel@redhat.com On Tue, Sep 27, 2016 at 02:37:44PM +0800, Peter Xu wrote: > On Thu, Sep 22, 2016 at 09:23:05PM +0300, Michael S. Tsirkin wrote: > > On Thu, Sep 22, 2016 at 02:15:08PM +0800, Peter Xu wrote: > > > pci-testdev is used mostly in kvm-unit-test for some eventfd tests. > > > However I see it a good framework for other tests as well (e.g., the > > > IOMMU unit test in the future). So enhanced it to support more > > > testcases. > > > > > > The original memory handlers and protocol are strict and not easy to > > > change (we need to keep the old behavior of pci-testdev). > > > So I added a > > > new parameter for the device, and memory ops will be dynamically handled > > > depending on what testcase it is configured. To specify a new test case > > > for pci-testdev, we use: > > > > > > -device pci-testdev,testcase=XXX > > > > > > The default will be "eventfd", which is the original behavior for > > > pci-testdev. In the future, we can just add new testcase for pci-testdev > > > to achieve different goals. > > > > Instead of a parameter, how about creating a subregion > > of the BAR and adding new tests at an offset? > > Yeah, I can do that as well. Actually what I want to propose is a new "protocol" for pci-testdev. Currently it only allows a very limited test case, which is ioeventfd (static device behavior, no parameter can be passed from guest OS, etc.). IMHO we need something more general, e.g., guest can send cmd to the testdev, to let it do specific test; along the way, we should be able to provide parameters from guest OS (maybe we can gather all kinds of test requirements from the list if people have any idea). Take my example: IOMMU unit test would want the guest to send DMA/IRQ request from the device's perspective. In that case, we would like to "tell" the pci-testdev about where to write the DMA, and what data to write specifically, or which IRQ to trigger. That's something we cannot do right now. And I don't want to just add a new test case for that specifically. I think we can make it more common. Btw, I just noticed that pci-io and pci-mmio tests are not run by default by kvm-unit-test. I don't know how many people are using pci-testdev (guessing there is little since the test is really a specific one). In that case, I don't know whether it'll be okay that I cook a patch to refactor the codes without compatibility considerations. If so, I can provide twin patch for kvm-unit-test as well. Thanks, -- peterx