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 19:07:15 +0300 [thread overview]
Message-ID: <20080610160715.GA7197@il.ibm.com> (raw)
In-Reply-To: <484E9C96.7090502@codemonkey.ws>
On Tue, Jun 10, 2008 at 10:24:06AM -0500, Anthony Liguori wrote:
> If you add the MMIO page to the IOMMU table, then the behavior is
> going to be identical to what occurs on bare metal which IMHO is a
> good thing. Why jump through hoops to change what may or may not be
> an error condition instead of letting the natural error behavior
> happen? There may be some weird piece of hardware that relies on
> this behavior out there.
One potential outcome of this behaviour on bare metal---which has been
observed!---is a machine check. Letting the guest machine check the
host is not a good thing.
> There is no such thing as an MMIO slot. All you would need to do is
> mmap(phys_ram_base + GPA, "/sys/bus/pci/.../region/0", MAP_SHARED |
> MAP_FIXED) and you'd have a mixed slot assuming GPA was within an
> existing RAM slot.
That doesn't happen with the current code base, but color me
convinced: we'll just continue checking gfns one by one when mapping
them into the IOMMU page tables, skipping any non-ram gfns.
Cheers,
Muli
next prev parent reply other threads:[~2008-06-10 16:08 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
2008-06-10 15:24 ` Anthony Liguori
2008-06-10 16:07 ` Muli Ben-Yehuda [this message]
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=20080610160715.GA7197@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.