All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Vincent Whitchurch <vincent.whitchurch@axis.com>
Cc: sudeep.dutt@intel.com, ashutosh.dixit@intel.com,
	gregkh <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Kishon Vijay Abraham I <kishon@ti.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	linux-pci <linux-pci@vger.kernel.org>,
	linux-ntb@googlegroups.com, Jon Mason <jdmason@kudzu.us>,
	Dave Jiang <dave.jiang@intel.com>,
	Allen Hubbe <allenbh@gmail.com>
Subject: Re: [PATCH 0/8] Virtio-over-PCIe on non-MIC
Date: Thu, 17 Jan 2019 17:34:10 +0100	[thread overview]
Message-ID: <CAK8P3a3qoxXZqrAuusw++dAU8csHDLHkPNhojjO0AF3FL3jZBg@mail.gmail.com> (raw)
In-Reply-To: <20190117162601.tbmi4ounrnktzjga@axis.com>

On Thu, Jan 17, 2019 at 5:26 PM Vincent Whitchurch
<vincent.whitchurch@axis.com> wrote:
> On Thu, Jan 17, 2019 at 04:53:25PM +0100, Arnd Bergmann wrote:
> > On Thu, Jan 17, 2019 at 4:19 PM Vincent Whitchurch

> > Ok, this seems fine so far. So the vop-host-backend is a regular PCI
> > driver that implements the VOP protocol from the host side, and it
> > can talk to either a MIC, or another guest-backend written for the PCI-EP
> > framework to implement the same protocol, right?
>
> Yes, but just to clarify:  the placement of the device page and the way
> to communicate the location of the device page address and any other
> information needed by the guest-backend are hardware-specific so there
> is no generic vop-host-backend implementation which can talk to both a
> MIC and to something else.

I'm not sure I understand what is hardware specific about it. Shouldn't
it be possible to define at least a vop-host-backend that could work with
any guest-backend running on the PCI-EP framework?

This may have to be different from the interface used on MIC, but
generally speaking that is what I expect from a PCI device.

       Arnd

  reply	other threads:[~2019-01-17 16:34 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-16 16:32 [PATCH 0/8] Virtio-over-PCIe on non-MIC Vincent Whitchurch
2019-01-16 16:32 ` [PATCH 1/8] vop: Use %z for size_t Vincent Whitchurch
2019-01-16 16:32 ` [PATCH 2/8] vop: Cast pointers to uintptr_t Vincent Whitchurch
2019-01-16 17:39   ` Joe Perches
2019-01-22 10:41   ` Greg KH
2019-01-16 16:32 ` [PATCH 3/8] vop: Add definition of readq/writeq if missing Vincent Whitchurch
2019-01-16 16:32 ` [PATCH 4/8] vop: Allow building on more systems Vincent Whitchurch
2019-01-16 16:32 ` [PATCH 5/8] vop: vringh: Do not crash if no DMA channel Vincent Whitchurch
2019-01-16 16:32 ` [PATCH 6/8] vop: Fix handling of >32 feature bits Vincent Whitchurch
2019-01-16 16:32 ` [PATCH 7/8] vop: Use consistent DMA Vincent Whitchurch
2019-01-16 16:32 ` [PATCH 8/8] vop: Add loopback Vincent Whitchurch
2019-01-16 17:07 ` [PATCH 0/8] Virtio-over-PCIe on non-MIC Arnd Bergmann
2019-01-17 10:54   ` Vincent Whitchurch
2019-01-17 12:39     ` Arnd Bergmann
2019-01-17 15:15       ` Christoph Hellwig
2019-01-17 15:19         ` Christoph Hellwig
2019-01-17 15:31           ` Arnd Bergmann
2019-01-17 15:19       ` Vincent Whitchurch
2019-01-17 15:21         ` Christoph Hellwig
2019-01-17 15:32           ` Vincent Whitchurch
2019-01-17 15:46             ` Christoph Hellwig
2019-01-17 16:18               ` Arnd Bergmann
2019-01-17 15:53         ` Arnd Bergmann
2019-01-17 16:26           ` Vincent Whitchurch
2019-01-17 16:34             ` Arnd Bergmann [this message]
2019-01-17 22:17         ` Logan Gunthorpe
2019-01-18 23:49 ` Stephen Warren
2019-01-21 16:25   ` Vincent Whitchurch
2019-01-22 10:45 ` Greg KH

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=CAK8P3a3qoxXZqrAuusw++dAU8csHDLHkPNhojjO0AF3FL3jZBg@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=allenbh@gmail.com \
    --cc=ashutosh.dixit@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jdmason@kudzu.us \
    --cc=kishon@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-ntb@googlegroups.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=sudeep.dutt@intel.com \
    --cc=vincent.whitchurch@axis.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.