Xen devel - Jan 2007 - [PATCH] [XEND] alignment of vtpm support in xenapi, documentation and libxen

This patch aligns vTPM support in the Xen-API, documentation and lib-xen
(after the recent changes).

Signed-off-by: Stefan Berger <stefanb@us.ibm.com>




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

On Tue, Jan 30, 2007 at 09:29:47AM -0500, Stefan Berger wrote:
> This patch aligns vTPM support in the Xen-API, documentation and lib-xen
> (after the recent changes).
> 
> Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
What''s the intention here?  You''ve removed the get_instance
calls, but not the
instance field from the documentation.  Assuming that that''s just a
mistake,
and you meant to remove the instance field, we''re left with a VTPM
class that
has nothing other than a reference to a VM and a reference to a backend
domain.  What are the semantics of that object now?

Ewan.

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

Ewan Mellor <ewan@xensource.com> wrote on 01/30/2007 10:12:10 AM:
> On Tue, Jan 30, 2007 at 09:29:47AM -0500, Stefan Berger wrote:
> 
> > This patch aligns vTPM support in the Xen-API, documentation and 
lib-xen
> > (after the recent changes).
> > 
> > Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
> 
> What''s the intention here?  You''ve removed the
get_instance calls, but
not the
> instance field from the documentation.  Assuming that that''s just
a
mistake,
> and you meant to remove the instance field, we''re left with a VTPM
class
that
> has nothing other than a reference to a VM and a reference to a backend
> domain.  What are the semantics of that object now?
The instance will remain to be assigned by the hotplug scripts. In the 
old-style of VM configuration file one could still pass it as parameter, 
but its ignored. I rather not have it passed in as a parameter by the 
Xen-API, either. From what I can see a getter for it is not useful, 
either, since I want the instance number to be hidden from management 
software.
The instance field should then also be removed from the documentation - I 
forgot that.
 
Stefan
> 
> Ewan.

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

On Tue, Jan 30, 2007 at 10:23:13AM -0500, Stefan Berger wrote:
> Ewan Mellor <ewan@xensource.com> wrote on 01/30/2007 10:12:10 AM:
> 
> > On Tue, Jan 30, 2007 at 09:29:47AM -0500, Stefan Berger wrote:
> >
> > > This patch aligns vTPM support in the Xen-API, documentation and
> lib-xen
> > > (after the recent changes).
> > >
> > > Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
> >
> > What''s the intention here?  You''ve removed the
get_instance calls, but
> not the
> > instance field from the documentation.  Assuming that that''s
just a
> mistake,
> > and you meant to remove the instance field, we''re left with a
VTPM class
> that
> > has nothing other than a reference to a VM and a reference to a
backend
> > domain.  What are the semantics of that object now?
> 
> The instance will remain to be assigned by the hotplug scripts. In the
> old-style of VM configuration file one could still pass it as parameter,
> but its ignored. I rather not have it passed in as a parameter by the
> Xen-API, either. From what I can see a getter for it is not useful,
> either, since I want the instance number to be hidden from management
> software.
What we''re left with seems like a pretty expensive way of saying
"VTPM_backend
= N".  Is there really nothing else that''s configurable?  We could
just put
this into VM.other_config if that''s the only thing that you need, which
would
make configuring a VTPM a lot easier.

Ewan.

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

Ewan Mellor <ewan@xensource.com> wrote on 01/30/2007 10:32:40 AM:
> On Tue, Jan 30, 2007 at 10:23:13AM -0500, Stefan Berger wrote:
> 
> > Ewan Mellor <ewan@xensource.com> wrote on 01/30/2007 10:12:10
AM:
> > 
> > > On Tue, Jan 30, 2007 at 09:29:47AM -0500, Stefan Berger wrote:
> > >
> > > > This patch aligns vTPM support in the Xen-API, documentation
and
> > lib-xen
> > > > (after the recent changes).
> > > >
> > > > Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
> > >
> > > What''s the intention here?  You''ve removed the
get_instance calls,
but
> > not the
> > > instance field from the documentation.  Assuming that
that''s just a
> > mistake,
> > > and you meant to remove the instance field, we''re left
with a VTPM
class
> > that
> > > has nothing other than a reference to a VM and a reference to a 
backend
> > > domain.  What are the semantics of that object now?
> > 
> > The instance will remain to be assigned by the hotplug scripts. In the
> > old-style of VM configuration file one could still pass it as 
parameter,
> > but its ignored. I rather not have it passed in as a parameter by the
> > Xen-API, either. From what I can see a getter for it is not useful,
> > either, since I want the instance number to be hidden from management
> > software.
> 
> What we''re left with seems like a pretty expensive way of saying 
"VTPM_backend
> = N".  Is there really nothing else that''s configurable?  We
could just
put
> this into VM.other_config if that''s the only thing that you need,
which
would
> make configuring a VTPM a lot easier.
I would like to treat the vTPM as a device like VIF and VBDs with create 
and destroy methods exported to management software so that a TPM device 
can be added to a VM similar to other devices and possibly removed when 
the VM is not running.

  Stefan
> 
> Ewan.

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

