Xen devel - Apr 2006 - [PATCH] - add symmetry to para and fully virtualized domain shutdown/reboot

Add code to make handling domain poweroff/reboot symmetrical
between paravirtualized and fully virtualized.

A paravirtualized domain uses sched_op to shut down and set the
reason code. This will send a VIRQ_DOM_EXC, which can be
handled in dom0 by control software.  In some ways, this resembles
SIGCHILD/waitpid, and is a reasonable model.

The fully virtualized case has qemu invoke xm directly. This is a
different path than paravirtualized. It also removes
decision and policy making choices from the rest of the control
software and places it within qemu. When any dom0 logic
eventually gets a VIRQ_DOM_EXC, the information about the
domain is gone having been destroyed by xm.

It would be useful if all shutdown/reboot operations were
symmetrical from domain 0''s point of view. One approach
would be to redefine sched_op to handle other domains than
the current domain, but this seemed excessive. Another
approach, which is what this patch implements, adds
a DOM0 hypervisor call very similar to the existing
DOM0_DESTROYDOMAIN, called DOM0_SHUTDOWNDOMAIN, which handles
the shutdown and reason -- basically, just like a
paravirtualized system.

Like DOM0_DESTROYDOMAIN, add a xenctrl wrapper, and have qemu
call it.

With this change, both domain types shutdown/reboot using
the same dom0 management logic. All control decisions are
removed from qemu, which now simply handles the request
and reason. At a very high level, the flow is "notify of
shutdown and reason", "send VIRQ_DOM_EXC", process, and
destroy domain.  Paravirtualized and fully-virtualized
domains would differ slightly in the first step of
notification.  Paravirtualized continues to use sched_op,
fully virtualized uses DOM0_SHUTDOWNDOMAIN. The rest
of the steps would be identical in both cases.

Or, back to the opening sentence, make the operations as
symmetrical as possible.

(As a freebie, #if 0 some very verbose logging code in qemu.
  Totally unrelated, but as long as I was there...)

Signed-off-by: Ben Thomas (ben@virtualiron.com)


-- 
------------------------------------------------------------------------
Ben Thomas                                         Virtual Iron Software
bthomas@virtualiron.com                            Tower 1, Floor 2
978-849-1214                                       900 Chelmsford Street
                                                    Lowell, MA 01851


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

On 3 Apr 2006, at 16:57, Ben Thomas wrote:
> It would be useful if all shutdown/reboot operations were
> symmetrical from domain 0''s point of view. One approach
> would be to redefine sched_op to handle other domains than
> the current domain, but this seemed excessive.
I''d prefer an extra sched_op (maybe SCHEDOP_remote_shutdown with 
accompanying sched_remote_shutdown structure). This will need to be 
invokable by the emulator mini domain at some point in the future, so 
adding this as a dom0_op isn''t really for the best.

  -- Keir


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

Keir Fraser wrote:
> 
> On 3 Apr 2006, at 16:57, Ben Thomas wrote:
> 
>> It would be useful if all shutdown/reboot operations were
>> symmetrical from domain 0''s point of view. One approach
>> would be to redefine sched_op to handle other domains than
>> the current domain, but this seemed excessive.
> 
> 
> I''d prefer an extra sched_op (maybe SCHEDOP_remote_shutdown with 
> accompanying sched_remote_shutdown structure). This will need to be 
> invokable by the emulator mini domain at some point in the future, so 
> adding this as a dom0_op isn''t really for the best.
> 
>  -- Keir
> 

Ok, that''s workable.  Is there anything else that needs modification ?

Do you foresee a need for any sort of need for filtering and/or
permissioning of allowable domains as specified in remote_shutdown ?
As long as a non-privileged domain may execute this op, what
level of protection(s) need to exist? (That also was part of my
factoring it into a DOM0 op).

I''m willing to go with anything that gets the job done. This is
one of several points of asymmetry that I''d like to see get
resolved.

Thanks,
-b

-- 
------------------------------------------------------------------------
Ben Thomas                                         Virtual Iron Software
bthomas@virtualiron.com                            Tower 1, Floor 2
978-849-1214                                       900 Chelmsford Street
                                                    Lowell, MA 01851

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

On 3 Apr 2006, at 18:14, Ben Thomas wrote:
> Ok, that''s workable.  Is there anything else that needs
modification ?
>
> Do you foresee a need for any sort of need for filtering and/or
> permissioning of allowable domains as specified in remote_shutdown ?
> As long as a non-privileged domain may execute this op, what
> level of protection(s) need to exist? (That also was part of my
> factoring it into a DOM0 op).
>
> I''m willing to go with anything that gets the job done. This is
> one of several points of asymmetry that I''d like to see get
> resolved.
For now, IS_PRIV() is the correct check as for a dom0_op, but it can be 
revisited in future.

Apart from that the patch looked okay to me.

  -- Keir


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

thomas,

your patch is reasonable.

as my understanding, destroy is totally different from shutdown. destroy just 
issues a hyper-call(DOM0_OP), while shutdown writes xenstore and waits the guest
handling almost everything( use sched_op hypercall for itself).

so, qemu''s destroy command(kill hvm dom immediately when hang) should
use the
original destroy hyper-call to take place of "xm destroy".


