From: Avi Kivity <avi@redhat.com>
To: nemesis@icequake.net
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
Alexander Graf <agraf@suse.de>,
kvm@vger.kernel.org
Subject: Re: PCI passthrough resource remapping
Date: Sat, 16 Jan 2010 11:23:35 +0200 [thread overview]
Message-ID: <4B518597.5030809@redhat.com> (raw)
In-Reply-To: <20100114193419.GK4727@localhost.localdomain>
On 01/14/2010 09:34 PM, Ryan C. Underwood wrote:
> On Thu, Jan 14, 2010 at 09:09:32PM +0200, Avi Kivity wrote:
>
>> PCI cards can access system memory directly. If you assign a card
>> to a guest, the guest will program the card to transfer data to
>> system memory using guest addresses; since guest addresses don't
>> correspond to host addresses, memory corruption will ensue.
>>
> I see, so the only way to fix this would be either with a special guest
> driver for the device that does not perform DMA, or if that is
> impossible (due to no docs), to trap and rewrite any command writes to
> the device's MMIO region that reference a DMA write target buffer.
>
> Forgive my ignorance, but is it possible that the latter is already
> possible with qemu-kvm (somewhat like hardware memory breakpoints in
> Soft-ICE)?
>
>
Yes, you can easily trap mmio writes to a device, and in fact kvm does
this in some non-default scenarios.
> If qemu-kvm can be made to break and log on PCI memory accesses, I would
> then hack around the safety limitations, assuming that's all they are,
> and analyze the PCI writes one by one to find the cases where a physical
> address is passed to the card.
>
> Then I would perform the IOMMU translation myself in software whenever a
> physmem address shows up in the command stream. (Somewhat like the
> security validation of a 3D graphics card command stream in the DRM.)
>
>
That's definitely doable, but you would need to know exactly how the
device does dma. You would also need to lock all pages into memory
(mlockall()) and how pages are mapped (/proc/$pid/pagemap?)
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
next prev parent reply other threads:[~2010-01-16 9:23 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-09 2:45 PCI passthrough resource remapping Ryan C. Underwood
2010-01-09 3:22 ` Alexander Graf
2010-01-10 21:53 ` Ryan C. Underwood
2010-01-10 22:15 ` Ryan C. Underwood
2010-01-14 13:59 ` Avi Kivity
2010-01-14 15:26 ` Ryan C. Underwood
2010-01-14 15:34 ` Avi Kivity
2010-01-14 15:47 ` Michael S. Tsirkin
2010-01-14 15:54 ` Avi Kivity
2010-01-14 18:31 ` Ryan C. Underwood
2010-01-14 19:09 ` Avi Kivity
2010-01-14 19:34 ` Ryan C. Underwood
2010-01-16 9:23 ` Avi Kivity [this message]
2010-01-15 13:11 ` Pasi Kärkkäinen
2010-01-15 13:15 ` Alexander Graf
2010-03-26 2:37 ` Kenni Lund
2010-03-26 3:00 ` Brian Jackson
2010-03-29 17:23 ` Kenni Lund
2010-03-29 19:17 ` Alexander Graf
2010-03-29 23:00 ` Kenni Lund
2010-03-29 23:12 ` Alexander Graf
2010-03-29 23:47 ` Chris Wright
2010-03-30 0:21 ` Kenni Lund
2010-03-30 2:08 ` Chris Wright
2010-03-30 22:27 ` Kenni Lund
2010-03-30 22:29 ` Alexander Graf
2010-03-30 23:52 ` Kenni Lund
2010-03-31 0:59 ` Chris Wright
2010-03-30 23:58 ` Chris Wright
2010-03-31 0:47 ` Kenni Lund
2010-03-31 1:32 ` Chris Wright
2010-03-31 10:07 ` Kenni Lund
2010-03-31 15:15 ` Chris Wright
2010-03-31 11:43 ` Kenni Lund
2010-03-31 12:24 ` Alexander Graf
2010-03-31 13:04 ` Kenni Lund
2010-03-31 15:18 ` Chris Wright
2010-03-31 15:23 ` Alexander Graf
2010-04-07 5:52 ` 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=4B518597.5030809@redhat.com \
--to=avi@redhat.com \
--cc=agraf@suse.de \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=nemesis@icequake.net \
/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