From: Alex Williamson <alex.williamson@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
Alexey Kardashevskiy <aik@ozlabs.ru>,
Alexander Graf <agraf@suse.de>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"anthony@codemonkey.ws" <anthony@codemonkey.ws>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [RFC PATCH] qemu pci: pci_add_capability enhancement to prevent damaging config space
Date: Fri, 08 Jun 2012 09:22:00 -0600 [thread overview]
Message-ID: <1339168920.26976.86.camel@ul30vt> (raw)
In-Reply-To: <4FD214C3.90507@siemens.com>
On Fri, 2012-06-08 at 17:05 +0200, Jan Kiszka wrote:
> On 2012-06-08 16:56, Alex Williamson wrote:
> > The difference between VFIO and kvm device assignment is that VFIO
> > emulates a lot of config space for us, so most things are passed
> > through.
>
> That's not different from current device assignment, is it? I think the
> major difference is that VFIO filters and potentially post-processes the
> direct writes in kernel space.
Right, and having the filtering/virtualization in the kernel means that
qemu only handles a very small subset of PCI config space. That's made
us lax in even telling qemu about the areas that it'll never see
accesses too. For current device assignment, since we doing the
emulation in qemu, it's a little more beneficial to register everything.
Thanks,
Alex
next prev parent reply other threads:[~2012-06-08 15:22 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-11 6:45 [Qemu-devel] [RFC PATCH] qemu pci: pci_add_capability enhancement to prevent damaging config space Alexey Kardashevskiy
2012-05-11 10:52 ` Alexander Graf
2012-05-11 12:47 ` Alexey Kardashevskiy
2012-05-11 14:13 ` Alexander Graf
2012-05-14 3:49 ` Alexey Kardashevskiy
2012-05-18 5:12 ` Alexey Kardashevskiy
2012-05-22 2:02 ` Benjamin Herrenschmidt
2012-05-22 3:21 ` Alexander Graf
2012-05-22 3:44 ` Alexey Kardashevskiy
2012-05-22 5:52 ` Alexander Graf
2012-05-22 6:11 ` Alexey Kardashevskiy
2012-05-22 6:31 ` Alexander Graf
2012-05-22 7:01 ` Alexey Kardashevskiy
2012-05-22 7:13 ` Alexander Graf
2012-05-22 7:37 ` Benjamin Herrenschmidt
2012-06-08 8:47 ` Alexey Kardashevskiy
2012-06-08 10:56 ` Jan Kiszka
2012-06-08 11:16 ` Alexey Kardashevskiy
2012-06-08 11:30 ` Jan Kiszka
2012-06-08 14:00 ` Alexey Kardashevskiy
2012-06-08 14:43 ` Jan Kiszka
2012-06-08 14:56 ` Alex Williamson
2012-06-08 15:05 ` Jan Kiszka
2012-06-08 15:22 ` Alex Williamson [this message]
2012-05-22 6:38 ` Alexander Graf
2012-05-11 19:20 ` Jason Baron
2012-05-12 0:27 ` Alexey Kardashevskiy
2012-05-14 2:37 ` Alex Williamson
-- strict thread matches above, loose matches on Subject: below --
2012-05-11 6:59 Alexey Kardashevskiy
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=1339168920.26976.86.camel@ul30vt \
--to=alex.williamson@redhat.com \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=anthony@codemonkey.ws \
--cc=david@gibson.dropbear.id.au \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.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;
as well as URLs for NNTP newsgroup(s).