On Mon, Apr 03, 2006 at 11:57:51AM -0400, Ben Thomas
wrote:
> Add code to make handling domain poweroff/reboot symmetrical
> between paravirtualized and fully virtualized.
> 
> A paravirtualized domain uses sched_op to shut down and set the
> reason code. This will send a VIRQ_DOM_EXC, which can be
> handled in dom0 by control software.  In some ways, this resembles
> SIGCHILD/waitpid, and is a reasonable model.
> 
> The fully virtualized case has qemu invoke xm directly. This is a
> different path than paravirtualized. It also removes
> decision and policy making choices from the rest of the control
> software and places it within qemu. When any dom0 logic
> eventually gets a VIRQ_DOM_EXC, the information about the
> domain is gone having been destroyed by xm.
> 
> It would be useful if all shutdown/reboot operations were
> symmetrical from domain 0''s point of view. One approach
> would be to redefine sched_op to handle other domains than
> the current domain, but this seemed excessive. Another
> approach, which is what this patch implements, adds
> a DOM0 hypervisor call very similar to the existing
> DOM0_DESTROYDOMAIN, called DOM0_SHUTDOWNDOMAIN, which handles
> the shutdown and reason -- basically, just like a
> paravirtualized system.
> 
> Like DOM0_DESTROYDOMAIN, add a xenctrl wrapper, and have qemu
> call it.
> 
> With this change, both domain types shutdown/reboot using
> the same dom0 management logic. All control decisions are
> removed from qemu, which now simply handles the request
> and reason. At a very high level, the flow is "notify of
> shutdown and reason", "send VIRQ_DOM_EXC", process, and
> destroy domain.  Paravirtualized and fully-virtualized
> domains would differ slightly in the first step of
> notification.  Paravirtualized continues to use sched_op,
> fully virtualized uses DOM0_SHUTDOWNDOMAIN. The rest
> of the steps would be identical in both cases.
> 
> Or, back to the opening sentence, make the operations as
> symmetrical as possible.
> 
> (As a freebie, #if 0 some very verbose logging code in qemu.
>  Totally unrelated, but as long as I was there...)
> 
> Signed-off-by: Ben Thomas (ben@virtualiron.com)
> 
> 
> -- 
> ------------------------------------------------------------------------
> Ben Thomas                                         Virtual Iron Software
> bthomas@virtualiron.com                            Tower 1, Floor 2
> 978-849-1214                                       900 Chelmsford Street
>                                                    Lowell, MA 01851
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

-- 
thanks,
edwin


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

On Mon, Apr 03, 2006 at 05:58:22PM +0100, Keir Fraser
wrote:
> 
> I''d prefer an extra sched_op (maybe SCHEDOP_remote_shutdown with 
can we use common code to avoid extra same function?
> accompanying sched_remote_shutdown structure). This will need to be 
> invokable by the emulator mini domain at some point in the future, so 
> adding this as a dom0_op isn''t really for the best.
> 
>  -- Keir
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
-- 
thanks,
edwin


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

On 4 Apr 2006, at 16:18, Edwin Zhai wrote:
>> I''d prefer an extra sched_op (maybe SCHEDOP_remote_shutdown
with
> can we use common code to avoid extra same function?
We need a separate interface function as it takes an extra parameter. 
There''ll be code sharing inside Xen, of course.

  -- Keir


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

Add code to make handling domain poweroff/reboot symmetrical
between paravirtualized and fully virtualized.

A paravirtualized domain uses sched_op to shut down and set the
reason code. This will send a VIRQ_DOM_EXC, which can be
handled in dom0 by control software.  In some ways, this resembles
SIGCHILD/waitpid, and is a reasonable model.

The fully virtualized case has qemu invoke xm directly. This is a
different path than paravirtualized. It also removes
decision and policy making choices from the rest of the control
software and places it within qemu. When any dom0 logic
eventually gets a VIRQ_DOM_EXC, the information about the
domain is gone having been destroyed by xm.

It would be useful if all shutdown/reboot operations were
symmetrical from domain 0''s point of view. This approach
uses the new sched_op to handle other domains than
the current domain.  The new code, SCHEDOP_remote_shutdown,
is very much like SCHEDOP_shutdown, but is called with
the id of the domain which is to be shut down. This allows
fully virtualized shutdown and para-virtualized shutdown
to be identical from that point forward.

A libxenctrl wrapper, xc_shutdown_domain has been added
and qemu now calls it.

With this change, both domain types shutdown/reboot using
the same dom0 management logic. All control decisions are
removed from qemu, which now simply handles the request
and reason. At a very high level, the flow is "notify of
shutdown and reason", "send VIRQ_DOM_EXC", process, and
destroy domain.  Paravirtualized and fully-virtualized
domains would differ slightly in the first step of
notification.

Or, back to the opening sentence, make the operations as
symmetrical as possible.

As a freebie, #if 0 some very verbose logging code in qemu.
Totally unrelated, but as long as I was there...


Signed-off-by: Ben Thomas (ben@virtualiron.com)
-- 
------------------------------------------------------------------------
Ben Thomas                                         Virtual Iron Software
bthomas@virtualiron.com                            Tower 1, Floor 2
978-849-1214                                       900 Chelmsford Street
                                                    Lowell, MA 01851


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