Re: [PATCH v2 0/2] Dirtying, failing memop: don't indicate suppression

[Christian Borntraeger]

Am 25.04.22 um 19:29 schrieb Janis Schoetterl-Glausch:
> On 4/25/22 18:30, Christian Borntraeger wrote:
> > Am 25.04.22 um 12:01 schrieb Janis Schoetterl-Glausch:
> > > If a memop fails due to key checked protection, after already having
> > > written to the guest, don't indicate suppression to the guest, as that
> > > would imply that memory wasn't modified.
> > >
> > > This could be considered a fix to the code introducing storage key
> > > support, however this is a bug in KVM only if we emulate an
> > > instructions writing to an operand spanning multiple pages, which I
> > > don't believe we do.
> >
> > Thanks applied. I think it makes sense for 5.18 nevertheless.
>
> Janosch had some concerns because the protection code being 000 implies
> that the effective address in the TEID is unpredictable.
> Let's see if he chimes in.

z/VM does exactly the same on key protection crossing a page boundary. The
architecture was written in a way to allow all zeros exactly for this case.
(hypervisor emulation of key protection crossing pages).
This is even true for ESOP-2. See Figure 3-5 or figure 3-8 (the first line)
which allows to NOT have a valid address in the TEID for key controlled
protection.

The only question is, do we need to change the suppression parameter in
access_guest_with_key

 (mode != GACC_STORE) || (idx == 0)

to also check for prot != PROT_TYPE_KEYC
? I think we do not need this as we have checked other reasons before.