On Fri, Feb 14, 2025 at 9:26 PM Alexander Graf <g...@amazon.com> wrote:
>
>
> On 14.02.25 16:35, Ani Sinha wrote:
> > On Mon, Feb 3, 2025 at 3:50 AM Alexander Graf <g...@amazon.com> wrote:
> >> Hey Ani!
> >>
> >> On 28.01.25 22:31, Ani Sinha wrote:
>
>
> [...]
>
>
> >>> diff --git a/hw/core/machine.c b/hw/core/machine.c
> >>> index c23b399496..0eaf8aa3ba 100644
> >>> --- a/hw/core/machine.c
> >>> +++ b/hw/core/machine.c
> >>> @@ -34,6 +34,7 @@
> >>> #include "hw/virtio/virtio-pci.h"
> >>> #include "hw/virtio/virtio-net.h"
> >>> #include "hw/virtio/virtio-iommu.h"
> >>> +#include "hw/misc/vmfwupdate.h"
> >>> #include "audio/audio.h"
> >>>
> >>> GlobalProperty hw_compat_9_2[] = {
> >>> @@ -252,6 +253,7 @@ GlobalProperty hw_compat_2_8[] = {
> >>> { "virtio-pci", "x-pcie-pm-init", "off" },
> >>> { "cirrus-vga", "vgamem_mb", "8" },
> >>> { "isa-cirrus-vga", "vgamem_mb", "8" },
> >>> + {TYPE_VMFWUPDATE, "disable", "1"},
> >>
> >> If vmfwupdate is opt-in anyway, why disable for older machines?
> > Some older machines does not have enough slots for new fw-cfg files.
> > For those machines, we cannot add this device. Unless we disable the
> > device, QEMU would crash on an assertion.
> > This particular case was caught because the CI pipeline was failing.
> > There might be other cases where we need to disable it but CI does not
> > have a test case for it.
>
>
> Please find a better way to fix that. You can have better error
> propagation when fw-cfg fills up so it's clear that the problem is the
> additional vmfwupdate device. But silently changing the behavior from
> "Device does what I want it to do" to "Device is attached, but not
> functional" based on machine version is a big no-go. You *must* fail
> loudly, because you can not honor the user's wish (expose vmfwupdate).
OK I will figure out a better way to disable the device if there are
not enough fw-cfg slots availble.
Meanwhile, I sent out a v6
https://mail.gnu.org/archive/html/qemu-devel/2025-02/msg02982.html
