[GIT PULL] KVM/arm64 fixes for 6.7, part #2

[GIT PULL] KVM/arm64 fixes for 6.7, part #2

[Oliver Upton]

Hi Paolo,

Here's the second batch of fixes for 6.7. Please note that this pull
is based on -rc4 instead of my first fixes tag as the KVM selftests
breakage was introduced by one of my changes that went through the
perf tree.

Please pull.

-- 
Thanks,
Oliver

The following changes since commit 33cc938e65a98f1d29d0a18403dbbee050dcad9a:

  Linux 6.7-rc4 (2023-12-03 18:52:56 +0900)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-6.7-2

for you to fetch changes up to 0c12e6c8267f831e491ee64ac6f216601cea3eee:

  KVM: selftests: Ensure sysreg-defs.h is generated at the expected path (2023-12-12 16:49:43 +0000)

----------------------------------------------------------------
KVM/arm64 fixes for 6.7, part #2

 - Ensure a vCPU's redistributor is unregistered from the MMIO bus
   if vCPU creation fails

 - Fix building KVM selftests for arm64 from the top-level Makefile

----------------------------------------------------------------
Marc Zyngier (5):
      KVM: arm64: vgic: Simplify kvm_vgic_destroy()
      KVM: arm64: vgic: Add a non-locking primitive for kvm_vgic_vcpu_destroy()
      KVM: arm64: vgic: Force vcpu vgic teardown on vcpu destroy
      KVM: arm64: vgic: Ensure that slots_lock is held in vgic_register_all_redist_iodevs()
      KVM: Convert comment into an assertion in kvm_io_bus_register_dev()

Oliver Upton (1):
      KVM: selftests: Ensure sysreg-defs.h is generated at the expected path

 arch/arm64/kvm/arm.c                 |  2 +-
 arch/arm64/kvm/vgic/vgic-init.c      | 47 ++++++++++++++++++++++--------------
 arch/arm64/kvm/vgic/vgic-mmio-v3.c   |  4 ++-
 arch/arm64/kvm/vgic/vgic.h           |  1 +
 tools/testing/selftests/kvm/Makefile | 26 ++++++++++++--------
 virt/kvm/kvm_main.c                  |  3 ++-
 6 files changed, 52 insertions(+), 31 deletions(-)

Re: [GIT PULL] KVM/arm64 fixes for 6.7, part #2

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 450 bytes --]

On Mon, Dec 18, 2023 at 11:17:24AM -0800, Oliver Upton wrote:

> Here's the second batch of fixes for 6.7. Please note that this pull
> is based on -rc4 instead of my first fixes tag as the KVM selftests
> breakage was introduced by one of my changes that went through the
> perf tree.

Any news on this?  The KVM selftests are still broken in mainline,
pending-fixes and -next and the release is getting near.

Oliver, should your tree be in -next?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [GIT PULL] KVM/arm64 fixes for 6.7, part #2

[Marc Zyngier]

On 2023-12-22 13:09, Mark Brown wrote:
> On Mon, Dec 18, 2023 at 11:17:24AM -0800, Oliver Upton wrote:
> 
>> Here's the second batch of fixes for 6.7. Please note that this pull
>> is based on -rc4 instead of my first fixes tag as the KVM selftests
>> breakage was introduced by one of my changes that went through the
>> perf tree.
> 
> Any news on this?  The KVM selftests are still broken in mainline,
> pending-fixes and -next and the release is getting near.
> 
> Oliver, should your tree be in -next?

No, we don't have the KVM/arm64 fixes in -next.

And we have another two weeks to release, so ample amount of
time until Paolo picks up the PR.

         M.
-- 
Jazz is not dead. It just smells funny...

Re: [GIT PULL] KVM/arm64 fixes for 6.7, part #2

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

On Fri, Dec 22, 2023 at 01:16:41PM +0000, Marc Zyngier wrote:

> > Oliver, should your tree be in -next?

> No, we don't have the KVM/arm64 fixes in -next.

I see it's not, I'm asking if it should be - given the latencies
involved it seems like it'd be helpful for keeping -next working.

