[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Zs3pnCj6wUWD2K-8@google.com>
Date: Tue, 27 Aug 2024 07:58:36 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Ilias Stamatis <ilstam@...zon.co.uk>
Cc: "pbonzini@...hat.com" <pbonzini@...hat.com>, "maz@...nel.org" <maz@...nel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "anup@...infault.org" <anup@...infault.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"oliver.upton@...ux.dev" <oliver.upton@...ux.dev>, "paul@....org" <paul@....org>
Subject: Re: [PATCH 1/2] KVM: selftests: Add a test for coalesced MMIO (and
PIO on x86)
On Tue, Aug 27, 2024, Ilias Stamatis wrote:
> On Fri, 2024-08-23 at 12:13 -0700, Sean Christopherson wrote:
> > Add a test to verify that KVM correctly exits (or not) when a vCPU's
> > coalesced I/O ring is full (or isn't). Iterate over all legal starting
> > points in the ring (with an empty ring), and verify that KVM doesn't exit
> > until the ring is full.
> >
> > Opportunistically verify that KVM exits immediately on non-coalesced I/O,
> > either because the MMIO/PIO region was never registered, or because a
> > previous region was unregistered.
> >
> > This is a regression test for a KVM bug where KVM would prematurely exit
> > due to bad math resulting in a false positive if the first entry in the
> > ring was before the halfway mark. See commit 92f6d4130497 ("KVM: Fix
> > coalesced_mmio_has_room() to avoid premature userspace exit").
> >
> > Enable the test for x86, arm64, and risc-v, i.e. all architectures except
> > s390, which doesn't have MMIO.
> >
> > On x86, which has both MMIO and PIO, interleave MMIO and PIO into the same
> > ring, as KVM shouldn't exit until a non-coalesced I/O is encountered,
> > regardless of whether the ring is filled with MMIO, PIO, or both.
>
> I guess there is some overlap between this patch and the one I proposed
> here:
> https://lore.kernel.org/kvm/20240820133333.1724191-7-ilstam@amazon.com/
/facepalm
> Even though my test depends on the new ioctls that the series
> introduces. However, both the existing v1 API and the new proposed v2
> API take the same code path internally when trying to push to the ring
> buffer.
Sorry, I completely spaced on the fact that you had already written a selftest.
I'll take a closer look at your selftest and see how best to smush the two
together.
Powered by blists - more mailing lists