[libvirt] vTPM support in libvirt

Andreas Sommer AndiDog at web.de
Thu Jun 25 17:18:11 UTC 2009


Hi again,

I found out that the important files for the patch will be
- domain_conf.c
- util.h
- domain_conf.h
- xm_internal.c

Guess I could figure out how to code it, but I still need to know how to 
install libvirt from sources. There's no documentation about it...


Andreas Sommer wrote:
> I agree on ignoring "backend" for now. The "instance" parameter 
> defines a vTPM ID associated to that domain. There's a file "vtpm.db" 
> which lists all mappings between domain UUID and vTPM ID, which means 
> as long as you set a UUID for each of your domains, the correct vTPM 
> is selected automatically (this is important for loading the last vTPM 
> state).
>
> Can you please give me a short introduction on how to add this feature 
> to libvirt? I know how to check out the code and how to change the 
> domain RelaxNG schema, but where do I need to change the source code? 
> Oh, and how do I need to configure it in order to install it on a 
> machine (I guess "./configure --prefix=???" is important?!).
>
> Best regards
>    Andreas
>
> Daniel P. Berrange wrote:
>> On Thu, Jun 25, 2009 at 09:16:26AM +0100, Andreas Sommer wrote:
>>  
>>> I'm wondering if there will be vTPM support in libvirt in the near 
>>> future?! Xen does support it already with the configuration "vtpm = 
>>> ['instance=1,backend=0']", for example.
>>>
>>> So it would be great if the libvirt XML format supported it, too... 
>>> For example like this:
>>>
>>> <devices>
>>>    <vtpm instance="1" backend="xxx" />
>>> </devices>
>>>
>>> Both attributes are optional. The backend attribute is a VM ID (on 
>>> Xen, only zero for dom0 is supported) and could be implemented as a 
>>> UUID?!
>>>     
>>
>> I'd just ignore 'backend' for now - none of the other existing devices
>> suport anything other than dom0 as the backend, so its no loss to assume
>> dom0 for TPM too.
>>
>> What is 'instance' ?
>>
>> For element I'd prefer to just call it '<tpm>' - the 'v' is redundant
>> since every device is virtual here :-)
>>
>>  
>>> What do you think? Are there any efforts to introducing that?
>>>     
>>
>> No one has ever asked for it before, which is why we've not supported
>> this to date. I don't have any objection to supporting it, so patches
>> would be welcomed.
>>
>> Regards,
>> Daniel
>>   
>
> -- 
> Libvir-list mailing list
> Libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>




More information about the libvir-list mailing list