From: "Michael S. Tsirkin" <mst@redhat.com> To: Christoph Hellwig <hch@infradead.org> Cc: Will Deacon <will.deacon@arm.com>, Anshuman Khandual <khandual@linux.vnet.ibm.com>, virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, aik@ozlabs.ru, robh@kernel.org, joe@perches.com, elfring@users.sourceforge.net, david@gibson.dropbear.id.au, jasowang@redhat.com, benh@kernel.crashing.org, mpe@ellerman.id.au, linuxram@us.ibm.com, haren@linux.vnet.ibm.com, paulus@samba.org, srikar@linux.vnet.ibm.com, robin.murphy@arm.com, jean-philippe.brucker@arm.com, marc.zyngier@arm.com Subject: Re: [RFC 0/4] Virtio uses DMA API for all devices Date: Mon, 30 Jul 2018 16:26:32 +0300 [thread overview] Message-ID: <20180730155633-mutt-send-email-mst@kernel.org> (raw) In-Reply-To: <20180730111802.GA9830@infradead.org> On Mon, Jul 30, 2018 at 04:18:02AM -0700, Christoph Hellwig wrote: > On Mon, Jul 30, 2018 at 01:28:03PM +0300, Michael S. Tsirkin wrote: > > Let me reply to the "crappy" part first: > > So virtio devices can run on another CPU or on a PCI bus. Configuration > > can happen over mupltiple transports. There is a discovery protocol to > > figure out where it is. It has some warts but any real system has warts. > > > > So IMHO virtio running on another CPU isn't "legacy virtual crappy > > virtio". virtio devices that actually sit on a PCI bus aren't "sane" > > simply because the DMA is more convoluted on some architectures. > > All of what you said would be true if virtio didn't claim to be > a PCI device. There's nothing virtio claims to be. It's a PV device that uses PCI for its configuration. Configuration is enumerated on the virtual PCI bus. That part of the interface is emulated PCI. Data path is through a PV device enumerated on the virtio bus. > Once it claims to be a PCI device and we also see > real hardware written to the interface I stand to all what I said > above. Real hardware would reuse parts of the interface but by necessity it needs to behave slightly differently on some platforms. However for some platforms (such as x86) a PV virtio driver will by luck work with a PCI device backend without changes. As these platforms and drivers are widely deployed, some people will deploy hardware like that. Should be a non issue as by definition it's transparent to guests. > > With this out of my system: > > I agree these approaches are hacky. I think it is generally better to > > have virtio feature negotiation tell you whether device runs on a CPU or > > not rather than rely on platform specific ways for this. To this end > > there was a recent proposal to rename VIRTIO_F_IO_BARRIER to > > VIRTIO_F_REAL_DEVICE. It got stuck since "real" sounds vague to people, > > e.g. what if it's a VF - is that real or not? But I can see something > > like e.g. VIRTIO_F_PLATFORM_DMA gaining support. > > > > We would then rename virtio_has_iommu_quirk to virtio_has_dma_quirk > > and test VIRTIO_F_PLATFORM_DMA in addition to the IOMMU thing. > > I don't really care about the exact naming, and indeed a device that > sets the flag doesn't have to be a 'real' device - it just has to act > like one. I explained all the issues that this means (at least relating > to DMA) in one of the previous threads. I believe you refer to this: https://lkml.org/lkml/2018/6/7/15 that was a very helpful list outlining the problems we need to solve, thanks a lot for that! > The important bit is that we can specify exact behavior for both > devices that sets the "I'm real!" flag and that ones that don't exactly > in the spec. I would very much like that, yes. > And that very much excludes arch-specific (or > Xen-specific) overrides. We already committed to a xen specific hack but generally I prefer devices that describe how they work instead of platforms magically guessing, yes. However the question people raise is that DMA API is already full of arch-specific tricks the likes of which are outlined in your post linked above. How is this one much worse? -- MST
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com> To: Christoph Hellwig <hch@infradead.org> Cc: robh@kernel.org, srikar@linux.vnet.ibm.com, benh@kernel.crashing.org, Will Deacon <will.deacon@arm.com>, linux-kernel@vger.kernel.org, linuxram@us.ibm.com, virtualization@lists.linux-foundation.org, paulus@samba.org, marc.zyngier@arm.com, mpe@ellerman.id.au, joe@perches.com, robin.murphy@arm.com, david@gibson.dropbear.id.au, linuxppc-dev@lists.ozlabs.org, elfring@users.sourceforge.net, haren@linux.vnet.ibm.com, Anshuman Khandual <khandual@linux.vnet.ibm.com> Subject: Re: [RFC 0/4] Virtio uses DMA API for all devices Date: Mon, 30 Jul 2018 16:26:32 +0300 [thread overview] Message-ID: <20180730155633-mutt-send-email-mst@kernel.org> (raw) In-Reply-To: <20180730111802.GA9830@infradead.org> On Mon, Jul 30, 2018 at 04:18:02AM -0700, Christoph Hellwig wrote: > On Mon, Jul 30, 2018 at 01:28:03PM +0300, Michael S. Tsirkin wrote: > > Let me reply to the "crappy" part first: > > So virtio devices can run on another CPU or on a PCI bus. Configuration > > can happen over mupltiple transports. There is a discovery protocol to > > figure out where it is. It has some warts but any real system has warts. > > > > So IMHO virtio running on another CPU isn't "legacy virtual crappy > > virtio". virtio devices that actually sit on a PCI bus aren't "sane" > > simply because the DMA is more convoluted on some architectures. > > All of what you said would be true if virtio didn't claim to be > a PCI device. There's nothing virtio claims to be. It's a PV device that uses PCI for its configuration. Configuration is enumerated on the virtual PCI bus. That part of the interface is emulated PCI. Data path is through a PV device enumerated on the virtio bus. > Once it claims to be a PCI device and we also see > real hardware written to the interface I stand to all what I said > above. Real hardware would reuse parts of the interface but by necessity it needs to behave slightly differently on some platforms. However for some platforms (such as x86) a PV virtio driver will by luck work with a PCI device backend without changes. As these platforms and drivers are widely deployed, some people will deploy hardware like that. Should be a non issue as by definition it's transparent to guests. > > With this out of my system: > > I agree these approaches are hacky. I think it is generally better to > > have virtio feature negotiation tell you whether device runs on a CPU or > > not rather than rely on platform specific ways for this. To this end > > there was a recent proposal to rename VIRTIO_F_IO_BARRIER to > > VIRTIO_F_REAL_DEVICE. It got stuck since "real" sounds vague to people, > > e.g. what if it's a VF - is that real or not? But I can see something > > like e.g. VIRTIO_F_PLATFORM_DMA gaining support. > > > > We would then rename virtio_has_iommu_quirk to virtio_has_dma_quirk > > and test VIRTIO_F_PLATFORM_DMA in addition to the IOMMU thing. > > I don't really care about the exact naming, and indeed a device that > sets the flag doesn't have to be a 'real' device - it just has to act > like one. I explained all the issues that this means (at least relating > to DMA) in one of the previous threads. I believe you refer to this: https://lkml.org/lkml/2018/6/7/15 that was a very helpful list outlining the problems we need to solve, thanks a lot for that! > The important bit is that we can specify exact behavior for both > devices that sets the "I'm real!" flag and that ones that don't exactly > in the spec. I would very much like that, yes. > And that very much excludes arch-specific (or > Xen-specific) overrides. We already committed to a xen specific hack but generally I prefer devices that describe how they work instead of platforms magically guessing, yes. However the question people raise is that DMA API is already full of arch-specific tricks the likes of which are outlined in your post linked above. How is this one much worse? -- MST
next prev parent reply other threads:[~2018-07-30 13:26 UTC|newest] Thread overview: 240+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-07-20 3:59 [RFC 0/4] Virtio uses DMA API for all devices Anshuman Khandual 2018-07-20 3:59 ` [RFC 1/4] virtio: Define virtio_direct_dma_ops structure Anshuman Khandual 2018-07-20 3:59 ` Anshuman Khandual 2018-07-30 9:24 ` Christoph Hellwig 2018-07-30 9:24 ` Christoph Hellwig 2018-07-31 4:01 ` Anshuman Khandual 2018-07-31 4:01 ` Anshuman Khandual 2018-07-20 3:59 ` [RFC 2/4] virtio: Override device's DMA OPS with virtio_direct_dma_ops selectively Anshuman Khandual 2018-07-20 3:59 ` Anshuman Khandual 2018-07-28 8:56 ` Anshuman Khandual 2018-07-28 8:56 ` Anshuman Khandual 2018-07-28 21:16 ` Michael S. Tsirkin 2018-07-30 4:15 ` Anshuman Khandual 2018-07-30 4:15 ` Anshuman Khandual 2018-07-30 9:30 ` Christoph Hellwig 2018-07-31 6:39 ` Anshuman Khandual 2018-07-31 6:39 ` Anshuman Khandual 2018-07-30 9:30 ` Christoph Hellwig 2018-07-28 21:16 ` Michael S. Tsirkin 2018-07-30 9:25 ` Christoph Hellwig 2018-07-31 7:00 ` Anshuman Khandual 2018-07-31 7:00 ` Anshuman Khandual 2018-07-30 9:25 ` Christoph Hellwig 2018-07-20 3:59 ` [RFC 3/4] virtio: Force virtio core to use DMA API callbacks for all virtio devices Anshuman Khandual 2018-07-20 3:59 ` Anshuman Khandual 2018-07-20 3:59 ` [RFC 4/4] virtio: Add platform specific DMA API translation for virito devices Anshuman Khandual 2018-07-20 13:15 ` Michael S. Tsirkin 2018-07-20 13:15 ` Michael S. Tsirkin 2018-07-23 2:16 ` Anshuman Khandual 2018-07-23 2:16 ` Anshuman Khandual 2018-07-25 4:30 ` Anshuman Khandual 2018-07-25 4:30 ` Anshuman Khandual 2018-07-25 13:31 ` Michael S. Tsirkin 2018-07-25 13:31 ` Michael S. Tsirkin 2018-07-20 3:59 ` Anshuman Khandual 2018-07-20 13:16 ` [RFC 0/4] Virtio uses DMA API for all devices Michael S. Tsirkin 2018-07-20 13:16 ` Michael S. Tsirkin 2018-07-23 6:28 ` Anshuman Khandual 2018-07-23 9:08 ` Michael S. Tsirkin 2018-07-23 9:08 ` Michael S. Tsirkin 2018-07-25 3:26 ` Anshuman Khandual 2018-07-27 11:31 ` Michael S. Tsirkin 2018-07-27 11:31 ` Michael S. Tsirkin 2018-07-28 8:37 ` Anshuman Khandual 2018-07-28 8:37 ` Anshuman Khandual 2018-07-25 3:26 ` Anshuman Khandual 2018-07-23 6:28 ` Anshuman Khandual 2018-07-27 9:58 ` Will Deacon 2018-07-27 9:58 ` Will Deacon 2018-07-27 9:58 ` Will Deacon 2018-07-27 10:58 ` Anshuman Khandual 2018-07-27 10:58 ` Anshuman Khandual 2018-07-30 9:34 ` Christoph Hellwig 2018-07-30 9:34 ` Christoph Hellwig 2018-07-30 10:28 ` Michael S. Tsirkin 2018-07-30 10:28 ` Michael S. Tsirkin 2018-07-30 11:18 ` Christoph Hellwig 2018-07-30 11:18 ` Christoph Hellwig 2018-07-30 13:26 ` Michael S. Tsirkin [this message] 2018-07-30 13:26 ` Michael S. Tsirkin 2018-07-31 17:30 ` Christoph Hellwig 2018-07-31 17:30 ` Christoph Hellwig 2018-07-31 20:36 ` Benjamin Herrenschmidt 2018-07-31 20:36 ` Benjamin Herrenschmidt 2018-08-01 8:16 ` Will Deacon 2018-08-01 8:16 ` Will Deacon 2018-08-01 8:36 ` Christoph Hellwig 2018-08-01 8:36 ` Christoph Hellwig 2018-08-01 8:36 ` Christoph Hellwig 2018-08-01 9:05 ` Will Deacon 2018-08-01 9:05 ` Will Deacon 2018-08-01 22:41 ` Michael S. Tsirkin 2018-08-01 22:41 ` Michael S. Tsirkin 2018-08-01 22:35 ` Michael S. Tsirkin 2018-08-01 22:35 ` Michael S. Tsirkin 2018-08-02 15:24 ` Benjamin Herrenschmidt 2018-08-02 15:24 ` Benjamin Herrenschmidt 2018-08-02 15:41 ` Michael S. Tsirkin 2018-08-02 15:41 ` Michael S. Tsirkin 2018-08-02 16:01 ` Benjamin Herrenschmidt 2018-08-02 16:01 ` Benjamin Herrenschmidt 2018-08-02 17:19 ` Michael S. Tsirkin 2018-08-02 17:19 ` Michael S. Tsirkin 2018-08-02 17:53 ` Benjamin Herrenschmidt 2018-08-02 17:53 ` Benjamin Herrenschmidt 2018-08-02 20:52 ` Michael S. Tsirkin 2018-08-02 20:52 ` Michael S. Tsirkin 2018-08-02 21:13 ` Benjamin Herrenschmidt 2018-08-02 21:13 ` Benjamin Herrenschmidt 2018-08-02 21:51 ` Michael S. Tsirkin 2018-08-02 21:51 ` Michael S. Tsirkin 2018-08-03 7:05 ` Christoph Hellwig 2018-08-03 7:05 ` Christoph Hellwig 2018-08-03 15:58 ` Benjamin Herrenschmidt 2018-08-03 15:58 ` Benjamin Herrenschmidt 2018-08-03 16:02 ` Christoph Hellwig 2018-08-03 16:02 ` Christoph Hellwig 2018-08-03 18:58 ` Benjamin Herrenschmidt 2018-08-03 18:58 ` Benjamin Herrenschmidt 2018-08-04 8:21 ` Christoph Hellwig 2018-08-04 8:21 ` Christoph Hellwig 2018-08-05 1:10 ` Benjamin Herrenschmidt 2018-08-05 1:10 ` Benjamin Herrenschmidt 2018-08-05 1:10 ` Benjamin Herrenschmidt 2018-08-05 7:29 ` Christoph Hellwig 2018-08-05 7:29 ` Christoph Hellwig 2018-08-05 21:16 ` Benjamin Herrenschmidt 2018-08-05 21:16 ` Benjamin Herrenschmidt 2018-08-05 21:30 ` Benjamin Herrenschmidt 2018-08-05 21:30 ` Benjamin Herrenschmidt 2018-08-06 9:42 ` Christoph Hellwig 2018-08-06 9:42 ` Christoph Hellwig 2018-08-06 19:52 ` Benjamin Herrenschmidt 2018-08-06 19:52 ` Benjamin Herrenschmidt 2018-08-07 6:21 ` Christoph Hellwig 2018-08-07 6:42 ` Benjamin Herrenschmidt 2018-08-07 6:42 ` Benjamin Herrenschmidt 2018-08-07 13:55 ` Christoph Hellwig 2018-08-07 20:32 ` Benjamin Herrenschmidt 2018-08-07 20:32 ` Benjamin Herrenschmidt 2018-08-08 6:31 ` Christoph Hellwig 2018-08-08 6:31 ` Christoph Hellwig 2018-08-08 10:07 ` Benjamin Herrenschmidt 2018-08-08 10:07 ` Benjamin Herrenschmidt 2018-08-08 12:30 ` Christoph Hellwig 2018-08-08 13:18 ` Benjamin Herrenschmidt 2018-08-08 13:18 ` Benjamin Herrenschmidt 2018-08-08 20:31 ` Michael S. Tsirkin 2018-08-08 22:13 ` Benjamin Herrenschmidt 2018-08-08 22:13 ` Benjamin Herrenschmidt 2018-08-09 2:00 ` Benjamin Herrenschmidt 2018-08-09 2:00 ` Benjamin Herrenschmidt 2018-08-09 5:40 ` Christoph Hellwig 2018-08-09 5:40 ` Christoph Hellwig 2018-09-07 0:09 ` Jiandi An 2018-09-10 6:19 ` Christoph Hellwig 2018-09-10 6:19 ` Christoph Hellwig 2018-09-10 8:53 ` Gerd Hoffmann 2018-09-10 8:53 ` Gerd Hoffmann 2018-08-08 20:31 ` Michael S. Tsirkin 2018-08-08 12:30 ` Christoph Hellwig 2018-08-07 13:55 ` Christoph Hellwig 2018-08-07 6:21 ` Christoph Hellwig 2018-08-03 19:07 ` Michael S. Tsirkin 2018-08-03 19:07 ` Michael S. Tsirkin 2018-08-04 1:11 ` Benjamin Herrenschmidt 2018-08-04 1:11 ` Benjamin Herrenschmidt 2018-08-04 1:16 ` Benjamin Herrenschmidt 2018-08-04 1:16 ` Benjamin Herrenschmidt 2018-08-05 0:22 ` Michael S. Tsirkin 2018-08-05 4:52 ` Benjamin Herrenschmidt 2018-08-05 4:52 ` Benjamin Herrenschmidt 2018-08-06 13:46 ` Michael S. Tsirkin 2018-08-06 19:56 ` Benjamin Herrenschmidt 2018-08-06 19:56 ` Benjamin Herrenschmidt 2018-08-06 20:35 ` Michael S. Tsirkin 2018-08-06 21:26 ` Benjamin Herrenschmidt 2018-08-06 21:26 ` Benjamin Herrenschmidt 2018-08-06 21:46 ` Michael S. Tsirkin 2018-08-06 21:46 ` Michael S. Tsirkin 2018-08-06 22:13 ` Benjamin Herrenschmidt 2018-08-06 22:13 ` Benjamin Herrenschmidt 2018-08-06 23:16 ` Benjamin Herrenschmidt 2018-08-06 23:16 ` Benjamin Herrenschmidt 2018-08-06 23:45 ` Michael S. Tsirkin 2018-08-07 0:18 ` Benjamin Herrenschmidt 2018-08-07 0:18 ` Benjamin Herrenschmidt 2018-08-07 6:32 ` Christoph Hellwig 2018-08-07 6:32 ` Christoph Hellwig 2018-08-06 23:45 ` Michael S. Tsirkin 2018-08-07 6:27 ` Christoph Hellwig 2018-08-07 6:27 ` Christoph Hellwig 2018-08-07 6:44 ` Benjamin Herrenschmidt 2018-08-07 6:44 ` Benjamin Herrenschmidt 2018-08-07 6:18 ` Christoph Hellwig 2018-08-07 6:18 ` Christoph Hellwig 2018-08-07 6:16 ` Christoph Hellwig 2018-08-07 6:16 ` Christoph Hellwig 2018-08-06 23:18 ` Benjamin Herrenschmidt 2018-08-06 23:18 ` Benjamin Herrenschmidt 2018-08-07 6:12 ` Christoph Hellwig 2018-08-07 6:12 ` Christoph Hellwig 2018-08-06 20:35 ` Michael S. Tsirkin 2018-08-06 13:46 ` Michael S. Tsirkin 2018-08-05 0:22 ` Michael S. Tsirkin 2018-08-04 1:18 ` Benjamin Herrenschmidt 2018-08-04 1:18 ` Benjamin Herrenschmidt 2018-08-04 1:22 ` Benjamin Herrenschmidt 2018-08-04 1:22 ` Benjamin Herrenschmidt 2018-08-05 0:23 ` Michael S. Tsirkin 2018-08-05 0:23 ` Michael S. Tsirkin 2018-08-03 19:17 ` Michael S. Tsirkin 2018-08-03 19:17 ` Michael S. Tsirkin 2018-08-04 8:15 ` Christoph Hellwig 2018-08-04 8:15 ` Christoph Hellwig 2018-08-05 0:09 ` Michael S. Tsirkin 2018-08-05 0:09 ` Michael S. Tsirkin 2018-08-05 1:11 ` Benjamin Herrenschmidt 2018-08-05 1:11 ` Benjamin Herrenschmidt 2018-08-05 7:25 ` Christoph Hellwig 2018-08-05 7:25 ` Christoph Hellwig 2018-08-05 0:53 ` Benjamin Herrenschmidt 2018-08-05 0:53 ` Benjamin Herrenschmidt 2018-08-05 0:27 ` Michael S. Tsirkin 2018-08-05 0:27 ` Michael S. Tsirkin 2018-08-06 14:05 ` Will Deacon 2018-08-06 14:05 ` Will Deacon 2018-08-01 21:56 ` Michael S. Tsirkin 2018-08-01 21:56 ` Michael S. Tsirkin 2018-08-02 15:33 ` Benjamin Herrenschmidt 2018-08-02 15:33 ` Benjamin Herrenschmidt 2018-08-02 20:53 ` Michael S. Tsirkin 2018-08-03 7:06 ` Christoph Hellwig 2018-08-03 7:06 ` Christoph Hellwig 2018-08-02 20:53 ` Michael S. Tsirkin 2018-08-02 20:55 ` Michael S. Tsirkin 2018-08-02 20:55 ` Michael S. Tsirkin 2018-08-03 2:41 ` Jason Wang 2018-08-03 2:41 ` Jason Wang 2018-08-03 19:08 ` Michael S. Tsirkin 2018-08-04 1:21 ` Benjamin Herrenschmidt 2018-08-04 1:21 ` Benjamin Herrenschmidt 2018-08-05 0:24 ` Michael S. Tsirkin 2018-08-05 0:24 ` Michael S. Tsirkin 2018-08-06 9:02 ` Anshuman Khandual 2018-08-06 9:02 ` Anshuman Khandual 2018-08-06 13:36 ` Michael S. Tsirkin 2018-08-06 13:36 ` Michael S. Tsirkin 2018-08-06 15:24 ` Christoph Hellwig 2018-08-06 16:06 ` Michael S. Tsirkin 2018-08-06 16:06 ` Michael S. Tsirkin 2018-08-06 16:10 ` Christoph Hellwig 2018-08-06 16:10 ` Christoph Hellwig 2018-08-06 16:13 ` Michael S. Tsirkin 2018-08-06 16:13 ` Michael S. Tsirkin 2018-08-06 16:34 ` Christoph Hellwig 2018-08-06 16:34 ` Christoph Hellwig 2018-08-06 15:24 ` Christoph Hellwig 2018-08-03 19:08 ` Michael S. Tsirkin 2018-07-20 3:59 Anshuman Khandual
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=20180730155633-mutt-send-email-mst@kernel.org \ --to=mst@redhat.com \ --cc=aik@ozlabs.ru \ --cc=benh@kernel.crashing.org \ --cc=david@gibson.dropbear.id.au \ --cc=elfring@users.sourceforge.net \ --cc=haren@linux.vnet.ibm.com \ --cc=hch@infradead.org \ --cc=jasowang@redhat.com \ --cc=jean-philippe.brucker@arm.com \ --cc=joe@perches.com \ --cc=khandual@linux.vnet.ibm.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=linuxram@us.ibm.com \ --cc=marc.zyngier@arm.com \ --cc=mpe@ellerman.id.au \ --cc=paulus@samba.org \ --cc=robh@kernel.org \ --cc=robin.murphy@arm.com \ --cc=srikar@linux.vnet.ibm.com \ --cc=virtualization@lists.linux-foundation.org \ --cc=will.deacon@arm.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: linkBe 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.