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: > > On Wed, Feb 02, 2022 at 08:00:12AM +0000, Chaitanya Kulkarni wrote: > > > Mikulas, > > > > > > On 2/1/22 10:33 AM, Mikulas Patocka wrote: > > > > 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@xxxxxxxxxx> > > > > > > > > > > > > > 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.
