From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=60524 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OEHzr-00024J-SY
	for qemu-devel@nongnu.org; Tue, 18 May 2010 04:18:11 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1OEGiY-0002Sa-P7
	for qemu-devel@nongnu.org; Tue, 18 May 2010 02:59:17 -0400
Received: from mx1.redhat.com ([209.132.183.28]:53432)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1OEGiX-0002RZ-WF
	for qemu-devel@nongnu.org; Tue, 18 May 2010 02:55:54 -0400
Message-ID: <4BF239ED.2070604@redhat.com>
Date: Tue, 18 May 2010 09:55:41 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 1/2] QMP: Introduce commands doc
References: <1273086712-29163-1-git-send-email-lcapitulino@redhat.com>	<1273086712-29163-2-git-send-email-lcapitulino@redhat.com>	<4BEC031D.6020506@redhat.com>
	<m3pr0yq333.fsf@blackfin.pond.sub.org>	<4BED6F85.50309@redhat.com>
	<m3tyqa5sbb.fsf@blackfin.pond.sub.org>	<4BED83BD.8000604@redhat.com>
	<m38w7jvspm.fsf@blackfin.pond.sub.org>	<4BF107E1.2020600@redhat.com>
	<m3ocgeojvu.fsf@blackfin.pond.sub.org>
	<4BF1847D.9090603@codemonkey.ws> <4BF1971E.4040709@redhat.com>
In-Reply-To: <4BF1971E.4040709@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: bazulay@redhat.com, qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>, Luiz Capitulino <lcapitulino@redhat.com>, juzhang@redhat.com

On 05/17/2010 10:21 PM, Gerd Hoffmann wrote:
>
>>> Dunno. Gerd, what do you think?
>
> There is a PCIDevice for each function.  PCIDevice->devfn (aka addr 
> property) contains slot+function.  So hw/pci.c can figure which device 
> functions belong to the same slot.  The pci hotplug code might need 
> some fixes to handle multi-function devices correctly though (I guess 
> this is the original issue?).

The original issue is that the code does not model reality.  Yes, it 
only hurts with multifunction devices.

We need a PCIDevice->devaddr and PCIDevice->function[]->fnaddr.


> unplug is probably easy, plug might be harder. You have to plug-in all 
> functions belonging to the slot first, then signal the guest that the 
> slot has been hotplugged, which might need changes in the monitor 
> protocol.

We need to plug in a device, not functions.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.