linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Damien Le Moal <dlemoal@kernel.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	Wadim Mueller <wafgo01@gmail.com>
Cc: "Bjorn Helgaas" <bhelgaas@google.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	"Jens Axboe" <axboe@kernel.dk>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Shunsuke Mie" <mie@igel.co.jp>,
	linux-pci@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-block@vger.kernel.org
Subject: Re: [PATCH 0/3] Add support for Block Passthrough Endpoint function driver
Date: Mon, 26 Feb 2024 04:58:24 -0800	[thread overview]
Message-ID: <2f0f67d3-6a69-400b-b653-9353a3ddff02@kernel.org> (raw)
In-Reply-To: <20240226094530.GA2778@thinkpad>

On 2024/02/26 1:45, Manivannan Sadhasivam wrote:

[...]

>> As virtio is made mainly for Hypervisor <->
>> Guest communication I was afraid that a Hypersisor is able to Trap every
>> Register access from the Guest and act accordingly, which I would not be
>> able to do. I hope this make sense to you.
>>
> 
> I'm not worrying about the hypervisor right now. Here the endpoint is exposing
> the virtio devices and host is consuming it. There is no virtualization play
> here. I talked about this in the last plumbers [2].

FYI, we are still working on our NVMe PCI EPF function driver. It is working OK
using either a rockpro64 (PCI Gen2) board and a Radxa Rock 5B board (PCI Gen3,
rk3588 SoC/DWC EPF driver). Just been super busy recently with the block layer &
ATA stuff so I have not been able to rebase/cleanup and send stuff. This driver
also depends on many cleanup/improvement patches (see below).

> 
>> But to make a long story short, yes I agree with you that virtio-blk
>> would satisfy my usecase, and I generally think it would be a better
>> solution, I just did not know that you are working on some
>> infrastructure for that. And yes I would like to implement the endpoint
>> function driver for virtio-blk. Is there already an development tree you
>> use to work on the infrastructre I could have a look at?
>>
> 
> Shunsuke has a WIP branch [3], that I plan to co-work in the coming days.
> You can use it as a reference in the meantime.

This one is very similar to what I did in my series:

https://github.com/torvalds/linux/commit/05e21d458b1eaa8c22697f12a1ae42dcb04ff377

My series is here:

https://github.com/damien-lemoal/linux/tree/rock5b_ep_v8

It is a bit of a mess but what's there is:
1) Add the "map_info" EPF method to get mapping that are not dependent on the
host address alignment. That is similar to the align_mem method Shunsuke
introduced, but with more info to make it generic and allow EPF to deal with any
host DMA address.
2) Fixes for the rockpro64 DMA mapping as it is broken
3) Adds rk2588 EPF driver
4) Adds the NVMe EPF function driver. That is implemented as a PCI EPF frontend
to an NVMe-of controller so that any NMVe-Of supported device can be exposed
over PCI (block device, file, real NVMe controller).

There are also a bunch of API changes and cleanups to make the EPF code (core
and driver) more compact/easier to read.

Once I am done with my current work on the block layer side, I intend to come
back to this for the next cycle. I still need to complete the IRQ lehacy -> intx
renaming as well...

Cheers.

-- 
Damien Le Moal
Western Digital Research


  reply	other threads:[~2024-02-26 12:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-24 21:03 [PATCH 0/3] Add support for Block Passthrough Endpoint function driver Wadim Mueller
2024-02-24 21:04 ` [PATCH 1/3] PCI: Add PCI Endpoint function driver for Block-device passthrough Wadim Mueller
2024-02-24 21:04 ` [PATCH 2/3] PCI: Add PCI driver for a PCI EP remote Blockdevice Wadim Mueller
2024-02-24 21:04 ` [PATCH 3/3] Documentation: PCI: Add documentation for the PCI Block Passthrough Wadim Mueller
2024-02-25 16:09 ` [PATCH 0/3] Add support for Block Passthrough Endpoint function driver Manivannan Sadhasivam
2024-02-25 20:39   ` Wadim Mueller
2024-02-26  9:45     ` Manivannan Sadhasivam
2024-02-26 12:58       ` Damien Le Moal [this message]
2024-02-26 18:47       ` Wadim Mueller
2024-02-26 16:47     ` Frank Li
2024-02-26 11:08 ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2f0f67d3-6a69-400b-b653-9353a3ddff02@kernel.org \
    --to=dlemoal@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=bhelgaas@google.com \
    --cc=corbet@lwn.net \
    --cc=kishon@kernel.org \
    --cc=kw@linux.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=mie@igel.co.jp \
    --cc=wafgo01@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).