Received-SPF: pass (google.com: domain of linux-kernel+bounces-84574-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Wed, 28 Feb 2024 07:48:26 +0100
From: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= <linux@weissschuh.net>
To: "Michael S. Tsirkin" <mst@redhat.com>, 
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Arnd Bergmann <arnd@arndb.de>, linux-kernel@vger.kernel.org, 
	Zhangjin Wu <falcon@tinylab.org>, Willy Tarreau <w@1wt.eu>, Yuan Tan <tanyuan@tinylab.org>
Subject: Re: [PATCH RFC] misc/pvpanic: add support for normal shutdowns
Message-ID: <ae7a35e9-16f6-4877-8075-a0fb9fe5bfff@t-8ch.de>
References: <20231104-pvpanic-shutdown-v1-1-5ee7c9b3e301@weissschuh.net>
 <2023110407-unselect-uptight-b96d@gregkh>
 <20240213053953-mutt-send-email-mst@kernel.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240213053953-mutt-send-email-mst@kernel.org>

Hi Michael,

On 2024-02-13 05:41:48-0500, Michael S. Tsirkin wrote:
> On Sat, Nov 04, 2023 at 02:05:02PM +0100, Greg Kroah-Hartman wrote:
> > > diff --git a/include/uapi/misc/pvpanic.h b/include/uapi/misc/pvpanic.h
> > > index 54b7485390d3..82fc618bfbcf 100644
> > > --- a/include/uapi/misc/pvpanic.h
> > > +++ b/include/uapi/misc/pvpanic.h
> > > @@ -5,5 +5,6 @@
> > >  
> > >  #define PVPANIC_PANICKED	(1 << 0)
> > >  #define PVPANIC_CRASH_LOADED	(1 << 1)
> > > +#define PVPANIC_SHUTDOWN	(1 << 2)
> > 
> > Why are these in a uapi file?
> > 
> > And if they need to be here, why not use the proper BIT() macro for it?
> > 
> > thanks,
> > 
> > greg k-h
> 
> This is interface with hypervisor not userspace, but for PV historically
> we do this since the compatibility implications are about the same,
> hypervisors (e.g. QEMU) are mostly userspace and so it is convenient for
> them to reuse the same machinery to export the headers.
> 
> Let's stick to that, cleaner than duplicating everything I think.

as Greg seems to be busy with other stuff I'd like to go ahead with
submitting this again using the existing header file.
It seems unfortunate to block this work on the non-function detail of
the location if a header file which already exists and which we could
always change after the fact, too.

Do you have any recommendations in which parts and order to submit these
changes to the kernel and Qemu?

I need to touch the specification document in qemu, the header in the
kernel, the import of the header in qemu and drivers in both qemu and
the kernel.


Thomas