Bug 1375444 - Add fw_cfg device in windows guest in order to make svvp test pass
Summary: Add fw_cfg device in windows guest in order to make svvp test pass
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.3
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: 7.4
Assignee: Michael S. Tsirkin
QA Contact: jingzhao
URL:
Whiteboard:
Keywords: TestBlocker, TestOnly
Depends On: 1368153 1390714
Blocks: 1401400 1395265
TreeView+ depends on / blocked
 
Reported: 2016-09-13 07:20 UTC by Marcel Apfelbaum
Modified: 2017-08-02 03:29 UTC (History)
15 users (show)

(edit)
Clone Of: 1368153
: 1390714 (view as bug list)
(edit)
Last Closed: 2017-08-01 23:34:44 UTC


Attachments (Terms of Use)
proposed patch - pls confirm and I will post it upstream (1.31 KB, patch)
2016-09-13 20:34 UTC, Michael S. Tsirkin
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:2392 normal SHIPPED_LIVE Important: qemu-kvm-rhev security, bug fix, and enhancement update 2017-08-01 20:04:36 UTC

Comment 1 Marcel Apfelbaum 2016-09-13 07:25:40 UTC
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.

Comment 3 Marcel Apfelbaum 2016-09-13 15:17:23 UTC
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.

Comment 4 Laszlo Ersek 2016-09-13 16:11:03 UTC
(Only one question here: why wasn't it me who thought of this? ;))

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

Comment 5 Michael S. Tsirkin 2016-09-13 20:24:17 UTC
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.

Comment 6 Michael S. Tsirkin 2016-09-13 20:34 UTC
Created attachment 1200614 [details]
proposed patch - pls confirm and I will post it upstream

would the attached fix the issue upstream?

Comment 7 Laszlo Ersek 2016-09-14 07:10:16 UTC
(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.

Comment 8 Igor Mammedov 2016-09-14 08:33:31 UTC
(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.

Comment 24 jingzhao 2016-11-10 05:53:47 UTC
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

Comment 25 Laszlo Ersek 2016-11-10 08:20:04 UTC
(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.

Comment 27 jingzhao 2016-11-10 09:06:32 UTC
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

Comment 28 Laszlo Ersek 2016-11-10 09:24:03 UTC
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?

Comment 29 jingzhao 2016-11-10 09:27:30 UTC
(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

Comment 30 Ademar Reis 2017-01-17 14:40:03 UTC
(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".

Comment 31 Miroslav Rezanina 2017-01-19 09:24:15 UTC
fw_cfg is abstract device in 2.8. Is this expected behavior with this BZ?

Comment 32 Laszlo Ersek 2017-02-16 18:33:37 UTC
(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).

Comment 35 errata-xmlrpc 2017-08-01 23:34:44 UTC
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

Comment 36 errata-xmlrpc 2017-08-02 01:12:22 UTC
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

Comment 37 errata-xmlrpc 2017-08-02 02:04:21 UTC
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

Comment 38 errata-xmlrpc 2017-08-02 02:45:08 UTC
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

Comment 39 errata-xmlrpc 2017-08-02 03:09:50 UTC
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

Comment 40 errata-xmlrpc 2017-08-02 03:29:59 UTC
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


Note You need to log in before you can comment on or make changes to this bug.