> And we have another two weeks to release, so ample amount of
> time until Paolo picks up the PR.

Sure, but we do also have the holidays and also the fact that it's a
build failure in a configuration used by some of the CIs means that
we've got a bunch of testing that simply hasn't been happening for a
couple of weeks now.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [GIT PULL] KVM/arm64 fixes for 6.7, part #2

[Marc Zyngier]

On 2023-12-22 13:26, Mark Brown wrote:
> On Fri, Dec 22, 2023 at 01:16:41PM +0000, Marc Zyngier wrote:
> 
>> > Oliver, should your tree be in -next?
> 
>> No, we don't have the KVM/arm64 fixes in -next.
> 
> I see it's not, I'm asking if it should be - given the latencies
> involved it seems like it'd be helpful for keeping -next working.

This is on purpose. We use -next for, well, the next release,
and not as a band-aid for some other purpose. If you think things
don't get merged quickly enough, please take it with the person
processing the PRs (Paolo).

> 
>> And we have another two weeks to release, so ample amount of
>> time until Paolo picks up the PR.
> 
> Sure, but we do also have the holidays and also the fact that it's a
> build failure in a configuration used by some of the CIs means that
> we've got a bunch of testing that simply hasn't been happening for a
> couple of weeks now.

Given that most of the KVM tests are usually more broken than
the kernel itself, I'm not losing much sleep over it.

         M.
-- 
Jazz is not dead. It just smells funny...

Re: [GIT PULL] KVM/arm64 fixes for 6.7, part #2

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2956 bytes --]

On Fri, Dec 22, 2023 at 01:34:09PM +0000, Marc Zyngier wrote:
> On 2023-12-22 13:26, Mark Brown wrote:
> > On Fri, Dec 22, 2023 at 01:16:41PM +0000, Marc Zyngier wrote:

> > > > Oliver, should your tree be in -next?

> > > No, we don't have the KVM/arm64 fixes in -next.

> > I see it's not, I'm asking if it should be - given the latencies
> > involved it seems like it'd be helpful for keeping -next working.

> This is on purpose. We use -next for, well, the next release,
> and not as a band-aid for some other purpose. If you think things

