[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1447184187.31884.89.camel@kernel.crashing.org>
Date: Wed, 11 Nov 2015 06:36:27 +1100
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Joerg Roedel <jroedel@...e.de>
Cc: Andy Lutomirski <luto@...capital.net>,
Andy Lutomirski <luto@...nel.org>,
David Woodhouse <dwmw2@...radead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
sparclinux@...r.kernel.org,
Christian Borntraeger <borntraeger@...ibm.com>,
Cornelia Huck <cornelia.huck@...ibm.com>,
Sebastian Ott <sebott@...ux.vnet.ibm.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Christoph Hellwig <hch@....de>, KVM <kvm@...r.kernel.org>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
linux-s390 <linux-s390@...r.kernel.org>,
Linux Virtualization <virtualization@...ts.linux-foundation.org>,
"Michael S. Tsirkin" <mst@...hat.com>
Subject: Re: [PATCH v4 0/6] virtio core DMA API conversion
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists