Bug 1375444

Hiding the fw_cfg device from 'Device Manager' is not enough, the
machine will still have an unrecognized device with no driver, so we will
fail the Windows svvp tests.

The solution is to add a new property like "guest-visible"
to the fw_cfg device and defaulting it to 'off' for new machines.

Igor's notes:

There is one more option:
- provide/ship stub driver for it along with the rest of virtio drivers.
For starters it could be dumb stub that climes declared resources and later extended to do the same stuff linux driver would do.

benefits:
 1. it would allow to pass svvp tests
 2. no need to cripple QEMU for the sake of SVVP, (i.e. OSPM still would do resource conflict checks)
 3. no need for tunables/conditionals on host side (qemu, libvirt, ...)

I've asked Ladi how difficult it would be to implement and he said
that it's mostly copy/past from panic driver that we already have,
and shouldn't be hard especially for stub.

(Only one question here: why wasn't it me who thought of this? ;))

So, yes, totally great idea! I support it!

In fact, I think I have a better idea:
if fw cfg is not used on command line,
remove the acpi device.
There's no real need for guests to access
built-in fw cfg entries which is all that exists
unless -fw_cfg is used.

Created attachment 1200614 [details]
proposed patch - pls confirm and I will post it upstream

would the attached fix the issue upstream?

(In reply to Michael S. Tsirkin from comment #6)
> Created attachment 1200614 [details]
> proposed patch - pls confirm and I will post it upstream
> 
> would the attached fix the issue upstream?

Who are you asking, Michael?

Personally I think the patch is okay technically; but for upstream Gabriel should review it primarily.

Whether this patch is more useful than a stub guest driver for Windows, that's another question IMO... Hiding the ACPI object is certainly simpler and should have fewer dependencies; on the other hand, Gabriel might have an interest in enhancing the windows guest driver once a skeleton / stub exists. I think I'd "approve" either way.

(In reply to Michael S. Tsirkin from comment #5)
> In fact, I think I have a better idea:
> if fw cfg is not used on command line,
> remove the acpi device.
> There's no real need for guests to access
> built-in fw cfg entries which is all that exists
> unless -fw_cfg is used.

that would work also, but with fw_cfg in ACPI and even dumb driver we keep resource conflict checks working, without it we loose that.

According to comment17, will see the device on 7.4 QEM, so, is there any bz can track the recovered device on 7.4 QEMU? if not, open an new issue for the tracking or keep tracking the recovered device on this bz.

Thanks
Jing Zhao

(In reply to jingzhao from comment #24)
> According to comment17, will see the device on 7.4 QEM, so, is there any bz
> can track the recovered device on 7.4 QEMU? if not, open an new issue for
> the tracking or keep tracking the recovered device on this bz.

We are in the process of rebasing qemu-kvm-rhev to upstream QEMU v2.7.0. I proposed in the rebase review thread that the downstream-only qemu-kvm-rhev patch that had fixed the issue temporarily, for bug 1368153, be simply dropped in the course of the rebase, and that this bug (== bug 1375444) be closed without code changes. Due to the issue being fixed through the virtio-win change for good (bug 1390714).

So no explicit revert is going to be necessary.

Hi Laszlo

  Thanks for your sharing, and QE just worried about missing related tests on rhel7.4, So I think we can open a new bz for the recover device on rhel7.4 and close the bz. How about you?

Thanks
Jing Zhao

That's not a bad idea, but I think it can be simplified: we can simply use this bug for tracking the reinstatement of the fw_cfg device, and move it to MODIFIED when the rebase to v2.7.0 is complete.

In other words, let's not close this BZ immediately; wait until it is fixed by the rebase, and then QE can test it explicitly. Agreed?

(In reply to Laszlo Ersek from comment #28)
> That's not a bad idea, but I think it can be simplified: we can simply use
> this bug for tracking the reinstatement of the fw_cfg device, and move it to
> MODIFIED when the rebase to v2.7.0 is complete.
> 
> In other words, let's not close this BZ immediately; wait until it is fixed
> by the rebase, and then QE can test it explicitly. Agreed?

---OK, that's great.

Thanks
Jing

(In reply to Laszlo Ersek from comment #28)
> That's not a bad idea, but I think it can be simplified: we can simply use
> this bug for tracking the reinstatement of the fw_cfg device, and move it to
> MODIFIED when the rebase to v2.7.0 is complete.
> 
> In other words, let's not close this BZ immediately; wait until it is fixed
> by the rebase, and then QE can test it explicitly. Agreed?

Based on that, I'm switching the BZ to POST+"fixed-in-version=qemu-2.7".

fw_cfg is abstract device in 2.8. Is this expected behavior with this BZ?

(In reply to Miroslav Rezanina from comment #31)
> fw_cfg is abstract device in 2.8. Is this expected behavior with this BZ?

Yes, it is expected behavior; the non-abstract device types (derived from the abstract fw_cfg base) are fw_cfg_io (x86) and fw_cfg_mem (aarch64).

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392