From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Early ACPI events prevent subsequent ACPI functionality on xen 4.3 + HVM domU Date: Wed, 22 May 2013 11:55:03 +0100 Message-ID: <519CA407.7000609@eu.citrix.com> References: <752956577.8634488.1368537190555.JavaMail.root@zimbra002> <86B77960F7BEC777A3C5C339@Ximines.local> <519B947D.8030607@eu.citrix.com> <519B9801.3080901@eu.citrix.com> <20130521164531.GE3669@phenom.dumpdata.com> <6D7B8289F0F8A65C8C2A25C7@Ximines.local> <1809930721.71216.1369219520131.JavaMail.root@flexiant.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1809930721.71216.1369219520131.JavaMail.root@flexiant.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Diana Crisan Cc: Ian Campbell , Konrad Rzeszutek Wilk , xen-devel@lists.xen.org, Paul Durrant , Stefano Stabellini , Alex Bligh , Anthony Perard , Dave Scott List-Id: xen-devel@lists.xenproject.org On 22/05/13 11:45, Diana Crisan wrote: >> --On 22 May 2013 10:21:44 +0100 George Dunlap >> wrote: >>>> The second problem is that ACPI shutdown appears not to work reliably >>>> either (whenever issued). >>> I'll have another look today, but it seemed fairly reliable to me. >>> Just to double-check -- you are issuing the ACPI commands after the VM >>> has come all the way up, right? Or are you issuing them early during >>> boot, like you were for the xl shutdown commands? >> I believe Diana has tried both. Diana? > I have tested both cases with Ubuntu. > Sending the trigger is reliable if you wait for boot to fully complete. > However, if I issue it during boot it does not get executed. Any subsequent triggers do not get executed as well until one is sent when the vm has fully booted. Right -- so what I hear you saying is, "ACPI commands issued before the OS is paying attention are ignored." I think that's expected behavior. I can see that "Shut this vm down as soon as possible" is a useful thing to have. The problem at the moment guest OSes can ignore signals sent too early, it doesn't really seem within the scope of libxl to work around that. You could hold off issuing shutdown commands until the guest responds to a ping; here is a rune I use for that in my test harness: ping -c 1 -i 5 -q -w ${timeout} ${host} This will ping ${host} every 5 seconds until it receives 1 ping back, failing with an error after ${timeout} seconds. Alternately, you could find another xenstore key that indicates that the guest is ready to receive a shutdown command; or you could add a line to /etc/rc.local to write a xenstore key once the system is done booting. -George