Note that -next includes pending-fixes which is specifically for the
purpose of getting coverage for fixes intended to go to mainline (indeed
this issue was found and reported before the original problematic patch
was sent to mainline, it's not clear to me what went wrong there).  As
well as the fixes getting coverage through being in -next itself there's
a bunch of the CI that specifically looks at pending-fixes, trying to
both prioritise keeping mainline stable and catch things like unintended
dependencies on things only in -next.

There's also the fact that if mainline is broken and not somehow fixed
in -next then that does disrupt the use of -next for testing things
aimed at the next release.

> don't get merged quickly enough, please take it with the person
> processing the PRs (Paolo).

He is on CC here.  I'm not sure that it's specifically things not
getting merged (well, modulo this one fixing an issue in mainline) -
it's a totally reasonable approach to want to give things time to get
reviewed and tested before they get merged, but if we're doing that then
it seems sensible to take advantage of the coverage from having things
in the integration trees.  OTOH if things get merged very quickly then 
it's less clear since there's less time for the integration trees to do
their thing.  It feels like things aren't lining up well here.

> > > And we have another two weeks to release, so ample amount of
> > > time until Paolo picks up the PR.

> > Sure, but we do also have the holidays and also the fact that it's a
> > build failure in a configuration used by some of the CIs means that
> > we've got a bunch of testing that simply hasn't been happening for a
> > couple of weeks now.

> Given that most of the KVM tests are usually more broken than
> the kernel itself, I'm not losing much sleep over it.

That's suprising to me, other than this release it doesn't match my
experiences too well - there is a bit of glitchiness in one of the
dirty_log tests on some platforms but otherwise the KVM selftests are
generally rather stable on the systems where I pay attention to the
results.  They're certainly not a testsuite I expect to have to
frequently worry about - we might wish for more coverage but that's
something different to brokenness.

The build issues during this release cycle have been a bit of an
exception.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [GIT PULL] KVM/arm64 fixes for 6.7, part #2

[Paolo Bonzini]

On Mon, Dec 18, 2023 at 8:17 PM Oliver Upton <oliver.upton@linux.dev> wrote:
>
> Hi Paolo,
>
> Here's the second batch of fixes for 6.7. Please note that this pull
> is based on -rc4 instead of my first fixes tag as the KVM selftests
> breakage was introduced by one of my changes that went through the
> perf tree.
>
> Please pull.

Pulled, thanks.

Paolo

>
> --
> Thanks,
> Oliver
>
> The following changes since commit 33cc938e65a98f1d29d0a18403dbbee050dcad9a:
>
>   Linux 6.7-rc4 (2023-12-03 18:52:56 +0900)
>
> are available in the Git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-6.7-2
>
> for you to fetch changes up to 0c12e6c8267f831e491ee64ac6f216601cea3eee:
>
>   KVM: selftests: Ensure sysreg-defs.h is generated at the expected path (2023-12-12 16:49:43 +0000)
>
> ----------------------------------------------------------------
> KVM/arm64 fixes for 6.7, part #2
>
>  - Ensure a vCPU's redistributor is unregistered from the MMIO bus
>    if vCPU creation fails
>
>  - Fix building KVM selftests for arm64 from the top-level Makefile
>
> ----------------------------------------------------------------
> Marc Zyngier (5):
>       KVM: arm64: vgic: Simplify kvm_vgic_destroy()
>       KVM: arm64: vgic: Add a non-locking primitive for kvm_vgic_vcpu_destroy()
>       KVM: arm64: vgic: Force vcpu vgic teardown on vcpu destroy
>       KVM: arm64: vgic: Ensure that slots_lock is held in vgic_register_all_redist_iodevs()
>       KVM: Convert comment into an assertion in kvm_io_bus_register_dev()
>
> Oliver Upton (1):
>       KVM: selftests: Ensure sysreg-defs.h is generated at the expected path
>
>  arch/arm64/kvm/arm.c                 |  2 +-
>  arch/arm64/kvm/vgic/vgic-init.c      | 47 ++++++++++++++++++++++--------------
>  arch/arm64/kvm/vgic/vgic-mmio-v3.c   |  4 ++-
>  arch/arm64/kvm/vgic/vgic.h           |  1 +
>  tools/testing/selftests/kvm/Makefile | 26 ++++++++++++--------
>  virt/kvm/kvm_main.c                  |  3 ++-
>  6 files changed, 52 insertions(+), 31 deletions(-)
>

Re: [GIT PULL] KVM/arm64 fixes for 6.7, part #2

[Paolo Bonzini]

On Fri, Dec 22, 2023 at 3:21 PM Mark Brown <broonie@kernel.org> wrote:
> > > I see it's not, I'm asking if it should be - given the latencies
> > > involved it seems like it'd be helpful for keeping -next working.
>
> > This is on purpose. We use -next for, well, the next release,
> > and not as a band-aid for some other purpose. If you think things
>
> Note that -next includes pending-fixes which is specifically for the
> purpose of getting coverage for fixes intended to go to mainline (indeed
> this issue was found and reported before the original problematic patch
> was sent to mainline, it's not clear to me what went wrong there).

Indeed most other KVM architectures have a tree included in
linux-next's pending-fixes and kvm/master is included in there.

Knowing that KVM/ARM does not have a fixes tree included in linux-next
might make me get those in kvm/master a bit faster, but then I'd let
them stay in kvm/master, for a day or two of soaking in linux-next.
It's never happened to me to send broken or conflicting pull requests
after -rc1, as far as I remember, and it's indeed unlikely, but
linux-next does provide a little bit of peace of mind.

> He is on CC here.  I'm not sure that it's specifically things not
> getting merged (well, modulo this one fixing an issue in mainline) -

I'm indeed not exactly a speed demon, but in this case I specifically
wanted to make sure to include everything posted before Christmas, as
this was likely going to be the last PR in the release.

I also wouldn't have minded a review or tested-by for
https://www.spinics.net/lists/kvm/msg335755.html :) but in the end I
included it in the pull request anyway.

Paolo