Bug 1281413 - Passthrough of tpm devices is broken in qemu-kvm in fedora 23
Passthrough of tpm devices is broken in qemu-kvm in fedora 23
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
23
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Fedora Virtualization Maintainers
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-12 08:15 EST by Markus Heberling
Modified: 2016-05-15 01:27 EDT (History)
18 users (show)

See Also:
Fixed In Version: qemu-2.4.1-9.fc23
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-15 01:27:43 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
tpm acpi v2 patch (2.18 KB, text/plain)
2016-03-16 19:00 EDT, Cole Robinson
no flags Details
tpm acpi v3 patch (1.75 KB, text/plain)
2016-03-17 12:10 EDT, Cole Robinson
no flags Details

  None (edit)
Description Markus Heberling 2015-11-12 08:15:29 EST
Description of problem:

Enabeling tpm passthrough in libvirt for a qemu-kvm virtual machine does nothing on fedora 23. I can see that wemu is started with the correct tpm parameters, but the guest operating system (windows 8 in this case) does not see the tpm device. It worked with fedora 22 with the same guest machine.

Version-Release number of selected component (if applicable):
 libvirt-client                  x86_64 1.2.18.1-2.fc23           fedora  4.4 M
 libvirt-daemon                  x86_64 1.2.18.1-2.fc23           fedora  536 k
 libvirt-daemon-config-network   x86_64 1.2.18.1-2.fc23           fedora   45 k
 libvirt-daemon-driver-interface x86_64 1.2.18.1-2.fc23           fedora   89 k
 libvirt-daemon-driver-network   x86_64 1.2.18.1-2.fc23           fedora  232 k
 libvirt-daemon-driver-nodedev   x86_64 1.2.18.1-2.fc23           fedora   88 k
 libvirt-daemon-driver-nwfilter  x86_64 1.2.18.1-2.fc23           fedora  113 k
 libvirt-daemon-driver-qemu      x86_64 1.2.18.1-2.fc23           fedora  516 k
 libvirt-daemon-driver-secret    x86_64 1.2.18.1-2.fc23           fedora   82 k
 libvirt-daemon-driver-storage   x86_64 1.2.18.1-2.fc23           fedora  261 k
 libvirt-daemon-kvm              x86_64 1.2.18.1-2.fc23           fedora   44 k
 libvirt-python                  x86_64 1.2.18-1.fc23             fedora  247 k
 libwsman1                       x86_64 2.6.0-1.fc23              fedora  131 k
 qemu-common                     x86_64 2:2.4.1-1.fc23            updates 293 k
 qemu-kvm                        x86_64 2:2.4.1-1.fc23            updates  57 k
 qemu-system-x86                 x86_64 2:2.4.1-1.fc23            updates 4.1 M

How reproducible:

fails for me every time.

Steps to Reproduce:
1. create a vm with tom passthrough
2. try to access the tpm from inside the guest

Actual results:

Guest does not see tpm device.

Expected results:

Guest sees tpm device.

Additional info:

downgrading qemu-kvm and dependencies to the fedora 22 versions fixes the problem:
  libvirt-client.x86_64 1.2.13.1-3.fc22                                         
  libvirt-daemon.x86_64 1.2.13.1-3.fc22                                         
  libvirt-daemon-config-network.x86_64 1.2.13.1-3.fc22                          
  libvirt-daemon-driver-interface.x86_64 1.2.13.1-3.fc22                        
  libvirt-daemon-driver-network.x86_64 1.2.13.1-3.fc22                          
  libvirt-daemon-driver-nodedev.x86_64 1.2.13.1-3.fc22                          
  libvirt-daemon-driver-nwfilter.x86_64 1.2.13.1-3.fc22                         
  libvirt-daemon-driver-qemu.x86_64 1.2.13.1-3.fc22                             
  libvirt-daemon-driver-secret.x86_64 1.2.13.1-3.fc22                           
  libvirt-daemon-driver-storage.x86_64 1.2.13.1-3.fc22                          
  libvirt-daemon-kvm.x86_64 1.2.13.1-3.fc22                                     
  libvirt-python.x86_64 1.2.13-1.fc22                                           
  libwsman1.x86_64 2.4.15-1.fc22                                                
  qemu-common.x86_64 2:2.3.1-7.fc22                                             
  qemu-kvm.x86_64 2:2.3.1-7.fc22                                                
  qemu-system-x86.x86_64 2:2.3.1-7.fc22
Comment 1 Cole Robinson 2015-11-12 10:17:59 EST
Thanks for the report. Can you try f23 libvirt with f22 qemu? That should isolate whether it's libvirt or qemu
Comment 2 Markus Heberling 2015-11-12 10:37:43 EST
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.
Comment 3 Cole Robinson 2015-11-16 19:57:28 EST
stefanb, do you know any qemu tpm issues between versions 2.3 and 2.4?
Comment 4 Stefan Berger 2015-11-16 20:41:24 EST
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.
Comment 5 Cole Robinson 2016-01-20 18:39:37 EST
Markus, are you still seeing this with up to date fedora 23? Libvirt patches might fix your case
Comment 6 Markus Heberling 2016-01-21 04:13:12 EST
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.
Comment 7 Stefan Berger 2016-01-21 08:10:19 EST
(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
Comment 8 Markus Heberling 2016-01-22 11:02:33 EST
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
Comment 9 Stefan Berger 2016-01-25 14:47:42 EST
(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
Comment 10 Stefan Berger 2016-01-25 15:47:13 EST
(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
Comment 11 alon 2016-03-10 07:30:42 EST
any news about this issue?
I think I also have this use with win 10 as guest..
Comment 12 Cole Robinson 2016-03-10 10:47:58 EST
(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
Comment 13 Markus Heberling 2016-03-10 14:17:03 EST
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. :)
Comment 14 Cole Robinson 2016-03-11 14:10:13 EST
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?
Comment 15 Markus Heberling 2016-03-12 05:48:36 EST
I tried the build from http://koji.fedoraproject.org/koji/taskinfo?taskID=13301538 but TPM is still not working with my Windows 8 guest.
Comment 16 Stefan Berger 2016-03-12 14:06:10 EST
(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
Comment 17 Stefan Berger 2016-03-12 17:49:35 EST
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.
Comment 18 Cole Robinson 2016-03-15 14:38:45 EDT
Okay I built stefan's second patch:

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

Markus please give that a whirl
Comment 19 Markus Heberling 2016-03-15 15:11:44 EDT
I tried the new build, but still can't dee the TPM from inside the windows VM.
Comment 20 Cole Robinson 2016-03-15 15:35:00 EDT
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 ...
Comment 21 Markus Heberling 2016-03-16 09:22:53 EDT
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.
Comment 22 Stefan Berger 2016-03-16 09:36:53 EDT
Is there a Windows boot log that shows differences ?
Comment 23 Stefan Berger 2016-03-16 17:40:22 EDT
(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
Comment 24 Cole Robinson 2016-03-16 18:59:37 EDT
So I reproduced the issue. Definitely ACPI related like Stefan said... first buildable and broken commit is:

commit 9e472263b07d53cb3401ee49ef1b45ef195ddb84
Author: Michael S. Tsirkin <mst@redhat.com>
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
Comment 25 Cole Robinson 2016-03-16 19:00 EDT
Created attachment 1137166 [details]
tpm acpi v2 patch
Comment 26 Cole Robinson 2016-03-16 19:04:50 EDT
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'
Comment 27 Cole Robinson 2016-03-17 12:10 EDT
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.
Comment 28 Cole Robinson 2016-03-17 12:11:19 EDT
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
Comment 29 Markus Heberling 2016-03-18 03:33:22 EDT
Yes, the latest patch works, I can use the certificate on my TPM to log into windows. :)

Thanks all for fixing this.
Comment 30 Igor Mammedov 2016-03-21 12:57:40 EDT
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.
Comment 31 Stefan Berger 2016-03-21 16:50:16 EDT
(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 \
Comment 32 Igor Mammedov 2016-04-21 07:46:43 EDT
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
Comment 33 Cole Robinson 2016-04-21 08:57:29 EDT
Thanks Igor!
Comment 34 Fedora Update System 2016-05-10 09:59:28 EDT
qemu-2.4.1-9.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-f2b1f07256
Comment 35 Fedora Update System 2016-05-12 05:35:33 EDT
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
Comment 36 Fedora Update System 2016-05-15 01:25:11 EDT
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.

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