From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56409) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R45x8-0006qo-SL for qemu-devel@nongnu.org; Thu, 15 Sep 2011 03:01:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R45x7-0008Ir-SR for qemu-devel@nongnu.org; Thu, 15 Sep 2011 03:01:42 -0400 Sender: Paolo Bonzini Message-ID: <4E71A2D2.2080008@redhat.com> Date: Thu, 15 Sep 2011 09:01:38 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1315989802-18753-1-git-send-email-agraf@suse.de> <1315989802-18753-2-git-send-email-agraf@suse.de> <20110915031437.GR9025@yookeroo.fritz.box> In-Reply-To: <20110915031437.GR9025@yookeroo.fritz.box> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 01/58] spapr: proper qdevification List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf , qemu-devel Developers , qemu-ppc@nongnu.org, David Gibson Cc: Blue Swirl , Aurelien Jarno On 09/15/2011 05:14 AM, David Gibson wrote: > Under PAPR, there is generally only > supposed to be one SCSI target (disk / cd / whatever) per virtual scsi > bus. But the generic qdev code will, by default, keep assigning > devices to the existing bus until it's full. Any thoughts on how to > sanely change that behaviour on a per-machine basis? You could change the if_max_devs array in blockdev.c to something provided by the machines. However, I'm not sure about this, for two reasons: 1) do you mean, in Linux terms, one target per SCSI _host_ or one target per SCSI _channel_? i.e. if you looks at /sys/bus/scsi/devices, right now it looks like 0:0:0:0 0:0:1:0 (two targets on the same host and channel) Should it be? 0:0:0:0 0:1:0:0 (one target per channel) or 0:0:0:0 1:0:0:0 (one target per host) If it is the former, then you are simply hitting a limitation of the SCSI layer in QEMU and I do have patches to make assignment more flexible. Based on the Linux VSCSI driver, and based on what SLOF does, I'd guess that's what you mean. 2) does this matter at all? First, when doing "real world" virtualization you won't use the legacy options (neither -hda/-cdrom nor "-drive ...,if=scsi"), you would use -device to manually assign the devices to their buses. Second, why should you care in the case of SCSI? It seems like a very hard limitation to me, and unlike the PCI case it doesn't buy you anything in terms of isolation. Paolo