Some Coverity fixes and minor cleanups. And most notably, dropping
support for Xen libraries older than 4.7.1.

I believe there are two issues that remain to be fixed. The x32 build
fails, and I've seen patches which attempt to detect x32 and disable
the Xen emulation. Along with assertions that we just shouldn't care.
I don't have a strong opinion either way but it seems to be in hand.

The other is the question of what Xen *actually* does if you try to
unmap an IRQ_MSI_EMU PIRQ. I don't think Linux guests try that, and
I'm fairly sure Windows doesn't even use MSI→PIRQ mappings in the
first place, and I doubt any other guests care either. I'd like to
establish the 'correct' behaviour and implement it, ideally before
the 8.0 release, but it's going to take me a few days more.

David Woodhouse (5):
      hw/xen: Simplify emulated Xen platform init
      hw/xen: Fix memory leak in libxenstore_open() for Xen
      xen: Drop support for Xen versions below 4.7.1
      hw/xen: Fix double-free in xen_console store_con_info()
      hw/xen: Fix broken check for invalid state in xs_be_open()

 hw/char/xen_console.c       |  13 ++----
 hw/i386/kvm/xen_evtchn.c    |  40 ++++++++---------
 hw/i386/kvm/xen_evtchn.h    |   3 +-
 hw/i386/kvm/xen_xenstore.c  |   2 +-
 hw/i386/pc.c                |  13 ++----
 hw/xen/xen-operations.c     |  59 +-----------------------
 include/hw/xen/xen_native.h | 107 +-------------------------------------------
 meson.build                 |   5 +--
 scripts/xen-detect.c        |  60 -------------------------
 9 files changed, 33 insertions(+), 269 deletions(-)

On Wed, 11 Apr 2023, David Woodhouse wrote:
> Some Coverity fixes and minor cleanups. And most notably, dropping
> support for Xen libraries older than 4.7.1.

I just wanted to say that I am fine with this

On Wed, 12 Apr 2023 at 19:52, David Woodhouse <dwmw2@infradead.org> wrote:
>
> Some Coverity fixes and minor cleanups. And most notably, dropping
> support for Xen libraries older than 4.7.1.
>
> I believe there are two issues that remain to be fixed. The x32 build
> fails, and I've seen patches which attempt to detect x32 and disable
> the Xen emulation. Along with assertions that we just shouldn't care.
> I don't have a strong opinion either way but it seems to be in hand.
>
> The other is the question of what Xen *actually* does if you try to
> unmap an IRQ_MSI_EMU PIRQ. I don't think Linux guests try that, and
> I'm fairly sure Windows doesn't even use MSI→PIRQ mappings in the
> first place, and I doubt any other guests care either. I'd like to
> establish the 'correct' behaviour and implement it, ideally before
> the 8.0 release, but it's going to take me a few days more.
>
> David Woodhouse (5):
>       hw/xen: Simplify emulated Xen platform init
>       hw/xen: Fix memory leak in libxenstore_open() for Xen
>       xen: Drop support for Xen versions below 4.7.1
>       hw/xen: Fix double-free in xen_console store_con_info()
>       hw/xen: Fix broken check for invalid state in xs_be_open()
>

This is highly unlikely to make 8.0 at this point, FYI.
If there's anything in this you think is super-critical we
might be able to sneak it in.

thanks
-- PMM

On Wed, 2023-04-12 at 19:55 +0100, Peter Maydell wrote:
> On Wed, 12 Apr 2023 at 19:52, David Woodhouse <dwmw2@infradead.org> wrote:
> > 
> > Some Coverity fixes and minor cleanups. And most notably, dropping
> > support for Xen libraries older than 4.7.1.
> > 
> > I believe there are two issues that remain to be fixed. The x32 build
> > fails, and I've seen patches which attempt to detect x32 and disable
> > the Xen emulation. Along with assertions that we just shouldn't care.
> > I don't have a strong opinion either way but it seems to be in hand.
> > 
> > The other is the question of what Xen *actually* does if you try to
> > unmap an IRQ_MSI_EMU PIRQ. I don't think Linux guests try that, and
> > I'm fairly sure Windows doesn't even use MSI→PIRQ mappings in the
> > first place, and I doubt any other guests care either. I'd like to
> > establish the 'correct' behaviour and implement it, ideally before
> > the 8.0 release, but it's going to take me a few days more.
> > 
> > David Woodhouse (5):
> >       hw/xen: Simplify emulated Xen platform init
> >       hw/xen: Fix memory leak in libxenstore_open() for Xen
> >       xen: Drop support for Xen versions below 4.7.1
> >       hw/xen: Fix double-free in xen_console store_con_info()
> >       hw/xen: Fix broken check for invalid state in xs_be_open()
> > 
> 
> This is highly unlikely to make 8.0 at this point, FYI.
> If there's anything in this you think is super-critical we
> might be able to sneak it in.

