WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: xsm: Consolidate xsm processing within domain control hy

To: ncmike@xxxxxxxxxx
Subject: [Xen-devel] Re: xsm: Consolidate xsm processing within domain control hypercall.
From: Alex Williamson <alex.williamson@xxxxxx>
Date: Tue, 04 Dec 2007 17:19:32 -0700
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 04 Dec 2007 16:20:09 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1196805907.19310.70.camel@lappy>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: OSLO R&D
References: <200712041026.lB4AQPM6004133@xxxxxxxxxxxxxxxxxxxxxxx> <1196798782.19310.36.camel@lappy> <20071204214930.GC23369@xxxxxxxxxxxxxxxxxxxxxx> <1196805907.19310.70.camel@lappy>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2007-12-04 at 15:05 -0700, Alex Williamson wrote:
> On Tue, 2007-12-04 at 16:49 -0500, Mike D. Day wrote:
> > On 04/12/07 13:06 -0700, Alex Williamson wrote:
> > > 
> > >   Does this work right across a PV domain save/restore on x86?  On ia64
> > > I end up with "Domain-Unnamed" after I save a PV domain and another
> > > after I restore it, then do a shutdown.  Reverting this patch restores
> > > correct behavior.  Thanks,
> > 
> > I'll investigate this regression. Do you have any ideas as to why this
> > is happening?
> 
>    Nope, that's why I'm hoping x86 does something similar ;^)  Since I'm
> not using XSM_ENABLE, xsm_call should just be (0), which means the
> changed code should all be noops... but apparently something changes.
> BTW, xsm_call(domctl(domctl)) seems unnecessarily obfuscated.  Thanks,

Looks like the problem is that XEN_DOMCTL_destroydomain now always
returns -ESRCH.  The patch below seems to fix it although it may be just
as correct to hard code ret to 0.  I also took the liberty of returning
the error value xsm_domctl() returns, which seems to match previous
behavior.  Thanks,

        Alex

Signed-off-by: Alex Williamson <alex.williamson@xxxxxx>
---

diff -r 62451388f630 xen/common/domctl.c
--- a/xen/common/domctl.c       Tue Dec 04 11:52:10 2007 +0000
+++ b/xen/common/domctl.c       Tue Dec 04 17:11:07 2007 -0700
@@ -193,7 +193,8 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
 
     spin_lock(&domctl_lock);
 
-    if ( xsm_domctl(op) )
+    ret = xsm_domctl(op);
+    if ( ret != 0 )
         goto domctl_out;
 
     switch ( op->cmd )
@@ -400,7 +401,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
         ret = -ESRCH;
         if ( d != NULL )
         {
-            domain_kill(d);
+            ret = domain_kill(d);
             rcu_unlock_domain(d);
         }
     }




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