qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] pci-testdev: enhance to support new testcases


From: Peter Xu
Subject: Re: [Qemu-devel] [PATCH] pci-testdev: enhance to support new testcases
Date: Tue, 27 Sep 2016 16:38:19 +0800
User-agent: Mutt/1.5.24 (2015-08-30)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]