On Tue, Jan 30, 2007 at 10:53:24AM -0500, Stefan Berger wrote:
> Ewan Mellor <ewan@xensource.com> wrote on 01/30/2007 10:32:40 AM:
> 
> > On Tue, Jan 30, 2007 at 10:23:13AM -0500, Stefan Berger wrote:
> >
> > > Ewan Mellor <ewan@xensource.com> wrote on 01/30/2007
10:12:10 AM:
> > >
> > > > On Tue, Jan 30, 2007 at 09:29:47AM -0500, Stefan Berger
wrote:
> > > >
> > > > > This patch aligns vTPM support in the Xen-API,
documentation and
> > > lib-xen
> > > > > (after the recent changes).
> > > > >
> > > > > Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
> > > >
> > > > What''s the intention here?  You''ve removed
the get_instance calls,
> but
> > > not the
> > > > instance field from the documentation.  Assuming that
that''s just a
> > > mistake,
> > > > and you meant to remove the instance field, we''re
left with a VTPM
> class
> > > that
> > > > has nothing other than a reference to a VM and a reference
to a
> backend
> > > > domain.  What are the semantics of that object now?
> > >
> > > The instance will remain to be assigned by the hotplug scripts.
In the
> > > old-style of VM configuration file one could still pass it as
> parameter,
> > > but its ignored. I rather not have it passed in as a parameter by
the
> > > Xen-API, either. From what I can see a getter for it is not
useful,
> > > either, since I want the instance number to be hidden from
management
> > > software.
> >
> > What we''re left with seems like a pretty expensive way of
saying
> "VTPM_backend
> > = N".  Is there really nothing else that''s configurable?
We could just
> put
> > this into VM.other_config if that''s the only thing that you
need, which
> would
> > make configuring a VTPM a lot easier.
> 
> I would like to treat the vTPM as a device like VIF and VBDs with create
> and destroy methods exported to management software so that a TPM device
> can be added to a VM similar to other devices and possibly removed when
> the VM is not running.
Well you''ll certainly be able to remove it, whichever way it''s
modelled.  I''m
not sure that treating the VTPM as a device is worth the cost, but if you
prefer it that way, that''s fine by me.

I''ll just remove that instance field from the docs, and leave it at
that.

Ewan.

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

Ewan Mellor <ewan@xensource.com> wrote on 01/30/2007 11:13:35 AM:
> On Tue, Jan 30, 2007 at 10:53:24AM -0500, Stefan Berger wrote:
> 
> > Ewan Mellor <ewan@xensource.com> wrote on 01/30/2007 10:32:40
AM:
> > 
> > > On Tue, Jan 30, 2007 at 10:23:13AM -0500, Stefan Berger wrote:
> > >
> > > > Ewan Mellor <ewan@xensource.com> wrote on 01/30/2007
10:12:10 AM:
> > > >
> > > > > On Tue, Jan 30, 2007 at 09:29:47AM -0500, Stefan Berger
wrote:
> > > > >
> > > > > > This patch aligns vTPM support in the Xen-API,
documentation
and
> > > > lib-xen
> > > > > > (after the recent changes).
> > > > > >
> > > > > > Signed-off-by: Stefan Berger
<stefanb@us.ibm.com>
> > > > >
> > > > > What''s the intention here?  You''ve
removed the get_instance
calls,
> > but
> > > > not the
> > > > > instance field from the documentation.  Assuming that
that''s
just a
> > > > mistake,
> > > > > and you meant to remove the instance field,
we''re left with a
VTPM
> > class
> > > > that
> > > > > has nothing other than a reference to a VM and a
reference to a
> > backend
> > > > > domain.  What are the semantics of that object now?
> > > >
> > > > The instance will remain to be assigned by the hotplug
scripts. In
the
> > > > old-style of VM configuration file one could still pass it
as
> > parameter,
> > > > but its ignored. I rather not have it passed in as a
parameter by
the
> > > > Xen-API, either. From what I can see a getter for it is not 
useful,
> > > > either, since I want the instance number to be hidden from 
management
> > > > software.
> > >
> > > What we''re left with seems like a pretty expensive way
of saying
> > "VTPM_backend
> > > = N".  Is there really nothing else that''s
configurable?  We could
just
> > put
> > > this into VM.other_config if that''s the only thing that
you need,
which
> > would
> > > make configuring a VTPM a lot easier.
> > 
> > I would like to treat the vTPM as a device like VIF and VBDs with 
create
> > and destroy methods exported to management software so that a TPM 
device
> > can be added to a VM similar to other devices and possibly removed 
when
> > the VM is not running.
> 
> Well you''ll certainly be able to remove it, whichever way
it''s modelled.
 I''m
> not sure that treating the VTPM as a device is worth the cost, but if 
you
> prefer it that way, that''s fine by me.
> 
> I''ll just remove that instance field from the docs, and leave it
at
that.
> 
Thank you. I noticed there''s an error in the patch to XendDomainInfo.
If
you replace the has_type() part with has_key() then test 9 passes. Sorry 
for that.

  Stefan

> Ewan.

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

On Tue, Jan 30, 2007 at 11:18:01AM -0500, Stefan Berger wrote:
> I noticed there''s an error in the patch to XendDomainInfo. If
> you replace the has_type() part with has_key() then test 9 passes. Sorry
> for that.
Fixed, thanks.

Ewan.

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