Bug 1281413

Thanks for the report. Can you try f23 libvirt with f22 qemu? That should isolate whether it's libvirt or qemu

I have updated libvirt to the f23 versions again and tpm is still working in the guest, so seems to be a problem with qemu.

stefanb, do you know any qemu tpm issues between versions 2.3 and 2.4?

Cole, QEMU has the same issue with the cancel path. I'll need to send them an update as well. Linux kernel changes moved that path.

Markus, are you still seeing this with up to date fedora 23? Libvirt patches might fix your case

Yes, I am still having this issue.

I don't think this is related to the cancel path. The F22 qemu has also the wrong cancel path in its binary, but that is correctly overriden by the (fixed) cancel path from libvirt.

Using the F22 binary still works fine for me. So it must be something introduced in between F22 and F23.

(In reply to Markus Heberling from comment #6)
> Yes, I am still having this issue.
> 
> I don't think this is related to the cancel path. The F22 qemu has also the
> wrong cancel path in its binary, but that is correctly overriden by the
> (fixed) cancel path from libvirt.
> 
> Using the F22 binary still works fine for me. So it must be something
> introduced in between F22 and F23.

Do you get any error messages related to the TPM in /var/log/libvirt/qemu/<VM name>.log?

Can you check whether SELinux is 'Enforcing' and may be getting in the way?

getenforce

And if it's enabled try to disabled it.

setenforce 0

Then try running your VM again.


   Stefan

Selinux is in Permissive mode.

Here is the log output from a run with qemu from f23:

2016-01-22 15:40:44.361+0000: starting up libvirt version: 1.2.18.2, package: 1.fc23 (Fedora Project, 2015-12-24-00:55:42, buildhw-12.phx2.fedoraproject.org), qemu version: 2.4.1 (qemu-2.4.1-5.fc23)
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=spice /usr/bin/qemu-kvm -name PCCOE -S -machine pc-i440fx-2.3,accel=kvm,usb=off -cpu Haswell-noTSX,+abm,+pdpe1gb,+rdrand,+f16c,+osxsave,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 8192 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 869ae859-4cfe-42de-8315-5191f4ecb14c -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/PCCOE.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -device usb-ccid,id=ccid0 -drive file=/var/lib/libvirt/images/PCCOE.qcow2,if=none,id=drive-ide0-0-0,format=qcow2 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=2 -drive if=none,id=drive-ide0-0-1,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=1 -netdev tap,fd=23,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:11:f5:fd,bus=pci.0,addr=0x3 -netdev tap,fd=24,id=hostnet1 -device rtl8139,netdev=hostnet1,id=net1,mac=52:54:00:8e:6d:d7,bus=pci.0,addr=0x8 -netdev tap,fd=25,id=hostnet2 -device rtl8139,netdev=hostnet2,id=net2,mac=52:54:00:47:c6:8b,bus=pci.0,addr=0x9 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -tpmdev passthrough,id=tpm-tpm0,path=/dev/fdset/3,cancel-path=/dev/fdset/4 -add-fd set=3,fd=26 -add-fd set=4,fd=27 -device tpm-tis,tpmdev=tpm-tpm0,id=tpm0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -smbios type=1,serial=CND5078SJD -msg timestamp=on
Domain id=2 is tainted: custom-argv
char device redirected to /dev/pts/6 (label charserial0)
main_channel_link: add main channel client
main_channel_handle_parsed: net test: latency 0.094000 ms, bitrate 33573770491 bps (32018.442622 Mbps)
red_dispatcher_set_cursor_peer: 
inputs_connect: inputs channel client create
ehci warning: guest updated active QH
ehci warning: guest updated active QH
main_channel_handle_parsed: agent start
ehci warning: guest updated active QH



For comparison, here an output from qemu from f22:

2016-01-22 15:51:53.540+0000: starting up libvirt version: 1.2.18.2, package: 1.fc23 (Fedora Project, 2015-12-24-00:55:42, buildhw-12.phx2.fedoraproject.org), qemu version: 2.3.1 (qemu-2.3.1-10.fc22)
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=spice /usr/bin/qemu-kvm -name PCCOE -S -machine pc-i440fx-2.3,accel=kvm,usb=off -cpu Haswell-noTSX,+abm,+pdpe1gb,+rdrand,+f16c,+osxsave,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 8192 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 869ae859-4cfe-42de-8315-5191f4ecb14c -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/PCCOE.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -device usb-ccid,id=ccid0 -drive file=/var/lib/libvirt/images/PCCOE.qcow2,if=none,id=drive-ide0-0-0,format=qcow2 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=2 -drive if=none,id=drive-ide0-0-1,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=1 -netdev tap,fd=23,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:11:f5:fd,bus=pci.0,addr=0x3 -netdev tap,fd=24,id=hostnet1 -device rtl8139,netdev=hostnet1,id=net1,mac=52:54:00:8e:6d:d7,bus=pci.0,addr=0x8 -netdev tap,fd=25,id=hostnet2 -device rtl8139,netdev=hostnet2,id=net2,mac=52:54:00:47:c6:8b,bus=pci.0,addr=0x9 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -tpmdev passthrough,id=tpm-tpm0,path=/dev/fdset/3,cancel-path=/dev/fdset/4 -add-fd set=3,fd=26 -add-fd set=4,fd=27 -device tpm-tis,tpmdev=tpm-tpm0,id=tpm0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -smbios type=1,serial=CND5078SJD -msg timestamp=on
Domain id=3 is tainted: custom-argv

(process:23043): GLib-WARNING **: gmem.c:482: custom memory allocation vtable not supported
char device redirected to /dev/pts/6 (label charserial0)
main_channel_link: add main channel client
main_channel_handle_parsed: net test: latency 0.109000 ms, bitrate 29681159420 bps (28306.159420 Mbps)
red_dispatcher_set_cursor_peer: 
inputs_connect: inputs channel client create
ehci warning: guest updated active QH
ehci warning: guest updated active QH
main_channel_handle_parsed: agent start



I don't see any messages related to tpm at all.

Markus

(In reply to Markus Heberling from comment #6)
> Yes, I am still having this issue.
> 
> I don't think this is related to the cancel path. The F22 qemu has also the
> wrong cancel path in its binary, but that is correctly overriden by the
> (fixed) cancel path from libvirt.
> 
> Using the F22 binary still works fine for me. So it must be something
> introduced in between F22 and F23.

So the only other thing I could think of would some ACPI table that's different between these versions and Windows 8 notices the difference.

    Stefan

(In reply to Stefan Berger from comment #9)
> (In reply to Markus Heberling from comment #6)
> > Yes, I am still having this issue.
> > 
> > I don't think this is related to the cancel path. The F22 qemu has also the
> > wrong cancel path in its binary, but that is correctly overriden by the
> > (fixed) cancel path from libvirt.
> > 
> > Using the F22 binary still works fine for me. So it must be something
> > introduced in between F22 and F23.
> 
> So the only other thing I could think of would some ACPI table that's
> different between these versions and Windows 8 notices the difference.
> 
>     Stefan


Markus,

  if I was to put a patch in here, could you try it? Or should I build an RPM of qemu for you to try?


This is the 2.3.1 ACPI table:

[...]
{
    Scope(\_SB) {
        /* TPM with emulated TPM TIS interface */
        Device (TPM) {
            Name (_HID, EisaID ("PNP0C31"))
            Name (_CRS, ResourceTemplate ()
            {
                Memory32Fixed (ReadWrite, TPM_TIS_ADDR_BASE, TPM_TIS_ADDR_SIZE)
                // older Linux tpm_tis drivers do not work with IRQ
                //IRQNoFlags () {TPM_TIS_IRQ}
            })
            Method (_STA, 0, NotSerialized) {
                Return (0x0F)
            }
        }
    }
}

This is the 2.4.1 APCI table code:

    sb_scope = aml_scope("\\_SB");
    {
    [ lots omitted ]
            if (bus) {
                Aml *scope = aml_scope("PCI0");
                /* Scan all PCI buses. Generate tables to support hotplug. */
                build_append_pci_bus_devices(scope, bus, pm->pcihp_bridge_en);

                if (misc->tpm_version != TPM_VERSION_UNSPEC) {
                    dev = aml_device("ISA.TPM");
                    aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0C31")));
                    aml_append(dev, aml_name_decl("_STA", aml_int(0xF)));
                    crs = aml_resource_template();
                    aml_append(crs, aml_memory32_fixed(TPM_TIS_ADDR_BASE,
                               TPM_TIS_ADDR_SIZE, AML_READ_WRITE));
                    aml_append(crs, aml_irq_no_flags(TPM_TIS_IRQ));
                    aml_append(dev, aml_name_decl("_CRS", crs));
                    aml_append(scope, dev);
                }

                aml_append(sb_scope, scope);
            }
        }
        aml_append(ssdt, sb_scope);


It looks like our ISA TPM device gets hooked to the 'scope' [aml_append(scope, dev)], which is 'PCI0'. So that's likely the difference between 2.3.1 and 2.4.1.

We may may need to replace aml_append(scope, dev) with aml_append(sb_scope, dev) and can forget about that PCI scope.


  Stefan

any news about this issue?
I think I also have this use with win 10 as guest..

(In reply to alon from comment #11)
> any news about this issue?
> I think I also have this use with win 10 as guest..

Can you try latest qemu from fedora virt preview and report if the issue still exists?

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwi6_Obiu7bLAhXFbj4KHZSqCDkQFggdMAA&url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FVirtualization_Preview_Repository&usg=AFQjCNEJDqkW3R4_rpGAn5xEwh6smY0jVQ

I just tried the qemu from fedora virt preview, and the TPM is not detected inside the VM, the same as in the qemu from f23. Reverting back to qemu from f22, so i can do some work. :)

Stefan gave me a patch offline to try, I made a build here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=13301538

Can someone who is reproducing this issue download the relevant packages linked there, install them, and see if the issue still reproduces?

I tried the build from http://koji.fedoraproject.org/koji/taskinfo?taskID=13301538 but TPM is still not working with my Windows 8 guest.

(In reply to Cole Robinson from comment #14)
> Stefan gave me a patch offline to try, I made a build here:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=13301538
> 
> Can someone who is reproducing this issue download the relevant packages
> linked there, install them, and see if the issue still reproduces?

Another difference is that this line here:

                //IRQNoFlags () {TPM_TIS_IRQ}

has changed to:

                    aml_append(crs, aml_irq_no_flags(TPM_TIS_IRQ));

For the record: I ran the following version with a Fedora 22 guest on a Fedora 23 host. The guest works fine. But this is Linux and Windows could be more 'picky' about something. Running the F22 guest shows that the 'mechanics' are working (cat /sys/devcise/pnp0/00:05/pcrs shows the PCRs), so the passthrough driver is not the reason.

# qemu-system-x86_64 --version
QEMU emulator version 2.4.1 (qemu-2.4.1-7.fc23), Copyright (c) 2003-2008 Fabrice Bellard

The underlying problem may be this message in 'dmesg':

tpm_tis 00:55: [Firmware Bug]: TPM interrupt not working, polling instead

So we may need to disabled the interrupts for the TIS.

   Stefan

With the ACPI patch I sent to Cole I don't get the above error in dmesg on Linux. So it solves a problem for Linux as well, though Linux falls back to polling if interrupt mode does not work and the error would not be noticed there. 

My conclusion is the TPM device cannot be on the PCI node in ACPI.


I would say that interrupts should be disabled for now. I am not sure whether we can hard code the interrupt into the ACPI table that then may lead to sharing interrupts with other devices that may or may not be plugged into the VM. With Linux I can use interrupt 5 ( = TPM_TIS_IRQ) or also 11, but that may depend on the configuration of the VM.

Okay I built stefan's second patch:

http://koji.fedoraproject.org/koji/taskinfo?taskID=13355995

Markus please give that a whirl

I tried the new build, but still can't dee the TPM from inside the windows VM.

Markus, can you describe how you are verifying the TPM is present/working in the windows VM? I'll try and reproduce, I think my laptop has a tpm ...

When the TPM is available I can log in using it on the windows login screen. If it's not working I don't have that option. 

Additionally we have some TPM troubleshooting tool from our company called TPMChecker. here is the output for a working TPM:
2016/03/16 [09:55:11.609] - TPMChecker.exe started. 
2016/03/16 [09:55:11.656] - {DoTPMConfigure} Entering... 
2016/03/16 [09:55:11.672] -  {DoTPMConfigure} Checking TPM spec version...
2016/03/16 [09:55:12.422] -  {DoTPMConfigure} TPM is avaiable. Spec Version:1.2.
2016/03/16 [09:55:12.422] -  {DoTPMConfigure} Checking TPM Status information...
2016/03/16 [09:55:12.890] -  {DoTPMConfigure} TPM Status information:
				TPM Activated:	Yes
				TPM Enabled:	Yes
				TPM Ownable:	Yes
				TPM Owned:	Yes
2016/03/16 [09:55:15.922] - TPMChecker.exe leaving.

This is a non working one:
2016/03/16 [14:17:28.670] - TPMChecker.exe started. 
2016/03/16 [14:17:28.841] - {DoTPMConfigure} Entering... 
2016/03/16 [14:17:28.857] -  {DoTPMConfigure} Checking TPM spec version...
2016/03/16 [14:17:29.732] -  {DoTPMConfigure} TPM is not available(e.g. No instance was found in WMI WIN32_TPM class. This could be no TPM physically or it was hidden in BIOS.).
2016/03/16 [14:17:29.732] -  {DoTPMConfigure} Trying to un-hide TPM by BIOS configuration...
2016/03/16 [14:17:37.560] -   [LaunchAppA] Entering...
	Command Line: "C:\Users\heberlim\Downloads\TPMCheck\TPMChecker2.1.1\BiosConfigUtility.EXE" /nspwd:XXX 
2016/03/16 [14:17:38.482] -   [LaunchAppA] Leaving... return code(Process Exit Code):0x0000000a
2016/03/16 [14:17:38.482] -   [LaunchAppA] Entering...
	Command Line: "C:\Users\heberlim\Downloads\TPMCheck\TPMChecker2.1.1\BiosConfigUtility.EXE" /cspwd:XXX /nspwd: 
2016/03/16 [14:17:38.857] -   [LaunchAppA] Leaving... return code(Process Exit Code):0x00000000
2016/03/16 [14:17:38.857] -   [LaunchAppA] Entering...
	Command Line: "C:\Users\heberlim\Downloads\TPMCheck\TPMChecker2.1.1\BiosConfigUtility.EXE" /getconfig:"C:\Users\heberlim\Downloads\TPMCheck\TPMChecker2.1.1\Current.REPSET"  
2016/03/16 [14:17:39.388] -   [LaunchAppA] Leaving... return code(Process Exit Code):0x00000010
2016/03/16 [14:17:39.388] -  {DoTPMConfigure} Failed to configure BIOS settings.
2016/03/16 [14:17:44.326] -   [LaunchAppW] Entering...
	Command Line:  /select, C:\Users\heberlim\Downloads\TPMCheck\TPMChecker2.1.1\TPMChecker.log 
2016/03/16 [14:17:44.326] -   [LaunchAppW] Leaving... return code(Process Exit Code):0xffffffff

Also the TPM module does not show up in the device manager in this case.

Is there a Windows boot log that shows differences ?

(In reply to Stefan Berger from comment #16)

> 
> # qemu-system-x86_64 --version
> QEMU emulator version 2.4.1 (qemu-2.4.1-7.fc23), Copyright (c) 2003-2008
> Fabrice Bellard
> 
> The underlying problem may be this message in 'dmesg':
> 
> tpm_tis 00:55: [Firmware Bug]: TPM interrupt not working, polling instead
> 
> So we may need to disabled the interrupts for the TIS.
> 
>    Stefan


After investigation of the above [Firmware Bug], the following seems to be causing this sequence error to appear in the log when using the passthrough driver:

421         chip->vendor.irq = irq;
422         if (!priv->irq_tested)
423                 msleep(1);
424         if (!priv->irq_tested) {
425                 disable_interrupts(chip);
426                 dev_err(chip->pdev,
427                         FW_BUG "TPM interrupt not working, polling instead\n");
428         }

The msleep(1) is likely too short for the response from the HW TPM to come back all the way through QEMU. So if I for example use the CUSE TPM driver (not in QEMU repo) the response comes back a lot faster and the error message does not get trigger. The TIS is working in interrupt mode on IRQ 5 just fine then. So this is a Linux issue and doesn't help us much with Windows. No changes to the construction of the ACPI tables were required to get this to work.

http://lxr.free-electrons.com/source/drivers/char/tpm/tpm_tis.c?v=4.3#L422

So I reproduced the issue. Definitely ACPI related like Stefan said... first buildable and broken commit is:

commit 9e472263b07d53cb3401ee49ef1b45ef195ddb84
Author: Michael S. Tsirkin <mst>
Date:   Mon Jun 1 21:03:59 2015 +0200

    acpi: add missing ssdt

For testing I was just checking windows device manager: when this is working, the device appears fine at Security Devices->Trusted Platform Module 1.2. When it isn't working, the device appears with a warning icon. The device status is "The device cannot find enough free resources it can use (Code 12)"

Trying Stefan's patch (I'll attach shortly), the results are different: the device doesn't appear in Device Manager _at_all_. So I suspect the patch is not correct anyways

Created attachment 1137166 [details]
tpm acpi v2 patch

Another difference: when the device is working (v2.3.0) device manager lists location='on Microsoft ACPI-Compliant System'. When it's not working (v2.5.0 without patch) location='on PCI to ISA bridge'

Created attachment 1137429 [details]
tpm acpi v3 patch

Stefan gave me another patch, this one appears to work in my testing, at least device manager shows the device fine without error.

Markus, can you try this build with the latest patch and confirm that things work correctly? I didn't do any functional testing

http://koji.fedoraproject.org/koji/taskinfo?taskID=13377047

Yes, the latest patch works, I can use the certificate on my TPM to log into windows. :)

Thanks all for fixing this.

Could you provide a minimum QMU CLI to reproduce issue, so I could try run Windows under ACPI debugger, perhaps that could tell us what exactly is wrong.

(In reply to Igor Mammedov from comment #30)
> Could you provide a minimum QMU CLI to reproduce issue, so I could try run
> Windows under ACPI debugger, perhaps that could tell us what exactly is
> wrong.

The follwing parameters add TPM passthrough to /dev/tpm0 support:

       -tpmdev passthrough,id=tpm0 \
        -device tpm-tis,irq=5,id=tpm0,tpmdev=tpm0 \

fixed/workarounded upstream for QEMU 2.6:

commit 2b1c2e8e5f1990f0a201a8cbf9d366fca60f4aa8
    pc: acpi: tpm: add missing MMIO resource to PCI0._CRS

commit 52e38eb0512585a5fadb431a65997b602d44874b
    tpm: acpi: remove IRQ from TPM's CRS to make Windows not see conflict

Thanks Igor!

qemu-2.4.1-9.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-f2b1f07256

qemu-2.4.1-9.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-f2b1f07256

qemu-2.4.1-9.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.