Hi, The patches support BCV table/priority in rombios. The motivation is we want to: - select bootable device because loading optionROM take a long time. - retry other devices if we fail to boot wiht the first device. BCV priority is a order of installing int 0x13 handler. In my patch, the priorty is decided with BDF number. ATA emulation disk is the highest priority, and lower BDF number of passthrough devices is higher priority. The patch adds two syntax in configuration file. 1. boot option of pci e.g. pci = [ ''01:00.0@6,boot=1'' ] 2. p option of boot e.g. boot = "pcd" In the above example, hvmloader will load optionROM of 01:00.0 pass-through device. Then rombios will try to boot from pass-through device. If it fail, rombios will try CD boot, and ATA disk boot. I use hvm_info table for passing BDF numbers which we want to load their optionROMs. If still possible, please apply the patch. Best Regards, Akio Takebe _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, this patch is tools parts. Signed-off-by: Akio Takebe <takebe_akio@jp.fujitsu.com> Best Regards, Akio Takebe _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, This patch is qemu parts. Signed-off-by: Akio Takebe <takebe_akio@jp.fujitsu.com> Best Regards, Akio Takebe _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, # Oops, the subject of the previous mail is wrong.:) # I send again with correct subject. Sorry. this patch is tools parts. Signed-off-by: Akio Takebe <takebe_akio@jp.fujitsu.com> Best Regards, Akio Takebe _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 26/03/2009 13:43, "Akio Takebe" <takebe_akio@jp.fujitsu.com> wrote:> Hi, > > This patch is qemu parts. > > Signed-off-by: Akio Takebe <takebe_akio@jp.fujitsu.com>You want qemu mucking about with the hvm_info_table? I don''t think so. You''ll have to consider an approach which doesn''t touch qemu - you have some time anyway since this is not going in for 3.4. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi,>On 26/03/2009 13:43, "Akio Takebe" <takebe_akio@jp.fujitsu.com> wrote: > >> Hi, >> >> This patch is qemu parts. >> >> Signed-off-by: Akio Takebe <takebe_akio@jp.fujitsu.com> > >You want qemu mucking about with the hvm_info_table? I don''t think so. >You''ll have to consider an approach which doesn''t touch qemu - you have some >time anyway since this is not going in for 3.4.I didn''t want to modify qemu, but virtual slot is decided in qemu. Most of my patch modify hw/pass-through.c Because hw/pass-though.c is used by only xen, I though it was accectable to modify it. So I modified qemu involuntarily. I''m sorry. If we don''t modify qemu, we need to see xenstore and so on from hvmloader. Do you have any idea? Best Regards, Akio Takebe _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, Keir>Hi, > >>On 26/03/2009 13:43, "Akio Takebe" <takebe_akio@jp.fujitsu.com> wrote: >> >>> Hi, >>> >>> This patch is qemu parts. >>> >>> Signed-off-by: Akio Takebe <takebe_akio@jp.fujitsu.com> >> >>You want qemu mucking about with the hvm_info_table? I don''t think so. >>You''ll have to consider an approach which doesn''t touch qemu - you have some >>time anyway since this is not going in for 3.4. >I didn''t want to modify qemu, but virtual slot is decided in qemu. >Most of my patch modify hw/pass-through.c >Because hw/pass-though.c is used by only xen, >I though it was accectable to modify it. >So I modified qemu involuntarily. I''m sorry. >If we don''t modify qemu, we need to see xenstore and so on >from hvmloader. Do you have any idea? >After some consideration, I abandon a feature of selecting bootable device. If I abandon it, I don''t need to modify qemu. As the result, we need to configure a bootable device as vslot 6 or 7. I think it is reasonable. How about you? Best Regards, Akio Takebe _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 27/03/2009 00:48, "Akio Takebe" <takebe_akio@jp.fujitsu.com> wrote:>> You want qemu mucking about with the hvm_info_table? I don''t think so. >> You''ll have to consider an approach which doesn''t touch qemu - you have some >> time anyway since this is not going in for 3.4. > I didn''t want to modify qemu, but virtual slot is decided in qemu. > Most of my patch modify hw/pass-through.c > Because hw/pass-though.c is used by only xen, > I though it was accectable to modify it. > So I modified qemu involuntarily. I''m sorry. > If we don''t modify qemu, we need to see xenstore and so on > from hvmloader. Do you have any idea?I may be missing some of the motivation and higher-level design, which you may have to describe. I''m not really sure what the whole patchset was actually for and why we''d want it. But, for example, why not specify the vendor:dev identifier via hvm_info_table, rather than specifying the vslot? Or, if you feel you must do this via qemu, hack extra info into the PCI config space of each device, or expose via the xen-platform device I/O ports? Something which qemu already controls (unlike hvm_info_table). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 27/03/2009 04:44, "Akio Takebe" <takebe_akio@jp.fujitsu.com> wrote:>> I didn''t want to modify qemu, but virtual slot is decided in qemu. >> Most of my patch modify hw/pass-through.c >> Because hw/pass-though.c is used by only xen, >> I though it was accectable to modify it. >> So I modified qemu involuntarily. I''m sorry. >> If we don''t modify qemu, we need to see xenstore and so on >> from hvmloader. Do you have any idea? >> > After some consideration, I abandon a feature of selecting bootable > device. If I abandon it, I don''t need to modify qemu. As the result, we > need to configure a bootable device as vslot 6 or 7. I think it is > reasonable. How about you?Errrr. You''ll have to gove me some more hints about exactly what problem all your work so far is trying to solve. :-) -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>On 27/03/2009 00:48, "Akio Takebe" <takebe_akio@jp.fujitsu.com> wrote: > >>> You want qemu mucking about with the hvm_info_table? I don''t think so. >>> You''ll have to consider an approach which doesn''t touch qemu - you have >>> some >>> time anyway since this is not going in for 3.4. >> I didn''t want to modify qemu, but virtual slot is decided in qemu. >> Most of my patch modify hw/pass-through.c >> Because hw/pass-though.c is used by only xen, >> I though it was accectable to modify it. >> So I modified qemu involuntarily. I''m sorry. >> If we don''t modify qemu, we need to see xenstore and so on >> from hvmloader. Do you have any idea? > >I may be missing some of the motivation and higher-level design, which you >may have to describe. I''m not really sure what the whole patchset was >actually for and why we''d want it. >I have two problems. 1. We cannot load many optionROM In the case of a native PnP BIOS, it load a optionROM and try to initialize their device, then it can free unnecessary ROM memory. So a native BIOS can load many optionROM. But in the case of xen, optionROMs are loaded in hvmloader. So we cannot free unnecessary memory. Current hvmloader try to load all of optionROM, But if shadow memory doesn''t have enough space, it stop loading optionROM. So I wanted to load some necessary optionROM for booting. As the side effect, the patch make booting faster if you don''t want to boot from pass-through device. I think it is not important problem. We can configure bootable devices with early number of vslot. 2. We cannot retry the next drive of HDD type. rombios try to boot from only 0x80 drive. So rombios cannot retry to boot with other drives. I want to boot from other drive. It is useful when the first drive(0x80) broke. Also if acceptable, I want to implement interactive boot key for pass-through device.>But, for example, why not specify the vendor:dev identifier via >hvm_info_table, rather than specifying the vslot?Oh, I didn''t have the idea. I''ll try it.>Or, if you feel you must do this via qemu, hack extra info into the PCI >config space of each device, or expose via the xen-platform device I/O >ports? Something which qemu already controls (unlike hvm_info_table).Best Regards, Akio Takebe _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>On 27/03/2009 00:48, "Akio Takebe" <takebe_akio@jp.fujitsu.com> wrote: >> >>>> You want qemu mucking about with the hvm_info_table? I don''t think so. >>>> You''ll have to consider an approach which doesn''t touch qemu - you have >>>> some >>>> time anyway since this is not going in for 3.4. >>> I didn''t want to modify qemu, but virtual slot is decided in qemu. >>> Most of my patch modify hw/pass-through.c >>> Because hw/pass-though.c is used by only xen, >>> I though it was accectable to modify it. >>> So I modified qemu involuntarily. I''m sorry. >>> If we don''t modify qemu, we need to see xenstore and so on >>> from hvmloader. Do you have any idea? >> >>I may be missing some of the motivation and higher-level design, which you >>may have to describe. I''m not really sure what the whole patchset was >>actually for and why we''d want it. >> >I have two problems. >1. We cannot load many optionROM > In the case of a native PnP BIOS, it load a optionROM and > try to initialize their device, then it can free unnecessary ROM > memory. So a native BIOS can load many optionROM. > But in the case of xen, optionROMs are loaded in hvmloader. > So we cannot free unnecessary memory. > Current hvmloader try to load all of optionROM, But if shadow memory > doesn''t have enough space, it stop loading optionROM. > So I wanted to load some necessary optionROM for booting. > As the side effect, the patch make booting faster if you don''t want to > boot from pass-through device. > I think it is not important problem. > We can configure bootable devices with early number of vslot. > >2. We cannot retry the next drive of HDD type. > rombios try to boot from only 0x80 drive. > So rombios cannot retry to boot with other drives. > I want to boot from other drive. > It is useful when the first drive(0x80) broke. > Also if acceptable, I want to implement interactive boot key > for pass-through device. > >>But, for example, why not specify the vendor:dev identifier via >>hvm_info_table, rather than specifying the vslot? >Oh, I didn''t have the idea. I''ll try it. >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. Best Regards, Akio Takebe _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 27/03/2009 10:31, "Akio Takebe" <takebe_akio@jp.fujitsu.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel
>On 27/03/2009 10:31, "Akio Takebe" <takebe_akio@jp.fujitsu.com> 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,Thanks. Yes, you are right.>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.OK, I will also improve my patch with your idea of vendor:dev id for Xen-3.5. Best Regards, Akio Takebe _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, Akio Takebe wrote:>>> On 27/03/2009 00:48, "Akio Takebe" <takebe_akio@jp.fujitsu.com> wrote: >>> >>>>> You want qemu mucking about with the hvm_info_table? I don''t think so. >>>>> You''ll have to consider an approach which doesn''t touch qemu - you have >>>>> some >>>>> time anyway since this is not going in for 3.4. >>>> I didn''t want to modify qemu, but virtual slot is decided in qemu. >>>> Most of my patch modify hw/pass-through.c >>>> Because hw/pass-though.c is used by only xen, >>>> I though it was accectable to modify it. >>>> So I modified qemu involuntarily. I''m sorry. >>>> If we don''t modify qemu, we need to see xenstore and so on >>>> from hvmloader. Do you have any idea? >>> I may be missing some of the motivation and higher-level design, which you >>> may have to describe. I''m not really sure what the whole patchset was >>> actually for and why we''d want it. >>> >> I have two problems. >> 1. We cannot load many optionROM >> In the case of a native PnP BIOS, it load a optionROM and >> try to initialize their device, then it can free unnecessary ROM >> memory. So a native BIOS can load many optionROM. >> But in the case of xen, optionROMs are loaded in hvmloader. >> So we cannot free unnecessary memory. >> Current hvmloader try to load all of optionROM, But if shadow memory >> doesn''t have enough space, it stop loading optionROM. >> So I wanted to load some necessary optionROM for booting. >> As the side effect, the patch make booting faster if you don''t want to >> boot from pass-through device. >> I think it is not important problem. >> We can configure bootable devices with early number of vslot. >> >> 2. We cannot retry the next drive of HDD type. >> rombios try to boot from only 0x80 drive. >> So rombios cannot retry to boot with other drives. >> I want to boot from other drive. >> It is useful when the first drive(0x80) broke. >> Also if acceptable, I want to implement interactive boot key >> for pass-through device. >> >>> But, for example, why not specify the vendor:dev identifier via >>> hvm_info_table, rather than specifying the vslot? >> Oh, I didn''t have the idea. I''ll try it. >> > 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. >Just RFC. I made a patch which we can select bootable devices with vendor_id:device_id. It depends on previous 2 patches(bcv.v2.patch, support_interactive_boot_for_bcv.patch). If acceptable, I will remake, cleanup and post them after xen-3.5. Best Regards, Akio Takebe _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel