On 05/21/14 14:19, David Woodhouse wrote: > On Tue, 2014-05-13 at 04:54 +0200, Laszlo Ersek wrote:
>> - The specific (possibly accidental, fixable) problem is that using the >> SeaBIOS CSM plus the CSM infrastructure in edk2 breaks OVMF's S3 resume. >> I had not set out to track this down because of the other problem (see >> below). > > Wimp :) ... Yeah :) >> - The generic / inherent problem with the current SeaBIOS CSM + the edk2 >> CSM infrastructure is that the combination is a nightmare to trace, >> debug, and modify, for mere mortals. It switches from long mode to real >> mode and vice versa, and it's impossible to follow unless you know the >> relevant magic from the Intel SDM from memory. > > Actually I'm not sure that's any more true for CSM than it is for EDK2 > itself. If it doesn't work, most mortals will just give up. > > You did a *lot* of amazing work on enabling S3 support in OVMF. That was > dark magic, and yes its interaction with CSM will also involve darker > magic. But once it's fixed, it's fixed. It's largely a solved problem > and shouldn't *need* to be re-debugged very often. Especially since 'git > bisect' is such a no-brainer to use once you at least have a point in > history that *did* work¹. I wish this were true. I don't mean to imply it is not -- I *fear* it would turn out differently, potentially after we made a support promise to customers. >> (Without enabling the CSM in an OVMF build, the option to legacy-boot is >> lost of course as well, but I expressly don't desire that option. Just >> boot legacy OSes with pure SeaBIOS; it's easy to choose your firmware in >> a virtual machine.) > > I don't think I agree that it's easy to choose your firmware. Ah, by "easy" I meant "easily automatable at some point". There are plans. > If I'm > using virt-manager/libvirt under Fedora, how do I do it? I suppose it'd > be implicit in my choice of operating system? So I might be expected to > know that selecting "Fedora 20" will use legacy BIOS while "Fedora 21" > will magically switch me over to UEFI, according to criteria that are > entirely opaque to me? And if I'm using Ubuntu or something else, the > choices there might be entirely different? The libvirt / virt-manager plans (obligatory disclaimer about forward-looking statements etc etc :)) are about allowing the user to set the boot firmware in the libvirt domain XML, and to expose that setting in virt-manager as well. It should be independent of your OS choice -- for example you could install a SeaBIOS-based Fedora 20 VM and an OVMF-based Fedora 20 VM. The /domain/os/loader XML element already presents the possibility of picking any boot firwmare, but for OVMF it is not sufficient. (Perhaps the presentation (the XML schema) is, but the implementation (the -bios qemu flag) is not.) The proposed command line is visible in <http://git.qemu.org/?p=qemu.git;a=commitdiff;h=637a5acb> (but it needs another patch for OVMF that splits the build output in two, a variable store file and a firmware iamge file, to be mapped consecutively). In short the plan is to allow VMs to share the fw image on the host (some VMs would use SeaBIOS, some OVMF, but these would be all backed by two host-side files in total), and the OVMF-based VMs would each own a private variable store file in addition. The user-facing tools should allow the user to pick the firmware. > Or were you really intending the tools to give the user an explicit > choice of legacy vs. UEFI rather than depending on the OS? That would > kind of suck too. I consider that an advantage. Defaults can be set (OS types already come with different libvirt defaults), so the user is not forced to choose, but he/she can opt to. > Really, I think we should make CSM work and keep it working, Agreed, but my upstream cycles (too) are finite. When searching for a good boundary, thinking about "products" is not the worst idea. Feature creep is dangerous; I like to keep everything at the necessary minimum. One example: not building the SeaBIOS CSM into the OVMF binary will likely save one from any latent SeaBIOS bugs (and latent bugs in the interfacing edk2 infrastructure). Decreasing code size, cutting project/library dependencies, and limiting responsibility are always good. (Conversely, choosing SeaBIOS over OVMF will save one from *all* latent bugs in OVMF / edk2, and the affected guest OS code. If the user doesn't need the UEFI features, why should I convince him/her to pick OVMF over SeaBIOS?) > then it's a > no-brainer for users because things Just Work™. Never underestimate the > collective stupidity of end-users. If we can make it Just Work™, > especially since we're so close already, then I think we should. I agree, someone should find the time. :) Not sure about "so close" though; that's only evident in retrospect. > Which is why I spent the time to enable CSM in the first place, of > course. Not to mention the fact that having OVMF+CSM as a default > firmware will serve to accelerate adoption of UEFI in virtual machines, > and that gives people a *really* easy playground to get involved in EDK2 > source code; fixing bugs and making improvements. Making OVMF more widely available would probably attract more users, yes (and if we were forced to provide only one image in some distribution, then including the CSM could contribute to that). I'm not sure though how many of the new users would turn into developers (and in particular, patch reviewers). Remember what you said about the collective stup^W cluesness of end users! :) I agree that the CSM build should be kept in working shape, and new features should consider it as much as possible (and as much as the developers' workloads allow it). For example, making CSM support a hard requirement for patch acceptance seems too much (not implying that you suggested anything like that of course). Thanks Laszlo ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
