All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] [XEN-API] Not raising an API error in VTPM destroy method
@ 2007-02-07 23:37 Stefan Berger
  2007-02-08 15:53 ` Ewan Mellor
  0 siblings, 1 reply; 6+ messages in thread
From: Stefan Berger @ 2007-02-07 23:37 UTC (permalink / raw)
  To: xen-devel; +Cc: Ewan Mellor

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

Don't return an API error if vTPM cannot be destroyed due to a running
VM, but a value indicating failure instead. Adapt python code, libxen
and documentation.

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


[-- Attachment #2: xenapi_vtpm_destroy.diff --]
[-- Type: text/x-patch, Size: 4139 bytes --]

Index: root/xen-unstable.hg/tools/libxen/include/xen_vtpm.h
===================================================================
--- root.orig/xen-unstable.hg/tools/libxen/include/xen_vtpm.h
+++ root/xen-unstable.hg/tools/libxen/include/xen_vtpm.h
@@ -172,7 +172,7 @@ xen_vtpm_create(xen_session *session, xe
  * Destroy the specified VTPM instance.
  */
 extern bool
-xen_vtpm_destroy(xen_session *session, xen_vtpm vtpm);
+xen_vtpm_destroy(xen_session *session, int64_t *result, xen_vtpm vtpm);
 
 
 /**
Index: root/xen-unstable.hg/tools/libxen/src/xen_vtpm.c
===================================================================
--- root.orig/xen-unstable.hg/tools/libxen/src/xen_vtpm.c
+++ root/xen-unstable.hg/tools/libxen/src/xen_vtpm.c
@@ -132,7 +132,7 @@ xen_vtpm_create(xen_session *session, xe
 
 
 bool
-xen_vtpm_destroy(xen_session *session, xen_vtpm vtpm)
+xen_vtpm_destroy(xen_session *session, int64_t *result, xen_vtpm vtpm)
 {
     abstract_value param_values[] =
         {
@@ -140,7 +140,10 @@ xen_vtpm_destroy(xen_session *session, x
               .u.string_val = vtpm }
         };
 
-    xen_call_(session, "VTPM.destroy", param_values, 1, NULL, NULL);
+    abstract_type result_type = abstract_type_int;
+
+    *result = 0;
+    XEN_CALL_("VTPM.destroy");
     return session->ok;
 }
 
Index: root/xen-unstable.hg/tools/python/xen/xend/XendAPI.py
===================================================================
--- root.orig/xen-unstable.hg/tools/python/xen/xend/XendAPI.py
+++ root/xen-unstable.hg/tools/python/xen/xend/XendAPI.py
@@ -1834,9 +1834,7 @@ class XendAPI(object):
         if dom:
             if dom.state != XEN_API_VM_POWER_STATE_HALTED:
                 vm_ref = dom.get_dev_property('vtpm', vtpm_ref, 'VM')
-                return xen_api_error(['VM_BAD_POWER_STATE', vm_ref,
-                 XendDomain.POWER_STATE_NAMES[XEN_API_VM_POWER_STATE_HALTED],
-                 XendDomain.POWER_STATE_NAMES[dom.state]])
+                return xen_api_success(False)
             from xen.xend.server import tpmif
             tpmif.destroy_vtpmstate(dom.getName())
             return xen_api_success(True)
Index: root/xen-unstable.hg/docs/xen-api/xenapi-datamodel.tex
===================================================================
--- root.orig/xen-unstable.hg/docs/xen-api/xenapi-datamodel.tex
+++ root/xen-unstable.hg/docs/xen-api/xenapi-datamodel.tex
@@ -10880,7 +10880,7 @@ reference to the newly created object
 Destroy the specified VTPM instance.
 
  \noindent {\bf Signature:} 
-\begin{verbatim} void destroy (session_id s, VTPM ref self)\end{verbatim}
+\begin{verbatim} int destroy (session_id s, VTPM ref self)\end{verbatim}
 
 
 \noindent{\bf Arguments:}
@@ -10898,11 +10898,11 @@ Destroy the specified VTPM instance.
 
  \noindent {\bf Return Type:} 
 {\tt 
-void
+int
 }
 
 
-
+Success (1) or failure of the operation.
 \vspace{0.3cm}
 \vspace{0.3cm}
 \vspace{0.3cm}
Index: root/xen-unstable.hg/tools/xm-test/tests/vtpm/09_vtpm-xapi.py
===================================================================
--- root.orig/xen-unstable.hg/tools/xm-test/tests/vtpm/09_vtpm-xapi.py
+++ root/xen-unstable.hg/tools/xm-test/tests/vtpm/09_vtpm-xapi.py
@@ -112,22 +112,19 @@ if not re.search("PCR-00:",run["output"]
     saveLog(console.getHistory())
     FAIL("1. Virtual TPM is not working correctly on /dev/vtpm on backend side: \n%s" % run["output"])
 
-try:
-    rc = session.xenapi.VTPM.destroy(vtpm_uuid)
-    #Should never get here
+rc = session.xenapi.VTPM.destroy(vtpm_uuid)
+if int(rc) != 0:
+    #Should not be able to destroy the VTPM with the VM running
     FAIL("Could destroy vTPM while VM is running")
-except:
-    pass
 
 rc = session.xenapi.VM.suspend(vm_uuid)
 if rc:
     FAIL("Could not suspend VM")
 
-try:
-    rc = session.xenapi.VTPM.destroy(vtpm_uuid)
-    #May not throw an exception in 'suspend' state
-except:
-    pass
+rc = session.xenapi.VTPM.destroy(vtpm_uuid)
+if int(rc) != 0:
+    #Should not be able to destroy the VTPM with the VM running
+    print "Could destroy vTPM while VM is suspended?!"
 
 rc = session.xenapi.VM.resume(vm_uuid, False)
 if rc:

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

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] [XEN-API] Not raising an API error in VTPM destroy method
  2007-02-07 23:37 [PATCH] [XEN-API] Not raising an API error in VTPM destroy method Stefan Berger
@ 2007-02-08 15:53 ` Ewan Mellor
  2007-02-08 18:25   ` Stefan Berger
  0 siblings, 1 reply; 6+ messages in thread
From: Ewan Mellor @ 2007-02-08 15:53 UTC (permalink / raw)
  To: Stefan Berger; +Cc: xen-devel

On Wed, Feb 07, 2007 at 06:37:19PM -0500, Stefan Berger wrote:

> Don't return an API error if vTPM cannot be destroyed due to a running
> VM, but a value indicating failure instead. Adapt python code, libxen
> and documentation.
> 
> Signed-off-by: Stefan Berger <stefanb@us.ibm.com>

We have a separate error-returning mechanism -- you should be using that
rather than returning an error code.  Take a look at the end of
xenapi-datamodel.tex; the error code definitions are there.  In XendAPI.py,
you have xen_api_error available, which will marshall an error code and
arguments, and in xen/xm/messages there is a translation database for those
error messages.

Cheers,

Ewan.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Re: [PATCH] [XEN-API] Not raising an API error in VTPM destroy method
  2007-02-08 15:53 ` Ewan Mellor
@ 2007-02-08 18:25   ` Stefan Berger
  2007-02-08 19:00     ` Ewan Mellor
  0 siblings, 1 reply; 6+ messages in thread
From: Stefan Berger @ 2007-02-08 18:25 UTC (permalink / raw)
  To: Ewan Mellor; +Cc: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 1991 bytes --]

xen-devel-bounces@lists.xensource.com wrote on 02/08/2007 10:53:24 AM:

> On Wed, Feb 07, 2007 at 06:37:19PM -0500, Stefan Berger wrote:
> 
> > Don't return an API error if vTPM cannot be destroyed due to a running
> > VM, but a value indicating failure instead. Adapt python code, libxen
> > and documentation.
> > 
> > Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
> 
> We have a separate error-returning mechanism -- you should be using that
> rather than returning an error code.  Take a look at the end of
> xenapi-datamodel.tex; the error code definitions are there.  In 
XendAPI.py,
> you have xen_api_error available, which will marshall an error code and
> arguments, and in xen/xm/messages there is a translation database for 
those
> error messages.

Thanks for pointing this out. I looked at the xenapi-datamodel.tex, of 
course, but I mostly find information related to the errors in 1.3.1 and 
towards the end of the document there's the debug class, but I don't think 
you are referring to that one.

The reason why I am actually trying to get rid of the 'return 
xen_api_error(...)' statement is that if I am using the C client library 
,libxen, the session->ok parameter changes to 'false' if this error comes 
back when for example trying to delete a vTPM from a running VM. I have 
tried to make the session usable again by doing 'session->ok = true'  so I 
don't have to establish yet another session -- not sure whether that is an 
allowed usage model of the session, though. Although this session works 
for further transactions the program fails at the point when the session 
is cleaned up with glibc complaining about bad memory. So the easiest way 
to circumvent this is to have the API return an error code for failure of 
the operation using xen_api_success().

  Cheers,
   Stefan

> 
> Cheers,
> 
> Ewan.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
1.3

