lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160725214322-mutt-send-email-mst@kernel.org>
Date:	Mon, 25 Jul 2016 22:13:05 +0300
From:	"Michael S. Tsirkin" <mst@...hat.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	linux-kernel@...r.kernel.org,
	virtualization@...ts.linux-foundation.org
Subject: Re: [PATCH v3] virtio: new feature to detect IOMMU device quirk

On Mon, Jul 25, 2016 at 12:50:09AM -0700, Christoph Hellwig wrote:
> On Tue, Jul 19, 2016 at 05:38:23AM +0300, Michael S. Tsirkin wrote:
> > 
> > On other systems, including SPARC and PPC64, virtio-pci devices are
> > enumerated as though they are behind an IOMMU, but the virtio host
> > ignores the IOMMU, so we must either pretend that the IOMMU isn't
> > there or somehow map everything as the identity.
> > 
> > Add a feature bit to detect that quirk: VIRTIO_F_IOMMU_PLATFORM.
> > 
> > Any device with this feature bit set to 0 needs a quirk and has to be
> > passed physical addresses (as opposed to bus addresses) even though
> > the device is behind an IOMMU.
> 
> This is the wrong way around.

Well given there are tons of quirky devices out there
and they have this bit set to 0, I don't think we can change this.
New devices will have it set to 1.

> > Note: it has to be a per-device quirk because for example, there could
> > be a mix of passed-through and virtual virtio devices. As another
> > example, some devices could be implemented by an out of process
> > hypervisor backend (in case of qemu vhost, or vhost-user) and so support
> > for an IOMMU needs to be coded up separately.
> > 
> > It would be cleanest to handle this in IOMMU core code, but that needs
> > per-device DMA ops. While we are waiting for that to be implemented, use
> > a work-around in virtio core.
> > 
> > Signed-off-by: Michael S. Tsirkin <mst@...hat.com>
> > ---
> > 
> > wanted to use per-device dma ops but that does not
> > seem to be ready. So let's put this in virtio
> > code for now, and move when it becomes possible.
> 
> So work on making it ready.  We're close to there, and given that
> virtio needs it, finish it off.  We now have everyone using the
> operation vectors for DMA, so the only thing you need is a dma_ops
> pointer in struct device initialized to what get_dma_ops returns.

And then pci_dma_configure would have a quirk to
set that for legacy virtio devices?

-- 
MST

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