On 2023-11-29 09:23:46+0100, Cornelia Huck wrote: > On Tue, Nov 28 2023, Thomas Weißschuh <tho...@t-8ch.de> wrote: > > > Shutdown requests are normally hardware dependent. > > By extending pvpanic to also handle shutdown requests, guests can > > submit such requests with an easily implementable and cross-platform > > mechanism. > > > > Signed-off-by: Thomas Weißschuh <tho...@t-8ch.de> > > --- > > docs/specs/pvpanic.rst | 2 ++ > > hw/misc/pvpanic.c | 5 +++++ > > include/hw/misc/pvpanic.h | 2 +- > > include/standard-headers/linux/pvpanic.h | 1 + > > 4 files changed, 9 insertions(+), 1 deletion(-) > > (...) > > > diff --git a/include/standard-headers/linux/pvpanic.h > > b/include/standard-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 @@ > > > > #define PVPANIC_PANICKED (1 << 0) > > #define PVPANIC_CRASH_LOADED (1 << 1) > > +#define PVPANIC_SHUTDOWN (1 << 2) > > > > #endif /* __PVPANIC_H__ */ > > > > 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/
