From: Muli Ben-Yehuda <muli@il.ibm.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: "Kay, Allen M" <allen.m.kay@intel.com>,
kvm@vger.kernel.org, Amit Shah <amit.shah@qumranet.com>,
Ben-Ami Yassour1 <BENAMI@il.ibm.com>,
Avi Kivity <avik@qumranet.com>, Chris Wright <chrisw@redhat.com>,
"Han, Weidong" <weidong.han@intel.com>
Subject: Re: [PATCH 4/4][VTD] vt-d specific files in KVM
Date: Tue, 10 Jun 2008 18:15:26 +0300 [thread overview]
Message-ID: <20080610151526.GG6702@il.ibm.com> (raw)
In-Reply-To: <484E9795.4010409@codemonkey.ws>
On Tue, Jun 10, 2008 at 10:02:45AM -0500, Anthony Liguori wrote:
> Why? Wouldn't MMIO pages have to be mapped in the VT-d page table
> in order to support pass-through? It certainly can't hurt, can it?
By MMIO pages we refer to pages which are mapped (or can mapped) to
device MMIO regions. In other words, they are only relevant for host
memory accesses. VT-d mappings are used for *device* memory
accesses. I can't think of a good reason for a device to try to DMA to
such a page (where would the DMA end? There is no backing RAM), hence
the principal of least surprise says that we shouldn't map such pages
in the IOMMU page tables so that *if* the device tries to DMA to them
we will take an IOMMU fault rather than fail silently or machine check
(I've seen both happen with DMAs to MMIO regions).
> At any rate, looking at the code again, the else clause is:
>
>> + printk(KERN_DEBUG "kvm_iommu_map_page:"
>> + "invalid pfn=%lx\n", pfn);
>> + return 0;
>
>
> Which looks like error handling to me.
You are right, that snippet should be fixed to just skip non-RAM
gfns.
> I don't think it's at all safe to assume that a slot is either
> entirely MMIO or entirely RAM. You could very easily construct a
> slot that's a mix of both so if this is an attempt to skip MMIO
> slots, it's broken.
How would suc a slot be constructed with the current code base? (Note
that you need Ben's direct MMIO patches to create an MMIO slot).
Cheers,
Muli
next prev parent reply other threads:[~2008-06-10 15:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-10 0:43 [PATCH 4/4][VTD] vt-d specific files in KVM Kay, Allen M
2008-06-10 10:27 ` Muli Ben-Yehuda
2008-06-10 14:26 ` Anthony Liguori
2008-06-10 14:56 ` Muli Ben-Yehuda
2008-06-10 15:02 ` Anthony Liguori
2008-06-10 15:15 ` Muli Ben-Yehuda [this message]
2008-06-10 15:24 ` Anthony Liguori
2008-06-10 16:07 ` Muli Ben-Yehuda
2008-06-20 18:24 ` Avi Kivity
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=20080610151526.GG6702@il.ibm.com \
--to=muli@il.ibm.com \
--cc=BENAMI@il.ibm.com \
--cc=allen.m.kay@intel.com \
--cc=amit.shah@qumranet.com \
--cc=anthony@codemonkey.ws \
--cc=avik@qumranet.com \
--cc=chrisw@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=weidong.han@intel.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