>On 27/03/2009 00:48, "Akio Takebe" <takebe_akio@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home