Bug 1368153

Created attachment 1191885 [details]
unknown device in windows guest

Description of problem:
In RHEL7.3,fw_cfg device can be shown in windows guest with no driver installed which will lead to win2016 svvp test fail.

RHEL7.2 qemu(qemu-kvm-rhev-2.3.0-31.el7.x86_64.) does not hit this issue.

As it's too late to create such driver in rhel7.3,we hope qemu can create a flag that can be used to hide the fw_cfg device in windows guest.

Version-Release number of selected component (if applicable):
qemu-kvm-rhev-2.6.0-21.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.boot a windows server 2016 guest on rhel7.3

2.check in qtree
(qemu) info qtree 
   dev: fw_cfg_io, id ""
       iobase = 1296 (0x510)
       dma_iobase = 1300 (0x514)
       dma_enabled = true


3.check in windows guest
in device manager(View-->resources by type),there is an unknown device(please check the screenshot)

Actual results:
There is an unknown device(please check the screenshot);
When we run rhel7.3 svvp test with windows2016,it will automatically detect this device has no driver installed which will lead to svvp test fail.
So I set test blocker keyword in this bug.

Expected results:
No unknown device shown in windows guest.

Additional info:
Following is Marcel's suggestion: https://bugzilla.redhat.com/show_bug.cgi?id=1246993#c14

I have some answers:
The problem is not connected to the "dma-enabled" flag, but with a new feature
added to the fw_cfg device: The possibility to see the fw_cfg data in the guest OS.

The way they did it is by adding a node in the ACPI DSDT table for the fw_cfg device:
Please see: https://lists.gnu.org/archive/html/qemu-devel/2016-02/msg04660.html
for details.

The way it is used in guest kernel can be seen here:
https://lkml.org/lkml/2016/1/27/1650


I can confirm this is the issue, possible solutions are:
- Add a Windows driver for it
- Find a way to hide the device, by removing it from DSDT or using a
an ACPI 'trick' to hide it from Windows guests - all that based on some property flag.


I suggest to reply to the QEMU upstream thread and explain what is the exact issue for Windows guests asking for guidance.