Dear all, I have been testing the patches for the full virtual TPM implementation.
Following the comments of the previous posts I have had no issues to make it working (using a QCOW2 non encrypted image). Nevertheless, if I use a QCOW2 encrypted image to store the NVRAM information, the TPM cannot be initiated normally after the first reboot: qemu-system-x86_64: TPM NVRAM blob size too big qemu-system-x86_64: TPM NVRAM load state failed Are you aware of this? Have you experienced this issue? Regards, Jordi. On 12/02/2013 03:16 PM, Corey Bryant wrote: > > > On 12/01/2013 11:00 PM, Xu, Quan wrote: >> >> >>> -----Original Message----- >>> From: Corey Bryant [mailto:cor...@linux.vnet.ibm.com] >>> Sent: Tuesday, November 26, 2013 10:40 PM >>> To: Xu, Quan >>> Cc: qemu-devel@nongnu.org >>> Subject: Re: [Qemu-devel] [PATCH 4/4] tpm: Provide libtpms software TPM >>> backend >>> >>> >>> On 11/25/2013 10:04 PM, Xu, Quan wrote: >>>> Thanks Bryant, this problem has been solved by following >>> "http://www.mail-archive.com/qemu-devel@nongnu.org/msg200808.html";. >>>> But there is another problem when run configure with >>>> "./configure --target-list=x86_64-softmmu --enable-tpm". The value of >>>> "libtpms" is still "no". when I modified "tpm_libtpms" to "yes" in >>>> configure file directly and make, then reported with error >>>> "hw/tpm/tpm_libtpms.c:21:33: fatal error: libtpms/tpm_library.h: No >>>> such file or directory". Now I am installing libtpms with >>> https://github.com/coreycb/libtpms for libtpms lib. Could you share >>> specific step >>> to configure QEMU based on your patch, if it comes easily to you? >>> >>> Here's what I've been using to build libtpms: >>> >>> $ CFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >>> -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' >>> $ export CFLAGS >>> $ ./configure --build=x86_64-redhat-linux-gnu --prefix=/usr >>> --libdir=/usr/lib64 >>> $ make >>> $ sudo make install >>> >>> And then the configure you're using above should work for QEMU. >> >> >> >> Sorry for my delay to answer you. I had a cold and took a sick >> leave at last Friday. > > Not a problem. I hope you're feeling better. > >> >> Now I have setup QEMU with your patch. Start VM with below command: >> == >> qemu-system-x86_64 -m 1024 -hda rhel.raw -nographic -vnc :1 >> -drive file=nvram.qcow2,if=none,id=nvram0-0-0,format=qcow2 -device >> tpm-tis,tpmdev=tpm-tpm0,id=tpm0 -tpmdev >> libtpms,id=tpm-tpm0,nvram=nvram0-0-0 -net nic -net >> tap,ifname=tap0,script=no >> == >> >> rhel.raw is Red Hat 6.4 image. Also I have rebuild kernel with TPM >> 1.2 driver in VM. But I still can't find " /sys/class/misc/tpm0/ ". >> >> Does it need SeaBios bios.bin to make it work? If need >> bios.bin, could you send me a bios.bin and tell me how to enable >> bios.bin with your patch? > > Yes it needs bios.bin. I've attached a bios.bin that has vTPM seabios > updates. You should be able to copy everything from > /usr/local/share/qemu to a new directory, and just replace the > bios.bin in the new directory with the one I've attached. Then point > qemu at the new directory. > > Also, make sure you enable the boot menu. Then when you boot your > guest you can press F11 to get a menu of TPM options to enable, > disable, activate, deactivate, clear, etc the vTPM. > > Here's some sample libvirt domain XML updates: > > <domain type='kvm' > xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> > ... > <os> > <bootmenu enable='yes'/> > </os> > ... > <qemu:commandline> > <qemu:arg value='-drive'/> > <qemu:arg > value='file=/home/corey/images/nvram.raw,if=none,id=drive-nvram0-0-0,format=raw'/> > <qemu:arg value='-tpmdev'/> > <qemu:arg value='libtpms,id=tpm-tpm0,nvram=drive-nvram0-0-0'/> > <qemu:arg value='-device'/> > <qemu:arg value='tpm-tis,tpmdev=tpm-tpm0,id=tpm0'/> > <qemu:arg value='-L'/> > <qemu:arg value='/usr/local/share/qemu/corey_seabios/'/> > </qemu:commandline> > ... > >> >> BTW, I found a SeaBios patch:( Add TPM support to SeaBIOS) >> http://www.seabios.org/pipermail/seabios/2011-April/001609.html. >> >> >> > > Stefan, do you know if this is the same code that was used to build > our bios.bin? >
