From: Cornelia Huck <cohuck@redhat.com>
To: Janosch Frank <frankja@linux.ibm.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:45:57 +0100 [thread overview]
Message-ID: <20191128174557.2e421e94.cohuck@redhat.com> (raw)
In-Reply-To: <da848181-41a3-0738-84f8-258046965671@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3660 bytes --]
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
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").
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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-11-28 19:23 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 [this message]
2019-11-28 16:54 ` Janosch Frank
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=20191128174557.2e421e94.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=david@redhat.com \
--cc=frankja@linux.ibm.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).