Bug 2170730
| Summary: | Regression: OvmfPkgX64 no longer supports Xen HVM | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Chuck Zmudzinski <brchuckz> | ||||
| Component: | edk2 | Assignee: | Paolo Bonzini <pbonzini> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 37 | CC: | berrange, brchuckz, crobinso, kraxel, m.a.young, pbonzini, philmd, virt-maint | ||||
| Target Milestone: | --- | Keywords: | Bugfix | ||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | edk2-20221117gitfff6d81270b5-14.fc39 edk2-20221117gitfff6d81270b5-14.fc38 edk2-20221117gitfff6d81270b5-14.fc37 edk2-20221117gitfff6d81270b5-14.fc36 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2023-02-17 17:16:54 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Chuck Zmudzinski
2023-02-17 05:15:51 UTC
> The result is that the file that is shipped by Fedora in the xen component
> (specifically, the /usr/libexec/xen/boot/ovmf.bin file in the xen-runtime
> package) no longer functions correctly when using it to boot a Xen HVM guest
> with the bios = 'ovmf' option set in the libxl xl.cfg domain configuration
> file.
Well, if xen goes combine code and vars into a single file anyway
(as noted in the patch) there is little reason to ship them.
We can just package OVMF.fd instead which xen can use directly,
and placing it in a separate sub-package which xen-runtime can
pull in as dependency probably makes sense too.
Test builds at https://copr.fedorainfracloud.org/coprs/kraxel/edk2.testbuilds/ now. > > The result is that the file that is shipped by Fedora in the xen component
> > (specifically, the /usr/libexec/xen/boot/ovmf.bin file in the xen-runtime
> > package) no longer functions correctly when using it to boot a Xen HVM guest
> > with the bios = 'ovmf' option set in the libxl xl.cfg domain configuration
> > file.
>
> Well, if xen goes combine code and vars into a single file anyway
> (as noted in the patch) there is little reason to ship them.
> We can just package OVMF.fd instead which xen can use directly,
> and placing it in a separate sub-package which xen-runtime can
> pull in as dependency probably makes sense too.
Yes, that is fine with me, I also tested the combined OVMF.fd file instead of
the combined file by concatenating the code and vars files (as the xen package
currently does) and it also fixes the bug. So unless there is a reason to ship
the code and vars files we can just ship OVMF.fd in the separate ovmf-xen
sub-package that xen-runtime can pull in as its build dependency.
Thanks for the quick response.
(In reply to Chuck Zmudzinski from comment #3) > > > The result is that the file that is shipped by Fedora in the xen component > > > (specifically, the /usr/libexec/xen/boot/ovmf.bin file in the xen-runtime > > > package) no longer functions correctly when using it to boot a Xen HVM guest > > > with the bios = 'ovmf' option set in the libxl xl.cfg domain configuration > > > file. > > > > Well, if xen goes combine code and vars into a single file anyway > > (as noted in the patch) there is little reason to ship them. > > We can just package OVMF.fd instead which xen can use directly, > > and placing it in a separate sub-package which xen-runtime can > > pull in as dependency probably makes sense too. > > Yes, that is fine with me, I also tested the combined OVMF.fd file instead > of the combined file by concatenating the code and vars files (as the xen > package currently does) and it also fixes the bug. So unless there is a > reason to ship the code and vars files we can just ship OVMF.fd in the > separate ovmf-xen sub-package that xen-runtime can pull in as its build > dependency. > In fact, I think it would be appropriate to just make the new ovmf-xen sub-package a Recommended dependency (not required because seabios, not ovmf is still the default firmware for Xen) of the xen-runtime package and configure Xen to use the OVMF.fd firmware from the ovmf-xen sub-package directly instead of having the ovmf-xen sub-package as a build dependency and installing the ovmf firmware for xen under /usr/libexec/xen/boot/ovmf.bin. So I inquire if that is OK with the xen packages maintainer (Michael Young). Michael, what do you think? Thanks. FEDORA-2023-951bd0eeaf has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-951bd0eeaf FEDORA-2023-951bd0eeaf has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report. I am satisfied with the update to rawwhide, so clearing all needinfo requests. Thanks! FEDORA-2023-d9a4db9d73 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-d9a4db9d73 FEDORA-2023-d9a4db9d73 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2023-06e4cf6b9f has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-06e4cf6b9f FEDORA-2023-e821b64a4c has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2023-e821b64a4c FEDORA-2023-e821b64a4c has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-e821b64a4c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-e821b64a4c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2023-06e4cf6b9f has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-06e4cf6b9f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-06e4cf6b9f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2023-06e4cf6b9f has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2023-e821b64a4c has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report. |