public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: "linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Linux Virtualization <virtualization@lists.linux-foundation.org>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	"linux390@de.ibm.com" <linux390@de.ibm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH v5 2/3] virtio_pci: Use the DMA API for virtqueues when possible
Date: Thu, 25 Sep 2014 08:38:19 +1000	[thread overview]
Message-ID: <1411598299.4184.53.camel@pasglop> (raw)
In-Reply-To: <CALCETrUGRCNT-bhfeYoVuFA1TAwjtadCEOLMbAQ_xN6A0GVPaQ@mail.gmail.com>

On Wed, 2014-09-24 at 15:15 -0700, Andy Lutomirski wrote:
> On Wed, Sep 24, 2014 at 3:04 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Wed, 2014-09-24 at 14:59 -0700, Andy Lutomirski wrote:
> >
> >> Scratch that idea, then.
> >>
> >> The best that I can currently come up with is to say that pre-1.0
> >> devices on PPC bypass the IOMMU and that 1.0 devices on PPC and all
> >> devices on all other architectures do not bypass the IOMMU.
> >
> > Well, the thing is, we *want* them to bypass the IOMMU for performance
> > reasons in the long run. Today we have no ways to tell our guests that
> > a PCI bus doesn't have an IOMMU, they always do !
> 
> Alternatively, the IOMMU could be extended to allow an efficient
> identity map of the entire physical address space.

We have that option, but I'm a bit reluctant to rely on it, it has its
issues, but it's something we can look into.

> > Also qemu can mix and match devices on a given PCI bus so making this a
> > bus property wouldn't work either.
> >
> >> I agree that this is far from ideal.  Any ideas?  Is there any other
> >> channel that QEMU can use to signal to a PPC guest that a specific PCI
> >> virtio device isn't really behind an IOMMU?
> >
> > Any reason why this can't be a virtio capability ?
> >
> 
> For Xen.

And ? I don't see the problem... When running Xen, you don't put the
capability in. They are negociated... Why can't qemu set the capability
accordingly based on whether it's using KVM or Xen ? It's not like we
care about backward compat of ppc on Xen anyway...


 .../...

> a) IOMMU should be used.
> b) Device is trusted but the IOMMU still works.  The guest may want to
> set up an identity map.
> c) (PPC only) Device bypasses the IOMMU.  There's no security issue
> here: a malicious device wouldn't be able to bypass the IOMMU, so it
> would be unable to do DMA at all.

I wouldn't make it "ppc only" at this point but yes. Also keep in mind
that we do have ppc cases where we will want to use the iommu (in which
case the capability would be enforced by the other half).

Cheers,
Ben.

> --Andy
> 
> >> From my POV, the main
> >> consideration is that existing QEMU versions hosting Xen hypervisors
> >> should work, which is not the case in current kernels, but which is
> >> the case with my patches without any known regressions.
> >>
> >> Is there some evil trick that a PPC guest could use to detect whether
> >> the IOMMU is honored?  As an example that I don't like at all, the
> >> guest could program the IOMMU so that the ring's physical address maps
> >> to a second copy of the ring and then see which one works.
> >
> > Cheers,
> > Ben.
> >
> >
> 
> 
> 

  reply	other threads:[~2014-09-24 22:38 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-17  5:22 [PATCH v5 0/3] virtio: Use the DMA API when appropriate Andy Lutomirski
2014-09-17  5:22 ` [PATCH v5 1/3] virtio_ring: Support DMA APIs if requested Andy Lutomirski
2014-09-17  5:22 ` [PATCH v5 2/3] virtio_pci: Use the DMA API for virtqueues when possible Andy Lutomirski
2014-09-17 12:02   ` Benjamin Herrenschmidt
2014-09-17 14:16     ` Michael S. Tsirkin
2014-09-17 16:07       ` Andy Lutomirski
2014-09-17 16:49         ` David Woodhouse
2014-09-19 21:28           ` Benjamin Herrenschmidt
2014-09-19 21:33         ` Benjamin Herrenschmidt
2014-09-20  5:59           ` Andy Lutomirski
2014-09-21  5:03             ` Benjamin Herrenschmidt
2014-09-21  5:05               ` Benjamin Herrenschmidt
2014-09-21  5:48                 ` Andy Lutomirski
2014-09-21  6:01                   ` David Woodhouse
2014-09-24 21:41                 ` Andy Lutomirski
2014-09-24 21:50                   ` Benjamin Herrenschmidt
2014-09-24 21:59                     ` Andy Lutomirski
2014-09-24 22:04                       ` Benjamin Herrenschmidt
2014-09-24 22:15                         ` Andy Lutomirski
2014-09-24 22:38                           ` Benjamin Herrenschmidt [this message]
2014-09-24 22:49                             ` Andy Lutomirski
2014-09-19 21:31       ` Benjamin Herrenschmidt
2014-09-29 18:55       ` Andy Lutomirski
2014-09-29 20:49         ` Benjamin Herrenschmidt
2014-09-29 20:55           ` Andy Lutomirski
2014-09-29 21:06             ` Benjamin Herrenschmidt
2014-09-30 15:38             ` Michael S. Tsirkin
2014-09-30 15:48               ` Andy Lutomirski
2014-09-30 16:19                 ` Andy Lutomirski
2014-09-30 17:53                 ` Konrad Rzeszutek Wilk
2014-09-30 18:01                   ` Andy Lutomirski
2014-10-02 16:36                     ` Konrad Rzeszutek Wilk
2014-10-01  6:42                 ` Michael S. Tsirkin
2014-09-30 15:53               ` Paolo Bonzini
2014-10-01  7:36                 ` Michael S. Tsirkin
2014-09-30 20:05               ` Andy Lutomirski
2014-10-06  9:59         ` Christian Borntraeger
2014-10-06 10:48           ` Benjamin Herrenschmidt
2014-09-17 16:09   ` Ira W. Snyder
2014-09-17 16:15     ` Andy Lutomirski
2014-09-17  5:22 ` [PATCH v5 3/3] virtio_net: Stop doing DMA from the stack Andy Lutomirski
2014-09-19 18:25 ` [PATCH v5 0/3] virtio: Use the DMA API when appropriate Konrad Rzeszutek Wilk

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=1411598299.4184.53.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=borntraeger@de.ibm.com \
    --cc=dwmw2@infradead.org \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux390@de.ibm.com \
    --cc=luto@amacapital.net \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --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