Received-SPF: pass (google.com: domain of linux-kernel+bounces-73344-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Tue, 20 Feb 2024 17:21:52 +0100
From: David Woodhouse <dwmw2@infradead.org>
To: Sean Christopherson <seanjc@google.com>, paul@xen.org
CC: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>,
 Christian Borntraeger <borntraeger@linux.ibm.com>,
 Janosch Frank <frankja@linux.ibm.com>,
 Claudio Imbrenda <imbrenda@linux.ibm.com>,
 David Hildenbrand <david@redhat.com>, Heiko Carstens <hca@linux.ibm.com>,
 Vasily Gorbik <gor@linux.ibm.com>,
 Alexander Gordeev <agordeev@linux.ibm.com>,
 Sven Schnelle <svens@linux.ibm.com>, Thomas Gleixner <tglx@linutronix.de>,
 Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
 Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
 "H. Peter Anvin" <hpa@zytor.com>, Shuah Khan <shuah@kernel.org>,
 kvm@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
 linux-s390@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_v13_00/21=5D_KVM=3A_xen=3A_upda?= =?US-ASCII?Q?te_shared=5Finfo_and_vcpu=5Finfo_handling?=
User-Agent: K-9 Mail for Android
In-Reply-To: <ZdTQCuWor4ipxW6E@google.com>
References: <20240215152916.1158-1-paul@xen.org> <170838297541.2281798.7838961694439257911.b4-ty@google.com> <05973da0-f68c-4c84-8806-bdba92f2ed6e@xen.org> <ZdTQCuWor4ipxW6E@google.com>
Message-ID: <CFFFCD77-3B9E-4808-B084-E86F8EF265A7@infradead.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 20 February 2024 17:15:06 CET, Sean Christopherson <seanjc@google=2Ecom>=
 wrote:
>On Tue, Feb 20, 2024, Paul Durrant wrote:
>> On 20/02/2024 15:55, Sean Christopherson wrote:
>> > On Thu, 15 Feb 2024 15:28:55 +0000, Paul Durrant wrote:
>> > > From: Paul Durrant <pdurrant@amazon=2Ecom>
>> > >=20
>> > > This series contains a new patch from Sean added since v12 [1]:
>> > >=20
>> > > * KVM: s390: Refactor kvm_is_error_gpa() into kvm_is_gpa_in_memslot=
()
>> > >=20
>> > > This frees up the function name kvm_is_error_gpa() such that it can=
 then be
>> > > re-defined in:
>> > >=20
>> > > [=2E=2E=2E]
>> >=20
>> > *sigh*
>> >=20
>> > I forgot to hit "send" on this yesterday=2E  But lucky for me, that w=
orked out in
>> > my favor as I needed to rebase on top of kvm/kvm-uapi to avoid pointl=
ess conflicts
>> > in the uapi headeres=2E
>> >=20
>> > So=2E=2E=2E=2E
>> >=20
>> > Applied to kvm-x86 xen, minus 18 and 19 (trylock stuff) and 21 (locki=
ng cleanup
>> > that we're doing elsewhere)=2E
>> >=20
>>=20
>> Looks like you meant 17 & 18?
>
>Doh, yes=2E
>
>> > Paul and David, please take (another) look at the end result to make =
sure you don't
>> > object to any of my tweaks and that I didn't botch anything=2E
>> >=20
>>=20
>> What was the issue with 17? It was reasonable clean-up and I'd like to =
keep
>> it even without 18 being applied (and I totally understand your reasons=
 for
>> that)=2E
>
>I omitted it purely to avoid creating an unnecessary dependency for the t=
rylock
>patch=2E  That way the trylock patch (or whatever it morphs into) can be =
applied on
>any branch (along with the cleanup), i=2Ee=2E doesn't need to be taken th=
rough kvm-x86/xen=2E

What about if (in_atomic() && read_trylock()) return -EAGAIN; else read_lo=
ck();

That way we don't have any even theoretical fairness issues because the tr=
ylock can fail just *once* which kicks us to the slow path and that'll take=
 the lock normally now=2E

The condition might not actually be in_atomic() but I'm not working this w=
eek and you get the idea=2E