Nothing is super-critical except maybe the double-free in
store_con_info(). That could lead to a crash on startup if the QEMU Xen
console is being used.

On Wed, 12 Apr 2023 at 20:01, David Woodhouse <dwmw2@infradead.org> wrote:
>
> On Wed, 2023-04-12 at 19:55 +0100, Peter Maydell wrote:
> > On Wed, 12 Apr 2023 at 19:52, David Woodhouse <dwmw2@infradead.org> wrote:
> > >
> > > Some Coverity fixes and minor cleanups. And most notably, dropping
> > > support for Xen libraries older than 4.7.1.
> > >
> > > I believe there are two issues that remain to be fixed. The x32 build
> > > fails, and I've seen patches which attempt to detect x32 and disable
> > > the Xen emulation. Along with assertions that we just shouldn't care.
> > > I don't have a strong opinion either way but it seems to be in hand.
> > >
> > > The other is the question of what Xen *actually* does if you try to
> > > unmap an IRQ_MSI_EMU PIRQ. I don't think Linux guests try that, and
> > > I'm fairly sure Windows doesn't even use MSI→PIRQ mappings in the
> > > first place, and I doubt any other guests care either. I'd like to
> > > establish the 'correct' behaviour and implement it, ideally before
> > > the 8.0 release, but it's going to take me a few days more.
> > >
> > > David Woodhouse (5):
> > >       hw/xen: Simplify emulated Xen platform init
> > >       hw/xen: Fix memory leak in libxenstore_open() for Xen
> > >       xen: Drop support for Xen versions below 4.7.1
> > >       hw/xen: Fix double-free in xen_console store_con_info()
> > >       hw/xen: Fix broken check for invalid state in xs_be_open()
> > >
> >
> > This is highly unlikely to make 8.0 at this point, FYI.
> > If there's anything in this you think is super-critical we
> > might be able to sneak it in.
>
> Nothing is super-critical except maybe the double-free in
> store_con_info(). That could lead to a crash on startup if the QEMU Xen
> console is being used.

I've cherry-picked that double-free patch to apply for 8.0; thanks.

-- PMM

On Wed, 2023-04-12 at 20:01 +0100, David Woodhouse wrote:
> On Wed, 2023-04-12 at 19:55 +0100, Peter Maydell wrote:
> > On Wed, 12 Apr 2023 at 19:52, David Woodhouse <dwmw2@infradead.org> wrote:
> > > 
> > > Some Coverity fixes and minor cleanups. And most notably, dropping
> > > support for Xen libraries older than 4.7.1.
> > > 
> > > I believe there are two issues that remain to be fixed. The x32 build
> > > fails, and I've seen patches which attempt to detect x32 and disable
> > > the Xen emulation. Along with assertions that we just shouldn't care.
> > > I don't have a strong opinion either way but it seems to be in hand.
> > > 
> > > The other is the question of what Xen *actually* does if you try to
> > > unmap an IRQ_MSI_EMU PIRQ. I don't think Linux guests try that, and
> > > I'm fairly sure Windows doesn't even use MSI→PIRQ mappings in the
> > > first place, and I doubt any other guests care either. I'd like to
> > > establish the 'correct' behaviour and implement it, ideally before
> > > the 8.0 release, but it's going to take me a few days more.
> > > 
> > > David Woodhouse (5):
> > >       hw/xen: Simplify emulated Xen platform init
> > >       hw/xen: Fix memory leak in libxenstore_open() for Xen
> > >       xen: Drop support for Xen versions below 4.7.1
> > >       hw/xen: Fix double-free in xen_console store_con_info()
> > >       hw/xen: Fix broken check for invalid state in xs_be_open()
> > > 
> > 
> > This is highly unlikely to make 8.0 at this point, FYI.
> > If there's anything in this you think is super-critical we
> > might be able to sneak it in.
> 
> Nothing is super-critical except maybe the double-free in
> store_con_info(). That could lead to a crash on startup if the QEMU Xen
> console is being used.

Although we could just do the one-liner that drops the extra 'free'
instead of converting to g_autoptr.