On Thu, Feb 03, 2022 at 08:52:38AM -0800, Keith Busch wrote:

On Thu, Feb 03, 2022 at 07:38:43AM -0800, Luis Chamberlain wrote:

quoted

On Wed, Feb 02, 2022 at 08:00:12AM +0000, Chaitanya Kulkarni wrote:

quoted

Mikulas,

On 2/1/22 10:33 AM, Mikulas Patocka wrote:

quoted

External email: Use caution opening links or attachments


This patch adds a new driver "nvme-debug". It uses memory as a backing
store and it is used to test the copy offload functionality.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>

NVMe Controller specific memory backed features needs to go into
QEMU which are targeted for testing and debugging, just like what
we have done for NVMe ZNS QEMU support and not in kernel.

I don't see any special reason to make copy offload an exception.

One can instantiate scsi devices with qemu by using fake scsi devices,
but one can also just use scsi_debug to do the same. I see both efforts
as desirable, so long as someone mantains this.

For instance, blktests uses scsi_debug for simplicity.

In the end you decide what you want to use.

Can we use the nvme-loop target instead?

I am advocating for this approach as well. It presentas a virtual nvme
controller already.