[PATCH 0/6] vTPM: Xen stubdom vTPM for HVM virtual machine

[PATCH 0/6] vTPM: Xen stubdom vTPM for HVM virtual machine

[Quan Xu]

Signed-off-by: Quan Xu <quan.xu@intel.com>

This patch series are only the Xen part to enable stubdom vTPM for HVM virtual machine.
it will work w/ Qemu patch series and seaBios patch series. Change QEMU_STUBDOM_VTPM 
compile option from 'n' to 'y', when the Qemu/SeaBios patch series are merged.

 Config.mk                             |  4 ++++
 extras/mini-os/include/tpmback.h      |  3 +++
 extras/mini-os/tpmback.c              | 20 +++++++++++++++++---
 tools/Makefile                        |  7 +++++++
 tools/firmware/hvmloader/acpi/build.c |  5 +++--
 tools/libxl/libxl.c                   | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_create.c            | 16 +++++++++++++---
 tools/libxl/libxl_dm.c                | 16 ++++++++++++++++
 tools/libxl/libxl_dom.c               |  2 ++
 tools/libxl/libxl_internal.h          |  3 +++
 tools/libxl/libxl_types.idl           |  1 +
 tools/libxl/xl_cmdimpl.c              |  2 ++
 xen/arch/x86/hvm/hvm.c                |  3 +++
 xen/include/public/hvm/params.h       |  1 +

I've tried to break it down to smaller patches:

 *(Patch 1/6)*  event channel bind interdomain with para/hvm virtual machine

 *(Patch 2/6)*  add HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine

 *(Patch 3/6)*  limit libxl__add_vtpms() function to para virtual machine

 *(Patch 4/6)*  add TPM TCPA and SSDT for HVM virtual machine when vTPM is added

 *(Patch 5/6)*  add vTPM device for HVM virtual machine

 *(Patch 6/6)*  add QEMU_STUBDOM_VTPM compile option

[PATCH 1/6] vTPM: event channel bind interdomain with para/hvm virtual machine

[Quan Xu]

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 extras/mini-os/include/tpmback.h |  3 +++
 extras/mini-os/tpmback.c         | 20 +++++++++++++++++---
 2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/extras/mini-os/include/tpmback.h b/extras/mini-os/include/tpmback.h
index 4408986..2618098 100644
--- a/extras/mini-os/include/tpmback.h
+++ b/extras/mini-os/include/tpmback.h
@@ -41,6 +41,9 @@
 #ifndef TPMBACK_H
 #define TPMBACK_H
 
