hw/s390x/sclp.c | 18 +++++++++++++ include/hw/s390x/sclp.h | 2 ++ target/s390x/kvm.c | 56 ++++++++++++++++++++++++++++++++++++++++- 3 files changed, 75 insertions(+), 1 deletion(-)
A new proposition: I think it would be wise to fork directly from handle_instruction instead to accept per default all instructions with with secure instruction interception code. Just in case future firmware with older QEMU. How ever I let three dors open. 1) This patch accepts the all B2 instructions, mostly I/O. Some of the instructions will not work correctly for PV until patched. This should be fixed, and will be, in a separate patch. 2) The same is true for DIAG instructions. 3) Secure notifications are separated from secure instructions and normal instructions interception because this case is completely new. For B2 instructions we do not have to do anything this just informative. However, one information is of interrest, a notification that SIGP(STOP) is sent to stop the CPUs and terminate QEMU. Pierre Morel (1): s390x: protvirt: SCLP interpretation hw/s390x/sclp.c | 18 +++++++++++++ include/hw/s390x/sclp.h | 2 ++ target/s390x/kvm.c | 56 ++++++++++++++++++++++++++++++++++++++++- 3 files changed, 75 insertions(+), 1 deletion(-) -- 2.17.0
On 11/28/19 11:13 AM, Pierre Morel wrote: > A new proposition: > I think it would be wise to fork directly from handle_instruction > instead to accept per default all instructions with with secure > instruction interception code. > Just in case future firmware with older QEMU. > > How ever I let three dors open. > > 1) This patch accepts the all B2 instructions, mostly I/O. > Some of the instructions will not work correctly for PV until patched. > This should be fixed, and will be, in a separate patch. > > 2) The same is true for DIAG instructions. > > 3) Secure notifications are separated from secure instructions and > normal instructions interception because this case is completely new. > For B2 instructions we do not have to do anything this just informative. > However, one information is of interrest, a notification that > SIGP(STOP) is sent to stop the CPUs and terminate QEMU. Pierre, I told you this morning that I don't want this and that you should leave this untouched until I can explain my thoughts behind the initial patch in a f2f. Thomas' review of your change only confirmed my concerns about this patch. This is the wrong patch at the wrong time, which creates noise and work for other people. Please stop and work on something else. > > > > Pierre Morel (1): > s390x: protvirt: SCLP interpretation > > hw/s390x/sclp.c | 18 +++++++++++++ > include/hw/s390x/sclp.h | 2 ++ > target/s390x/kvm.c | 56 ++++++++++++++++++++++++++++++++++++++++- > 3 files changed, 75 insertions(+), 1 deletion(-) >
On 2019-11-28 13:28, Janosch Frank wrote: > On 11/28/19 11:13 AM, Pierre Morel wrote: >> A new proposition: >> I think it would be wise to fork directly from handle_instruction >> instead to accept per default all instructions with with secure >> instruction interception code. >> Just in case future firmware with older QEMU. >> >> How ever I let three dors open. >> >> 1) This patch accepts the all B2 instructions, mostly I/O. >> Some of the instructions will not work correctly for PV until patched. >> This should be fixed, and will be, in a separate patch. >> >> 2) The same is true for DIAG instructions. >> >> 3) Secure notifications are separated from secure instructions and >> normal instructions interception because this case is completely new. >> For B2 instructions we do not have to do anything this just informative. >> However, one information is of interrest, a notification that >> SIGP(STOP) is sent to stop the CPUs and terminate QEMU. > Pierre, I told you this morning that I don't want this and that you > should leave this untouched until I can explain my thoughts behind the > initial patch in a f2f. > Thomas' review of your change only confirmed my concerns about this patch. > > This is the wrong patch at the wrong time, which creates noise and work > for other people. Please stop and work on something else. !? - you sent to me info on slack that I did not see until now, next time be sure I have acknowledged if it is important. - You told me to dive into this patch quite abruptly, and it invested time to understand how the I/O works with PV, so sorry for the wrong time - I see no problem with the questions from Thomas, may be you can explain this to me - I have a lot of other things to do so I just close this thread after having answered to Thomas. > > > >> >> >> Pierre Morel (1): >> s390x: protvirt: SCLP interpretation >> >> hw/s390x/sclp.c | 18 +++++++++++++ >> include/hw/s390x/sclp.h | 2 ++ >> target/s390x/kvm.c | 56 ++++++++++++++++++++++++++++++++++++++++- >> 3 files changed, 75 insertions(+), 1 deletion(-) >> > -- Pierre Morel IBM Lab Boeblingen
Patchew URL: https://patchew.org/QEMU/1574935984-16910-1-git-send-email-pmorel@linux.ibm.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [PATCH v1 0/1] s390x: protvirt: SCLP interpretation
Type: series
Message-id: 1574935984-16910-1-git-send-email-pmorel@linux.ibm.com
=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===
Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
cc42cdc s390x: protvirt: SCLP interpretation
=== OUTPUT BEGIN ===
ERROR: switch and case should be at the same indent
#135: FILE: target/s390x/kvm.c:1715:
switch (icpt_code) {
+ case ICPT_PV_INSTR_NOT:
[...]
+ case ICPT_PV_INSTR:
total: 1 errors, 0 warnings, 105 lines checked
Commit cc42cdc36171 (s390x: protvirt: SCLP interpretation) has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===
Test command exited with code: 1
The full log is available at
http://patchew.org/logs/1574935984-16910-1-git-send-email-pmorel@linux.ibm.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com
© 2016 - 2024 Red Hat, Inc.