[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aN7HxBgFwm2B7Cv3@google.com>
Date: Thu, 2 Oct 2025 11:43:16 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Ackerley Tng <ackerleytng@...gle.com>
Cc: kvm@...r.kernel.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
x86@...nel.org, linux-fsdevel@...r.kernel.org, aik@....com,
ajones@...tanamicro.com, akpm@...ux-foundation.org, amoorthy@...gle.com,
anthony.yznaga@...cle.com, anup@...infault.org, aou@...s.berkeley.edu,
bfoster@...hat.com, binbin.wu@...ux.intel.com, brauner@...nel.org,
catalin.marinas@....com, chao.p.peng@...el.com, chenhuacai@...nel.org,
dave.hansen@...el.com, david@...hat.com, dmatlack@...gle.com,
dwmw@...zon.co.uk, erdemaktas@...gle.com, fan.du@...el.com, fvdl@...gle.com,
graf@...zon.com, haibo1.xu@...el.com, hch@...radead.org, hughd@...gle.com,
ira.weiny@...el.com, isaku.yamahata@...el.com, jack@...e.cz,
james.morse@....com, jarkko@...nel.org, jgg@...pe.ca, jgowans@...zon.com,
jhubbard@...dia.com, jroedel@...e.de, jthoughton@...gle.com,
jun.miao@...el.com, kai.huang@...el.com, keirf@...gle.com,
kent.overstreet@...ux.dev, kirill.shutemov@...el.com, liam.merwick@...cle.com,
maciej.wieczor-retman@...el.com, mail@...iej.szmigiero.name, maz@...nel.org,
mic@...ikod.net, michael.roth@....com, mpe@...erman.id.au,
muchun.song@...ux.dev, nikunj@....com, nsaenz@...zon.es,
oliver.upton@...ux.dev, palmer@...belt.com, pankaj.gupta@....com,
paul.walmsley@...ive.com, pbonzini@...hat.com, pdurrant@...zon.co.uk,
peterx@...hat.com, pgonda@...gle.com, pvorel@...e.cz, qperret@...gle.com,
quic_cvanscha@...cinc.com, quic_eberman@...cinc.com,
quic_mnalajal@...cinc.com, quic_pderrin@...cinc.com, quic_pheragu@...cinc.com,
quic_svaddagi@...cinc.com, quic_tsoni@...cinc.com, richard.weiyang@...il.com,
rick.p.edgecombe@...el.com, rientjes@...gle.com, roypat@...zon.co.uk,
rppt@...nel.org, shuah@...nel.org, steven.price@....com,
steven.sistare@...cle.com, suzuki.poulose@....com, tabba@...gle.com,
thomas.lendacky@....com, usama.arif@...edance.com, vannapurve@...gle.com,
vbabka@...e.cz, viro@...iv.linux.org.uk, vkuznets@...hat.com,
wei.w.wang@...el.com, will@...nel.org, willy@...radead.org,
xiaoyao.li@...el.com, yan.y.zhao@...el.com, yilun.xu@...el.com,
yuzenghui@...wei.com, zhiquan1.li@...el.com
Subject: Re: [RFC PATCH v2 11/51] KVM: selftests: Allow cleanup of ucall_pool
from host
On Wed, May 14, 2025, Ackerley Tng wrote:
> Many selftests use GUEST_DONE() to signal the end of guest code, which
> is handled in userspace. In most tests, the test exits and there is no
> need to clean up the ucall_pool->in_use bitmap.
>
> If there are many guest code functions using GUEST_DONE(), or of guest
> code functions are run many times, the ucall_pool->in_use bitmap will
> fill up, causing later runs of the same guest code function to fail.
>
> This patch allows ucall_free() to be called from userspace on uc.hva,
> which will unset and free the correct struct ucall in the pool,
> allowing ucalls to continue being used.
NAK.
The ucall thing isn't an issue with GUEST_DONE(), it's a general issue with not
completing a ucall. The simple answer here is to not abuse GUEST_xxx().
I tried doing the same thing (jumping back to a guest's entry point) in what is
now the mmu_stress_test, and it didn't end well. Restoring just registers mostly
works on x86, but it's not foolproof even there. And on other architectures, the
approach is even less viable (IIRC). E.g. if the guest code touches *anything*
that's not saved/restore, the test is hosed.
In short, while clever, the approach just doesn't work. Which is why I don't want
ucall_free() to exist: it's only useful for a pattern that is deeply flawed.
The easiest alternative is to use GUEST_SYNC(), have the guest code loop, and
use global variables to pass data. It's ugly, but it works and is much less likely
to have arch specific quirks. The worst of the ugliness can be mitigated by
using a struct to pass info, e.g. so that you only have to do one "sync global"
call.
Powered by blists - more mailing lists