+#define T_DOMAIN_TYPE_HVM 1
+#define T_DOMAIN_TYPE_PV  2
+
 struct tpmcmd {
    domid_t domid;		/* Domid of the frontend */
    uint8_t locality;    /* Locality requested by the frontend */
diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c
index 00b66e8..d76e05e 100644
--- a/extras/mini-os/tpmback.c
+++ b/extras/mini-os/tpmback.c
@@ -555,7 +555,7 @@ int connect_fe(tpmif_t* tpmif)
 {
    char path[512];
    char* err, *value;
-   uint32_t domid;
+   uint32_t domid, domtype;
    grant_ref_t ringref;
    evtchn_port_t evtchn;
 
@@ -608,14 +608,28 @@ int connect_fe(tpmif_t* tpmif)
    }
    free(value);
 
-   domid = tpmif->domid;
+   /* get the domain type*/
+   snprintf(path, 512, "%s/domain-type", tpmif->fe_path);
+   if ((err = xenbus_read(XBT_NIL, path, &value))) {
+       TPMBACK_ERR("xenbus_read(%s) Error = %s", path, err);
+       free(err);
+       return -1;
+   }
+   if (sscanf(value, "%d", &domtype) != 1) {
+       TPMBACK_ERR("Non integer value (%s) \n", value);
+       free(value);
+       return -1;
+   }
+
+   printk("domtype = %d \n",domtype);
+   domid = (domtype == T_DOMAIN_TYPE_HVM) ? 0 : tpmif->domid;
    if((tpmif->page = gntmap_map_grant_refs(&gtpmdev.map, 1, &domid, 0, &ringref, PROT_READ | PROT_WRITE)) == NULL) {
       TPMBACK_ERR("Failed to map grant reference %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle);
       return -1;
    }
 
    /*Bind the event channel */
-   if((evtchn_bind_interdomain(tpmif->domid, evtchn, tpmback_handler, tpmif, &tpmif->evtchn)))
+   if((evtchn_bind_interdomain(domid, evtchn, tpmback_handler, tpmif, &tpmif->evtchn)))
    {
       TPMBACK_ERR("%u/%u Unable to bind to interdomain event channel!\n", (unsigned int) tpmif->domid, tpmif->handle);
       goto error_post_map;
-- 
1.8.3.2

FW: FW: [PATCH 1/6] vTPM: event channel bind interdomain with para/hvm virtual machine

[Xu, Quan]

Forward to mail list. 
Thanks for your comment, I will read it in detail and try out some of your suggestions. 

Quan
> -----Original Message-----
> From: Daniel De Graaf [mailto:dgdegra@tycho.nsa.gov]
> Sent: Friday, October 31, 2014 2:29 AM
> To: Xu, Quan
> Cc: samuel.thibault@ens-lyon.org
> Subject: Re: FW: [PATCH 1/6] vTPM: event channel bind interdomain with
> para/hvm virtual machine
> 
> On 10/30/2014 11:06 AM, Xu, Quan wrote:
> [...]
> >> +   domid = (domtype == T_DOMAIN_TYPE_HVM) ? 0 : tpmif->domid;
> 
> This seems to preclude the use of stub domain device models for HVM domains;
> in that case, the event channel/grant page would need to be mapped to the stub
> domain.  I think it may be better to pass in the target domain ID in xenstore
> rather than overriding it based on PV vs HVM.  In any case, in order to support
> HVM domains with PV drivers, an additional backend/frontend pair is required
> for QEMU rather than redirecting the existing vTPM to the device model's
> domain.
> 
> I would suggest attaching the vTPM directly to domain 0, but that would cause
> the vTPM to be picked up by the dom0 kernel instead of by QEMU, so that is not
> helpful.  If there is an existing solution for disk or network driver domains
> attached to HVM, the solution used there should be mirrored here; I have not
> looked to see how (or if) it is solved in those drivers.
> 
> A solution needs to be able to handle:
> 
> 1. Existing PV domains
> 2. HVM domain using TIS MMIO and no stubdom - without special casing dom0 3.
> HVM domain using TIS MMIO via a stubdom 4. Linux HVM domain with the PV
> vTPM driver (talks directly to the vTPM)
> 
> Similar to network and disk, when an OS that understands Xen devices finds a
> vTPM interface, it should detach/ignore the MMIO TPM interface.
> The vTPM domain is set up to handle this case: multiple connections to a single
> vTPM domain are permitted and will all talk to the same TPM instance.  Locality
> restrictions are based on the event channel endpoint, and so will still work even
> when tpmif->domid is incorrect; this is required to properly implement the DRTM
> if it is to be emulated.
> 
> --
> Daniel De Graaf
> National Security Agency

Re: FW: [PATCH 1/6] vTPM: event channel bind interdomain with para/hvm virtual machine

[Xu, Quan]

> -----Original Message-----
> From: Daniel De Graaf [mailto:dgdegra@tycho.nsa.gov]
> Sent: Friday, October 31, 2014 2:29 AM
> To: Xu, Quan
> Cc: samuel.thibault@ens-lyon.org
> Subject: Re: FW: [PATCH 1/6] vTPM: event channel bind interdomain with
> para/hvm virtual machine
> 
> On 10/30/2014 11:06 AM, Xu, Quan wrote:
> [...]
> >> +   domid = (domtype == T_DOMAIN_TYPE_HVM) ? 0 : tpmif->domid;
> 
> This seems to preclude the use of stub domain device models for HVM
> domains; in that case, the event channel/grant page would need to be
> mapped to the stub domain.  I think it may be better to pass in the target
> domain ID in xenstore rather than overriding it based on PV vs HVM.  In any
> case, in order to support HVM domains with PV drivers, an additional
> backend/frontend pair is required for QEMU rather than redirecting the
> existing vTPM to the device model's domain.
> 

Thanks Graaf.
HVM domains are still runing tpm_tis.ko driver or Windows TPM 1.2 driver,
as they run on physical machine.
When I tried to enable vTPM for HVM domains, I pass in the target domain ID
in XenStore too, but it is not working. because the vTPM frontend is implemented in QEMU.

For HVM domains, QEMU is running in Dom0 as usual. So the domid shoud be 0.
some requirement from local ISV, they need vTPM for unmodified domain in
virtual desktop infrastructure.

> I would suggest attaching the vTPM directly to domain 0, but that would
> cause the vTPM to be picked up by the dom0 kernel instead of by QEMU, so
> that is not helpful.  If there is an existing solution for disk or network driver
> domains attached to HVM, the solution used there should be mirrored here;
> I have not looked to see how (or if) it is solved in those drivers.
> 
In this patch series, It is a solution for HVM domains. 
I am very pleased if we can collaborate to enhance / modify it in coming Xen version(4.7 or ..) 

> A solution needs to be able to handle:
> 
> 1. Existing PV domains

Yes, it is compatible with pv domains or non-vtpm domains. 

> 2. HVM domain using TIS MMIO and no stubdom - without special casing
> dom0 3. HVM domain using TIS MMIO via a stubdom 

Now the TIS MMIO is registered in Qemu. 


>4. Linux HVM domain
> with the PV vTPM driver (talks directly to the vTPM)

I did not have available physical machine. It is still building the domu 
kernel with PV vTPM driver.
I guess, there may be /dev/tpm0 and /dev/tpm1
I will share the test result tomorrow 

> 
> Similar to network and disk, when an OS that understands Xen devices finds
> a vTPM interface, it should detach/ignore the MMIO TPM interface.
> The vTPM domain is set up to handle this case: multiple connections to a
> single vTPM domain are permitted and will all talk to the same TPM instance.

Yes, pv domains and hvm domains can talk to the same TPM instance.
 
> Locality restrictions are based on the event channel endpoint, and so will still
> work even when tpmif->domid is incorrect; this is required to properly
> implement the DRTM if it is to be emulated.


Graaf, I will read your suggestion again and again. I have not read your new feature in 
Docs/misc/vtpm-platforms.txt.
I am still committing some other features, And dealing with some review comments. 
BTW, could you share some document about disk_io in stubdom/vtpmmgr. 
I enabled vtpmmgr on TPM 2.0 based on Xen 4.3.0. try to get rooted trust on TPM 2.0 .
it is not working now, as you changed disk io. 



> 
> --
> Daniel De Graaf
> National Security Agency


Thanks 
Quan Xu

Re: FW: [PATCH 1/6] vTPM: event channel bind interdomain with para/hvm virtual machine

[Xu, Quan]

> -----Original Message-----
> From: Xu, Quan
> Sent: Friday, November 07, 2014 12:56 AM
> To: Daniel De Graaf
> Cc: samuel.thibault@ens-lyon.org; xen-devel@lists.xen.org; Xu, Quan
> Subject: RE: FW: [PATCH 1/6] vTPM: event channel bind interdomain with
> para/hvm virtual machine
> 
> 
> 
> > -----Original Message-----
> > From: Daniel De Graaf [mailto:dgdegra@tycho.nsa.gov]
> > Sent: Friday, October 31, 2014 2:29 AM
> > To: Xu, Quan
> > Cc: samuel.thibault@ens-lyon.org
> > Subject: Re: FW: [PATCH 1/6] vTPM: event channel bind interdomain with
> > para/hvm virtual machine
> >
> > On 10/30/2014 11:06 AM, Xu, Quan wrote:
> > [...]
> > >> +   domid = (domtype == T_DOMAIN_TYPE_HVM) ? 0 : tpmif->domid;
> >
> > This seems to preclude the use of stub domain device models for HVM
> > domains; in that case, the event channel/grant page would need to be
> > mapped to the stub domain.  I think it may be better to pass in the
> > target domain ID in xenstore rather than overriding it based on PV vs
> > HVM.  In any case, in order to support HVM domains with PV drivers, an
> > additional backend/frontend pair is required for QEMU rather than
> > redirecting the existing vTPM to the device model's domain.
> >
> 
> Thanks Graaf.
> HVM domains are still runing tpm_tis.ko driver or Windows TPM 1.2 driver,
> as they run on physical machine.
> When I tried to enable vTPM for HVM domains, I pass in the target domain
> ID in XenStore too, but it is not working. because the vTPM frontend is
> implemented in QEMU.
> 
> For HVM domains, QEMU is running in Dom0 as usual. So the domid shoud
> be 0.
> some requirement from local ISV, they need vTPM for unmodified domain in
> virtual desktop infrastructure.
> 
> > I would suggest attaching the vTPM directly to domain 0, but that
> > would cause the vTPM to be picked up by the dom0 kernel instead of by
> > QEMU, so that is not helpful.  If there is an existing solution for
> > disk or network driver domains attached to HVM, the solution used
> > there should be mirrored here; I have not looked to see how (or if) it is
> solved in those drivers.
> >
> In this patch series, It is a solution for HVM domains.
> I am very pleased if we can collaborate to enhance / modify it in coming Xen
> version(4.7 or ..)
> 
> > A solution needs to be able to handle:
> >
> > 1. Existing PV domains
> 
> Yes, it is compatible with pv domains or non-vtpm domains.
> 
> > 2. HVM domain using TIS MMIO and no stubdom - without special casing
> > dom0 3. HVM domain using TIS MMIO via a stubdom
> 
> Now the TIS MMIO is registered in Qemu.
> 
> 
> >4. Linux HVM domain
> > with the PV vTPM driver (talks directly to the vTPM)
> 
> I did not have available physical machine. It is still building the domu kernel
> with PV vTPM driver.
> I guess, there may be /dev/tpm0 and /dev/tpm1 I will share the test result
> tomorrow

Graaf, the test result:
1. tpm_tis.ko / xen_tpmfront.ko are both enabled. 
  PV vTPM driver is running in guest domain.
# lsmod | grep xen_tpmfront
xen_tpmfront  6202  0

vtpm backend in xenstore:
backend = ""
    vtpm = ""
     9 = ""
      0 = ""
        [...]

Vtpm frontend in xenstore:
    vtpm = ""
     0 = ""
      [...]
      domain-type = "1"
      [...]
the domain type is 1, so HVM frontend vTPM driver is running.  
(  #define T_DOMAIN_TYPE_HVM 1
  #define T_DOMAIN_TYPE_PV  2
)




> 
> >
> > Similar to network and disk, when an OS that understands Xen devices
> > finds a vTPM interface, it should detach/ignore the MMIO TPM interface.
> > The vTPM domain is set up to handle this case: multiple connections to
> > a single vTPM domain are permitted and will all talk to the same TPM
> instance.
> 
> Yes, pv domains and hvm domains can talk to the same TPM instance.
> 
> > Locality restrictions are based on the event channel endpoint, and so
> > will still work even when tpmif->domid is incorrect; this is required
> > to properly implement the DRTM if it is to be emulated.
> 
> 
> Graaf, I will read your suggestion again and again. I have not read your new
> feature in Docs/misc/vtpm-platforms.txt.
> I am still committing some other features, And dealing with some review
> comments.
> BTW, could you share some document about disk_io in stubdom/vtpmmgr.
> I enabled vtpmmgr on TPM 2.0 based on Xen 4.3.0. try to get rooted trust on
> TPM 2.0 .
> it is not working now, as you changed disk io.
> 
> 
> 
> >
> > --
> > Daniel De Graaf
> > National Security Agency
> 
> 
> Thanks
> Quan Xu

[PATCH 2/6] vTPM: add HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine

[Quan Xu]

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 tools/libxl/libxl_dom.c         | 2 ++
 xen/arch/x86/hvm/hvm.c          | 3 +++
 xen/include/public/hvm/params.h | 1 +
 3 files changed, 6 insertions(+)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 74ea84b..a60e8c9 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -291,6 +291,8 @@ static void hvm_set_conf_params(xc_interface *handle, uint32_t domid,
 #if defined(__i386__) || defined(__x86_64__)
     xc_hvm_param_set(handle, domid, HVM_PARAM_HPET_ENABLED,
                     libxl_defbool_val(info->u.hvm.hpet));
+    xc_set_hvm_param(handle, domid, HVM_PARAM_STUBDOM_VTPM,
+                     info->num_vtpms);
 #endif
     xc_hvm_param_set(handle, domid, HVM_PARAM_TIMER_MODE, timer_mode(info));
     xc_hvm_param_set(handle, domid, HVM_PARAM_VPT_ALIGN,
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 78f519d..39e4c11 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5696,6 +5696,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
 
                 break;
             }
+            case HVM_PARAM_STUBDOM_VTPM:
+                rc = 0;
+                break;
             }
 
             if ( rc == 0 ) 
diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h
index 3c51072..333c131 100644
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -56,6 +56,7 @@
 
 #if defined(__i386__) || defined(__x86_64__)
 
+#define HVM_PARAM_STUBDOM_VTPM 8
 /*
  * Viridian enlightenments
  *
-- 
1.8.3.2

Re: [PATCH 2/6] vTPM: add HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine

[Andrew Cooper]

On 30/10/14 07:38, Quan Xu wrote:
> Signed-off-by: Quan Xu <quan.xu@intel.com>

What is the purpose of this parameter?  A patch like this is currently
unacceptable, especially as the libxl hunk indicates that the parameter
name does not match whatever information you are putting into it.

> ---
>  tools/libxl/libxl_dom.c         | 2 ++
>  xen/arch/x86/hvm/hvm.c          | 3 +++
>  xen/include/public/hvm/params.h | 1 +
>  3 files changed, 6 insertions(+)
>
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 74ea84b..a60e8c9 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -291,6 +291,8 @@ static void hvm_set_conf_params(xc_interface *handle, uint32_t domid,
>  #if defined(__i386__) || defined(__x86_64__)
>      xc_hvm_param_set(handle, domid, HVM_PARAM_HPET_ENABLED,
>                      libxl_defbool_val(info->u.hvm.hpet));
> +    xc_set_hvm_param(handle, domid, HVM_PARAM_STUBDOM_VTPM,
> +                     info->num_vtpms);
>  #endif
>      xc_hvm_param_set(handle, domid, HVM_PARAM_TIMER_MODE, timer_mode(info));
>      xc_hvm_param_set(handle, domid, HVM_PARAM_VPT_ALIGN,
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 78f519d..39e4c11 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -5696,6 +5696,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
>  
>                  break;
>              }
> +            case HVM_PARAM_STUBDOM_VTPM:
> +                rc = 0;
> +                break;
>              }
>  
>              if ( rc == 0 ) 
> diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h
> index 3c51072..333c131 100644
> --- a/xen/include/public/hvm/params.h
> +++ b/xen/include/public/hvm/params.h
> @@ -56,6 +56,7 @@
>  
>  #if defined(__i386__) || defined(__x86_64__)
>  
> +#define HVM_PARAM_STUBDOM_VTPM 8

New params should be added to the end of the number range.  8 is not up
for grabs.

~Andrew

>  /*
>   * Viridian enlightenments
>   *

Re: [PATCH 2/6] vTPM: add HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine

[Xu, Quan]

> -----Original Message-----
> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
> Sent: Thursday, October 30, 2014 7:50 PM
> To: Xu, Quan; xen-devel@lists.xen.org
> Cc: keir@xen.org; ian.campbell@citrix.com; tim@xen.org;
> ian.jackson@eu.citrix.com; jbeulich@suse.com
> Subject: Re: [Xen-devel] [PATCH 2/6] vTPM: add
> HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine
> 
> On 30/10/14 07:38, Quan Xu wrote:
> > Signed-off-by: Quan Xu <quan.xu@intel.com>
> 
> What is the purpose of this parameter?  A patch like this is currently
> unacceptable, especially as the libxl hunk indicates that the parameter name
> does not match whatever information you are putting into it.
> 
Thanks for your suggestion. 
This parameter tell the Qemu whether to register Qemu vTPM frontend in xen_hvm_init().
Qemu will get the parameter value by xc_get_hvm_param(). How can I change it?


> > ---
> >  tools/libxl/libxl_dom.c         | 2 ++
> >  xen/arch/x86/hvm/hvm.c          | 3 +++
> >  xen/include/public/hvm/params.h | 1 +
> >  3 files changed, 6 insertions(+)
> >
> > diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c index
> > 74ea84b..a60e8c9 100644
> > --- a/tools/libxl/libxl_dom.c
> > +++ b/tools/libxl/libxl_dom.c
> > @@ -291,6 +291,8 @@ static void hvm_set_conf_params(xc_interface
> > *handle, uint32_t domid,  #if defined(__i386__) || defined(__x86_64__)
> >      xc_hvm_param_set(handle, domid, HVM_PARAM_HPET_ENABLED,
> >                      libxl_defbool_val(info->u.hvm.hpet));
> > +    xc_set_hvm_param(handle, domid, HVM_PARAM_STUBDOM_VTPM,
> > +                     info->num_vtpms);
> >  #endif
> >      xc_hvm_param_set(handle, domid, HVM_PARAM_TIMER_MODE,
> timer_mode(info));
> >      xc_hvm_param_set(handle, domid, HVM_PARAM_VPT_ALIGN, diff --git
> > a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index
> > 78f519d..39e4c11 100644
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -5696,6 +5696,9 @@ long do_hvm_op(unsigned long op,
> > XEN_GUEST_HANDLE_PARAM(void) arg)
> >
> >                  break;
> >              }
> > +            case HVM_PARAM_STUBDOM_VTPM:
> > +                rc = 0;
> > +                break;
> >              }
> >
> >              if ( rc == 0 )
> > diff --git a/xen/include/public/hvm/params.h
> > b/xen/include/public/hvm/params.h index 3c51072..333c131 100644
> > --- a/xen/include/public/hvm/params.h
> > +++ b/xen/include/public/hvm/params.h
> > @@ -56,6 +56,7 @@
> >
> >  #if defined(__i386__) || defined(__x86_64__)
> >
> > +#define HVM_PARAM_STUBDOM_VTPM 8
> 
> New params should be added to the end of the number range.  8 is not up for
> grabs.
> 
> ~Andrew
> 
> >  /*
> >   * Viridian enlightenments
> >   *

Re: [PATCH 2/6] vTPM: add HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine

[Andrew Cooper]

On 30/10/14 12:05, Xu, Quan wrote:
>
>> -----Original Message-----
>> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
>> Sent: Thursday, October 30, 2014 7:50 PM
>> To: Xu, Quan; xen-devel@lists.xen.org
>> Cc: keir@xen.org; ian.campbell@citrix.com; tim@xen.org;
>> ian.jackson@eu.citrix.com; jbeulich@suse.com
>> Subject: Re: [Xen-devel] [PATCH 2/6] vTPM: add
>> HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine
>>
>> On 30/10/14 07:38, Quan Xu wrote:
>>> Signed-off-by: Quan Xu <quan.xu@intel.com>
>> What is the purpose of this parameter?  A patch like this is currently
>> unacceptable, especially as the libxl hunk indicates that the parameter name
>> does not match whatever information you are putting into it.
>>
> Thanks for your suggestion. 
> This parameter tell the Qemu whether to register Qemu vTPM frontend in xen_hvm_init().
> Qemu will get the parameter value by xc_get_hvm_param(). How can I change it?

This is surely something which should be a command line parameter to
qemu, or perhaps for qemu to read out of xenstore.

An HVM param is entirely inappropriate for this purpose, in my opinion.

~Andrew

Re: [PATCH 2/6] vTPM: add HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine

[Stefano Stabellini]

On Thu, 30 Oct 2014, Andrew Cooper wrote:
> On 30/10/14 12:05, Xu, Quan wrote:
> >
> >> -----Original Message-----
> >> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
> >> Sent: Thursday, October 30, 2014 7:50 PM
> >> To: Xu, Quan; xen-devel@lists.xen.org
> >> Cc: keir@xen.org; ian.campbell@citrix.com; tim@xen.org;
> >> ian.jackson@eu.citrix.com; jbeulich@suse.com
> >> Subject: Re: [Xen-devel] [PATCH 2/6] vTPM: add
> >> HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine
> >>
> >> On 30/10/14 07:38, Quan Xu wrote:
> >>> Signed-off-by: Quan Xu <quan.xu@intel.com>
> >> What is the purpose of this parameter?  A patch like this is currently
> >> unacceptable, especially as the libxl hunk indicates that the parameter name
> >> does not match whatever information you are putting into it.
> >>
> > Thanks for your suggestion. 
> > This parameter tell the Qemu whether to register Qemu vTPM frontend in xen_hvm_init().
> > Qemu will get the parameter value by xc_get_hvm_param(). How can I change it?
> 
> This is surely something which should be a command line parameter to
> qemu, or perhaps for qemu to read out of xenstore.
> 
> An HVM param is entirely inappropriate for this purpose, in my opinion.

I agree that an HVM param for this might not the best way to do it, but I
can see why Quan did it that way as we already have a few key parameters
passed to QEMU that way.

A QEMU command line option, QMP command or xenstore key would be better.

Re: [PATCH 2/6] vTPM: add HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine

[Xu, Quan]

> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Thursday, October 30, 2014 9:35 PM
> To: Andrew Cooper
> Cc: Xu, Quan; xen-devel@lists.xen.org; ian.jackson@eu.citrix.com; tim@xen.org;
> keir@xen.org; ian.campbell@citrix.com; jbeulich@suse.com
> Subject: Re: [Xen-devel] [PATCH 2/6] vTPM: add
> HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine
> 
> On Thu, 30 Oct 2014, Andrew Cooper wrote:
> > On 30/10/14 12:05, Xu, Quan wrote:
> > >
> > >> -----Original Message-----
> > >> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
> > >> Sent: Thursday, October 30, 2014 7:50 PM
> > >> To: Xu, Quan; xen-devel@lists.xen.org
> > >> Cc: keir@xen.org; ian.campbell@citrix.com; tim@xen.org;
> > >> ian.jackson@eu.citrix.com; jbeulich@suse.com
> > >> Subject: Re: [Xen-devel] [PATCH 2/6] vTPM: add
> > >> HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine
> > >>
> > >> On 30/10/14 07:38, Quan Xu wrote:
> > >>> Signed-off-by: Quan Xu <quan.xu@intel.com>
> > >> What is the purpose of this parameter?  A patch like this is
> > >> currently unacceptable, especially as the libxl hunk indicates that
> > >> the parameter name does not match whatever information you are putting
> into it.
> > >>
> > > Thanks for your suggestion.
> > > This parameter tell the Qemu whether to register Qemu vTPM frontend in
> xen_hvm_init().
> > > Qemu will get the parameter value by xc_get_hvm_param(). How can I
> change it?
> >
> > This is surely something which should be a command line parameter to
> > qemu, or perhaps for qemu to read out of xenstore.
> >
> > An HVM param is entirely inappropriate for this purpose, in my opinion.
> 
> I agree that an HVM param for this might not the best way to do it, but I can see
> why Quan did it that way as we already have a few key parameters passed to
> QEMU that way.
> 
> A QEMU command line option, QMP command or xenstore key would be better.

If hvm param is not the best way, I think xenstore key would be better.

Below is part of Qemu patch, that's why I add HVM_PARAM_STUBDOM_VTPM param.
xen_vtpm_register() is similar to xen_be_register()

### Qemu : xen_hvm_init() [xen-hvm.c]###
+#ifdef CONFIG_TPM_XENSTUBDOMS
+    xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
+    if (stubdom_vtpm) {
+        xen_vtpm_register(&xen_vtpmdev_ops);
+    }
+#endif

    xen_be_register("console", &xen_console_ops);
    xen_be_register("vkbd", &xen_kbdmouse_ops);
    xen_be_register("qdisk", &xen_blkdev_ops);
    xen_read_physmap(state);
##### Qemu ####


Quan 

Re: [PATCH 2/6] vTPM: add HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine

[Stefano Stabellini]

On Thu, 30 Oct 2014, Xu, Quan wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > Sent: Thursday, October 30, 2014 9:35 PM
> > To: Andrew Cooper
> > Cc: Xu, Quan; xen-devel@lists.xen.org; ian.jackson@eu.citrix.com; tim@xen.org;
> > keir@xen.org; ian.campbell@citrix.com; jbeulich@suse.com
> > Subject: Re: [Xen-devel] [PATCH 2/6] vTPM: add
> > HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine
> > 
> > On Thu, 30 Oct 2014, Andrew Cooper wrote:
> > > On 30/10/14 12:05, Xu, Quan wrote:
> > > >
> > > >> -----Original Message-----
> > > >> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
> > > >> Sent: Thursday, October 30, 2014 7:50 PM
> > > >> To: Xu, Quan; xen-devel@lists.xen.org
> > > >> Cc: keir@xen.org; ian.campbell@citrix.com; tim@xen.org;
> > > >> ian.jackson@eu.citrix.com; jbeulich@suse.com
> > > >> Subject: Re: [Xen-devel] [PATCH 2/6] vTPM: add
> > > >> HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine
> > > >>
> > > >> On 30/10/14 07:38, Quan Xu wrote:
> > > >>> Signed-off-by: Quan Xu <quan.xu@intel.com>
> > > >> What is the purpose of this parameter?  A patch like this is
> > > >> currently unacceptable, especially as the libxl hunk indicates that
> > > >> the parameter name does not match whatever information you are putting
> > into it.
> > > >>
> > > > Thanks for your suggestion.
> > > > This parameter tell the Qemu whether to register Qemu vTPM frontend in
> > xen_hvm_init().
> > > > Qemu will get the parameter value by xc_get_hvm_param(). How can I
> > change it?
> > >
> > > This is surely something which should be a command line parameter to
> > > qemu, or perhaps for qemu to read out of xenstore.
> > >
> > > An HVM param is entirely inappropriate for this purpose, in my opinion.
> > 
> > I agree that an HVM param for this might not the best way to do it, but I can see
> > why Quan did it that way as we already have a few key parameters passed to
> > QEMU that way.
> > 
> > A QEMU command line option, QMP command or xenstore key would be better.
> 
> If hvm param is not the best way, I think xenstore key would be better.
> 
> Below is part of Qemu patch, that's why I add HVM_PARAM_STUBDOM_VTPM param.
> xen_vtpm_register() is similar to xen_be_register()
> 
> ### Qemu : xen_hvm_init() [xen-hvm.c]###
> +#ifdef CONFIG_TPM_XENSTUBDOMS
> +    xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
> +    if (stubdom_vtpm) {
> +        xen_vtpm_register(&xen_vtpmdev_ops);
> +    }
> +#endif

I think I would need to see the rest of the QEMU patches to be able to
tell you which way I think is best.
In this context is vtpm an emulated device or a PV backend?

>     xen_be_register("console", &xen_console_ops);
>     xen_be_register("vkbd", &xen_kbdmouse_ops);
>     xen_be_register("qdisk", &xen_blkdev_ops);
>     xen_read_physmap(state);
> ##### Qemu ####
> 
> 
> Quan 
> 

Re: [PATCH 2/6] vTPM: add HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine

[Xu, Quan]

> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Saturday, November 01, 2014 1:51 AM
> To: Xu, Quan
> Cc: Stefano Stabellini; Andrew Cooper; xen-devel@lists.xen.org;
> ian.jackson@eu.citrix.com; tim@xen.org; keir@xen.org; ian.campbell@citrix.com;
> jbeulich@suse.com
> Subject: RE: [Xen-devel] [PATCH 2/6] vTPM: add
> HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine
> 
> On Thu, 30 Oct 2014, Xu, Quan wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > Sent: Thursday, October 30, 2014 9:35 PM
> > > To: Andrew Cooper
> > > Cc: Xu, Quan; xen-devel@lists.xen.org; ian.jackson@eu.citrix.com;
> > > tim@xen.org; keir@xen.org; ian.campbell@citrix.com;
> > > jbeulich@suse.com
> > > Subject: Re: [Xen-devel] [PATCH 2/6] vTPM: add
> > > HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine
> > >
> > > On Thu, 30 Oct 2014, Andrew Cooper wrote:
> > > > On 30/10/14 12:05, Xu, Quan wrote:
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
> > > > >> Sent: Thursday, October 30, 2014 7:50 PM
> > > > >> To: Xu, Quan; xen-devel@lists.xen.org
> > > > >> Cc: keir@xen.org; ian.campbell@citrix.com; tim@xen.org;
> > > > >> ian.jackson@eu.citrix.com; jbeulich@suse.com
> > > > >> Subject: Re: [Xen-devel] [PATCH 2/6] vTPM: add
> > > > >> HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine
> > > > >>
> > > > >> On 30/10/14 07:38, Quan Xu wrote:
> > > > >>> Signed-off-by: Quan Xu <quan.xu@intel.com>
> > > > >> What is the purpose of this parameter?  A patch like this is
> > > > >> currently unacceptable, especially as the libxl hunk indicates
> > > > >> that the parameter name does not match whatever information you
> > > > >> are putting
> > > into it.
> > > > >>
> > > > > Thanks for your suggestion.
> > > > > This parameter tell the Qemu whether to register Qemu vTPM
> > > > > frontend in
> > > xen_hvm_init().
> > > > > Qemu will get the parameter value by xc_get_hvm_param(). How can
> > > > > I
> > > change it?
> > > >
> > > > This is surely something which should be a command line parameter
> > > > to qemu, or perhaps for qemu to read out of xenstore.
> > > >
> > > > An HVM param is entirely inappropriate for this purpose, in my opinion.
> > >
> > > I agree that an HVM param for this might not the best way to do it,
> > > but I can see why Quan did it that way as we already have a few key
> > > parameters passed to QEMU that way.
> > >
> > > A QEMU command line option, QMP command or xenstore key would be
> better.
> >
> > If hvm param is not the best way, I think xenstore key would be better.
> >
> > Below is part of Qemu patch, that's why I add HVM_PARAM_STUBDOM_VTPM
> param.
> > xen_vtpm_register() is similar to xen_be_register()
> >
> > ### Qemu : xen_hvm_init() [xen-hvm.c]###
> > +#ifdef CONFIG_TPM_XENSTUBDOMS
> > +    xc_get_hvm_param(xen_xc, xen_domid,
> HVM_PARAM_STUBDOM_VTPM, &stubdom_vtpm);
> > +    if (stubdom_vtpm) {
> > +        xen_vtpm_register(&xen_vtpmdev_ops);
> > +    }
> > +#endif
> 
> I think I would need to see the rest of the QEMU patches to be able to tell you
> which way I think is best.
> In this context is vtpm an emulated device or a PV backend?
> 

I have submitted Qemu patch series -- "[PATCH 0/4] Qemu-Xen-vTPM: enable Xen stubdom vTPM for	HVM virtual machine"

It is not an emulated device. It is a pv backend. This driver transfers any request/repond between TPM xenstubdoms driver 
and Xen vTPM stubdom, and facilitates communications between Xen vTPM stubdom domain and vTPM xenstubdoms driver

Quan 

> >     xen_be_register("console", &xen_console_ops);
> >     xen_be_register("vkbd", &xen_kbdmouse_ops);
> >     xen_be_register("qdisk", &xen_blkdev_ops);
> >     xen_read_physmap(state);
> > ##### Qemu ####
> >
> >
> > Quan
> >

Re: [PATCH 2/6] vTPM: add HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine

[Xu, Quan]

> -----Original Message-----
> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
> Sent: Thursday, October 30, 2014 8:17 PM
> To: Xu, Quan; xen-devel@lists.xen.org
> Cc: keir@xen.org; ian.campbell@citrix.com; tim@xen.org;
> ian.jackson@eu.citrix.com; jbeulich@suse.com
> Subject: Re: [Xen-devel] [PATCH 2/6] vTPM: add
> HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine
> 
> On 30/10/14 12:05, Xu, Quan wrote:
> >
> >> -----Original Message-----
> >> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
> >> Sent: Thursday, October 30, 2014 7:50 PM
> >> To: Xu, Quan; xen-devel@lists.xen.org
> >> Cc: keir@xen.org; ian.campbell@citrix.com; tim@xen.org;
> >> ian.jackson@eu.citrix.com; jbeulich@suse.com
> >> Subject: Re: [Xen-devel] [PATCH 2/6] vTPM: add
> HVM_PARAM_STUBDOM_VTPM
> >> parameter for HVM virtual machine
> >>
> >> On 30/10/14 07:38, Quan Xu wrote:
> >>> Signed-off-by: Quan Xu <quan.xu@intel.com>
> >> What is the purpose of this parameter?  A patch like this is
> >> currently unacceptable, especially as the libxl hunk indicates that
> >> the parameter name does not match whatever information you are putting
> into it.
> >>
> > Thanks for your suggestion.
> > This parameter tell the Qemu whether to register Qemu vTPM frontend in
> xen_hvm_init().
> > Qemu will get the parameter value by xc_get_hvm_param(). How can I change
> it?
> 
> This is surely something which should be a command line parameter to qemu, or
> perhaps for qemu to read out of xenstore.
> 
> An HVM param is entirely inappropriate for this purpose, in my opinion.

Appreciate your advice, the below is the idea why I enable it with an hvm param.
Actually there are some command line parameter to qemu in patch
*[PATCH 5/6] vTPM: add vTPM device for HVM virtual machine*
+        flexarray_vappend(dm_args, "-tpmdev",
+                          "xenstubdoms,id=xenvtpm0", NULL);
+        flexarray_vappend(dm_args,"-device",
+                          "tpm-tis,tpmdev=xenvtpm0", NULL);

Qemu registers xen backend with 'xen_be_register()' in xen_hvm_init() [Qemu/xen-hvm.c]. 
Such as some existing devices,' console'/'vkbd'/'qdisk'.
## Qemu source code in xen_hvm_init() [Qemu/xen-hvm.c]##
    xen_be_register("console", &xen_console_ops);
    xen_be_register("vkbd", &xen_kbdmouse_ops);
    xen_be_register("qdisk", &xen_blkdev_ops);
####
So xen_vtpm_register() is also a xen backend. it should align with it.

Reading out of xenstore is also a common way to get value parameters. Try to align with 
Qemu, there are a lot of 'xc_get_hvm_param()'  to get ' HVM_PARAM_IOREQ_PFN ' /
HVM_PARAM_BUFIOREQ_PFN / HVM_PARAM_BUFIOREQ_EVTCHN
in xen_hvm_init() [Qemu/xen-hvm.c]. 

I should commit Qemu patch ASAP too. I will CC you when I commit it in next days.
I will modify it if it's better to for qemu to read out of xenstore.


Quan
> 
> ~Andrew

Re: [PATCH 2/6] vTPM: add HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine

[Xu, Quan]

> -----Original Message-----
> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
> Sent: Thursday, October 30, 2014 7:50 PM
> To: Xu, Quan; xen-devel@lists.xen.org
> Cc: keir@xen.org; ian.campbell@citrix.com; tim@xen.org;
> ian.jackson@eu.citrix.com; jbeulich@suse.com
> Subject: Re: [Xen-devel] [PATCH 2/6] vTPM: add
> HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine
> 
> On 30/10/14 07:38, Quan Xu wrote:
> > Signed-off-by: Quan Xu <quan.xu@intel.com>
> 
> What is the purpose of this parameter?  A patch like this is currently
> unacceptable, especially as the libxl hunk indicates that the parameter name
> does not match whatever information you are putting into it.
> 
> > ---
> >  tools/libxl/libxl_dom.c         | 2 ++
> >  xen/arch/x86/hvm/hvm.c          | 3 +++
> >  xen/include/public/hvm/params.h | 1 +
> >  3 files changed, 6 insertions(+)
> >
> > diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c index
> > 74ea84b..a60e8c9 100644
> > --- a/tools/libxl/libxl_dom.c
> > +++ b/tools/libxl/libxl_dom.c
> > @@ -291,6 +291,8 @@ static void hvm_set_conf_params(xc_interface
> > *handle, uint32_t domid,  #if defined(__i386__) || defined(__x86_64__)
> >      xc_hvm_param_set(handle, domid, HVM_PARAM_HPET_ENABLED,
> >                      libxl_defbool_val(info->u.hvm.hpet));
> > +    xc_set_hvm_param(handle, domid, HVM_PARAM_STUBDOM_VTPM,
> > +                     info->num_vtpms);
> >  #endif
> >      xc_hvm_param_set(handle, domid, HVM_PARAM_TIMER_MODE,
> timer_mode(info));
> >      xc_hvm_param_set(handle, domid, HVM_PARAM_VPT_ALIGN, diff --git
> > a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index
> > 78f519d..39e4c11 100644
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -5696,6 +5696,9 @@ long do_hvm_op(unsigned long op,
> > XEN_GUEST_HANDLE_PARAM(void) arg)
> >
> >                  break;
> >              }
> > +            case HVM_PARAM_STUBDOM_VTPM:
> > +                rc = 0;
> > +                break;
> >              }
> >
> >              if ( rc == 0 )
> > diff --git a/xen/include/public/hvm/params.h
> > b/xen/include/public/hvm/params.h index 3c51072..333c131 100644
> > --- a/xen/include/public/hvm/params.h
> > +++ b/xen/include/public/hvm/params.h
> > @@ -56,6 +56,7 @@
> >
> >  #if defined(__i386__) || defined(__x86_64__)
> >
> > +#define HVM_PARAM_STUBDOM_VTPM 8
> 
> New params should be added to the end of the number range.  8 is not up for
> grabs.
> 
I will fix it if HVM params is acceptable (or, I should use xenstore key). Now I am breaking down
Qemu/seabios patch. I will commit these patch ASAP.. 

> ~Andrew
> 
> >  /*
> >   * Viridian enlightenments
> >   *

[PATCH 3/6] vTPM: limit libxl__add_vtpms() function to para virtual machine

[Quan Xu]

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 tools/libxl/libxl_create.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index b1ff5ae..0a09925 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1358,8 +1358,9 @@ static void domcreate_attach_vtpms(libxl__egc *egc,
        goto error_out;
    }
 
-    /* Plug vtpm devices */
-   if (d_config->num_vtpms > 0) {
+   /* Plug vtpm devices for para virtual domain*/
+   if (d_config->num_vtpms > 0 &&
+       d_config->b_info.type == LIBXL_DOMAIN_TYPE_PV) {
        /* Attach vtpms */
        libxl__multidev_begin(ao, &dcs->multidev);
        dcs->multidev.callback = domcreate_attach_pci;
-- 
1.8.3.2

[PATCH 4/6] vTPM: add TPM TCPA and SSDT for HVM virtual machine when vTPM is added

[Quan Xu]

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 tools/firmware/hvmloader/acpi/build.c | 5 +++--
 tools/libxl/libxl_create.c            | 5 ++++-
 tools/libxl/libxl_types.idl           | 1 +
 tools/libxl/xl_cmdimpl.c              | 2 ++
 4 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 1431296..f2aa071 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -313,9 +313,10 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
 
     /* TPM TCPA and SSDT. */
     tis_hdr = (uint16_t *)0xFED40F00;
-    if ( (tis_hdr[0] == tis_signature[0]) &&
+    if ( ((tis_hdr[0] == tis_signature[0]) &&
          (tis_hdr[1] == tis_signature[1]) &&
-         (tis_hdr[2] == tis_signature[2]) )
+         (tis_hdr[2] == tis_signature[2])) ||
+         !strncmp(xenstore_read("platform/acpi_stubdom_vtpm", "1"), "1", 1) )
     {
         ssdt = mem_alloc(sizeof(ssdt_tpm), 16);
         if (!ssdt) return -1;
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 0a09925..c6f68fe 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -432,7 +432,7 @@ int libxl__domain_build(libxl__gc *gc,
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
 
-        localents = libxl__calloc(gc, 9, sizeof(char *));
+        localents = libxl__calloc(gc, 11, sizeof(char *));
         i = 0;
         localents[i++] = "platform/acpi";
         localents[i++] = libxl_defbool_val(info->u.hvm.acpi) ? "1" : "0";
@@ -440,6 +440,9 @@ int libxl__domain_build(libxl__gc *gc,
         localents[i++] = libxl_defbool_val(info->u.hvm.acpi_s3) ? "1" : "0";
         localents[i++] = "platform/acpi_s4";
         localents[i++] = libxl_defbool_val(info->u.hvm.acpi_s4) ? "1" : "0";
+        localents[i++] = "platform/acpi_stubdom_vtpm";
+        localents[i++] = (info->num_vtpms > 0) ? "1" : "0";
+
         if (info->u.hvm.mmio_hole_memkb) {
             uint64_t max_ram_below_4g =
                 (1ULL << 32) - (info->u.hvm.mmio_hole_memkb << 10);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index ca3f724..b08b974 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -379,6 +379,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
     # if you set device_model you must set device_model_version too
     ("device_model",     string),
     ("device_model_ssidref", uint32),
+    ("num_vtpms", integer),
     ("device_model_ssid_label", string),
 
     # extra parameters pass directly to qemu, NULL terminated
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3c9f146..9c43e88 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1414,6 +1414,7 @@ static void parse_config_data(const char *config_source,
 
     if (!xlu_cfg_get_list(config, "vtpm", &vtpms, 0, 0)) {
         d_config->num_vtpms = 0;
+        b_info->num_vtpms = 0;
         d_config->vtpms = NULL;
         while ((buf = xlu_cfg_get_listitem (vtpms, d_config->num_vtpms)) != NULL) {
             libxl_device_vtpm *vtpm;
@@ -1456,6 +1457,7 @@ static void parse_config_data(const char *config_source,
             }
             free(buf2);
             d_config->num_vtpms++;
+            b_info->num_vtpms++;
         }
     }
 
-- 
1.8.3.2

[PATCH 5/6] vTPM: add vTPM device for HVM virtual machine

[Quan Xu]

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 tools/libxl/libxl.c          | 62 ++++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_create.c   |  6 +++++
 tools/libxl/libxl_dm.c       | 16 ++++++++++++
 tools/libxl/libxl_internal.h |  3 +++
 4 files changed, 87 insertions(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 18561fb..656d4b0 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2015,6 +2015,10 @@ void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
     flexarray_append(front, "handle");
     flexarray_append(front, GCSPRINTF("%d", vtpm->devid));
 
+    /*for para virtual machine*/
+    flexarray_append(front, "domain-type");
+    flexarray_append(front, GCSPRINTF("%d", LIBXL_DOMAIN_TYPE_PV));
+
     if (aodev->update_json) {
         lock = libxl__lock_domain_userdata(gc, domid);
         if (!lock) {
@@ -2073,6 +2077,64 @@ out:
     return;
 }
 
+void libxl__device_hvm_vtpm_add(libxl__gc *gc, uint32_t domid,
+                                libxl_device_vtpm *vtpm)
+{
+    flexarray_t *front;
+    flexarray_t *back;
+    libxl__device *device;
+    unsigned int rc;
+
+    rc = libxl__device_vtpm_setdefault(gc, vtpm);
+    if (rc) goto out;
+
+    front = flexarray_make(gc, 16, 1);
+    back = flexarray_make(gc, 16, 1);
+
+    if (vtpm->devid == -1) {
+        if ((vtpm->devid = libxl__device_nextid(gc, domid, "vtpm")) < 0) {
+            rc = ERROR_FAIL;
+            goto out;
+        }
+    }
+
+    GCNEW(device);
+    rc = libxl__device_from_vtpm(gc, domid, vtpm, device);
+    if ( rc != 0 ) goto out;
+    flexarray_append(back, "frontend-id");
+    flexarray_append(back, GCSPRINTF("%d", domid));
+    flexarray_append(back, "online");
+    flexarray_append(back, "1");
+    flexarray_append(back, "state");
+    flexarray_append(back, GCSPRINTF("%d", 1));
+    flexarray_append(back, "handle");
+    flexarray_append(back, GCSPRINTF("%d", vtpm->devid));
+
+    flexarray_append(back, "uuid");
+    flexarray_append(back, GCSPRINTF(LIBXL_UUID_FMT, LIBXL_UUID_BYTES(vtpm->uuid)));
+    flexarray_append(back, "resume");
+    flexarray_append(back, "False");
+
+    flexarray_append(front, "backend-id");
+    flexarray_append(front, GCSPRINTF("%d", vtpm->backend_domid));
+    flexarray_append(front, "state");
+    flexarray_append(front, GCSPRINTF("%d", 1));
+    flexarray_append(front, "handle");
+    flexarray_append(front, GCSPRINTF("%d", vtpm->devid));
+
+    flexarray_append(front, "domain-type");
+    flexarray_append(front, GCSPRINTF("%d", LIBXL_DOMAIN_TYPE_HVM));
+
+    libxl__device_generic_add(gc, XBT_NULL, device,
+                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
+                              libxl__xs_kvs_of_flexarray(gc, front, front->count),
+                              NULL);
+
+    rc = 0;
+out:
+    return;
+}
+
 libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t domid, int *num)
 {
     GC_INIT(ctx);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index c6f68fe..b2f61cb 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -901,6 +901,12 @@ static void initiate_domain_create(libxl__egc *egc,
             d_config->nics[i].devid = ++last_devid;
     }
 
+    if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM &&
+        d_config->num_vtpms > 0) {
+        ret = libxl__device_vtpm_setdefault(gc, d_config->vtpms);
+        if (ret) goto error_out;
+    }
+
     if (restore_fd >= 0) {
         LOG(DEBUG, "restoring, not running bootloader");
         domcreate_bootloader_done(egc, &dcs->bl, 0);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3e191c3..337ac64 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -414,6 +414,7 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
     const libxl_device_nic *nics = guest_config->nics;
     const int num_disks = guest_config->num_disks;
     const int num_nics = guest_config->num_nics;
+    const int num_vtpms = guest_config->num_vtpms;
     const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
     const libxl_sdl_info *sdl = dm_sdl(guest_config);
     const char *keymap = dm_keymap(guest_config);
@@ -747,6 +748,15 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
         abort();
     }
 
+    /*add vTPM parameters for HVM virtual machine*/
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
+        num_vtpms >0) {
+        flexarray_vappend(dm_args, "-tpmdev",
+                          "xenstubdoms,id=xenvtpm0", NULL);
+        flexarray_vappend(dm_args,"-device",
+                          "tpm-tis,tpmdev=xenvtpm0", NULL);
+    }
+
     ram_size = libxl__sizekb_to_mb(b_info->max_memkb - b_info->video_memkb);
     flexarray_append(dm_args, "-m");
     flexarray_append(dm_args, libxl__sprintf(gc, "%"PRId64, ram_size));
@@ -1412,6 +1422,12 @@ retry_transaction:
     spawn->failure_cb = device_model_startup_failed;
     spawn->detached_cb = device_model_detached;
 
+    /* Plug vtpm devices*/
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
+        guest_config->num_vtpms > 0){
+        libxl__device_hvm_vtpm_add(gc, domid, guest_config->vtpms);
+    }
+
     rc = libxl__spawn_spawn(egc, spawn);
     if (rc < 0)
         goto out_close;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4361421..946b8cf 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2388,6 +2388,9 @@ _hidden void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
                                    libxl_device_vtpm *vtpm,
                                    libxl__ao_device *aodev);
 
+void libxl__device_hvm_vtpm_add(libxl__gc *gc, uint32_t domid,
+                                libxl_device_vtpm *vtpm);
+
 /* Internal function to connect a vkb device */
 _hidden int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,
                                   libxl_device_vkb *vkb);
-- 
1.8.3.2

[PATCH 6/6] vTPM: add QEMU_STUBDOM_VTPM compile option

[Quan Xu]

Signed-off-by: Quan Xu <quan.xu@intel.com>
---
 Config.mk      | 4 ++++
 tools/Makefile | 7 +++++++
 2 files changed, 11 insertions(+)

diff --git a/Config.mk b/Config.mk
index a5b6c41..5a5f413 100644
--- a/Config.mk
+++ b/Config.mk
@@ -254,6 +254,10 @@ endif
 OVMF_UPSTREAM_REVISION ?= 447d264115c476142f884af0be287622cd244423
 QEMU_UPSTREAM_REVISION ?= qemu-xen-4.5.0-rc1
 SEABIOS_UPSTREAM_REVISION ?= rel-1.7.5
+
+# Qemu stubdom vtpm frontend.
+QEMU_STUBDOM_VTPM ?= n
+
 # Thu May 22 16:59:16 2014 -0400
 # python3 fixes for vgabios and csm builds.
 
diff --git a/tools/Makefile b/tools/Makefile
index af9798a..1044149 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -197,6 +197,12 @@ else
 QEMU_XEN_ENABLE_DEBUG :=
 endif
 
+ifeq ($(QEMU_STUBDOM_VTPM),y)
+QEMU_TPM_ARGS="--enable-tpm"
+else
+QEMU_TPM_ARGS="--disable-tpm"
+endif
+
 subdir-all-qemu-xen-dir: qemu-xen-dir-find
 	if test -d $(QEMU_UPSTREAM_LOC) ; then \
 		source=$(QEMU_UPSTREAM_LOC); \
@@ -222,6 +228,7 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find
 		--datadir=$(SHAREDIR)/qemu-xen \
 		--localstatedir=$(localstatedir) \
 		--disable-kvm \
+                $(QEMU_TPM_ARGS) \
 		--disable-docs \
 		--disable-guest-agent \
 		--python=$(PYTHON) \
-- 
1.8.3.2

Re: [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM virtual machine

[Stefano Stabellini]

On Thu, 30 Oct 2014, Quan Xu wrote:
> 
> Signed-off-by: Quan Xu <quan.xu@intel.com>
> 
> This patch series are only the Xen part to enable stubdom vTPM for HVM virtual machine.
> it will work w/ Qemu patch series and seaBios patch series. Change QEMU_STUBDOM_VTPM 
> compile option from 'n' to 'y', when the Qemu/SeaBios patch series are merged.

Please, could you add more detailed commit messages in your patches?
Also spending a few more words here to explain why are you doing this
and how would help.

It looks like you are trying to introduce vTPM stubdomains. The QEMU
changes have been posted against upstream QEMU, that is good, however as
far as I know upstream QEMU doesn't build or work as a stubdomain yet.
Where are the changes to make upstream QEMU based stubdoms work?
I don't see them neither here nor in the QEMU series.

How are you testing this work?


>  Config.mk                             |  4 ++++
>  extras/mini-os/include/tpmback.h      |  3 +++
>  extras/mini-os/tpmback.c              | 20 +++++++++++++++++---
>  tools/Makefile                        |  7 +++++++
>  tools/firmware/hvmloader/acpi/build.c |  5 +++--
>  tools/libxl/libxl.c                   | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_create.c            | 16 +++++++++++++---
>  tools/libxl/libxl_dm.c                | 16 ++++++++++++++++
>  tools/libxl/libxl_dom.c               |  2 ++
>  tools/libxl/libxl_internal.h          |  3 +++
>  tools/libxl/libxl_types.idl           |  1 +
>  tools/libxl/xl_cmdimpl.c              |  2 ++
>  xen/arch/x86/hvm/hvm.c                |  3 +++
>  xen/include/public/hvm/params.h       |  1 +
> 
> I've tried to break it down to smaller patches:
> 
>  *(Patch 1/6)*  event channel bind interdomain with para/hvm virtual machine
> 
>  *(Patch 2/6)*  add HVM_PARAM_STUBDOM_VTPM parameter for HVM virtual machine
> 
>  *(Patch 3/6)*  limit libxl__add_vtpms() function to para virtual machine
> 
>  *(Patch 4/6)*  add TPM TCPA and SSDT for HVM virtual machine when vTPM is added
> 
>  *(Patch 5/6)*  add vTPM device for HVM virtual machine
> 
>  *(Patch 6/6)*  add QEMU_STUBDOM_VTPM compile option
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

Re: [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM virtual machine

[Xu, Quan]

> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Monday, November 03, 2014 7:30 PM
> To: Xu, Quan
> Cc: xen-devel@lists.xen.org; keir@xen.org; ian.campbell@citrix.com;
> tim@xen.org; ian.jackson@eu.citrix.com; jbeulich@suse.com
> Subject: Re: [Xen-devel] [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM
> virtual machine
> 
> On Thu, 30 Oct 2014, Quan Xu wrote:
> >
> > Signed-off-by: Quan Xu <quan.xu@intel.com>
> >
> > This patch series are only the Xen part to enable stubdom vTPM for HVM
> virtual machine.
> > it will work w/ Qemu patch series and seaBios patch series. Change
> > QEMU_STUBDOM_VTPM compile option from 'n' to 'y', when the
> Qemu/SeaBios patch series are merged.
> 
> Please, could you add more detailed commit messages in your patches?
> Also spending a few more words here to explain why are you doing this and
> how would help.
> 
The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM functionality
to virtual machines (Fedora, Ubuntu, Redhat, Windows .etc). This allows programs to
interact with a TPM in a virtual machine the same way they interact with a TPM on the
physical system. Each virtual machine gets its own unique, emulated, software TPM.
Each major component of vTPM is implemented as a stubdom, providing secure separation
guaranteed by the hypervisor.
The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for the virtual machine
to use. It is a small wrapper around the Berlios TPM emulator. TPM commands are passed
from mini-os TPM backend driver.

This patch series are to enable Xen stubdom vTPM for HVM virtual machine. his allows 
programs to interact with a TPM in a HVM virtual machine(Fedora, Ubuntu, Redhat, Windows .etc)
the same way they interact with a TPM on the physical system.


> It looks like you are trying to introduce vTPM stubdomains. The QEMU
> changes have been posted against upstream QEMU, that is good, however as
> far as I know upstream QEMU doesn't build or work as a stubdomain yet.
> Where are the changes to make upstream QEMU based stubdoms work?
> I don't see them neither here nor in the QEMU series.
> 
It's Xen stubdom, not QEMU stubdom. Sorry for this confusion. 

> How are you testing this work?


The following steps are how to build and test it: 

1. SeaBios with my patch against upstream seabios is not submitted. I will submit seabios patch when I 
finish these questions from review. Now I archive my seabios patch against upstream seabios in 
Github: https://github.com/virt2x/seabios2 , try to build it for test. 

Configure it with Xen,
--- <Xen> Config.mk
-SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
+SEABIOS_UPSTREAM_URL ?= https://github.com/virt2x/seabios2
[...]
-SEABIOS_UPSTREAM_REVISION ?= rel-1.7.5
+SEABIOS_UPSTREAM_REVISION ?= ea94c083cc15875f46f0bf288b6531154b866f5a

2. qemu with my patch against upstream QEMU is not merged. now I archive my 
qemu patch series again Upstream QEMU in github: https://github.com/virt2x/qemu-xen-unstable2 

Configure it with Xen, 
--- <Xen> Config.mk

-QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git
+QEMU_UPSTREAM_URL ?= https://github.com/virt2x/qemu-xen-unstable2
-QEMU_UPSTREAM_REVISION ?= qemu-xen-4.5.0-rc1
+QEMU_UPSTREAM_REVISION ?= e867e6cf86c8412ca516cf2d0ccad57130e3388c

3. build/install Xen
Change QEMU_STUBDOM_VTPM option from 'n' to 'y'
   QEMU_STUBDOM_VTPM ?= y
./configure --prefix=/usr
make dist
make install 

4. try to launch vtpmmgr / vtpm domain via <Xen>/docs/misc/vtpm-platforms.txt.
The reader is assumed to have familiarity with building and installing Xen, Linux, and a basic 
understanding of the TPM and vTPM concepts.

The Linux / Windows HVM guest configuration file needs to be modified to include the following line:
[..]
vtpm=["backend=domu-vtpm"]
device_model_version = 'qemu-xen'
acpi = 1
[..]

## domu-vtpm is the name vtpm domain, A mini-os stub domain that implements a vTPM. 

5. enable native TPM 1.2 drvier in HVM virtual machine. for example enable tpm_tis.ko in Linux 
HVM virtual machine. 
If you have trousers and tpm_tools installed on the guest, the tpm_version
command should return the following:

The version command should return the following:
  TPM 1.2 Version Info:
  Chip Version:        1.2.0.7
  Spec Level:          2
  Errata Revision:     1
  TPM Vendor ID:       ETHZ
  TPM Version:         01010000
  Manufacturer Info:   4554485a

Or check it with sysfs, /sys/class/misc/tpm0


BTW, Some local ISV are trying to integrate this feature into their cloud service for trusted services, 
Such as trusted virtual desktop infrastructure(HVM fedora/ubuntu/redhat/windows virtual machine).


> 
> 
> >  Config.mk                             |  4 ++++
> >  extras/mini-os/include/tpmback.h      |  3 +++
> >  extras/mini-os/tpmback.c              | 20 +++++++++++++++++---
> >  tools/Makefile                        |  7 +++++++
> >  tools/firmware/hvmloader/acpi/build.c |  5 +++--
> >  tools/libxl/libxl.c                   | 62
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> +++
> >  tools/libxl/libxl_create.c            | 16 +++++++++++++---
> >  tools/libxl/libxl_dm.c                | 16 ++++++++++++++++
> >  tools/libxl/libxl_dom.c               |  2 ++
> >  tools/libxl/libxl_internal.h          |  3 +++
> >  tools/libxl/libxl_types.idl           |  1 +
> >  tools/libxl/xl_cmdimpl.c              |  2 ++
> >  xen/arch/x86/hvm/hvm.c                |  3 +++
> >  xen/include/public/hvm/params.h       |  1 +
> >
> > I've tried to break it down to smaller patches:
> >
> >  *(Patch 1/6)*  event channel bind interdomain with para/hvm virtual
> > machine
> >
> >  *(Patch 2/6)*  add HVM_PARAM_STUBDOM_VTPM parameter for HVM
> virtual
> > machine
> >
> >  *(Patch 3/6)*  limit libxl__add_vtpms() function to para virtual
> > machine
> >
> >  *(Patch 4/6)*  add TPM TCPA and SSDT for HVM virtual machine when
> > vTPM is added
> >
> >  *(Patch 5/6)*  add vTPM device for HVM virtual machine
> >
> >  *(Patch 6/6)*  add QEMU_STUBDOM_VTPM compile option
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >

Re: [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM virtual machine

[Stefano Stabellini]

On Wed, 5 Nov 2014, Xu, Quan wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > Sent: Monday, November 03, 2014 7:30 PM
> > To: Xu, Quan
> > Cc: xen-devel@lists.xen.org; keir@xen.org; ian.campbell@citrix.com;
> > tim@xen.org; ian.jackson@eu.citrix.com; jbeulich@suse.com
> > Subject: Re: [Xen-devel] [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM
> > virtual machine
> > 
> > On Thu, 30 Oct 2014, Quan Xu wrote:
> > >
> > > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > >
> > > This patch series are only the Xen part to enable stubdom vTPM for HVM
> > virtual machine.
> > > it will work w/ Qemu patch series and seaBios patch series. Change
> > > QEMU_STUBDOM_VTPM compile option from 'n' to 'y', when the
> > Qemu/SeaBios patch series are merged.
> > 
> > Please, could you add more detailed commit messages in your patches?
> > Also spending a few more words here to explain why are you doing this and
> > how would help.
> > 
> The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM functionality
> to virtual machines (Fedora, Ubuntu, Redhat, Windows .etc). This allows programs to
> interact with a TPM in a virtual machine the same way they interact with a TPM on the
> physical system. Each virtual machine gets its own unique, emulated, software TPM.
> Each major component of vTPM is implemented as a stubdom, providing secure separation
> guaranteed by the hypervisor.
> The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for the virtual machine
> to use. It is a small wrapper around the Berlios TPM emulator. TPM commands are passed
> from mini-os TPM backend driver.
> 
> This patch series are to enable Xen stubdom vTPM for HVM virtual machine. his allows 
> programs to interact with a TPM in a HVM virtual machine(Fedora, Ubuntu, Redhat, Windows .etc)
> the same way they interact with a TPM on the physical system.
> 
> 
> > It looks like you are trying to introduce vTPM stubdomains. The QEMU
> > changes have been posted against upstream QEMU, that is good, however as
> > far as I know upstream QEMU doesn't build or work as a stubdomain yet.
> > Where are the changes to make upstream QEMU based stubdoms work?
> > I don't see them neither here nor in the QEMU series.
> > 
> It's Xen stubdom, not QEMU stubdom. Sorry for this confusion. 

What does "Xen stubdom" mean?
I am still a bit confused, I replied to the other email.


> > How are you testing this work?
> 
> 
> The following steps are how to build and test it: 
> 
> 1. SeaBios with my patch against upstream seabios is not submitted. I will submit seabios patch when I 
> finish these questions from review. Now I archive my seabios patch against upstream seabios in 
> Github: https://github.com/virt2x/seabios2 , try to build it for test. 
> 
> Configure it with Xen,
> --- <Xen> Config.mk
> -SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
> +SEABIOS_UPSTREAM_URL ?= https://github.com/virt2x/seabios2
> [...]
> -SEABIOS_UPSTREAM_REVISION ?= rel-1.7.5
> +SEABIOS_UPSTREAM_REVISION ?= ea94c083cc15875f46f0bf288b6531154b866f5a
> 
> 2. qemu with my patch against upstream QEMU is not merged. now I archive my 
> qemu patch series again Upstream QEMU in github: https://github.com/virt2x/qemu-xen-unstable2 
> 
> Configure it with Xen, 
> --- <Xen> Config.mk
> 
> -QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git
> +QEMU_UPSTREAM_URL ?= https://github.com/virt2x/qemu-xen-unstable2
> -QEMU_UPSTREAM_REVISION ?= qemu-xen-4.5.0-rc1
> +QEMU_UPSTREAM_REVISION ?= e867e6cf86c8412ca516cf2d0ccad57130e3388c
> 
> 3. build/install Xen
> Change QEMU_STUBDOM_VTPM option from 'n' to 'y'
>    QEMU_STUBDOM_VTPM ?= y
> ./configure --prefix=/usr
> make dist
> make install 

>From the previous email, it looks like you are running QEMU in a Linux
based stubdom. If so, I don't see where are you creating it.


> 4. try to launch vtpmmgr / vtpm domain via <Xen>/docs/misc/vtpm-platforms.txt.
> The reader is assumed to have familiarity with building and installing Xen, Linux, and a basic 
> understanding of the TPM and vTPM concepts.
> 
> The Linux / Windows HVM guest configuration file needs to be modified to include the following line:
> [..]
> vtpm=["backend=domu-vtpm"]
> device_model_version = 'qemu-xen'
> acpi = 1
> [..]
> 
> ## domu-vtpm is the name vtpm domain, A mini-os stub domain that implements a vTPM. 
> 
> 5. enable native TPM 1.2 drvier in HVM virtual machine. for example enable tpm_tis.ko in Linux 
> HVM virtual machine. 
> If you have trousers and tpm_tools installed on the guest, the tpm_version
> command should return the following:
> 
> The version command should return the following:
>   TPM 1.2 Version Info:
>   Chip Version:        1.2.0.7
>   Spec Level:          2
>   Errata Revision:     1
>   TPM Vendor ID:       ETHZ
>   TPM Version:         01010000
>   Manufacturer Info:   4554485a
> 
> Or check it with sysfs, /sys/class/misc/tpm0
> 
> 
> BTW, Some local ISV are trying to integrate this feature into their cloud service for trusted services, 
> Such as trusted virtual desktop infrastructure(HVM fedora/ubuntu/redhat/windows virtual machine).
> 
> 
> > 
> > 
> > >  Config.mk                             |  4 ++++
> > >  extras/mini-os/include/tpmback.h      |  3 +++
> > >  extras/mini-os/tpmback.c              | 20 +++++++++++++++++---
> > >  tools/Makefile                        |  7 +++++++
> > >  tools/firmware/hvmloader/acpi/build.c |  5 +++--
> > >  tools/libxl/libxl.c                   | 62
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > +++
> > >  tools/libxl/libxl_create.c            | 16 +++++++++++++---
> > >  tools/libxl/libxl_dm.c                | 16 ++++++++++++++++
> > >  tools/libxl/libxl_dom.c               |  2 ++
> > >  tools/libxl/libxl_internal.h          |  3 +++
> > >  tools/libxl/libxl_types.idl           |  1 +
> > >  tools/libxl/xl_cmdimpl.c              |  2 ++
> > >  xen/arch/x86/hvm/hvm.c                |  3 +++
> > >  xen/include/public/hvm/params.h       |  1 +
> > >
> > > I've tried to break it down to smaller patches:
> > >
> > >  *(Patch 1/6)*  event channel bind interdomain with para/hvm virtual
> > > machine
> > >
> > >  *(Patch 2/6)*  add HVM_PARAM_STUBDOM_VTPM parameter for HVM
> > virtual
> > > machine
> > >
> > >  *(Patch 3/6)*  limit libxl__add_vtpms() function to para virtual
> > > machine
> > >
> > >  *(Patch 4/6)*  add TPM TCPA and SSDT for HVM virtual machine when
> > > vTPM is added
> > >
> > >  *(Patch 5/6)*  add vTPM device for HVM virtual machine
> > >
> > >  *(Patch 6/6)*  add QEMU_STUBDOM_VTPM compile option
> > >
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/xen-devel
> > >
> 

Re: [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM virtual machine

[Xu, Quan]

[-- Attachment #1: Type: text/plain, Size: 8917 bytes --]



> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Stefano Stabellini
> Sent: Wednesday, November 05, 2014 7:02 PM
> To: Xu, Quan
> Cc: keir@xen.org; ian.campbell@citrix.com; Stefano Stabellini; tim@xen.org;
> ian.jackson@eu.citrix.com; xen-devel@lists.xen.org; jbeulich@suse.com;
> wei.liu2@citrix.com; Daniel De Graaf
> Subject: Re: [Xen-devel] [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM
> virtual machine
> 
> On Wed, 5 Nov 2014, Xu, Quan wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > Sent: Monday, November 03, 2014 7:30 PM
> > > To: Xu, Quan
> > > Cc: xen-devel@lists.xen.org; keir@xen.org; ian.campbell@citrix.com;
> > > tim@xen.org; ian.jackson@eu.citrix.com; jbeulich@suse.com
> > > Subject: Re: [Xen-devel] [PATCH 0/6] vTPM: Xen stubdom vTPM for HVM
> > > virtual machine
> > >
> > > On Thu, 30 Oct 2014, Quan Xu wrote:
> > > >
> > > > Signed-off-by: Quan Xu <quan.xu@intel.com>
> > > >
> > > > This patch series are only the Xen part to enable stubdom vTPM for
> > > > HVM
> > > virtual machine.
> > > > it will work w/ Qemu patch series and seaBios patch series. Change
> > > > QEMU_STUBDOM_VTPM compile option from 'n' to 'y', when the
> > > Qemu/SeaBios patch series are merged.
> > >
> > > Please, could you add more detailed commit messages in your patches?
> > > Also spending a few more words here to explain why are you doing
> > > this and how would help.
> > >
> > The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM
> > functionality to virtual machines (Fedora, Ubuntu, Redhat, Windows
> > .etc). This allows programs to interact with a TPM in a virtual
> > machine the same way they interact with a TPM on the physical system.
> Each virtual machine gets its own unique, emulated, software TPM.
> > Each major component of vTPM is implemented as a stubdom, providing
> > secure separation guaranteed by the hypervisor.
> > The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for the
> > virtual machine to use. It is a small wrapper around the Berlios TPM
> > emulator. TPM commands are passed from mini-os TPM backend driver.
> >
> > This patch series are to enable Xen stubdom vTPM for HVM virtual
> > machine. his allows programs to interact with a TPM in a HVM virtual
> > machine(Fedora, Ubuntu, Redhat, Windows .etc) the same way they
> interact with a TPM on the physical system.
> >
> >
> > > It looks like you are trying to introduce vTPM stubdomains. The QEMU
> > > changes have been posted against upstream QEMU, that is good,
> > > however as far as I know upstream QEMU doesn't build or work as a
> stubdomain yet.
> > > Where are the changes to make upstream QEMU based stubdoms work?
> > > I don't see them neither here nor in the QEMU series.
> > >
> > It's Xen stubdom, not QEMU stubdom. Sorry for this confusion.
> 
> What does "Xen stubdom" mean?
> I am still a bit confused, I replied to the other email.

It is StubDom, it is xen wiki about StubDom (http://wiki.xen.org/wiki/StubDom ). 
Stubdoms (or stub domains) are lightweight 'service' or 'driver' domain to run device models and one technique to 
implement Dom0 Disaggregation. The initial purpose of stub domains were to offload qemu workloads from dom0 
into a seperate domain.

The following link is the wiki of vTPM. 
http://wiki.xenproject.org/wiki/Virtual_Trusted_Platform_Module_%28vTPM%29 
in 'vTPM Extensions in Xen 4.3 ' section, 
[...]
Each major component of vTPM is implemented as a separate domain, providing secure separation guaranteed by the 
hypervisor. The vTPM domains are implemented in mini-os to reduce memory and processor overhead.


--> 
So 'Xen stubdom' is a separate domain, and implemented in mini-os.
My mistake, maybe 'Xen stubdom' is not a common Noun in community. 

> 
> 
> > > How are you testing this work?
> >
> >
> > The following steps are how to build and test it:
> >
> > 1. SeaBios with my patch against upstream seabios is not submitted. I
> > will submit seabios patch when I finish these questions from review.
> > Now I archive my seabios patch against upstream seabios in
> > Github: https://github.com/virt2x/seabios2 , try to build it for test.
> >
> > Configure it with Xen,
> > --- <Xen> Config.mk
> > -SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
> > +SEABIOS_UPSTREAM_URL ?= https://github.com/virt2x/seabios2
> > [...]
> > -SEABIOS_UPSTREAM_REVISION ?= rel-1.7.5
> > +SEABIOS_UPSTREAM_REVISION ?=
> ea94c083cc15875f46f0bf288b6531154b866f5a
> >
> > 2. qemu with my patch against upstream QEMU is not merged. now I
> > archive my qemu patch series again Upstream QEMU in github:
> > https://github.com/virt2x/qemu-xen-unstable2
> >
> > Configure it with Xen,
> > --- <Xen> Config.mk
> >
> > -QEMU_UPSTREAM_URL ?=
> git://xenbits.xen.org/qemu-upstream-unstable.git
> > +QEMU_UPSTREAM_URL ?=
> https://github.com/virt2x/qemu-xen-unstable2
> > -QEMU_UPSTREAM_REVISION ?= qemu-xen-4.5.0-rc1
> > +QEMU_UPSTREAM_REVISION ?=
> e867e6cf86c8412ca516cf2d0ccad57130e3388c
> >
> > 3. build/install Xen
> > Change QEMU_STUBDOM_VTPM option from 'n' to 'y'
> >    QEMU_STUBDOM_VTPM ?= y
> > ./configure --prefix=/usr
> > make dist
> > make install
> 
> From the previous email, it looks like you are running QEMU in a Linux based
> stubdom. If so, I don't see where are you creating it.

Not so,
The attach file is the picture of vTPM architecture. 

> 
> 
> > 4. try to launch vtpmmgr / vtpm domain via
> <Xen>/docs/misc/vtpm-platforms.txt.
> > The reader is assumed to have familiarity with building and installing
> > Xen, Linux, and a basic understanding of the TPM and vTPM concepts.
> >
> > The Linux / Windows HVM guest configuration file needs to be modified to
> include the following line:
> > [..]
> > vtpm=["backend=domu-vtpm"]
> > device_model_version = 'qemu-xen'
> > acpi = 1
> > [..]
> >
> > ## domu-vtpm is the name vtpm domain, A mini-os stub domain that
> implements a vTPM.
> >
> > 5. enable native TPM 1.2 drvier in HVM virtual machine. for example
> > enable tpm_tis.ko in Linux HVM virtual machine.
> > If you have trousers and tpm_tools installed on the guest, the
> > tpm_version command should return the following:
> >
> > The version command should return the following:
> >   TPM 1.2 Version Info:
> >   Chip Version:        1.2.0.7
> >   Spec Level:          2
> >   Errata Revision:     1
> >   TPM Vendor ID:       ETHZ
> >   TPM Version:         01010000
> >   Manufacturer Info:   4554485a
> >
> > Or check it with sysfs, /sys/class/misc/tpm0
> >
> >
> > BTW, Some local ISV are trying to integrate this feature into their
> > cloud service for trusted services, Such as trusted virtual desktop
> infrastructure(HVM fedora/ubuntu/redhat/windows virtual machine).
> >
> >
> > >
> > >
> > > >  Config.mk                             |  4 ++++
> > > >  extras/mini-os/include/tpmback.h      |  3 +++
> > > >  extras/mini-os/tpmback.c              | 20
> +++++++++++++++++---
> > > >  tools/Makefile                        |  7 +++++++
> > > >  tools/firmware/hvmloader/acpi/build.c |  5 +++--
> > > >  tools/libxl/libxl.c                   | 62
> > >
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > +++
> > > >  tools/libxl/libxl_create.c            | 16 +++++++++++++---
> > > >  tools/libxl/libxl_dm.c                | 16 ++++++++++++++++
> > > >  tools/libxl/libxl_dom.c               |  2 ++
> > > >  tools/libxl/libxl_internal.h          |  3 +++
> > > >  tools/libxl/libxl_types.idl           |  1 +
> > > >  tools/libxl/xl_cmdimpl.c              |  2 ++
> > > >  xen/arch/x86/hvm/hvm.c                |  3 +++
> > > >  xen/include/public/hvm/params.h       |  1 +
> > > >
> > > > I've tried to break it down to smaller patches:
> > > >
> > > >  *(Patch 1/6)*  event channel bind interdomain with para/hvm
> > > > virtual machine
> > > >
> > > >  *(Patch 2/6)*  add HVM_PARAM_STUBDOM_VTPM parameter for
> HVM
> > > virtual
> > > > machine
> > > >
> > > >  *(Patch 3/6)*  limit libxl__add_vtpms() function to para virtual
> > > > machine
> > > >
> > > >  *(Patch 4/6)*  add TPM TCPA and SSDT for HVM virtual machine
> when
> > > > vTPM is added
> > > >
> > > >  *(Patch 5/6)*  add vTPM device for HVM virtual machine
> > > >
> > > >  *(Patch 6/6)*  add QEMU_STUBDOM_VTPM compile option
> > > >
> > > >
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@lists.xen.org
> > > > http://lists.xen.org/xen-devel
> > > >
> >
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

[-- Attachment #2: vtpm.pdf --]
[-- Type: application/pdf, Size: 166430 bytes --]

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel