All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Andy Lutomirski <luto@kernel.org>, dwmw2@infradead.org
Cc: linux-kernel@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	sparclinux@vger.kernel.org, Joerg Roedel <jroedel@suse.de>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Cornelia Huck <cornelia.huck@de.ibm.com>,
	Sebastian Ott <sebott@linux.vnet.ibm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Christoph Hellwig <hch@lst.de>, KVM <kvm@vger.kernel.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	linux-s390 <linux-s390@vger.kernel.org>,
	virtualization@lists.linux-foundation.org,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH v4 0/6] virtio core DMA API conversion
Date: Tue, 10 Nov 2015 09:58:57 +1100	[thread overview]
Message-ID: <1447109937.31884.42.camel@kernel.crashing.org> (raw)
In-Reply-To: <20151109133624-mutt-send-email-mst@redhat.com>

So ...

I've finally tried to sort that out for powerpc and I can't find a way
to make that work that isn't a complete pile of stinking shit.

I'm very tempted to go back to my original idea: virtio itself should
indicate it's "bypassing ability" via the virtio config space or some
other bit (like the ProgIf of the PCI header etc...).

I don't see how I can make it work otherwise.

The problem with the statement "it's a platform matter" is that:

  - It's not entirely correct. It's actually a feature of a specific
virtio implementation (qemu's) that it bypasses all the platform IOMMU
facilities.

  - The platforms (on powerpc there's at least 3 or 4 that have qemu
emulation and support some form of PCI) don't have an existing way to
convey the information that a device bypasses the IOMMU (if any).

  - Even if we add such a mechanism (new property in the device-tree),
we end up with a big turd: Because we need to be compatible with older
qemus, we essentially need a quirk that will make all virtio devices
assume that property is present. That will of course break whenever we
try to use another implementation of virtio on powerpc which doesn't
bypass the iommu.

We don't have a way to differenciate a virtio device that does the
bypass from one that doesn't and the backward compatibility requirement
forces us to treat all existing virtio devices as doing bypass.

The only way out of this while keeping the "platform" stuff would be to
also bump some kind of version in the virtio config (or PCI header). I
have no other way to differenciate between "this is an old qemu that
doesn't do the 'bypass property' yet" from "this is a virtio device
that doesn't bypass".

Any better idea ?

Cheers,
Ben.



WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Andy Lutomirski <luto@kernel.org>, dwmw2@infradead.org
Cc: linux-s390 <linux-s390@vger.kernel.org>,
	Joerg Roedel <jroedel@suse.de>, KVM <kvm@vger.kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Sebastian Ott <sebott@linux.vnet.ibm.com>,
	linux-kernel@vger.kernel.org,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	sparclinux@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	virtualization@lists.linux-foundation.org,
	Christoph Hellwig <hch@lst.de>,
	"David S. Miller" <davem@davemloft.net>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [PATCH v4 0/6] virtio core DMA API conversion
Date: Tue, 10 Nov 2015 09:58:57 +1100	[thread overview]
Message-ID: <1447109937.31884.42.camel@kernel.crashing.org> (raw)
In-Reply-To: <20151109133624-mutt-send-email-mst@redhat.com>

So ...

I've finally tried to sort that out for powerpc and I can't find a way
to make that work that isn't a complete pile of stinking shit.

I'm very tempted to go back to my original idea: virtio itself should
indicate it's "bypassing ability" via the virtio config space or some
other bit (like the ProgIf of the PCI header etc...).

I don't see how I can make it work otherwise.

The problem with the statement "it's a platform matter" is that:

  - It's not entirely correct. It's actually a feature of a specific
virtio implementation (qemu's) that it bypasses all the platform IOMMU
facilities.

  - The platforms (on powerpc there's at least 3 or 4 that have qemu
emulation and support some form of PCI) don't have an existing way to
convey the information that a device bypasses the IOMMU (if any).

  - Even if we add such a mechanism (new property in the device-tree),
we end up with a big turd: Because we need to be compatible with older
qemus, we essentially need a quirk that will make all virtio devices
assume that property is present. That will of course break whenever we
try to use another implementation of virtio on powerpc which doesn't
bypass the iommu.

We don't have a way to differenciate a virtio device that does the
bypass from one that doesn't and the backward compatibility requirement
forces us to treat all existing virtio devices as doing bypass.

The only way out of this while keeping the "platform" stuff would be to
also bump some kind of version in the virtio config (or PCI header). I
have no other way to differenciate between "this is an old qemu that
doesn't do the 'bypass property' yet" from "this is a virtio device
that doesn't bypass".

Any better idea ?

Cheers,
Ben.


_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Andy Lutomirski <luto@kernel.org>, dwmw2@infradead.org
Cc: linux-s390 <linux-s390@vger.kernel.org>,
	Joerg Roedel <jroedel@suse.de>, KVM <kvm@vger.kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Sebastian Ott <sebott@linux.vnet.ibm.com>,
	linux-kernel@vger.kernel.org,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	sparclinux@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	virtualization@lists.linux-foundation.org,
	Christoph Hellwig <hch@lst.de>,
	"David S. Miller" <davem@davemloft.net>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [PATCH v4 0/6] virtio core DMA API conversion
Date: Mon, 09 Nov 2015 22:58:57 +0000	[thread overview]
Message-ID: <1447109937.31884.42.camel@kernel.crashing.org> (raw)
In-Reply-To: <20151109133624-mutt-send-email-mst@redhat.com>

So ...

I've finally tried to sort that out for powerpc and I can't find a way
to make that work that isn't a complete pile of stinking shit.

I'm very tempted to go back to my original idea: virtio itself should
indicate it's "bypassing ability" via the virtio config space or some
other bit (like the ProgIf of the PCI header etc...).

I don't see how I can make it work otherwise.

The problem with the statement "it's a platform matter" is that:

  - It's not entirely correct. It's actually a feature of a specific
virtio implementation (qemu's) that it bypasses all the platform IOMMU
facilities.

  - The platforms (on powerpc there's at least 3 or 4 that have qemu
emulation and support some form of PCI) don't have an existing way to
convey the information that a device bypasses the IOMMU (if any).

  - Even if we add such a mechanism (new property in the device-tree),
we end up with a big turd: Because we need to be compatible with older
qemus, we essentially need a quirk that will make all virtio devices
assume that property is present. That will of course break whenever we
try to use another implementation of virtio on powerpc which doesn't
bypass the iommu.

We don't have a way to differenciate a virtio device that does the
bypass from one that doesn't and the backward compatibility requirement
forces us to treat all existing virtio devices as doing bypass.

The only way out of this while keeping the "platform" stuff would be to
also bump some kind of version in the virtio config (or PCI header). I
have no other way to differenciate between "this is an old qemu that
doesn't do the 'bypass property' yet" from "this is a virtio device
that doesn't bypass".

Any better idea ?

Cheers,
Ben.



  parent reply	other threads:[~2015-11-09 23:21 UTC|newest]

Thread overview: 116+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-30  1:09 [PATCH v4 0/6] virtio core DMA API conversion Andy Lutomirski
2015-10-30  1:09 ` Andy Lutomirski
2015-10-30  1:09 ` [PATCH v4 1/6] virtio-net: Stop doing DMA from the stack Andy Lutomirski
2015-10-30  1:09 ` Andy Lutomirski
2015-10-30  1:09   ` Andy Lutomirski
2015-10-30 13:55   ` Christian Borntraeger
2015-10-30 13:55     ` Christian Borntraeger
2015-10-31  5:02     ` Andy Lutomirski
2015-10-31  5:02       ` Andy Lutomirski
2015-10-31  5:02       ` Andy Lutomirski
2015-10-30 13:55   ` Christian Borntraeger
2015-10-30  1:09 ` [PATCH v4 2/6] virtio_ring: Support DMA APIs Andy Lutomirski
2015-10-30  1:09   ` Andy Lutomirski
2015-10-30 12:01   ` Cornelia Huck
2015-10-30 12:01     ` Cornelia Huck
2015-10-30 12:01     ` Cornelia Huck
2015-10-30 12:05     ` Christian Borntraeger
2015-10-30 12:05       ` Christian Borntraeger
2015-10-30 12:05       ` Christian Borntraeger
2015-10-30 18:51       ` Andy Lutomirski
2015-10-30 18:51       ` Andy Lutomirski
2015-10-30 18:51         ` Andy Lutomirski
2015-10-30  1:09 ` Andy Lutomirski
2015-10-30  1:09 ` [PATCH v4 3/6] virtio_pci: Use the DMA API Andy Lutomirski
2015-10-30  1:09 ` Andy Lutomirski
2015-10-30  1:09   ` Andy Lutomirski
2015-10-30  1:09 ` [PATCH v4 4/6] virtio: Add improved queue allocation API Andy Lutomirski
2015-10-30  1:09   ` Andy Lutomirski
2015-10-30  1:09 ` Andy Lutomirski
2015-10-30  1:09 ` [PATCH v4 5/6] virtio_mmio: Use the DMA API Andy Lutomirski
2015-10-30  1:09   ` Andy Lutomirski
2015-10-30  1:09 ` Andy Lutomirski
2015-10-30  1:09 ` [PATCH v4 6/6] virtio_pci: " Andy Lutomirski
2015-10-30  1:09   ` Andy Lutomirski
2015-10-30  1:09 ` Andy Lutomirski
2015-10-30  1:17 ` [PATCH v4 0/6] virtio core DMA API conversion Andy Lutomirski
2015-10-30  1:17   ` Andy Lutomirski
2015-10-30  1:17   ` Andy Lutomirski
2015-10-30  9:57 ` Christian Borntraeger
2015-10-30  9:57   ` Christian Borntraeger
2015-10-30  9:57 ` Christian Borntraeger
2015-11-09 12:15 ` Michael S. Tsirkin
2015-11-09 12:15   ` Michael S. Tsirkin
2015-11-09 12:15   ` Michael S. Tsirkin
2015-11-09 12:27   ` Paolo Bonzini
2015-11-09 12:27     ` Paolo Bonzini
2015-11-09 12:27   ` Paolo Bonzini
2015-11-09 22:58   ` Benjamin Herrenschmidt [this message]
2015-11-09 22:58     ` Benjamin Herrenschmidt
2015-11-09 22:58     ` Benjamin Herrenschmidt
2015-11-10  0:46     ` Andy Lutomirski
2015-11-10  0:46       ` Andy Lutomirski
2015-11-10  0:46       ` Andy Lutomirski
2015-11-10  2:04       ` Benjamin Herrenschmidt
2015-11-10  2:04         ` Benjamin Herrenschmidt
2015-11-10  2:04         ` Benjamin Herrenschmidt
2015-11-10  2:18         ` Andy Lutomirski
2015-11-10  2:18         ` Andy Lutomirski
2015-11-10  2:18           ` Andy Lutomirski
2015-11-10  5:26           ` Benjamin Herrenschmidt
2015-11-10  5:26             ` Benjamin Herrenschmidt
2015-11-10  5:26             ` Benjamin Herrenschmidt
2015-11-10  5:33             ` Andy Lutomirski
2015-11-10  5:33             ` Andy Lutomirski
2015-11-10  5:33               ` Andy Lutomirski
2015-11-10  5:28           ` Benjamin Herrenschmidt
2015-11-10  5:28             ` Benjamin Herrenschmidt
2015-11-10  5:28             ` Benjamin Herrenschmidt
2015-11-10  5:35             ` Andy Lutomirski
2015-11-10  5:35             ` Andy Lutomirski
2015-11-10  5:35               ` Andy Lutomirski
2015-11-10 10:37               ` Benjamin Herrenschmidt
2015-11-10 10:37                 ` Benjamin Herrenschmidt
2015-11-10 10:37                 ` Benjamin Herrenschmidt
2015-11-10 12:43                 ` Michael S. Tsirkin
2015-11-10 12:43                   ` Michael S. Tsirkin
2015-11-10 12:43                   ` Michael S. Tsirkin
2015-11-10 19:37                   ` Benjamin Herrenschmidt
2015-11-10 19:37                     ` Benjamin Herrenschmidt
2015-11-10 19:37                     ` Benjamin Herrenschmidt
2015-11-10 12:43                 ` Michael S. Tsirkin
2015-11-10 18:54                 ` Andy Lutomirski
2015-11-10 18:54                   ` Andy Lutomirski
2015-11-10 18:54                   ` Andy Lutomirski
2015-11-10 22:27                   ` Benjamin Herrenschmidt
2015-11-10 22:27                     ` Benjamin Herrenschmidt
2015-11-10 22:27                     ` Benjamin Herrenschmidt
2015-11-10 23:44                     ` Andy Lutomirski
2015-11-10 23:44                     ` Andy Lutomirski
2015-11-10 23:44                       ` Andy Lutomirski
2015-11-11  0:44                       ` Benjamin Herrenschmidt
2015-11-11  0:44                         ` Benjamin Herrenschmidt
2015-11-11  0:44                         ` Benjamin Herrenschmidt
2015-11-11  4:46                         ` Andy Lutomirski
2015-11-11  4:46                           ` Andy Lutomirski
2015-11-11  4:46                           ` Andy Lutomirski
2015-11-11  5:08                           ` Benjamin Herrenschmidt
2015-11-11  5:08                             ` Benjamin Herrenschmidt
2015-11-11  5:08                             ` Benjamin Herrenschmidt
2015-11-10  7:28           ` Jan Kiszka
2015-11-10  7:28             ` Jan Kiszka
2015-11-10  7:28             ` Jan Kiszka
2015-11-10  7:28             ` Jan Kiszka
2015-11-10  9:45         ` Knut Omang
2015-11-10  9:45         ` Knut Omang
2015-11-10  9:45           ` Knut Omang
2015-11-10 10:26           ` Benjamin Herrenschmidt
2015-11-10 10:26             ` Benjamin Herrenschmidt
2015-11-10 10:26             ` Benjamin Herrenschmidt
2015-11-10 10:27         ` Joerg Roedel
2015-11-10 10:27           ` Joerg Roedel
2015-11-10 10:27           ` Joerg Roedel
2015-11-10 19:36           ` Benjamin Herrenschmidt
2015-11-10 19:36             ` Benjamin Herrenschmidt
2015-11-10 19:36             ` Benjamin Herrenschmidt
  -- strict thread matches above, loose matches on Subject: below --
2015-10-30  1:09 Andy Lutomirski

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=1447109937.31884.42.camel@kernel.crashing.org \
    --to=benh@kernel.crashing.org \
    --cc=borntraeger@de.ibm.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=davem@davemloft.net \
    --cc=dwmw2@infradead.org \
    --cc=hch@lst.de \
    --cc=jroedel@suse.de \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=sebott@linux.vnet.ibm.com \
    --cc=sparclinux@vger.kernel.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 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.