From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:57981)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <cornelia.huck@de.ibm.com>) id 1Tarc7-000839-Eu
	for qemu-devel@nongnu.org; Tue, 20 Nov 2012 12:28:00 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <cornelia.huck@de.ibm.com>) id 1Tarc2-0007dv-GS
	for qemu-devel@nongnu.org; Tue, 20 Nov 2012 12:27:59 -0500
Received: from e06smtp18.uk.ibm.com ([195.75.94.114]:33121)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <cornelia.huck@de.ibm.com>) id 1Tarc2-0007dR-7t
	for qemu-devel@nongnu.org; Tue, 20 Nov 2012 12:27:54 -0500
Received: from /spool/local
	by e06smtp18.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <qemu-devel@nongnu.org> from <cornelia.huck@de.ibm.com>;
	Tue, 20 Nov 2012 17:27:51 -0000
Received: from d06av11.portsmouth.uk.ibm.com (d06av11.portsmouth.uk.ibm.com
	[9.149.37.252])
	by b06cxnps4076.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with
	ESMTP id qAKHRdnd60293226
	for <qemu-devel@nongnu.org>; Tue, 20 Nov 2012 17:27:39 GMT
Received: from d06av11.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av11.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with
	ESMTP id qAKHRkqZ016869
	for <qemu-devel@nongnu.org>; Tue, 20 Nov 2012 10:27:47 -0700
Date: Tue, 20 Nov 2012 18:27:44 +0100
From: Cornelia Huck <cornelia.huck@de.ibm.com>
Message-ID: <20121120182744.6d117322@BR9GNB5Z>
In-Reply-To: <50ABB39B.8000101@greensocs.com>
References: <1353080159-10536-1-git-send-email-fred.konrad@greensocs.com>
	<1353080159-10536-2-git-send-email-fred.konrad@greensocs.com>
	<CAFEAcA-KK3Z8MThZ044=DoxZOHMFLkAwbDOO5TpJ84JmWzqnxA@mail.gmail.com>
	<20121120151201.3886aeaf@BR9GNB5Z> <50AB940B.306@greensocs.com>
	<20121120171512.3293afc3@BR9GNB5Z> <50ABB39B.8000101@greensocs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [RFC PATCH 1/3] virtio-bus : Introduce VirtioBus.
List-Id: <qemu-devel.nongnu.org>
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>
To: KONRAD =?UTF-8?B?RnLDqWTDqXJpYw==?= <fred.konrad@greensocs.com>
Cc: Peter Maydell <peter.maydell@linaro.org>, Anthony Liguori <aliguori@us.ibm.com>, Evgeny Voevodin <e.voevodin@samsung.com>, mark.burton@greensocs.com, qemu-devel@nongnu.org, Andreas =?UTF-8?B?RsOkcmJlcg==?= <afaerber@suse.de>

On Tue, 20 Nov 2012 17:45:15 +0100
KONRAD Fr=C3=A9d=C3=A9ric <fred.konrad@greensocs.com> wrote:


> eg for virtio-block-pci in virtio-pci.c :
> static void virtio_blk_class_init(ObjectClass *klass, void *data)
> {
>      k->device_id =3D PCI_DEVICE_ID_VIRTIO_BLOCK;
>      ...
>      k->class_id =3D PCI_CLASS_STORAGE_SCSI;
> }
>=20
> I think that the better solution is to put these value in a big switch=20
> case :
>=20
> eg :
>=20
> Adding that in virtio-bus.c :
>=20
> /* Return the virtio device id of the plugged device. */
> uint16_t get_virtio_device_id(VirtioBus *bus)
> {
>      return bus->vdev->device_id;
> }

Yes, we'll need this for virtio-ccw as well (the id is used as the CU
model).

>=20
> Using that in virtio-pci transport initialisation.
>=20
>      switch (get_virtio_device_id(&proxy->bus))
>      {
>          case VIRTIO_ID_BLOCK:
>              pci_config_set_device_id(proxy->pci_dev.config,
>                                       PCI_DEVICE_ID_VIRTIO_BLOCK);
>              pci_config_set_class(proxy->pci_dev.config,=20
> PCI_CLASS_STORAGE_SCSI);
>          break;
>          default:
>              error_report("unknown device id\n");
>          break;
>      }
>=20
> but the transport stay ( a little ) device dependent.

Well, given that the device id _is_ device dependent, doing the device
id -> transport specific id transition in the transport code seems
sensible.