From mboxrd@z Thu Jan  1 00:00:00 1970
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [RFC PATCH] qemu pci: pci_add_capability
 enhancement to prevent damaging config space
Date: Tue, 22 May 2012 17:37:17 +1000
Message-ID: <1337672237.2779.195.camel@pasglop>
References: <4FACB581.2050609@ozlabs.ru>
	<6A22E211-BC82-49BD-A335-02D3BAA14A17@suse.de>
	<4FAD0A4F.2050506@ozlabs.ru>
	<E3C5DF35-72FF-4247-BC86-F3374E2B40E6@suse.de>
	<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>
	<4FBB39BB.3040009@ozlabs.ru>
	<02B68212-DC07-457E-A340-7EF1C9E76643@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Alexey Kardashevskiy <aik@ozlabs.ru>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Alex Williamson <alex.williamson@redhat.com>,
	"anthony@codemonkey.ws" <anthony@codemonkey.ws>,
	David Gibson <david@gibson.dropbear.id.au>
To: Alexander Graf <agraf@suse.de>
Return-path: <qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org>
In-Reply-To: <02B68212-DC07-457E-A340-7EF1C9E76643@suse.de>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
List-Id: kvm.vger.kernel.org

On Tue, 2012-05-22 at 09:13 +0200, Alexander Graf wrote:
> On 22.05.2012, at 09:01, Alexey Kardashevskiy wrote:

> > This is internal kitchen of PCIDevice which I do not want to touch
> from anywhere but pci.c. And
> > there is no "fixup_capability" or something.
> 
> Hrm. Maybe we should have one? :) Or instead of populating the config
> space with the exact data from the host device,
> loop through the host device capabilities and populate them using this
> function as we go.
>  That should maintain the offsets, but ensure that all internal flags
> are set, no?

That actually sounds reasonable, though it might be more efficient
to have something like pci_parse_config() or similar called once
with a pre-cooked config space.

Internally inside pci.c it can do that same loop you mention. The
advantage is that it can also do whatever else we might need in the
future. If for some reason, something wants to cache a cap pointer
it can be done there, whatever else that is normally initialized as
fields to generate the config space can be initialized by reading the
config space and then initializing the fields etc... from that one
function.

Cheers,
Ben.