linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: "iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org" 
	<virtualization@lists.linux-foundation.org>,
	"virtio-dev@lists.oasis-open.org"
	<virtio-dev@lists.oasis-open.org>,
	"mst@redhat.com" <mst@redhat.com>,
	"jasowang@redhat.com" <jasowang@redhat.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	Mark Rutland <Mark.Rutland@arm.com>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"frowand.list@gmail.com" <frowand.list@gmail.com>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>,
	"tnowicki@caviumnetworks.com" <tnowicki@caviumnetworks.com>,
	"kevin.tian@intel.com" <kevin.tian@intel.com>,
	Marc Zyngier <Marc.Zyngier@arm.com>,
	Robin Murphy <Robin.Murphy@arm.com>,
	Will Deacon <Will.Deacon@arm.com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	"bharat.bhushan@nxp.com" <bharat.bhushan@nxp.com>
Subject: Re: [PATCH v7 0/7] Add virtio-iommu driver
Date: Thu, 24 Jan 2019 16:03:55 +0000	[thread overview]
Message-ID: <a6315ab3-bffb-7470-365d-b26df6524bda@arm.com> (raw)
In-Reply-To: <20190123083435.x3svwqp472mdgglw@8bytes.org>

Hi Joerg,

On 23/01/2019 08:34, Joerg Roedel wrote:
> Hi Jean-Philippe,
> 
> thanks for all your hard work on this!
> 
> On Tue, Jan 15, 2019 at 12:19:52PM +0000, Jean-Philippe Brucker wrote:
>> Implement the virtio-iommu driver, following specification v0.9 [1].
> 
> To make progress on this I think the spec needs to be close to something
> that can be included into the official virtio-specification. Have you
> proposed the specification for inclusion there?

I haven't yet. I did send a few drafts of the spec to the mailing list,
using arbitrary version numbers (0.1 - 0.9), and received excellent
feedback from Eric, Kevin, Ashok and others [2], but I hadn't formally
asked for inclusion yet. Since I haven't made any major change to the
interface in a while, I'll get on that.

> This is because I can't merge a driver that might be incompatible to
> future implementations because the specification needs to be changed on
> its way to an official standard.

Makes sense, though I think other virtio devices have been developed a
little more organically: device and driver code got upstreamed first,
and then the specification describing their interface got merged into
the standard. For example I believe that code for crypto, input and GPU
devices were upstreamed long before the specification was merged. Once
an implementation is upstream, the interface is expected to be
backward-compatible (all subsequent changes are introduced using feature
bits).

So I've been working with this process in mind, also described by Jens
at KVM forum 2017 [3]:
(1) Reserve a device ID, and get that merged into virtio (ID 23 for
virtio-iommu was reserved last year)
(2) Open-source an implementation (this driver and Eric's device)
(3) Formalize and upstream the device specification

But I get that some overlap between (2) and (3) would have been better.
So far the spec document has been reviewed mainly from the IOMMU point
of view, and might require more changes to be in line with the other
virtio devices -- hopefully just wording changes. I'll kick off step
(3), but I think the virtio folks are a bit busy with finalizing the 1.1
spec so I expect it to take a while.

Thanks,
Jean

[2] RFC https://markmail.org/thread/l6b2rpc46nua4egs
    0.4 https://markmail.org/thread/f5k37mab7tnrslin
    0.5 https://markmail.org/thread/tz65oolu5do7hi6n
    0.6 https://markmail.org/thread/dppbg6owzrx2km2n
    0.7 https://markmail.org/thread/dgdy4hicswpakmsq

[3] The future of virtio: riddles, myths and surprises
    https://www.linux-kvm.org/images/0/03/Virtio_fall_2017.pdf
    https://www.youtube.com/watch?v=z9cWwgYH97A


> I had a short discussion with Michael S. Tsirkin about that and from
> what I understood the spec needs to be proposed for inclusion on the
> virtio-comment[1] mailing list and later the TC needs to vote on it.
> Please work with Michael on this to get the specification official (or
> at least pretty close to something that will be part of the official
> virtio standard).
> 
> Regards,
> 
> 	Joerg
> 
> [1] https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=virtio


  reply	other threads:[~2019-01-24 16:04 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-15 12:19 [PATCH v7 0/7] Add virtio-iommu driver Jean-Philippe Brucker
2019-01-15 12:19 ` [PATCH v7 1/7] dt-bindings: virtio-mmio: Add IOMMU description Jean-Philippe Brucker
2019-01-15 12:19 ` [PATCH v7 2/7] dt-bindings: virtio: Add virtio-pci-iommu node Jean-Philippe Brucker
2019-01-15 12:19 ` [PATCH v7 3/7] of: Allow the iommu-map property to omit untranslated devices Jean-Philippe Brucker
2019-01-15 12:19 ` [PATCH v7 4/7] PCI: OF: Initialize dev->fwnode appropriately Jean-Philippe Brucker
2019-01-15 12:19 ` [PATCH v7 5/7] iommu: Add virtio-iommu driver Jean-Philippe Brucker
2019-01-15 12:19 ` [PATCH v7 6/7] iommu/virtio: Add probe request Jean-Philippe Brucker
2019-01-15 12:19 ` [PATCH v7 7/7] iommu/virtio: Add event queue Jean-Philippe Brucker
2019-01-18 15:51 ` [PATCH v7 0/7] Add virtio-iommu driver Michael S. Tsirkin
2019-01-21 11:29   ` Jean-Philippe Brucker
2019-01-29 18:54     ` Michael S. Tsirkin
2019-02-21 21:57       ` Thiago Jung Bauermann
2019-01-23  8:34 ` Joerg Roedel
2019-01-24 16:03   ` Jean-Philippe Brucker [this message]
2019-02-21 22:18     ` Thiago Jung Bauermann
2019-02-22 12:18       ` Jean-Philippe Brucker
2019-02-25 13:20 ` Tomasz Nowicki
2019-05-12 16:31 ` Michael S. Tsirkin
2019-05-27  9:26   ` Joerg Roedel
2019-05-27 15:15     ` Michael S. Tsirkin
2019-05-28  9:18       ` Jean-Philippe Brucker
2019-05-12 17:15 ` Michael S. Tsirkin

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=a6315ab3-bffb-7470-365d-b26df6524bda@arm.com \
    --to=jean-philippe.brucker@arm.com \
    --cc=Lorenzo.Pieralisi@arm.com \
    --cc=Marc.Zyngier@arm.com \
    --cc=Mark.Rutland@arm.com \
    --cc=Robin.Murphy@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=bharat.bhushan@nxp.com \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=eric.auger@redhat.com \
    --cc=frowand.list@gmail.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jasowang@redhat.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-pci@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=robh+dt@kernel.org \
    --cc=tnowicki@caviumnetworks.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=virtualization@lists.linux-foundation.org \
    /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).