shutdown question - PV vs HVM

shutdown question - PV vs HVM

[James Harper]

I've had a bit of a look through the code but can't seem to find the
answer to this question... what is the method by which 'xm' tells a
domain to shutdown?

What is different about HVM that means it just powers straight off?

Looking at the Linux source, it appears that something is done with
'platform-feature-multiprocessor-suspend' in the store, but it isn't
clear to me what...

Thanks

James

Re: shutdown question - PV vs HVM

[Keir Fraser]

For a PV guest, a shutdown node is written into xenstore which the guest
picks up. The guest will then usually initiate a clean shutdown.

The same happens for an HVM guest with PV drivers installed. If an HVM guest
has no PV drivers (And so will obviously not be watching xenstore) then xend
notifies the shutdown immediately to Xen. This causes Xen to immediately
transition the guest to shutdown state, and no longer execute the guest,
with no chance for clean shutdown. If there are no PV drivers installed,
clean shutdown needs to be initiated from within the guest.

 -- Keir

On 1/10/07 02:13, "James Harper" <james.harper@bendigoit.com.au> wrote:

> I've had a bit of a look through the code but can't seem to find the
> answer to this question... what is the method by which 'xm' tells a
> domain to shutdown?
> 
> What is different about HVM that means it just powers straight off?
> 
> Looking at the Linux source, it appears that something is done with
> 'platform-feature-multiprocessor-suspend' in the store, but it isn't
> clear to me what...
> 
> Thanks
> 
> James
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

RE: shutdown question - PV vs HVM

[James Harper]

> 
> For a PV guest, a shutdown node is written into xenstore which the
guest
> picks up. The guest will then usually initiate a clean shutdown.
> 

My Windows PV drivers now know how to put a watch on something, so by
putting a watch on 'control' I can see the shutdown request from Dom0
(written to 'control/shutdown' I think). As I do nothing currently
though, a forced shutdown occurs very soon after.

If I understand the code correctly, as soon as I see the
control/shutdown node appear, I should read it, and then write a blank
string into it, which acknowledges the shutdown request and stops the
forced shutdown. I should then give windows the shutdown or reboot
command, depending on what I read from the xenstore node.

Sound good?

Thanks

James

Re: shutdown question - PV vs HVM

[Keir Fraser]

On 5/10/07 14:48, "James Harper" <james.harper@bendigoit.com.au> wrote:

>> 
>> For a PV guest, a shutdown node is written into xenstore which the
> guest
>> picks up. The guest will then usually initiate a clean shutdown.
>> 
> 
> My Windows PV drivers now know how to put a watch on something, so by
> putting a watch on 'control' I can see the shutdown request from Dom0
> (written to 'control/shutdown' I think). As I do nothing currently
> though, a forced shutdown occurs very soon after.
> 
> If I understand the code correctly, as soon as I see the
> control/shutdown node appear, I should read it, and then write a blank
> string into it, which acknowledges the shutdown request and stops the
> forced shutdown. I should then give windows the shutdown or reboot
> command, depending on what I read from the xenstore node.
> 
> Sound good?

Yep, that sounds about right.

 -- Keir

RE: shutdown question - PV vs HVM

[James Harper]

> > If I understand the code correctly, as soon as I see the
> > control/shutdown node appear, I should read it, and then write a
blank
> > string into it, which acknowledges the shutdown request and stops
the
> > forced shutdown. I should then give windows the shutdown or reboot
> > command, depending on what I read from the xenstore node.
> >
> > Sound good?
> 
> Yep, that sounds about right.
> 

Hmmm... I am writing a blank string into the shutdown node, but xen
still performs the reboot about 30 seconds later... The blank string is
definitely getting written as I can do a xenstore-read from dom0 and it
shows blank.

The only thing I can see that is different is that linux does it in a
transaction, while I don't. Would that make a difference?

Thanks

James

RE: shutdown question - PV vs HVM

[James Harper]

> > > If I understand the code correctly, as soon as I see the
> > > control/shutdown node appear, I should read it, and then write a
> blank
> > > string into it, which acknowledges the shutdown request and stops
> the
> > > forced shutdown. I should then give windows the shutdown or reboot
> > > command, depending on what I read from the xenstore node.
> > >
> > > Sound good?
> >
> > Yep, that sounds about right.
> >
> 
> Hmmm... I am writing a blank string into the shutdown node, but xen
> still performs the reboot about 30 seconds later... The blank string
is
> definitely getting written as I can do a xenstore-read from dom0 and
it
> shows blank.
> 
> The only thing I can see that is different is that linux does it in a
> transaction, while I don't. Would that make a difference?
> 

I implemented transactions, and it doesn't appear that having a
transaction makes a difference. The shutdown happens exactly 30 second
after I initiate the shutdown from dom0.

Looking at the code (XendDomainInfo), the only relevant hvm check that I
can see is:

"
# HVM domain shuts itself down only if it has PV drivers
if self.info.is_hvm():
  hvm_pvdrv = xc.hvm_get_param(self.domid, HVM_PARAM_CALLBACK_IRQ)
  if not hvm_pvdrv:
    code = REVERSE_DOMAIN_SHUTDOWN_REASONS[reason]
    log.info("HVM save:remote shutdown dom %d!", self.domid)
    xc.domain_shutdown(self.domid, code)
"

And xend is obviously detecting my PV drivers successfully... the
following gets logged in xend.log:

"
[2007-10-06 18:06:55 4240] DEBUG (__init__:1072)
XendDomainInfo.shutdown(reboot)
[2007-10-06 18:06:55 4240] DEBUG (__init__:1072)
XendDomainInfo.handleShutdownWatch
[2007-10-06 18:06:55 4240] DEBUG (__init__:1072)
XendDomainInfo.handleShutdownWatch
[2007-10-06 18:07:25 4240] INFO (__init__:1072) Domain shutdown timeout
expired: name=virtdemo id=61
[2007-10-06 18:07:25 4240] DEBUG (__init__:1072) XendDomainInfo.destroy:
domid=61
[2007-10-06 18:07:25 4240] DEBUG (__init__:1072)
XendDomainInfo.destroyDomain(61)
"

Do I need to do something to shutdown_start_time to give me more time to
do the shutdown? I can't see that in 'xenstore-ls', and the only
reference to it is in XendDomainInfo...

The only other thing I can think of is that I need to tell xend that I
am shutting down the domain, and that writing a blank string to
control/shutdown isn't what is required...

Any suggestions?

Thanks

James

Re: shutdown question - PV vs HVM

[Keir Fraser]

On 6/10/07 09:17, "James Harper" <james.harper@bendigoit.com.au> wrote:

> Do I need to do something to shutdown_start_time to give me more time to
> do the shutdown? I can't see that in 'xenstore-ls', and the only
> reference to it is in XendDomainInfo...
> 
> The only other thing I can think of is that I need to tell xend that I
> am shutting down the domain, and that writing a blank string to
> control/shutdown isn't what is required...

Xend is waiting 30 seconds for your HVM domain to complete its shutdown.
Once your domain halts, or tries to reboot, or whatever, qemu or Xen will
set its state to 'shutdown' and this is picked up by xend. That event will
stop xend's 30-second fallback timer.

If your problem is simply that clean shutdown of your HVM guest takes longer
than 30 seconds, then you need to increase SHUTDOWN_TIMEOUT in
XendConstants.py. It is already increased to 5 minutes in xen-unstable and
in xen-3.1.1.

 -- Keir

RE: shutdown question - PV vs HVM

[James Harper]

> On 6/10/07 09:17, "James Harper" <james.harper@bendigoit.com.au>
wrote:
> 
> > Do I need to do something to shutdown_start_time to give me more
time to
> > do the shutdown? I can't see that in 'xenstore-ls', and the only
> > reference to it is in XendDomainInfo...
> >
> > The only other thing I can think of is that I need to tell xend that
I
> > am shutting down the domain, and that writing a blank string to
> > control/shutdown isn't what is required...
> 
> Xend is waiting 30 seconds for your HVM domain to complete its
shutdown.
> Once your domain halts, or tries to reboot, or whatever, qemu or Xen
will
> set its state to 'shutdown' and this is picked up by xend. That event
will
> stop xend's 30-second fallback timer.
> 
> If your problem is simply that clean shutdown of your HVM guest takes
> longer
> than 30 seconds, then you need to increase SHUTDOWN_TIMEOUT in
> XendConstants.py. It is already increased to 5 minutes in xen-unstable
and
> in xen-3.1.1.

