From: Jan Kiszka <jan.kiszka@siemens.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>,
Alexander Graf <agraf@suse.de>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"anthony@codemonkey.ws" <anthony@codemonkey.ws>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [RFC PATCH] qemu pci: pci_add_capability enhancement to prevent damaging config space
Date: Fri, 08 Jun 2012 17:05:39 +0200 [thread overview]
Message-ID: <4FD214C3.90507@siemens.com> (raw)
In-Reply-To: <1339167384.26976.71.camel@ul30vt>
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.
> MSI and MSIX are unique that we actually do want the qemu
> support for helping us to manage them. So we're basically not telling
> qemu about anything other than these, and for the most part, that works
> since qemu never handles access to the other capabilities. However, I
> think you're probably right, VFIO should just walk the capabilities
> list, registering each with qemu. It's a little "unnecessary" overhead
> from the VFIO perspective, but it makes the VFIO device less unique.
> I'll work on adding this. Thanks,
Great, thanks!
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2012-06-08 15:05 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-11 6:45 [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 [this message]
2012-06-08 15:22 ` Alex Williamson
2012-05-22 6:38 ` Alexander Graf
2012-05-11 19:20 ` Jason Baron
2012-05-12 0:27 ` [Qemu-devel] " 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=4FD214C3.90507@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=alex.williamson@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=david@gibson.dropbear.id.au \
--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