[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZRKHiE9iFuHGUkHV@infradead.org>
Date: Tue, 26 Sep 2023 00:26:00 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Kishon Vijay Abraham I <kvijayab@....com>
Cc: Shunsuke Mie <mie@...l.co.jp>,
Lorenzo Pieralisi <lpieralisi@...nel.org>,
"Michael S. Tsirkin" <mst@...hat.com>, vaishnav.a@...com,
Paolo Bonzini <pbonzini@...hat.com>,
Marcel Apfelbaum <marcel.apfelbaum@...il.com>,
qemu-devel@...gnu.org, Rob Herring <robh@...nel.org>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-pci@...r.kernel.org,
Krzysztof WilczyĆski <kw@...ux.com>,
Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
Kishon Vijay Abraham I <kishon@...nel.org>
Subject: Re: [RFC] Proposal of QEMU PCI Endpoint test environment
On Thu, Sep 21, 2023 at 02:41:54PM +0530, Kishon Vijay Abraham I wrote:
> > PCI Endpoint function driver is implemented using the PCIe Endpoint
> > framework, but it requires physical boards for testing, and it is difficult
> > to test sufficiently. In order to find bugs and hardware-dependent
> > implementations early, continuous testing is required. Since it is
> > difficult to automate tests that require hardware, this RFC proposes a
> > virtual environment for testing PCI endpoint function drivers.
>
> This would be quite useful and thank you for attempting it! I would like to
> compare other mechanisms available in-addition to QEMU before going with the
> QEMU approach.
Well, the point of PCIe endpoint subsystem in vhost or similar is that
you can use one and the same endpoint implementation. So you can debug
it using qemu and the use it with a physical port, which would be really
amazing.
Powered by blists - more mailing lists