From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Joerg Roedel <jroedel@suse.de>
Cc: linux-s390 <linux-s390@vger.kernel.org>,
KVM <kvm@vger.kernel.org>, "Michael S. Tsirkin" <mst@redhat.com>,
Sebastian Ott <sebott@linux.vnet.ibm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andy Lutomirski <luto@amacapital.net>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Christoph Hellwig <hch@lst.de>, Andy Lutomirski <luto@kernel.org>,
sparclinux@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Linux Virtualization <virtualization@lists.linux-foundation.org>,
David Woodhouse <dwmw2@infradead.org>,
"David S. Miller" <davem@davemloft.net>,
Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [PATCH v4 0/6] virtio core DMA API conversion
Date: Wed, 11 Nov 2015 06:36:27 +1100 [thread overview]
Message-ID: <1447184187.31884.89.camel@kernel.crashing.org> (raw)
In-Reply-To: <20151110102733.GJ2255@suse.de>
On Tue, 2015-11-10 at 11:27 +0100, Joerg Roedel wrote:
>
> You have the same problem when real PCIe devices appear that speak
> virtio. I think the only real (still not very nice) solution is to add a
> quirk to powerpc platform code that sets noop dma-ops for the existing
> virtio vendor/device-ids and add a DT property to opt-out of that quirk.
>
> New vendor/device-ids (as for real devices) would just not be covered by
> the quirk and existing emulated devices continue to work.
Why woud real devices use new vendor/device IDs ? Also there are other
cases such as using virtio between 2 partitions, which we could do
under PowerVM ... that would require proper iommu usage with existing
IDs.
> The absence of the property just means that the quirk is in place and
> the system assumes no translation for virtio devices.
The only way that works forward for me (and possibly sparc & others,
what about ARM ?) is if we *change* something in virtio qemu at the
same time as we add some kind of property. For example the ProgIf field
or revision ID field.
That way I can key on that change.
It's still tricky because I would have to somewhat tell my various firmwares
(SLOF, OpenBIOS, OPAL, ...) so they can create the appropriate property, it's
still hacky, but it would be workable.
Ben.
next prev parent reply other threads:[~2015-11-10 19:36 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1446162273.git.luto@kernel.org>
2015-10-30 1:09 ` [PATCH v4 1/6] virtio-net: Stop doing DMA from the stack Andy Lutomirski
2015-10-30 1:09 ` [PATCH v4 2/6] virtio_ring: Support DMA APIs Andy Lutomirski
2015-10-30 1:09 ` [PATCH v4 3/6] virtio_pci: Use the DMA API Andy Lutomirski
2015-10-30 1:09 ` [PATCH v4 4/6] virtio: Add improved queue allocation API Andy Lutomirski
2015-10-30 1:09 ` [PATCH v4 5/6] virtio_mmio: Use the DMA API Andy Lutomirski
2015-10-30 1:09 ` [PATCH v4 6/6] virtio_pci: " Andy Lutomirski
2015-10-30 1:17 ` [PATCH v4 0/6] virtio core DMA API conversion Andy Lutomirski
2015-10-30 9:57 ` Christian Borntraeger
[not found] ` <7c590bf685f5cbc3f01e42bdbc1dbe3ffd83420f.1446162273.git.luto@kernel.org>
2015-10-30 12:01 ` [PATCH v4 2/6] virtio_ring: Support DMA APIs Cornelia Huck
2015-10-30 12:05 ` Christian Borntraeger
2015-10-30 18:51 ` Andy Lutomirski
[not found] ` <8d6b1fc3b5d3b6f5e8b212ef690691a52fbefaff.1446162273.git.luto@kernel.org>
2015-10-30 13:55 ` [PATCH v4 1/6] virtio-net: Stop doing DMA from the stack Christian Borntraeger
[not found] ` <563376D2.20502@de.ibm.com>
2015-10-31 5:02 ` Andy Lutomirski
2015-11-09 12:15 ` [PATCH v4 0/6] virtio core DMA API conversion Michael S. Tsirkin
2015-11-09 12:27 ` Paolo Bonzini
2015-11-09 22:58 ` Benjamin Herrenschmidt
2015-11-10 0:46 ` Andy Lutomirski
2015-11-10 2:04 ` Benjamin Herrenschmidt
2015-11-10 2:18 ` Andy Lutomirski
[not found] ` <CALCETrW5_bKCX5gKYaH5y4rvD9jrjY5O5d=oX8hHtAM9EE2Bew@mail.gmail.com>
2015-11-10 5:26 ` Benjamin Herrenschmidt
2015-11-10 5:33 ` Andy Lutomirski
2015-11-10 5:28 ` Benjamin Herrenschmidt
2015-11-10 5:35 ` Andy Lutomirski
[not found] ` <CALCETrVPQc04Ah7FXcRMb4RhpUJ1WPCoC_4dbacB8a+u5XpmwA@mail.gmail.com>
2015-11-10 10:37 ` Benjamin Herrenschmidt
2015-11-10 12:43 ` Michael S. Tsirkin
2015-11-10 18:54 ` Andy Lutomirski
2015-11-10 22:27 ` Benjamin Herrenschmidt
2015-11-10 23:44 ` Andy Lutomirski
[not found] ` <CALCETrWb9poeyxXhcbAbQkpcP-XYjWtz2w9iSPkKJH8rdzAj-A@mail.gmail.com>
2015-11-11 0:44 ` Benjamin Herrenschmidt
2015-11-11 4:46 ` Andy Lutomirski
2015-11-11 5:08 ` Benjamin Herrenschmidt
[not found] ` <20151110142633-mutt-send-email-mst@redhat.com>
2015-11-10 19:37 ` Benjamin Herrenschmidt
2015-11-10 7:28 ` Jan Kiszka
2015-11-10 9:45 ` Knut Omang
[not found] ` <1447148714.3005.133.camel@oracle.com>
2015-11-10 10:26 ` Benjamin Herrenschmidt
2015-11-10 10:27 ` Joerg Roedel
2015-11-10 19:36 ` Benjamin Herrenschmidt [this message]
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=1447184187.31884.89.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=borntraeger@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@amacapital.net \
--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 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).