[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Patch][2/2][BIOS] Support BCV table


  • To: Akio Takebe <takebe_akio@xxxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Fri, 27 Mar 2009 13:49:18 +0000
  • Cc:
  • Delivery-date: Fri, 27 Mar 2009 06:49:50 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acmux0U+viwMhxIZRVylHc+X7wyQagAG42Yz
  • Thread-topic: [Xen-devel] [Patch][2/2][BIOS] Support BCV table

On 27/03/2009 10:31, "Akio Takebe" <takebe_akio@xxxxxxxxxxxxxx> wrote:

> I don't try the idea of vendor:dev id, but I made a patch(bcv.v2.patch)
> adding the feature of retrying to boot with the next drives.
> What do you think about this patch?
> This patch doesn't add any new syntax, just add the retry feature.
> 
> Also I made another patch(support_interactive_boot_for_bcv.patch).
> It allows user to select a bootable pass-through device with F12.
> support_interactive_boot_for_bcv.patch depends on bcv.v2.patch.

Both are plausible. Looking at your previous email, I get the impression
that the limitations are in rombios, and/or its integration with hvmloader.
Would the right fix really to make rombios be a bit smarter: being able to
load and discard option ROMs into 0xc0000-0xe0000 range, for example? Also,
I have the view that parts of rombios's POST routines could get moved into
hvmloader, even if we keep rombios for its real-mode BIOS service routines,
after POST. Actually I'd be happy to see hvmloader get a bit fatter at
rombios's expense! Perhaps this is a possibility for the Xen 3.5 development
cycle.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.