linux-kernel - Re: [PATCH RFC] misc/pvpanic: add support for normal shutdowns

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ae7a35e9-16f6-4877-8075-a0fb9fe5bfff@t-8ch.de>
Date: Wed, 28 Feb 2024 07:48:26 +0100
From: Thomas Weißschuh <linux@...ssschuh.net>
To: "Michael S. Tsirkin" <mst@...hat.com>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org, 
	Zhangjin Wu <falcon@...ylab.org>, Willy Tarreau <w@....eu>, Yuan Tan <tanyuan@...ylab.org>
Subject: Re: [PATCH RFC] misc/pvpanic: add support for normal shutdowns

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