On Fri, Jul 05, 2024 at 12:38:36PM GMT, Christian Ehrhardt wrote:
> That is due to the check for valid_path having /usr/share/OVMF/ in
> restricted_rw and therefore blocking this. Now the question is,
> was this meant to allow using the system files RW - then I think
> it is rightfully blocked. Ins
This scenario is going to be ever more popular, especially now
that virt-manager has started using UEFI by default on riscv64
(see https://github.com/virt-manager/virt-manager/pull/670/).
Signed-off-by: Andrea Bolognani
---
...efi-riscv64.riscv64-latest.abi-update.args | 34 +++
It's available as part of the edk2-riscv64 Fedora package.
Signed-off-by: Andrea Bolognani
---
.../qemu_5.2.0-tcg-virt.riscv64.xml | 4 ++-
.../qemu_5.2.0-virt.riscv64.xml | 4 ++-
.../qemu_8.0.0-tcg-virt.riscv64.xml | 4 ++-
.../qemu_8.0.0-virt.riscv64.xml
By definition. Accordingly, filter them out when looking for
a read/write image.
Signed-off-by: Andrea Bolognani
---
src/qemu/qemu_firmware.c | 5 +++
.../firmware-auto-efi-rw.x86_64-latest.args | 34 ---
.../firmware-auto-efi-rw.x86_64-latest.err| 1
If the configuration explicitly requests a specific type of
firmware image, be it pflash or ROM, we should ignore all images
that are not of that type.
If no specific type has been requested, of course, any type is
considered a match and the selection will be based upon the
other attributes.
Sign
This new test case covers the scenario in which the user
specifically asked for a read/write pflash image.
>From the output files, we can see that the firmware selection
algorithm has picked a ROM image, which demonstrates the
presence of another bug. We're going to fix it with an upcoming
commit.
Andrea Bolognani (6):
tests: Update firmware descriptors
tests: Add more firmware selection coverage
qemu: Filter firmware images by type
qemu: ROM firmware images are always readonly
tests: Add firmware descriptor for edk2 on riscv64
tests: Add test for UEFI autoselection on riscv64
Sync with the edk2-20240524-4.fc39 package from Fedora.
The only notable change is that the inteltdx variant now declares
support for Secure Boot and is a ROM image instead of a stateless
pflash one.
The latter causes it to be considered eligible for the
configuration described by the firmware-au
On Mon, Jul 08, 2024 at 14:52:51 +0200, Martin Kletzander wrote:
> Similarly to commit 2482801608b8 we can safely ignore connectionId,
> portId and portgroupId in both XML and VMX as they are only a blind
> pass-through between XML and VMX and an ethernet without such parameters
> was spotted in th
Similarly to commit 2482801608b8 we can safely ignore connectionId,
portId and portgroupId in both XML and VMX as they are only a blind
pass-through between XML and VMX and an ethernet without such parameters
was spotted in the wild. On top of that even our documentation says the
whole VMWare Dist
10 matches
Mail list logo
