OK, I did some tests on xen and LinuxBIOS. Status: I built special LinuxBIOS, and using ADLO as payload. (ADLO will have bochs bios in it). With that I could boot Linux and windows with vcpu=1, and no acpi, and apic. The real LinuxBIOS can create acpi tables and mptable and pirq table dynamically. So if some cpus are not installed, these tables may be different. So Next I could modify the ioemu to make it more AMD like. And device model will be amd64+amd8111. and the device model will only set read_only pci conf. and let the LinuxBIOS to enumerate the PCI bus and allocate the source. Also LinuxBIOS could create the acpi tables etc according to the pci conf and msr reading. Then the driver model could be some tide, and don''t need to do init thing for firmeare. The good is the LinuxBIOS for amd64 platform is there already, and the almost 99.9% LinuxBIOS is in C. we only use bochs for BIOS call. Also it could be get more cleaned. The drawback is that to keep consistent with qemu, I may need to update qemu to support amd64 model. So we can share the Diskimage between Qemu and xen. I tried the winxp installed image with qemu and I got blue screen. I need reinstall that in xen with LinuxBIOS. Is it a good way? Any comment? Thanks Yinghai Lu -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Lu, Yinghai Sent: Friday, July 14, 2006 9:41 AM To: John Levon; yhlu; rminnich@lanl.gov Cc: Ian Pratt; Anthony Liguori; xen-devel@lists.xensource.com; Mark Williamson; Michael Loehr Subject: RE: Xen bootloader (was: Re: [Xen-devel] Xen Roadmap proposal) You need to make sure the format can be handle by kexec. It could handle elf, linux kernel, grub.exe (for multiboot?), ... Maybe it is off topic. I am considering to use LinuxBIOS in hvmloader...then it could only support Linux ( with etherboot and FILO can load kernel from network or HD then kexec ). I can reuse LinuxBIOS ACPI code ... If the guest OS need BIOS call, we may need to use ADLO and BOCHS to feed the OS....----for windows and BSDs... YH _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 15 Jul 2006, at 01:40, Lu, Yinghai wrote:> Is it a good way? > > Any comment?It would be helpful to have a clearer explanation of the limitations of the current firmware, the benefits of your new approach, and likely effort and steps needed to get there. Also to compare that with the difficulty of solving any current problems by simply patching the current code base. For example, if the only aim is to emulate AMD64 platforms more accurately, maybe that is best done by evolving the current code. But moving to LinuxBIOS might have other benefits too -- if so they need explaining. Bear in mind also there''s an increasing amount of work going into hvmloader (e.g., SMBIOS patches) that will probably be impacted by a move to a whole new firmware architecture. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
1. virtual firmware do the pci init ( including bus enumerating and resource allocating) 2. virtual firmware create the acpi tables, mptable and irqtable according to driver model and cpu accessing instead of let loader to create thoese table. 3. So will have more clear boundary between driver model and vitutal firmware. in the ioemu side, need to update the current code to AMD device. Maybe the good way is using linuxbios+bochs and updating driver model in qemu at the same time Thanks Yinghai Lu On 7/15/06, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:> > On 15 Jul 2006, at 01:40, Lu, Yinghai wrote: > > > Is it a good way? > > > > Any comment? > > It would be helpful to have a clearer explanation of the limitations of > the current firmware, the benefits of your new approach, and likely > effort and steps needed to get there. Also to compare that with the > difficulty of solving any current problems by simply patching the > current code base. > > For example, if the only aim is to emulate AMD64 platforms more > accurately, maybe that is best done by evolving the current code. But > moving to LinuxBIOS might have other benefits too -- if so they need > explaining. > > Bear in mind also there''s an increasing amount of work going into > hvmloader (e.g., SMBIOS patches) that will probably be impacted by a > move to a whole new firmware architecture. > > -- Keir > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel