From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50139) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TK0ia-0003U4-Ms for qemu-devel@nongnu.org; Fri, 05 Oct 2012 01:45:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TK0iZ-0004XH-PS for qemu-devel@nongnu.org; Fri, 05 Oct 2012 01:45:00 -0400 Received: from e28smtp05.in.ibm.com ([122.248.162.5]:48649) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TK0iZ-0004Wi-6J for qemu-devel@nongnu.org; Fri, 05 Oct 2012 01:44:59 -0400 Received: from /spool/local by e28smtp05.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 5 Oct 2012 11:14:51 +0530 Message-ID: <506E73CD.6070502@linux.vnet.ibm.com> Date: Fri, 05 Oct 2012 11:14:45 +0530 From: Avik Sil MIME-Version: 1.0 References: <50641A82.4030708@linux.vnet.ibm.com> <1348738150.24701.21.camel@pasglop> <20120927095136.GI23096@redhat.com> <506D6B20.7020508@linux.vnet.ibm.com> <20121005003416.GS29302@truffula.fritz.box> <87626pv63r.fsf@linux.vnet.ibm.com> In-Reply-To: <87626pv63r.fsf@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nikunj A Dadhania Cc: Benjamin Herrenschmidt , "qemu-ppc@nongnu.org List" , qemu-devel qemu-devel , Gleb Natapov , David Gibson >>> I looked at the bootindex stuff and found that when the bootindex is >>> specified for the disk and cdrom it generates a string like: >>> >>> "/spapr-vio-bridge/spapr-vscsi/channel@0/disk@0,1 >>> /spapr-vio-bridge/spapr-vscsi/channel@0/disk@0,0" >> >> Ok, so I've just started looking at the bootindex stuff. What >> function is generating these strings? > > get_boot_devices_list gives you the above > >> >> We should also be able to get the raw bootindex values for a qdev, >> yes? I was thinking we could instead copy those values into the >> device tree when we populate it. The trouble is that we don't >> actually generate (in qemu) nodes for individual disks under a vscsi, >> or for individual PCI devices under the host bridge (that's done by >> SLOF). Still thinking... >> >> An aside, I'm thinking that once we do get bootindex working, then >> boot devices specified in NVRAM should have priority below all devices >> with explicit supplied bootindex, but above any that don't. Does that >> seem right to you? > > Even if the bootindex is taken care, there is still -boot that has to be > handled. Or we just need to drop -boot handling? In that case what > should we look at when there is no boot-index and nothing in nvram. Perhaps the default boot order "disk cdrom" should be taken care of if none of bootindex, -boot and nvram boot-device is provided. > > Regards > Nikunj > Regards, Avik