From: Claudio Imbrenda <imbrenda@linux.ibm.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
linux-s390@vger.kernel.org, frankja@linux.ibm.com,
david@kernel.org, seiden@linux.ibm.com, nrb@linux.ibm.com,
schlameuss@linux.ibm.com, gra@linux.ibm.com
Subject: Re: [PATCH v2 3/5] KVM: s390: vsie: Fix unshadowing logic
Date: Tue, 19 May 2026 13:40:25 +0200 [thread overview]
Message-ID: <20260519134025.54bd501e@p-imbrenda> (raw)
In-Reply-To: <15cb5a1f-4342-4d24-81ca-9397f3f83288@de.ibm.com>
On Mon, 18 May 2026 13:28:44 +0200
Christian Borntraeger <borntraeger@de.ibm.com> wrote:
> Am 12.05.26 um 19:52 schrieb Claudio Imbrenda:
> > In some cases (i.e. under extreme memory pressure on the host),
> > attempting to shadow memory will result in the same memory being
> > unshadowed, causing a loop.
> >
> > Add a PGSTE bit to distinguish between shadowed memory and shadowed DAT
> > tables, fix the unshadowing logic in _gmap_ptep_xchg() to prevent
> > unnecessary unshadowing and perform better checks.
> >
> > Also fix the unshadowing logic in _gmap_crstep_xchg_atomic() which did
> > not unshadow properly when the large page would become unprotected.
> >
> > Opportunistilcally add a check in gmap_protect_rmap() to make sure it
> ^
> Opportunistically
oops
>
> [...]
> > +static inline bool pte_needs_unshadow(union pte oldpte, union pte newpte, union pgste pgste)
> > +{
> > + if (!pgste.vsie_notif)
> > + return false;
> > + if (pgste.vsie_gmem)
> > + return (oldpte.h.p != newpte.h.p) || newpte.h.i;
> > + return !newpte.h.p || !newpte.s.pr;
> > +}
> > +
>
> The newpte.s.pr part is new and seems not related to the vsie_gmem change
> but I cannot find anything about this in the patch description. And I dont
it's part of "fix unshadowing logic"
> understand this part. So either some explanation here, in the patch description or
> a comment maybe?
I think a comment explaining what's going on is the best option
>
> > static inline union pgste _gmap_ptep_xchg(struct gmap *gmap, union pte *ptep, union pte newpte,
> > union pgste pgste, gfn_t gfn, bool needs_lock)
> > {
> > @@ -180,8 +189,9 @@ static inline union pgste _gmap_ptep_xchg(struct gmap *gmap, union pte *ptep, un
> > pgste.prefix_notif = 0;
> > gmap_unmap_prefix(gmap, gfn, gfn + 1);
> > }
> > - if (pgste.vsie_notif && (ptep->h.p != newpte.h.p || newpte.h.i)) {
> > + if (pte_needs_unshadow(*ptep, newpte, pgste)) {
> > pgste.vsie_notif = 0;
> > + pgste.vsie_gmem = 0;
> > if (needs_lock)
> > gmap_handle_vsie_unshadow_event(gmap, gfn);
> > else
> [...]
next prev parent reply other threads:[~2026-05-19 11:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-12 17:52 [PATCH v2 0/5] KVM: s390: some vSIE and UCONTROL fixes Claudio Imbrenda
2026-05-12 17:52 ` [PATCH v2 1/5] KVM: s390: vsie: Fix memory leak when unshadowing Claudio Imbrenda
2026-05-13 7:50 ` Christian Borntraeger
2026-05-12 17:52 ` [PATCH v2 2/5] KVM: s390: Fix leaking kvm_s390_mmu_cache in case of errors Claudio Imbrenda
2026-05-13 7:56 ` Christian Borntraeger
2026-05-12 17:52 ` [PATCH v2 3/5] KVM: s390: vsie: Fix unshadowing logic Claudio Imbrenda
2026-05-18 11:28 ` Christian Borntraeger
2026-05-19 11:40 ` Claudio Imbrenda [this message]
2026-05-12 17:52 ` [PATCH v2 4/5] KVM: s390: vsie: Fix redundant rmap entries Claudio Imbrenda
2026-05-18 11:54 ` Christian Borntraeger
2026-05-12 17:52 ` [PATCH v2 5/5] KVM: s390: Properly reset zero bit in PGSTE Claudio Imbrenda
2026-05-15 11:51 ` Steffen Eiden
2026-05-18 11:44 ` Christian Borntraeger
2026-05-19 11:38 ` Claudio Imbrenda
2026-05-19 11:57 ` Christian Borntraeger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260519134025.54bd501e@p-imbrenda \
--to=imbrenda@linux.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=david@kernel.org \
--cc=frankja@linux.ibm.com \
--cc=gra@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=nrb@linux.ibm.com \
--cc=schlameuss@linux.ibm.com \
--cc=seiden@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox