David Woodhouse
2013-Feb-19 10:51 UTC
Re: [SeaBIOS] [PATCHv2 0/6] Improved multi-platform support
On Tue, 2013-02-19 at 10:20 +0000, Ian Campbell wrote:> I expect there will be some rough edges like the NV variable thing -- I > have a feeling these will have a lot in common with qemu/KVM, since they > would tend to interact with the "platform" (provided by qemu-dm under > Xen) rather than processor or memory virt etc.Well, it''s mostly just storing text strings describing which device/path to boot from. So hopefully if the flash storage itself is OK for Xen, the rest should just work.> For the most part the I reckon the Xen specific things will be resync > with a recent upstream and fixup the Xen build system integration, stuff > like that.Current upstream OVMF works, AFAICT. Although as I said, I haven''t even tried booting an OS. One thing I obviously *also* haven''t tested, therefore, is *rebooting*., We''ve discovered a KVM bug on older CPUs without ''unrestricted guest'' mode, where after a reset it actually runs code from 0xffff0 and not 0xfffffff0. With the former being SeaBIOS-CSM, and the latter being the OVMF startup code that we *should* be running, that''s kind of a problem. If you have a similar bug, please go and fix it so I never have to know :)> We''d like to see PV I/O drivers at some point but that''s a separate > project in its own right I think.If you have an option ROM for them, that might not be a high priority. I think OVMF can thunk into INT 13h for disk access.> > And on the subject of the NV storage... does -pflash work on qemu-xen, > > as long as we''re not actually running *code* from the device and we''re > > only using it for data storage? > > I''m not sure, I''ve CC''d Anthony & Stefano. Assuming the Xen machine type > in Qemu wires it up then I don''t know why it shouldn''t work and if we > don''t wire it up I don''t see why we couldn''t.Qemu does but not in KVM mode, because it can''t *execute* from a region and also catch writes to properly emulate flash. But for a flash device that we *don''t* execute from, because it''s only used for NV storage and not the firmware itself, that restriction isn''t important. So I''ll need to fix that.> Hvmloader might need to be tweaked to setup the e820 correctly and > perhaps the some table or other would need to refer to it also?Right. Haven''t quite worked out how it would be ''found'' by the firmware yet. I was going to suggest making the address available via fw_cfg... but you don''t implement that. -- dwmw2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Ian Campbell
2013-Feb-20 11:57 UTC
Re: [SeaBIOS] [PATCHv2 0/6] Improved multi-platform support
On Tue, 2013-02-19 at 10:51 +0000, David Woodhouse wrote:> On Tue, 2013-02-19 at 10:20 +0000, Ian Campbell wrote: > > I expect there will be some rough edges like the NV variable thing -- I > > have a feeling these will have a lot in common with qemu/KVM, since they > > would tend to interact with the "platform" (provided by qemu-dm under > > Xen) rather than processor or memory virt etc. > > Well, it''s mostly just storing text strings describing which device/path > to boot from. So hopefully if the flash storage itself is OK for Xen, > the rest should just work.Ack.> > For the most part the I reckon the Xen specific things will be resync > > with a recent upstream and fixup the Xen build system integration, stuff > > like that. > > Current upstream OVMF works, AFAICT. Although as I said, I haven''t even > tried booting an OS. > > One thing I obviously *also* haven''t tested, therefore, is *rebooting*., > We''ve discovered a KVM bug on older CPUs without ''unrestricted guest'' > mode, where after a reset it actually runs code from 0xffff0 and not > 0xfffffff0. With the former being SeaBIOS-CSM, and the latter being the > OVMF startup code that we *should* be running, that''s kind of a problem. > > If you have a similar bug, please go and fix it so I never have to > know :)I''ve not heard of such a thing, but I''ve been half following the thread and it sounds a bit, shall we say, subtle ;-) Under Xen when qemu gets a reset event (via I/O writes or whatever) it ends up with the toolstack actually destroying and recreating the domain, so I think the issue you are thinking of doesn''t come up.> > We''d like to see PV I/O drivers at some point but that''s a separate > > project in its own right I think. > > If you have an option ROM for them, that might not be a high priority. I > think OVMF can thunk into INT 13h for disk access.We don''t have an option ROM, but that might be an interesting way to approach things, although there are issues with teardown before the OS comes along which endbootservices solves nicely for us.> > > And on the subject of the NV storage... does -pflash work on qemu-xen, > > > as long as we''re not actually running *code* from the device and we''re > > > only using it for data storage? > > > > I''m not sure, I''ve CC''d Anthony & Stefano. Assuming the Xen machine type > > in Qemu wires it up then I don''t know why it shouldn''t work and if we > > don''t wire it up I don''t see why we couldn''t. > > Qemu does but not in KVM mode, because it can''t *execute* from a region > and also catch writes to properly emulate flash. But for a flash device > that we *don''t* execute from, because it''s only used for NV storage and > not the firmware itself, that restriction isn''t important. So I''ll need > to fix that.Maybe it would be useful to emulate a dumb NV RAM region, as opposed to a full flash emulation?> > Hvmloader might need to be tweaked to setup the e820 correctly and > > perhaps the some table or other would need to refer to it also? > > Right. Haven''t quite worked out how it would be ''found'' by the firmware > yet. I was going to suggest making the address available via fw_cfg... > but you don''t implement that.There''s a little protocol between HVMloader and SeaBIOS which passes the tables across, see src/xen.c struct xen_seabios_info. Perhaps HVMloader+OVMF should be (or is?) using the same (or similar). Either way it should be extensible to cover this new info. The other option is an HVM_PARAM, which is Xen specific, but pretty simple. Ian. -- Ian Campbell Current Noise: Old Man''s Child - The Flames Of Deceit Did I SELL OUT yet??
Laszlo Ersek
2013-Feb-20 16:55 UTC
placement of emulated flash [was: seabios Improved multi-platform support]
Regarding the ACPI tables, OVMF takes them from Xen. It scans 0x000EA020 to 0x000FFFFF for the RSDP and goes from there. See OvmfPkg/AcpiPlatformDxe/Xen.c. I''m not sure about the e820 table. In hvmloader''s build_e820_table() [tools/firmware/hvmloader/e820.c], a range starting at RESERVED_MEMBASE is added to the table: /* * Explicitly reserve space for special pages. * This space starts at RESERVED_MEMBASE an extends to cover various * fixed hardware mappings (e.g., LAPIC, IOAPIC, default SVGA framebuffer). * * If igd_opregion_pgbase we need to split the RESERVED region in two. */ I gather this range is found non-specially by SeaBIOS [src/xen.c] in xen_ramsize_preinit(), following the xen_seabios_info struct you mentioned, placed at 0x00001000. However in OVMF the RESERVED_MEMBASE range is not parsed from this Xen-exported table, it is added manually in InitializeXen() [OvmfPkg/PlatformPei/Xen.c]: // // Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000). // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE. // AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000); "MemDetect.c" in the same directory might be relevant as well (GetSystemMemorySizeBelow4gb(), GetSystemMemorySizeAbove4gb(); they work from the CMOS). ... I gather this is about the placement of the flash memory, yes? If a static address could work for the flash, I think in OVMF we should update - MemMapInitialization() [OvmfPkg/PlatformPei/Platform.c] - OvmfPkg/AcpiTables/Dsdt.asl But I could be completely missing the topic here... Thanks, Laszlo
Ian Campbell
2013-Feb-20 17:18 UTC
Re: placement of emulated flash [was: seabios Improved multi-platform support]
On Wed, 2013-02-20 at 17:55 +0100, Laszlo Ersek wrote:> However in OVMF the RESERVED_MEMBASE range is not parsed from this > Xen-exported table, it is added manually in InitializeXen() > [OvmfPkg/PlatformPei/Xen.c]: > > // > // Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000). > // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE. > // > AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000);ICK, it would be far preferable for OVMF to do what SeaBIOS does and actually "communicate" with hvmloader IMHO. Ian. -- Ian Campbell Current Noise: Machine Head - Blistering Whatever doesn''t succeed in two months and a half in California will never succeed. -- Rev. Henry Durant, founder of the University of California
Laszlo Ersek
2013-Feb-20 22:50 UTC
Re: placement of emulated flash [was: seabios Improved multi-platform support]
On 02/20/13 18:18, Ian Campbell wrote:> On Wed, 2013-02-20 at 17:55 +0100, Laszlo Ersek wrote: >> However in OVMF the RESERVED_MEMBASE range is not parsed from this >> Xen-exported table, it is added manually in InitializeXen() >> [OvmfPkg/PlatformPei/Xen.c]: >> >> // >> // Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000). >> // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE. >> // >> AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000); > > ICK, it would be far preferable for OVMF to do what SeaBIOS does and > actually "communicate" with hvmloader IMHO.The table with "XenHVMSeaBIOS" signature is not created for OVMF I think; comparing the "bios_config" structure of function pointers between "seabios.c" and "ovmf.c" in tools/firmware/hvmloader/, the ovmf_config.bios_info_setup field is NULL. However there seem to be at least two "info" tables. Referring back, "seabios_info" at BIOS_INFO_PHYSICAL_ADDRESS (0x1000) is for SeaBIOS only, but "hvm_info" just below the end of conventional memory (at HVM_INFO_PADDR, 0x9F800) looks guest firmware independent. I guess the quoted range would be available from "hvm_info.reserved_mem_pgstart"? OvmfPkg/PlatformPei/Xen.c has a comment in XenConnect() saying /* TBD: Locate hvm_info and reserve it away. */ mXenInfo.HvmInfo = NULL; Is the generic approach "see if you can find all what you need in hvm_info, ask for the rest in a dedicated table"? (Out of pure curiosity.) Thanks Laszlo
Ian Campbell
2013-Feb-21 09:41 UTC
Re: placement of emulated flash [was: seabios Improved multi-platform support]
(dropping Attilio he has left Citrix). On Wed, 2013-02-20 at 23:50 +0100, Laszlo Ersek wrote:> On 02/20/13 18:18, Ian Campbell wrote: > > On Wed, 2013-02-20 at 17:55 +0100, Laszlo Ersek wrote: > >> However in OVMF the RESERVED_MEMBASE range is not parsed from this > >> Xen-exported table, it is added manually in InitializeXen() > >> [OvmfPkg/PlatformPei/Xen.c]: > >> > >> // > >> // Reserve away HVMLOADER reserved memory [0xFC000000,0xFD000000). > >> // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE. > >> // > >> AddReservedMemoryBaseSizeHob (0xFC000000, 0x1000000); > > > > ICK, it would be far preferable for OVMF to do what SeaBIOS does and > > actually "communicate" with hvmloader IMHO. > > The table with "XenHVMSeaBIOS" signature is not created for OVMF I > think; comparing the "bios_config" structure of function pointers > between "seabios.c" and "ovmf.c" in tools/firmware/hvmloader/, the > ovmf_config.bios_info_setup field is NULL.Yes. I think this should be changed then to provide a proper way for hvmloader to communicate to OVMF. It would seem sensible to follow a similar mechanism to SeaBIOS, or if possible just reuse the exact same thing (perhaps with a different signature).> However there seem to be at least two "info" tables. Referring back, > "seabios_info" at BIOS_INFO_PHYSICAL_ADDRESS (0x1000) is for SeaBIOS > only, but "hvm_info" just below the end of conventional memory (at > HVM_INFO_PADDR, 0x9F800) looks guest firmware independent.hvm_info is used by the toolstack to pass parameters to hvmloader itself when it starts, it is not intended to pass options from hvmloader to the bios. It is not a stable ABI struct (since hvmloader and the toolstack are a matched pair it doesn''t have to be) and we hope to eventually get rid of it. Possibly hvmloader should scrub it before calling the BIOS to discourage its use.> > I guess the quoted range would be available from > "hvm_info.reserved_mem_pgstart"? OvmfPkg/PlatformPei/Xen.c has a comment > in XenConnect() saying > > /* TBD: Locate hvm_info and reserve it away. */ > mXenInfo.HvmInfo = NULL;Oh dear.> Is the generic approach "see if you can find all what you need in > hvm_info, ask for the rest in a dedicated table"? (Out of pure curiosity.)As I hope is clear from the above, Nope ;-) Ian. -- Ian Campbell "Everyone is entitled to an *informed* opinion." -- Harlan Ellison