From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35256) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Scws3-00011b-9B for qemu-devel@nongnu.org; Fri, 08 Jun 2012 06:56:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Scwry-0001Xx-Lc for qemu-devel@nongnu.org; Fri, 08 Jun 2012 06:56:46 -0400 Received: from david.siemens.de ([192.35.17.14]:24154) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Scwry-0001Xo-Cm for qemu-devel@nongnu.org; Fri, 08 Jun 2012 06:56:42 -0400 Message-ID: <4FD1DA5C.5020900@siemens.com> Date: Fri, 08 Jun 2012 12:56:28 +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> In-Reply-To: <4FD1BC14.6030900@ozlabs.ru> Content-Type: text/plain; charset=KOI8-R 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: Alexey Kardashevskiy Cc: "kvm@vger.kernel.org" , Alexander Graf , "qemu-devel@nongnu.org" , Alex Williamson , "anthony@codemonkey.ws" , David Gibson On 2012-06-08 10:47, Alexey Kardashevskiy wrote: > Yet another try :) > > Normally the pci_add_capability is called on devices to add new > capability. This is ok for emulated devices which capabilities list > is being built by QEMU. > > In the case of VFIO the capability may already exist and adding new Why does it exit? VFIO should build the virtual capability list from scratch (just like classic device assignment does), recreating the layout of the physical device (except for masked out caps). In that case, this conflict should become impossible, no? But if pci_*add*_capability should actually be used like this (I doubt this), some renaming would be required. "Add" sound like "append" to me, not "update". Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux