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 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 95D8CC4167B for ; Wed, 29 Nov 2023 13:16:07 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r8KPc-0004cF-NW; Wed, 29 Nov 2023 08:15:32 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r8KPW-0004aK-Ci for qemu-devel@nongnu.org; Wed, 29 Nov 2023 08:15:26 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r8KPR-0003W0-8J for qemu-devel@nongnu.org; Wed, 29 Nov 2023 08:15:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1701263719; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tgmmFtv2ONmHepHt+UgW5H5sB/z96SyR6fDT1K3tW2Y=; b=bKbHsNutN+t0VPziJgtNpZFx+VvLtTpy+DVDmPV7vfs6+ELc1pHv0HBQlZfATHFZ8LgDe5 VQkSdew7u5jjdPzce9dk7vjIUJhUwtAf4uZQPaMWyK8yWrpO7n+KSyMW2RgfeFZ1j/SZl1 PAr+9VmKVCBbjdoyGtaq1R4e6wOn/i0= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-625-DAdSdG3mMWi6q5fy_K4g4Q-1; Wed, 29 Nov 2023 08:15:16 -0500 X-MC-Unique: DAdSdG3mMWi6q5fy_K4g4Q-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D237D88D01C; Wed, 29 Nov 2023 13:15:15 +0000 (UTC) Received: from localhost (dhcp-192-239.str.redhat.com [10.33.192.239]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8DFB3492BE0; Wed, 29 Nov 2023 13:15:15 +0000 (UTC) From: Cornelia Huck To: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= Cc: "Michael S. Tsirkin" , Paolo Bonzini , Thomas Huth , Laurent Vivier , qemu-devel@nongnu.org Subject: Re: [PATCH v2 3/3] hw/misc/pvpanic: add support for normal shutdowns In-Reply-To: <2d249b3e-0976-4c7e-969a-88d54feb290a@t-8ch.de> Organization: "Red Hat GmbH, Sitz: Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Handelsregister: Amtsgericht =?utf-8?Q?M=C3=BCnchen=2C?= HRB 153243, =?utf-8?Q?Gesch=C3=A4ftsf=C3=BChrer=3A?= Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross" References: <20231128-pvpanic-shutdown-v2-0-830393b45cb6@t-8ch.de> <20231128-pvpanic-shutdown-v2-3-830393b45cb6@t-8ch.de> <874jh5x90t.fsf@redhat.com> <2d249b3e-0976-4c7e-969a-88d54feb290a@t-8ch.de> User-Agent: Notmuch/0.37 (https://notmuchmail.org) Date: Wed, 29 Nov 2023 14:15:14 +0100 Message-ID: <87v89kwvj1.fsf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.9 Received-SPF: pass client-ip=170.10.129.124; envelope-from=cohuck@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org On Wed, Nov 29 2023, Thomas Wei=C3=9Fschuh wrote: > On 2023-11-29 09:23:46+0100, Cornelia Huck wrote: >> On Tue, Nov 28 2023, Thomas Wei=C3=9Fschuh wrote: >> > diff --git a/include/standard-headers/linux/pvpanic.h b/include/standa= rd-headers/linux/pvpanic.h >> > index 54b7485390d3..38e53ad45929 100644 >> > --- a/include/standard-headers/linux/pvpanic.h >> > +++ b/include/standard-headers/linux/pvpanic.h >> > @@ -5,5 +5,6 @@ >> >=20=20 >> > #define PVPANIC_PANICKED (1 << 0) >> > #define PVPANIC_CRASH_LOADED (1 << 1) >> > +#define PVPANIC_SHUTDOWN (1 << 2) >> >=20=20 >> > #endif /* __PVPANIC_H__ */ >> > >>=20 >> This hunk needs to come in via a separate headers update, or has to be >> split out into a placeholder patch if it is not included in the Linux >> kernel yet. > > Greg KH actually want this header removed from the Linux UAPI headers, > as it is not in fact a Linux UAPI [0]. > It's also a weird workflow to have the specification in qemu but the > header as part of Linux that is re-imported in qemu. > > What do you think about maintaining the header as a private part of qemu > and dropping it from Linux UAPI? > > Contrary to my response to Greg this wouldn't break old versions of > qemu, as qemu is using a private copy that would still exist there. > > [0] https://lore.kernel.org/lkml/2023110431-pacemaker-pruning-0e4c@gregkh/ Hm... we have a bunch of examples where we use things exported via the Linux uapi header files that are not a kernel<->userspace interface, but rather a host<->guest interface (sometimes defining the interface, sometimes more as a convenience mechanism). I agree that this is not quite what the Linux uapi is supposed to be (and yes, it's weird), but we've being doing that for many years now and changing it would be a non-zero effort (and we'd have to figure out another way to make sure the kernel and QEMU do not diverge if there's no authorative third party around.) In the case of the pvpanic device, this seems manageable, though; if we decide to go that way, we should 1. copy the header on the QEMU side somewhere else under include/ and remove it from the header update script 2. wait until this hits QEMU mainline (so nobody will try to run the old update script) 3. move the uapi file on the Linux side (We've had changes in the kernel break the update script before, but if we can do it more smoothly, I'd prefer that way -- the kernel merge window won't open before the new year anyway, and by that time, we'll have the QEMU tree open again.) Main downside is that you'd have extra hassle for something that looks like a straightforward feature, which is not ideal. (Also, are we sure that nobody else consumes that header file?) I'm not sure if dealing with the other host<->guest interfaces that get copied over is worth the effort, though... Opinions?