Actually, the problem is my assumption that xend would give me as long
as I wanted to shut down. I haven't yet put the code in to do the
shutdown, and I was concerned that the domain was still being
hard-shutdown anyway. You have enlightened me :)

As it turns out, there isn't really a way to do a shutdown from windows
kernel space. I need to write a usermode app/service to talk to the
driver, and initiate the shutdown from there.

Thanks

James

Re: shutdown question - PV vs HVM

[Russ Blaine]

Have a question on this old thread:

Keir Fraser wrote:
> For a PV guest, a shutdown node is written into xenstore which the guest
> picks up. The guest will then usually initiate a clean shutdown.
> 
> The same happens for an HVM guest with PV drivers installed. If an HVM guest
> has no PV drivers (And so will obviously not be watching xenstore) then xend
> notifies the shutdown immediately to Xen. This causes Xen to immediately
> transition the guest to shutdown state, and no longer execute the guest,
> with no chance for clean shutdown. If there are no PV drivers installed,
> clean shutdown needs to be initiated from within the guest.

Why are HVM domains treated differently for shutdown? Guest OSes already know 
how to do a clean ACPI-initiated shutdown, so why not use that for shutdown in 
the presence of PV drivers?

The current method requires extra complexity in PV drivers. I imagine that it 
either fell out of porting PV drivers from PV domains to HVM domains or is just 
  paranoia about losing data during ACPI shutdown.

- R



> 
>  -- Keir
> 
> On 1/10/07 02:13, "James Harper" <james.harper@bendigoit.com.au> wrote:
> 
>> I've had a bit of a look through the code but can't seem to find the
>> answer to this question... what is the method by which 'xm' tells a
>> domain to shutdown?
>>
>> What is different about HVM that means it just powers straight off?
>>
>> Looking at the Linux source, it appears that something is done with
>> 'platform-feature-multiprocessor-suspend' in the store, but it isn't
>> clear to me what...
>>
>> Thanks
>>
>> James
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

-- 

-----------------------------------------------------
Russ Blaine | Solaris Kernel | russell.blaine@sun.com

Re: shutdown question - PV vs HVM

[Keir Fraser]

On 3/9/08 19:01, "Russ Blaine" <russell.blaine@sun.com> wrote:

>> For a PV guest, a shutdown node is written into xenstore which the guest
>> picks up. The guest will then usually initiate a clean shutdown.
>> 
>> The same happens for an HVM guest with PV drivers installed. If an HVM guest
>> has no PV drivers (And so will obviously not be watching xenstore) then xend
>> notifies the shutdown immediately to Xen. This causes Xen to immediately
>> transition the guest to shutdown state, and no longer execute the guest,
>> with no chance for clean shutdown. If there are no PV drivers installed,
>> clean shutdown needs to be initiated from within the guest.
> 
> Why are HVM domains treated differently for shutdown? Guest OSes already know
> how to do a clean ACPI-initiated shutdown, so why not use that for shutdown in
> the presence of PV drivers?
> 
> The current method requires extra complexity in PV drivers. I imagine that it
> either fell out of porting PV drivers from PV domains to HVM domains or is
> just 
>   paranoia about losing data during ACPI shutdown.

Really it just fell out of porting the PV drivers. The shutdown node must be
watched as it is part of the save/restore/migrate protocol. Hooking shutdown
off the same node is trivial within the PV drivers.

Another issue is how to reliably trigger an S5 transition (poweroff) in a
wide range of OS versions. It might be hooked off the 'lid switch'. OTOH it
may not be externally triggerable at all...

 -- Keir