From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3E7C1C4361B for ; Thu, 17 Dec 2020 02:20:09 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EBDD423718 for ; Thu, 17 Dec 2020 02:20:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EBDD423718 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.55690.97016 (Exim 4.92) (envelope-from ) id 1kpitS-0005X4-5f; Thu, 17 Dec 2020 02:19:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 55690.97016; Thu, 17 Dec 2020 02:19:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kpitS-0005Wx-1R; Thu, 17 Dec 2020 02:19:50 +0000 Received: by outflank-mailman (input) for mailman id 55690; Thu, 17 Dec 2020 02:19:49 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kpitR-0005WZ-1q for xen-devel@lists.xenproject.org; Thu, 17 Dec 2020 02:19:49 +0000 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1dc8571a-e6eb-4f18-a8fa-e8e6417b8968; Thu, 17 Dec 2020 02:19:48 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1dc8571a-e6eb-4f18-a8fa-e8e6417b8968 Date: Wed, 16 Dec 2020 18:19:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1608171587; bh=G+cExh6jJq3EcNHX86SHv7LNuHfpcsIJ/6vBCBU7z40=; h=From:To:cc:Subject:In-Reply-To:References:From; b=FaCbO5GBXCcK2AB0ATojyjDhoT/RImLkOaaUx0741josrlAQneTT0CHVKVwlpg9V2 DQdfaPaOzwmyWHOZDQHEE4TX0ZTRC0F/g1s2TLgw+htuInE4Dci5f4H0YoymdJt/Ff A12l03g1bq74lZj2vFU9srOVQSjMp1E6hcROdIjg/YEe4aSB8Y7X32blBtrkTf9gXF S7TnNuYXI+4M7cj5C2UMnCtrf+BE7zwf2DhdBskxz9JRXrlrs2qM0fxdlsDwIrYnFn Qnc27aHZcqEoLNfPbZqFDiyU7VB7emxMDYWwuD9D3A8EEfqenZswH9eBRIu7JIois6 52RwvYBoWqXyQ== From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Andrew Cooper cc: Jason Andryuk , Chris Rogers , Stefano Stabellini , Rich Persaud , openxt , xen-devel , Anthony PERARD , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Olivier Lambert , Wei Liu , Jan Beulich , Roger Pau Monne Subject: Re: [openxt-dev] Re: Follow up on libxl-fix-reboot.patch In-Reply-To: Message-ID: References: <3ACCFEC6-A8B7-48E6-AA3F-48D4CDE75FA4@gmail.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-766529692-1608171587=:4040" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-766529692-1608171587=:4040 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Wed, 16 Dec 2020, Andrew Cooper wrote: > On 16/12/2020 14:14, Jason Andryuk wrote: > > On Tue, Dec 15, 2020 at 5:22 PM Chris Rogers wrote: > >> Hopefully I can provide a little more context. Here is a link to the patch: > >> > >> https://github.com/OpenXT/xenclient-oe/blob/master/recipes-extended/xen/files/libxl-fix-reboot.patch > >> > >> The patch is a bit mis-named. It does not implement XEN_DOMCTL_SENDTRIGGER_RESET. It's just a workaround to handle the missing RESET implementation. > >> > >> Its purpose is to make an HVM guest "reboot" regardless of whether PV tools have been installed and the xenstore interface is listening or not. From the client perspective that OpenXT is concerned with, this is for ease-of-use for working with HVM guests before PV tools are installed. To summarize the flow of the patch: > >> > >> - User input causes high level toolstack, xenmgr, to do xl reboot > >> - libxl hits "PV interface not available", so it tries the fallback ACPI reset trigger (but that's not implemented in domctl) > >> - therefore, the patch changes the RESET trigger to POWER trigger, and sets a 'reboot' flag > >> - when the xl create process handles the domain_death event for LIBXL_SHUTDOWN_REASON_POWEROFF, we check for our 'reboot' flag. > >> - It's set, so we set "action" as if we came from a real restart, which makes the xl create process take the 'goto start' codepath to rebuild the domain. > >> > >> I think we'd like to get rid of this patch, but at the moment I don't have any code or a design to propose that would implement the XEN_DOMCTL_SENDTRIGGER_RESET. > > I'm not sure it's possible to implement one. Does an ACPI > > reset/reboot button exist? And then you'd have the problem that the > > guest needs to be configured to react to the button. Looking at the patch, it is difficult to suggest anything better. The only thing I could think of would be to force shutdown_reason to be "reboot" from xl_vmcontrol.c:reboot_domain. To do that, we would have to be careful not to overwrite it in domain_death_xswatch_callback. I am not sure if it would be actually a lot better. > The ACPI spec has two signals as far as this goes. "the user pressed the > power button" and "the user {pressed the suspend button, closed the > laptop lid}".  Neither are useful for VMs typically, because default OS > settings do the wrong thing. > > The mystery to unravel here is why xl is issuing an erroneous hypercall. > > It is very unlikely that we will have dropped > XEN_DOMCTL_SENDTRIGGER_RESET from Xen, but I suppose its possible.  It's > definitely weird that we have it in the interface and unimplemented. > > It's also possible it was a copy&paste mistake when trying to implement > an interface consistent with `xm trigger`. > > It is definitely concerning that we've got a piece of functionality like > this which clearly hasn't seen any testing upstream. Indeed. I think we should fix this in 4.15, one way or another. --8323329-766529692-1608171587=:4040--