qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: valentine.sinitsyn@gmail.com, marcel@redhat.com,
	David Kiarie <davidkiarie4@gmail.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [V6 0/4] AMD IOMMU
Date: Tue, 1 Mar 2016 22:39:54 +0200	[thread overview]
Message-ID: <20160301223551-mutt-send-email-mst@redhat.com> (raw)
In-Reply-To: <56D5F8F6.2000001@siemens.com>

On Tue, Mar 01, 2016 at 09:17:58PM +0100, Jan Kiszka wrote:
> On 2016-03-01 21:11, Michael S. Tsirkin wrote:
> > On Tue, Mar 01, 2016 at 03:00:09PM +0100, Jan Kiszka wrote:
> >> On 2016-03-01 14:48, Jan Kiszka wrote:
> >>> There is likely no way around write-protecting the IOMMU page tables (in
> >>> KVM mode) once we evaluated and cached them somewhere.
> >>
> >> I mean, when in kvm mode AND having something that caches enabled, of
> >> course.
> > 
> > Just write-protecting won't be enough either, since
> > the moment you remove the protection, all bets are off,
> > and if you don't, guest will start from the same point
> > when you re-enter and fault again.
> 
> We would not remove protection as long as the entry is in use by the
> IOMMU. There should be no difference from shadow MMU logic here: trap
> and emulate the write.

Oh that's a nice trick. So you only write-protect it when you detect
that a range was invalidated.  Unfortunately it has page granularity so
a single invalid PTE causes faults for writes to all others sharing a
page with it.

> > 
> > What this seems to call for is a new kind of protection
> > where yes PTE is write protected, but instead of
> > making PTE writeable (or killing guest)
> > KVM handles it as an MMIO: emulates the write and then skips the instruction.
> > 
> > Emulation can be in kernel, just writing into guest memory
> > on behalf of the guest - with some kind of notifier
> > to flush the vfio cache - or instead it can exit to userspace
> > and have QEMU handle it like MMIO and write into guest memory.
> 
> Exactly, but that's nothing new, is it? It's "just" slow, like other
> shadow MMUs.
> 
> Jan

Well AFAIK KVM does not have such an option ATM: MMIO causes exits for
reads and writes.  We want MMIO exits for writes but not reads.
I agree it should be easy to implement.


> -- 
> Siemens AG, Corporate Technology, CT RDA ITP SES-DE
> Corporate Competence Center Embedded Linux

  reply	other threads:[~2016-03-01 20:40 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-21 18:10 [Qemu-devel] [V6 0/4] AMD IOMMU David Kiarie
2016-02-21 18:10 ` [Qemu-devel] [V6 1/4] hw/i386: Introduce " David Kiarie
2016-02-25 15:43   ` Marcel Apfelbaum
2016-02-26  6:23     ` David Kiarie
2016-03-02  4:00       ` David Kiarie
2016-03-02  4:08         ` David Kiarie
2016-03-03  9:40           ` Marcel Apfelbaum
2016-03-03  9:34         ` Marcel Apfelbaum
2016-03-02 19:11     ` David Kiarie
2016-03-03 12:16       ` Marcel Apfelbaum
2016-02-21 18:10 ` [Qemu-devel] [V6 2/4] hw/core: Add AMD IOMMU to machine properties David Kiarie
2016-02-21 20:09   ` Jan Kiszka
2016-03-02 20:51     ` David Kiarie
2016-03-03  9:28       ` Marcel Apfelbaum
2016-03-11 13:20   ` Michael S. Tsirkin
2016-02-21 18:10 ` [Qemu-devel] [V6 3/4] hw/i386: ACPI table for AMD IOMMU David Kiarie
2016-02-21 18:20   ` Jan Kiszka
2016-02-21 19:00     ` David Kiarie
2016-02-21 18:11 ` [Qemu-devel] [V6 4/4] hw/pci-host: Emulate " David Kiarie
2016-02-22 11:22   ` Marcel Apfelbaum
     [not found]     ` <56D75688.1020500@gmail.com>
2016-03-02 21:17       ` Michael S. Tsirkin
2016-03-02 22:04         ` David Kiarie
2016-03-03  9:49           ` Michael S. Tsirkin
2016-03-03 11:47             ` David Kiarie
2016-03-03 12:02               ` Marcel Apfelbaum
2016-03-03 12:06                 ` Marcel Apfelbaum
2016-03-03 12:18                   ` David Kiarie
2016-03-03 12:58                     ` Michael S. Tsirkin
2016-03-08 17:15             ` David Kiarie
2016-03-11 13:22   ` Michael S. Tsirkin
2016-03-13  0:14     ` David Kiarie
2016-03-13 13:59       ` Michael S. Tsirkin
2016-02-21 20:20 ` [Qemu-devel] [V6 0/4] " Jan Kiszka
2016-02-22  5:57   ` David Kiarie
2016-02-22  7:29     ` Jan Kiszka
2016-02-22 11:05       ` David Kiarie
2016-02-22 11:12         ` Jan Kiszka
2016-03-01 13:07 ` Michael S. Tsirkin
2016-03-01 13:48   ` Jan Kiszka
2016-03-01 13:55     ` Michael S. Tsirkin
2016-03-01 14:12       ` Jan Kiszka
2016-03-01 14:18         ` Jan Kiszka
2016-03-01 14:30           ` Michael S. Tsirkin
2016-03-01 14:35             ` Jan Kiszka
2016-03-01 14:19         ` Michael S. Tsirkin
2016-03-01 14:00     ` Jan Kiszka
2016-03-01 20:11       ` Michael S. Tsirkin
2016-03-01 20:17         ` Jan Kiszka
2016-03-01 20:39           ` Michael S. Tsirkin [this message]
2016-03-01 21:23             ` Jan Kiszka
2016-03-01 22:35               ` Michael S. Tsirkin
2016-03-02 21:17     ` David Kiarie
2016-03-02 21:32       ` Michael S. Tsirkin

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=20160301223551-mutt-send-email-mst@redhat.com \
    --to=mst@redhat.com \
    --cc=davidkiarie4@gmail.com \
    --cc=jan.kiszka@siemens.com \
    --cc=marcel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=valentine.sinitsyn@gmail.com \
    /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).