From: Janosch Frank <frankja@linux.ibm.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: Thomas Huth <thuth@redhat.com>,
pmorel@linux.ibm.com, david@redhat.com, qemu-devel@nongnu.org,
borntraeger@de.ibm.com, qemu-s390x@nongnu.org,
mihajlov@linux.ibm.com
Subject: Re: [PATCH 08/15] s390x: protvirt: KVM intercept changes
Date: Thu, 28 Nov 2019 17:54:21 +0100 [thread overview]
Message-ID: <ebe14d58-f7c7-bf97-e547-92a44c99d5f3@linux.ibm.com> (raw)
In-Reply-To: <20191128174557.2e421e94.cohuck@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 4314 bytes --]
On 11/28/19 5:45 PM, Cornelia Huck wrote:
> On Thu, 28 Nov 2019 17:38:19 +0100
> Janosch Frank <frankja@linux.ibm.com> wrote:
>
>> On 11/21/19 4:11 PM, Thomas Huth wrote:
>>> On 20/11/2019 12.43, Janosch Frank wrote:
>>>> Secure guests no longer intercept with code 4 for an instruction
>>>> interception. Instead they have codes 104 and 108 for secure
>>>> instruction interception and secure instruction notification
>>>> respectively.
>>>>
>>>> The 104 mirrors the 4, but the 108 is a notification, that something
>>>> happened and the hypervisor might need to adjust its tracking data to
>>>> that fact. An example for that is the set prefix notification
>>>> interception, where KVM only reads the new prefix, but does not update
>>>> the prefix in the state description.
>>>>
>>>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>>>> ---
>>>> target/s390x/kvm.c | 6 ++++++
>>>> 1 file changed, 6 insertions(+)
>>>>
>>>> diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
>>>> index 418154ccfe..58251c0229 100644
>>>> --- a/target/s390x/kvm.c
>>>> +++ b/target/s390x/kvm.c
>>>> @@ -115,6 +115,8 @@
>>>> #define ICPT_CPU_STOP 0x28
>>>> #define ICPT_OPEREXC 0x2c
>>>> #define ICPT_IO 0x40
>>>> +#define ICPT_PV_INSTR 0x68
>>>> +#define ICPT_PV_INSTR_NOT 0x6c
>>>>
>>>> #define NR_LOCAL_IRQS 32
>>>> /*
>>>> @@ -151,6 +153,7 @@ static int cap_s390_irq;
>>>> static int cap_ri;
>>>> static int cap_gs;
>>>> static int cap_hpage_1m;
>>>> +static int cap_protvirt;
>>>>
>>>> static int active_cmma;
>>>>
>>>> @@ -336,6 +339,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
>>>> cap_async_pf = kvm_check_extension(s, KVM_CAP_ASYNC_PF);
>>>> cap_mem_op = kvm_check_extension(s, KVM_CAP_S390_MEM_OP);
>>>> cap_s390_irq = kvm_check_extension(s, KVM_CAP_S390_INJECT_IRQ);
>>>> + cap_protvirt = kvm_check_extension(s, KVM_CAP_S390_PROTECTED);
>>>>
>>>> if (!kvm_check_extension(s, KVM_CAP_S390_GMAP)
>>>> || !kvm_check_extension(s, KVM_CAP_S390_COW)) {
>>>> @@ -1664,6 +1668,8 @@ static int handle_intercept(S390CPU *cpu)
>>>> (long)cs->kvm_run->psw_addr);
>>>> switch (icpt_code) {
>>>> case ICPT_INSTRUCTION:
>>>> + case ICPT_PV_INSTR:
>>>> + case ICPT_PV_INSTR_NOT:
>>>> r = handle_instruction(cpu, run);
>>>
>>> Even if this works by default, my gut feeling tells me that it would be
>>> safer and cleaner to have a separate handler for this...
>>> Otherwise we might get surprising results if future machine generations
>>> intercept/notify for more or different instructions, I guess?
>>>
>>> However, it's just a gut feeling ... I really don't have much experience
>>> with this PV stuff yet ... what do the others here think?
>>>
>>> Thomas
>>
>>
>> Adding a handle_instruction_pv doesn't hurt me too much.
>> The default case can then do an error_report() and exit(1);
>>
>> PV was designed in a way that we can re-use as much code as possible, so
>> I tried using the normal instruction handlers and only change as little
>> as possible in the instructions themselves.
>
> I think we could argue that handling 4 and 104 in the same function
> makes sense; but the 108 notification should really be separate, I
In my latest answer to Thomas I stated that we could move to a separate
pv instruction handler. I just had another look and rediscovered, that
it would mean a lot more changes. I would need to duplicate the ipa/b
parsing and for diagnose even the base+disp parsing.
So yes, I'd like to treat the 104 like the 4 intercept...
> think. From what I've seen, the expectation of what the hypervisor
> needs to do is just something else in this case ("hey, I did something;
> just to let you know").
We can remove the notification from QEMU, as far is I know, we moved the
instruction that used this path to a 104 code.
>
> Is the set of instructions you get a 104 for always supposed to be a
> subset of the instructions you get a 4 for? I'd expect it to be so.
>
Yes
I'll ask if we'll get a new code for instructions that are only valid in
PV mode; currently there are none.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-11-28 20:37 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-20 11:43 [PATCH 00/15] s390x: Protected Virtualization support Janosch Frank
2019-11-20 11:43 ` [PATCH 01/15] s390x: Cleanup cpu resets Janosch Frank
2019-11-21 11:10 ` Cornelia Huck
2019-11-21 11:32 ` Janosch Frank
2019-11-21 12:18 ` Cornelia Huck
2019-11-21 12:53 ` Thomas Huth
2019-11-21 13:11 ` Janosch Frank
2019-11-21 13:17 ` Thomas Huth
2019-11-20 11:43 ` [PATCH 02/15] s390x: Beautify diag308 handling Janosch Frank
2019-11-21 11:17 ` Cornelia Huck
2019-11-21 11:27 ` Janosch Frank
2019-11-21 11:21 ` David Hildenbrand
2019-11-21 11:28 ` Janosch Frank
2019-11-21 13:12 ` Thomas Huth
2019-11-21 13:20 ` Thomas Huth
2019-11-21 13:53 ` Janosch Frank
2019-11-20 11:43 ` [PATCH 03/15] s390x: protvirt: Add diag308 subcodes 8 - 10 Janosch Frank
2019-11-21 12:47 ` Cornelia Huck
2019-11-21 14:36 ` Thomas Huth
2020-02-07 7:56 ` Janosch Frank
2019-11-20 11:43 ` [PATCH 04/15] Header sync protvirt Janosch Frank
2019-11-21 12:59 ` Cornelia Huck
2019-11-21 13:12 ` Janosch Frank
2019-11-21 13:17 ` Cornelia Huck
2019-11-20 11:43 ` [PATCH 05/15] s390x: protvirt: Sync PV state Janosch Frank
2019-11-21 13:25 ` Cornelia Huck
2019-11-21 13:43 ` Janosch Frank
2019-11-21 14:43 ` Thomas Huth
2019-11-20 11:43 ` [PATCH 06/15] s390x: protvirt: Support unpack facility Janosch Frank
2019-11-20 13:43 ` Cornelia Huck
2019-11-21 11:33 ` Janosch Frank
2019-11-21 11:27 ` David Hildenbrand
2019-11-21 14:25 ` Janosch Frank
2019-11-21 14:28 ` David Hildenbrand
2019-11-21 14:31 ` Christian Borntraeger
2019-11-21 14:32 ` Janosch Frank
2019-11-22 13:39 ` Cornelia Huck
2019-11-22 13:49 ` Janosch Frank
2019-11-28 14:07 ` Thomas Huth
2019-11-28 14:20 ` Janosch Frank
2019-11-20 11:43 ` [PATCH 07/15] s390x: protvirt: Handle diag 308 subcodes 0,1,3,4 Janosch Frank
2019-11-21 13:50 ` Cornelia Huck
2019-11-21 14:00 ` Janosch Frank
2019-11-21 14:04 ` Janosch Frank
2019-11-21 14:17 ` Cornelia Huck
2019-11-21 14:23 ` Janosch Frank
2019-11-20 11:43 ` [PATCH 08/15] s390x: protvirt: KVM intercept changes Janosch Frank
2019-11-21 14:07 ` Cornelia Huck
2019-11-21 14:29 ` Janosch Frank
2019-11-21 15:11 ` Thomas Huth
2019-11-28 16:38 ` Janosch Frank
2019-11-28 16:45 ` Cornelia Huck
2019-11-28 16:54 ` Janosch Frank [this message]
2019-11-20 11:43 ` [PATCH 09/15] s390x: protvirt: SCLP interpretation Janosch Frank
2019-11-21 14:11 ` Cornelia Huck
2019-11-21 14:24 ` Janosch Frank
2019-11-22 13:48 ` Pierre Morel
2019-11-20 11:43 ` [PATCH 10/15] s390x: protvirt: Add new VCPU reset functions Janosch Frank
2019-11-20 11:43 ` [PATCH 11/15] RFC: s390x: Exit on vcpu reset error Janosch Frank
2019-11-21 12:14 ` David Hildenbrand
2019-11-21 12:19 ` Janosch Frank
2019-11-21 12:22 ` David Hildenbrand
2019-11-20 11:43 ` [PATCH 12/15] s390x: protvirt: Set guest IPL PSW Janosch Frank
2019-11-28 14:30 ` Thomas Huth
2019-11-28 15:39 ` Janosch Frank
2019-11-20 11:43 ` [PATCH 13/15] s390x: protvirt: Move diag 308 data over SIDAD Janosch Frank
2019-11-28 14:40 ` Thomas Huth
2019-11-28 16:08 ` Janosch Frank
2019-11-28 16:14 ` David Hildenbrand
2019-11-20 11:43 ` [PATCH 14/15] s390x: protvirt: Disable address checks for PV guest IO emulation Janosch Frank
2019-11-28 15:28 ` Thomas Huth
2019-11-28 15:36 ` Janosch Frank
2019-11-28 16:10 ` Janosch Frank
2019-11-28 16:18 ` Cornelia Huck
2019-11-28 16:24 ` Janosch Frank
2019-11-28 20:08 ` Thomas Huth
2019-11-20 11:43 ` [PATCH 15/15] s390x: protvirt: Handle SIGP store status correctly Janosch Frank
2019-11-21 11:24 ` David Hildenbrand
2019-11-21 11:29 ` Janosch Frank
2019-11-28 15:30 ` Thomas Huth
2019-11-20 13:26 ` [PATCH 00/15] s390x: Protected Virtualization support Cornelia Huck
2019-11-20 13:33 ` Janosch Frank
2019-11-21 9:13 ` Janosch Frank
2019-11-21 9:39 ` Cornelia Huck
2019-11-29 11:08 ` Daniel P. Berrangé
2019-11-29 12:14 ` Janosch Frank
2019-11-29 12:35 ` Daniel P. Berrangé
2019-11-29 14:02 ` Janosch Frank
2019-11-29 14:30 ` Viktor Mihajlovski
2019-12-03 10:49 ` Daniel P. Berrangé
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=ebe14d58-f7c7-bf97-e547-92a44c99d5f3@linux.ibm.com \
--to=frankja@linux.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=mihajlov@linux.ibm.com \
--cc=pmorel@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=thuth@redhat.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;
as well as URLs for NNTP newsgroup(s).