From: David Hildenbrand <david@redhat.com>
To: Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org, borntraeger@de.ibm.com,
frankja@linux.ibm.com, kvm@vger.kernel.org,
linux-s390@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v1 4/4] s390/kvm: VSIE: correctly handle MVPG when in VSIE
Date: Tue, 5 Jan 2021 11:17:04 +0100 [thread overview]
Message-ID: <b3dbadf7-80a9-36de-9d32-f80005ee6dcf@redhat.com> (raw)
In-Reply-To: <20210104173644.2e6c8df4@ibm-vm>
On 04.01.21 17:36, Claudio Imbrenda wrote:
> On Mon, 4 Jan 2021 17:08:15 +0100
> David Hildenbrand <david@redhat.com> wrote:
>
>> On 04.01.21 16:22, Claudio Imbrenda wrote:
>>> On Sun, 20 Dec 2020 11:13:57 +0100
>>> David Hildenbrand <david@redhat.com> wrote:
>>>
>>>> On 18.12.20 15:18, Claudio Imbrenda wrote:
>>>>> Correctly handle the MVPG instruction when issued by a VSIE guest.
>>>>>
>>>>
>>>> I remember that MVPG SIE documentation was completely crazy and
>>>> full of corner cases. :)
>>>
>>> you remember correctly
>>>
>>>> Looking at arch/s390/kvm/intercept.c:handle_mvpg_pei(), I can spot
>>>> that
>>>>
>>>> 1. "This interception can only happen for guests with DAT disabled
>>>> ..." 2. KVM does not make use of any mvpg state inside the SCB.
>>>>
>>>> Can this be observed with Linux guests?
>>>
>>> a Linux guest will typically not run with DAT disabled
>>>
>>>> Can I get some information on what information is stored at [0xc0,
>>>> 0xd) inside the SCB? I assume it's:
>>>>
>>>> 0xc0: guest physical address of source PTE
>>>> 0xc8: guest physical address of target PTE
>>>
>>> yes (plus 3 flags in the lower bits of each)
>>
>> Thanks! Do the flags tell us what the deal with the PTE was? If yes,
>> what's the meaning of the separate flags?
>>
>> I assume something like "invalid, proteced, ??"
>
> bit 61 indicates that the address is a region or segment table entry,
> when EDAT applies
> bit 62 is "protected" when the protected bit is set in the segment
> table entry (or region, if EDAT applies)
> bit 63 is set when the operand was translated with a real-space ASCE
Thanks!
> but you can check if the PTE is valid just by dereferencing the
> pointers...
The pgtable might already have been unshadowed and repurposed I think.
So for vSIE, the PTE content, therefore, is a little unreliable.
We could, of course, try using them to make a guess.
"Likely valid"
"Likely invalid"
A rerun of the vSIE will fixup any wrong guess.
>
>> I'm asking because I think we can handle this a little easier.
>
> what is your idea?
I was wondering if we can
1. avoid essentially two translations per PTE, obtaining the information
we need while tying to shadow. kvm_s390_shadow_fault() on steroids that
a) gives us the last guest pte address (tricky for segment.region table
I think ... will have to think about this)
b) the final protection
2. avoid faulting/shadowing in case we know an entry is not problematic.
E.g., no need to shadow/fault the source in case the PTE is there and
not invalid. "likely valid" case above.
The idea would be to call the new kvm_s390_shadow_fault() two times (or
only once due to our guesses) and either rerun the vsie, inject an
interrupt, or create the partial intercept.
Essentially avoiding kvm_s390_vsie_mvpg_check(). Will have to think
about this.
[...]
>>
>> arch/s390/kvm/intercept.c:handle_partial_execution() we only seem to
>> handle
>>
>> 1. MVPG
>> 2. SIGP PEI
>>
>> The latter is only relevant for external calls. IIRC, this is only
>> active with sigp interpretation - which is never active under vsie
>> (ECA_SIGPI).
>
> I think putting an explicit check is better than just a jump in the
> dark.
Agreed, but that should then be called out somewhere why the change as
done. (e.g., separate cleanup patch)
--
Thanks,
David / dhildenb
prev parent reply other threads:[~2021-01-05 10:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20201218141811.310267-1-imbrenda@linux.ibm.com>
2020-12-18 14:18 ` [PATCH v1 1/4] s390/kvm: VSIE: stop leaking host addresses Claudio Imbrenda
2020-12-20 9:44 ` David Hildenbrand
2021-01-04 13:58 ` Claudio Imbrenda
2021-01-04 15:36 ` David Hildenbrand
2021-01-19 14:23 ` Janosch Frank
2020-12-18 14:18 ` [PATCH v1 2/4] s390/kvm: extend guest_translate for MVPG interpretation Claudio Imbrenda
2021-01-19 14:59 ` Janosch Frank
2020-12-18 14:18 ` [PATCH v1 3/4] s390/kvm: add kvm_s390_vsie_mvpg_check needed for VSIE MVPG Claudio Imbrenda
2021-01-05 10:31 ` David Hildenbrand
2020-12-18 14:18 ` [PATCH v1 4/4] s390/kvm: VSIE: correctly handle MVPG when in VSIE Claudio Imbrenda
2020-12-20 10:13 ` David Hildenbrand
2021-01-04 15:22 ` Claudio Imbrenda
2021-01-04 16:08 ` David Hildenbrand
2021-01-04 16:36 ` Claudio Imbrenda
2021-01-05 10:17 ` David Hildenbrand [this message]
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=b3dbadf7-80a9-36de-9d32-f80005ee6dcf@redhat.com \
--to=david@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=frankja@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=stable@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).