[-- Attachment #1.2: Type: text/html, Size: 2413 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Re: [PATCH] [XEN-API] Not raising an API error in VTPM destroy method
  2007-02-08 18:25   ` Stefan Berger
@ 2007-02-08 19:00     ` Ewan Mellor
  2007-02-08 19:07       ` Stefan Berger
  2007-02-08 19:08       ` Stefan Berger
  0 siblings, 2 replies; 6+ messages in thread
From: Ewan Mellor @ 2007-02-08 19:00 UTC (permalink / raw)
  To: Stefan Berger; +Cc: xen-devel

On Thu, Feb 08, 2007 at 01:25:23PM -0500, Stefan Berger wrote:

> xen-devel-bounces@lists.xensource.com wrote on 02/08/2007 10:53:24 AM:
> 
> > On Wed, Feb 07, 2007 at 06:37:19PM -0500, Stefan Berger wrote:
> >
> > > Don't return an API error if vTPM cannot be destroyed due to a running
> > > VM, but a value indicating failure instead. Adapt python code, libxen
> > > and documentation.
> > >
> > > Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
> >
> > We have a separate error-returning mechanism -- you should be using that
> > rather than returning an error code.  Take a look at the end of
> > xenapi-datamodel.tex; the error code definitions are there.  In
> XendAPI.py,
> > you have xen_api_error available, which will marshall an error code and
> > arguments, and in xen/xm/messages there is a translation database for
> those
> > error messages.
> 
> Thanks for pointing this out. I looked at the xenapi-datamodel.tex, of
> course, but I mostly find information related to the errors in 1.3.1 and
> towards the end of the document there's the debug class, but I don't think
> you are referring to that one.

No, I mean the version that's in xen-unstable.  There's section 2.24 on error
handling in there.

> The reason why I am actually trying to get rid of the 'return
> xen_api_error(...)' statement is that if I am using the C client library
> ,libxen, the session->ok parameter changes to 'false' if this error comes
> back when for example trying to delete a vTPM from a running VM. I have
> tried to make the session usable again by doing 'session->ok = true'  so I
> don't have to establish yet another session -- not sure whether that is an
> allowed usage model of the session, though. Although this session works
> for further transactions the program fails at the point when the session
> is cleaned up with glibc complaining about bad memory. So the easiest way
> to circumvent this is to have the API return an error code for failure of
> the operation using xen_api_success().

That might be the easiest way, but it's certainly the wrong one!

This has been discussed a little on the xen-api list before, though I agree
that the documentation needs to be updated.  Setting session->ok back to true
when you've handled the error is fine.  The intention is to allow you to chain
together short groups of calls, and then check for errors at appropriate
points.  (If you prefer, you can check for errors after every single call,
that's fine too.)

If you're getting a segfault or a glibc-detected error, then that's clearly a
bug.  Could you post your code so that I can try it?

Ewan.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Re: [PATCH] [XEN-API] Not raising an API error in VTPM destroy method
  2007-02-08 19:00     ` Ewan Mellor
@ 2007-02-08 19:07       ` Stefan Berger
  2007-02-08 19:08       ` Stefan Berger
  1 sibling, 0 replies; 6+ messages in thread
From: Stefan Berger @ 2007-02-08 19:07 UTC (permalink / raw)
  To: Ewan Mellor; +Cc: xen-devel, xen-devel-bounces


[-- Attachment #1.1: Type: text/plain, Size: 2960 bytes --]

xen-devel-bounces@lists.xensource.com wrote on 02/08/2007 02:00:14 PM:

> On Thu, Feb 08, 2007 at 01:25:23PM -0500, Stefan Berger wrote:
> 
> > xen-devel-bounces@lists.xensource.com wrote on 02/08/2007 10:53:24 AM:
> > 
> > > On Wed, Feb 07, 2007 at 06:37:19PM -0500, Stefan Berger wrote:
> > >
> > > > Don't return an API error if vTPM cannot be destroyed due to a 
running
> > > > VM, but a value indicating failure instead. Adapt python code, 
libxen
> > > > and documentation.
> > > >
> > > > Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
> > >
> > > We have a separate error-returning mechanism -- you should be using 
that
> > > rather than returning an error code.  Take a look at the end of
> > > xenapi-datamodel.tex; the error code definitions are there.  In
> > XendAPI.py,
> > > you have xen_api_error available, which will marshall an error code 
and
> > > arguments, and in xen/xm/messages there is a translation database 
for
> > those
> > > error messages.
> > 
> > Thanks for pointing this out. I looked at the xenapi-datamodel.tex, of
> > course, but I mostly find information related to the errors in 1.3.1 
and
> > towards the end of the document there's the debug class, but I don't 
think
> > you are referring to that one.
> 
> No, I mean the version that's in xen-unstable.  There's section 2.24 on 
error
> handling in there.
> 
> > The reason why I am actually trying to get rid of the 'return
> > xen_api_error(...)' statement is that if I am using the C client 
library
> > ,libxen, the session->ok parameter changes to 'false' if this error 
comes
> > back when for example trying to delete a vTPM from a running VM. I 
have
> > tried to make the session usable again by doing 'session->ok = true' 
so I
> > don't have to establish yet another session -- not sure whether that 
is an
> > allowed usage model of the session, though. Although this session 
works
> > for further transactions the program fails at the point when the 
session
> > is cleaned up with glibc complaining about bad memory. So the easiest 
way
> > to circumvent this is to have the API return an error code for failure 
of
> > the operation using xen_api_success().
> 
> That might be the easiest way, but it's certainly the wrong one!
> 
> This has been discussed a little on the xen-api list before, though I 
agree
> that the documentation needs to be updated.  Setting session->ok back to 
true
> when you've handled the error is fine.  The intention is to allow you to 
chain
> together short groups of calls, and then check for errors at appropriate
> points.  (If you prefer, you can check for errors after every single 
call,
> that's fine too.)
> 
> If you're getting a segfault or a glibc-detected error, then that's 
clearly a
> bug.  Could you post your code so that I can try it?
> 
> Ewan.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

[-- Attachment #1.2: Type: text/html, Size: 3608 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Re: [PATCH] [XEN-API] Not raising an API error in VTPM destroy method
  2007-02-08 19:00     ` Ewan Mellor
  2007-02-08 19:07       ` Stefan Berger
@ 2007-02-08 19:08       ` Stefan Berger
  1 sibling, 0 replies; 6+ messages in thread
From: Stefan Berger @ 2007-02-08 19:08 UTC (permalink / raw)
  To: Ewan Mellor; +Cc: xen-devel, xen-devel-bounces


[-- Attachment #1.1: Type: text/plain, Size: 3044 bytes --]

xen-devel-bounces@lists.xensource.com wrote on 02/08/2007 02:00:14 PM:

> On Thu, Feb 08, 2007 at 01:25:23PM -0500, Stefan Berger wrote:
> 
> > xen-devel-bounces@lists.xensource.com wrote on 02/08/2007 10:53:24 AM:
> > 
> > > On Wed, Feb 07, 2007 at 06:37:19PM -0500, Stefan Berger wrote:
> > >
> > > > Don't return an API error if vTPM cannot be destroyed due to a 
running
> > > > VM, but a value indicating failure instead. Adapt python code, 
libxen
> > > > and documentation.
> > > >
> > > > Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
> > >
> > > We have a separate error-returning mechanism -- you should be using 
that
> > > rather than returning an error code.  Take a look at the end of
> > > xenapi-datamodel.tex; the error code definitions are there.  In
> > XendAPI.py,
> > > you have xen_api_error available, which will marshall an error code 
and
> > > arguments, and in xen/xm/messages there is a translation database 
for
> > those
> > > error messages.
> > 
> > Thanks for pointing this out. I looked at the xenapi-datamodel.tex, of
> > course, but I mostly find information related to the errors in 1.3.1 
and
> > towards the end of the document there's the debug class, but I don't 
think
> > you are referring to that one.
> 
> No, I mean the version that's in xen-unstable.  There's section 2.24 on 
error
> handling in there.
> 
> > The reason why I am actually trying to get rid of the 'return
> > xen_api_error(...)' statement is that if I am using the C client 
library
> > ,libxen, the session->ok parameter changes to 'false' if this error 
comes
> > back when for example trying to delete a vTPM from a running VM. I 
have
> > tried to make the session usable again by doing 'session->ok = true' 
so I
> > don't have to establish yet another session -- not sure whether that 
is an
> > allowed usage model of the session, though. Although this session 
works
> > for further transactions the program fails at the point when the 
session
> > is cleaned up with glibc complaining about bad memory. So the easiest 
way
> > to circumvent this is to have the API return an error code for failure 
of
> > the operation using xen_api_success().
> 
> That might be the easiest way, but it's certainly the wrong one!
> 
> This has been discussed a little on the xen-api list before, though I 
agree
> that the documentation needs to be updated.  Setting session->ok back to 
true
> when you've handled the error is fine.  The intention is to allow you to 
chain
> together short groups of calls, and then check for errors at appropriate
> points.  (If you prefer, you can check for errors after every single 
call,
> that's fine too.)
> 
> If you're getting a segfault or a glibc-detected error, then that's 
clearly a
> bug.  Could you post your code so that I can try it?

I'll try to put something in your test case that triggers this error.

   Stefan


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

[-- Attachment #1.2: Type: text/html, Size: 3813 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2007-02-08 19:08 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-07 23:37 [PATCH] [XEN-API] Not raising an API error in VTPM destroy method Stefan Berger
2007-02-08 15:53 ` Ewan Mellor
2007-02-08 18:25   ` Stefan Berger
2007-02-08 19:00     ` Ewan Mellor
2007-02-08 19:07       ` Stefan Berger
2007-02-08 19:08       ` Stefan Berger

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.