From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40994) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sd0l9-0001ch-22 for qemu-devel@nongnu.org; Fri, 08 Jun 2012 11:05:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sd0l4-0007fp-7w for qemu-devel@nongnu.org; Fri, 08 Jun 2012 11:05:54 -0400 Received: from david.siemens.de ([192.35.17.14]:24244) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sd0l3-0007fa-VH for qemu-devel@nongnu.org; Fri, 08 Jun 2012 11:05:50 -0400 Message-ID: <4FD214C3.90507@siemens.com> Date: Fri, 08 Jun 2012 17:05:39 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4FACB581.2050609@ozlabs.ru> <6A22E211-BC82-49BD-A335-02D3BAA14A17@suse.de> <4FAD0A4F.2050506@ozlabs.ru> <4FB080CE.3030703@ozlabs.ru> <4FB5DA43.90907@ozlabs.ru> <1337652170.2779.143.camel@pasglop> <6C472F5B-B8C3-48DE-B19B-00973AF6AC56@suse.de> <4FBB0B95.8050901@ozlabs.ru> <82643009-4F43-407F-B26C-C36537825BFD@suse.de> <4FBB2E25.2030206@ozlabs.ru> <584A5E54-2119-415C-93B4-BB91A08CA729@suse.de> <4FD1BC14.6030900@ozlabs.ru> <4FD1DA5C.5020900@siemens.com> <4FD1DF29.1050303@ozlabs.ru> <4FD1E25A.2010900@siemens.com> <4FD2058F.7030903@ozlabs.ru> <4FD20F92.9080805@siemens.com> <1339167384.26976.71.camel@ul30vt> In-Reply-To: <1339167384.26976.71.camel@ul30vt> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH] qemu pci: pci_add_capability enhancement to prevent damaging config space List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: "kvm@vger.kernel.org" , Alexey Kardashevskiy , Alexander Graf , "qemu-devel@nongnu.org" , "anthony@codemonkey.ws" , David Gibson 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