Re: [SeaBIOS] [Xen-devel] [PATCHv2 0/6] Improved multi-platform support
On Tue, 2013-02-19 at 10:51 +, David Woodhouse wrote: On Tue, 2013-02-19 at 10:20 +, 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 0x0 and not 0xfff0. 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?? ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Xen-devel] [PATCHv2 0/6] Improved multi-platform support
On Fri, 2013-02-15 at 12:09 +, David Woodhouse wrote: On Thu, 2013-02-14 at 16:46 +, Ian Campbell wrote: Right, we really need to find someone with hours to finish properly integrating OVMF. Hm, that 'someone' may end up being me¹. That would be awesome! I was actually wondering if this might make a good GSoC project, there has been someone (the same guy IIRC) doing Tianocore on Xen stuff in the last two years, under the Tianocore umbrella although with a Xen.org co-mentor. So... from the Xen point of view, what needs doing? I haven't looked at or run OVMF stuff myself on Xen or otherwise, so take this with a pinch of salt... 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. 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. We'd like to see PV I/O drivers at some point but that's a separate project in its own right I think. There are some things on my TODO list which apply to Qemu/KVM too — most importantly, fixing bootorder handling, which basically involves fixing the general case of NV variable storage for UEFI as discussed. But is there anything Xen-specific that I'm likely to miss? The main difference between Xen and Qemu/KVM in this context is that Xen supplied it's own SMBIOS ACPI tables etc. There's a likelyhood of Xen and OVMF exposing each others bugs in that area I suspect. 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. 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? If the ARM world continues moving towards UEFI then eventually we will likely want to enable this there too, but lets sort out x86 first. Are you content with my stated plan to provide a disk image for that, which is something like a 256KiB file on the host side, exposed as a flash device to the guest? It sounds OK to me. The other option would be to stash it in xenstore, but that doesn't sound like the right option to me. Ian. -- Ian Campbell Fascinating is a word I use for the unexpected. -- Spock, The Squire of Gothos, stardate 2124.5 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Xen-devel] [PATCHv2 0/6] Improved multi-platform support
On Tue, 2013-02-19 at 10:20 +, 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 0x0 and not 0xfff0. 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 smime.p7s Description: S/MIME cryptographic signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
