From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N8Df9-0003Cj-GQ for qemu-devel@nongnu.org; Wed, 11 Nov 2009 08:55:07 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N8Df4-00038s-JZ for qemu-devel@nongnu.org; Wed, 11 Nov 2009 08:55:07 -0500 Received: from [199.232.76.173] (port=49017 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8Df4-00038e-CT for qemu-devel@nongnu.org; Wed, 11 Nov 2009 08:55:02 -0500 Received: from mx20.gnu.org ([199.232.41.8]:31563) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N8Df4-00069S-00 for qemu-devel@nongnu.org; Wed, 11 Nov 2009 08:55:02 -0500 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N8Df3-0001Wo-7D for qemu-devel@nongnu.org; Wed, 11 Nov 2009 08:55:01 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH 0/2] port over extboot from kvm Date: Wed, 11 Nov 2009 13:54:58 +0000 References: <1252401463-3249-1-git-send-email-kraxel@redhat.com> <4AFAB5C6.8090607@suse.de> <4AFABB35.4070100@codemonkey.ws> In-Reply-To: <4AFABB35.4070100@codemonkey.ws> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200911111354.58540.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Hannes Reinecke , Gerd Hoffmann On Wednesday 11 November 2009, Anthony Liguori wrote: > Hannes Reinecke wrote: > > But why? Why do we have to emulate the entire HBA for the BIOS? > > The HBA is emulated, too, and just uses the bdrv interface > > internally anyway. > > So IMHO it makes far more sense to skip the HBA emulation in > > the BIOS completely and just use the bdrv interface directly > > here. > > If you use the bdrv interface (ala extboot), you couldn't boot via scsi > passthrough. > > VirtualBox implements a paravirtual SCSI bus to allow SCSI boot without > having to implement a full LSI driver. That's another way to solve the > problem. This has its own issues. How do you prevent the guest enumerating both the paravirt and "real" adapters, and getting the same disk twice? If this isn't a problem, then surely the user can do this explicitly. In this case "guest" includes future fancy versions of the BIOS/bootloader. Paul