On 5/21/25 8:37 AM, Thomas Huth wrote:
> On 09/05/2025 00.50, Zhuoying Cai wrote:
>> Add documentation for secure IPL.
>>
>> Signed-off-by: Collin Walling
>> Signed-off-by: Zhuoying Cai
>> ---
>> docs/system/s390x/secure-ipl.rst | 249 +
On 4/8/25 11:55 AM, Zhuoying Cai wrote:
> Enable secure IPL in audit mode, which performs signature verification,
> but any error does not terminate the boot process. Only warnings will be
> logged to the console instead.
>
> Add a comp_len variable to store the length of a segment in
> zipl_load_
On 4/11/25 9:57 AM, Thomas Huth wrote:
> On 08/04/2025 17.55, Zhuoying Cai wrote:
>> DIAG 320 subcode 1 provides information needed to determine
>> the amount of storage to store one or more certificates.
>>
>> The subcode value is denoted by setting the left-most bit
>> of an 8-byte field.
>>
>> T
On 4/8/25 11:55 AM, Zhuoying Cai wrote:
> Introduce Secure-IPL (SIPL) facility.
>
> Use the abbreviation CBL (Consolidated-Boot-Loader facility at bit 0 of
> byte 136) to represent bytes 136 and 137 for IPL device facilities of the
> SCLP Read Info block.
This should *not* be used to label these
On 4/8/25 11:55 AM, Zhuoying Cai wrote:
> If secure boot in audit mode or True Secure IPL mode is enabled without
> specifying a boot device, the boot process will terminate with an error.
>
> Signed-off-by: Zhuoying Cai
> ---
> hw/s390x/ipl.c | 10 ++
> 1 file changed, 10 insertions(+)
On 4/8/25 11:55 AM, Zhuoying Cai wrote:
> DIAG 320 subcode 2 provides certificates that are in the
> certificate store.
>
> The subcode value is denoted by setting the second-left-most bit
> of an 8-byte field.
>
> The verification-certificate-block (VCB) contains the output data
> when the opera
On 4/11/25 9:43 AM, Thomas Huth wrote:
> On 08/04/2025 17.55, Zhuoying Cai wrote:
>> From: Collin Walling
> ...
>> Signed-off-by: Zhuoying Cai
>
> So the patch is from Collin, but S-o-b only by you? Looks weird, this should
> either have an additional S-o-b by Co
On 4/11/25 10:38 AM, Thomas Huth wrote:
> On 08/04/2025 17.55, Zhuoying Cai wrote:
>> From: Collin Walling
>>
>> DIAG 508 subcode 2 performs signature-verfication on signed components.
>> A signed component may be a Linux kernel image, or any other signed
>> bi
7;if': { 'any': [ 'TARGET_S390X',
>>> 'TARGET_I386',
>>> 'TARGET_ARM',
>>>
>>>
>>> Should do the trick, right?
>>
>> Yes. Break the line before 'if
On 7/29/24 10:36 AM, Markus Armbruster wrote:
> David Hildenbrand writes:
>
> The simplest way to address 4 is to tack 'if': 'TARGET_S390X' to
> @deprecated-props.
>
diff --git a/qapi/machine-target.json b/qapi/machine-target.json
index 09dec2b9bb..0be95d559c 100644
>>>
On 7/26/24 5:16 PM, David Hildenbrand wrote:
> On 26.07.24 22:36, Collin Walling wrote:
>> The @deprecated-props array did not make any sense to be a member of the
>> CpuModelInfo struct, since this field would only be populated by a
>> query-cpu-model-expansion response
://lists.gnu.org/archive/html/qemu-devel/2024-07/msg05996.html
- commit eed0e8ffa38f0695c0519508f6e4f5a3297cbd67
Signed-off-by: Collin Walling
---
@David, the previous commit header did not align with the changes made
here, so I tagged this as a "v1" but added the previous convers
On 7/26/24 4:03 PM, David Hildenbrand wrote:
> On 26.07.24 22:00, Collin Walling wrote:
>> On 7/26/24 3:57 PM, David Hildenbrand wrote:
>>> On 25.07.24 20:39, Collin Walling wrote:
>>>> Currently, there is no way to execute the query-cpu-model-expansion
>>&g
On 7/26/24 3:57 PM, David Hildenbrand wrote:
> On 25.07.24 20:39, Collin Walling wrote:
>> Currently, there is no way to execute the query-cpu-model-expansion
>> command to retrieve a comprehenisve list of deprecated properties, as
>> the result is dependent per-model
On 7/26/24 3:15 AM, Markus Armbruster wrote:
> Collin Walling writes:
>
>> On 7/25/24 3:39 AM, David Hildenbrand wrote:
>>> On 25.07.24 09:35, Markus Armbruster wrote:
>>>> Markus Armbruster writes:
>
> [...]
>
>>>>> Ar
of deprecated properties.
Additionally, the @deprecated-props array has been moved from the
CpuModelInfo struct to the CpuModelExpansionInfo struct, since the data
did not belong in the former.
Acked-by: David Hildenbrand
Suggested-by: Jiri Denemark
Signed-off-by: Collin Walling
---
Changelog:
v
On 7/25/24 3:39 AM, David Hildenbrand wrote:
> On 25.07.24 09:35, Markus Armbruster wrote:
>> Markus Armbruster writes:
>>
>>> Collin Walling writes:
>>>
>>>> On 7/24/24 3:56 AM, Markus Armbruster wrote:
>>>>> Collin Walling writes:
On 7/24/24 3:56 AM, Markus Armbruster wrote:
> Collin Walling writes:
>
>> On 7/20/24 1:33 AM, Markus Armbruster wrote:
>>> Collin Walling writes:
>>>
>>>> Currently, there is no way to execute the query-cpu-model-expansion
>>>> command to
On 7/23/24 5:23 AM, Thomas Huth wrote:
> On 22/07/2024 16.50, Collin Walling wrote:
>> On 7/20/24 1:33 AM, Markus Armbruster wrote:
>>> Collin Walling writes:
>>>
>>>> Currently, there is no way to execute the query-cpu-model-expansion
>>>> com
On 7/20/24 1:33 AM, Markus Armbruster wrote:
> Collin Walling writes:
>
>> Currently, there is no way to execute the query-cpu-model-expansion
>> command to retrieve a comprehenisve list of deprecated properties, as
>> the result is dependent per-model. To enable this, th
that
were never otherwise introduced for certain models.
Acked-by: David Hildenbrand
Suggested-by: Jiri Denemark
Signed-off-by: Collin Walling
---
Changelog:
v3
- Removed the 'note' and cleaned up documentation
- Revised commit message
v2
- Changed commit message
On 7/19/24 7:11 AM, Markus Armbruster wrote:
> Thomas Huth writes:
>
>> On 18/07/2024 20.22, Collin Walling wrote:
>>> On 7/18/24 9:39 AM, Markus Armbruster wrote:
>>>> Collin Walling writes:
>>>>
>>>>> As s390 CPU models progress and
On 7/19/24 6:16 AM, Thomas Huth wrote:
> On 18/07/2024 20.22, Collin Walling wrote:
>> On 7/18/24 9:39 AM, Markus Armbruster wrote:
>>> Collin Walling writes:
>>>
>>>> As s390 CPU models progress and deprecated properties are dropped
>>>> out
On 7/18/24 9:39 AM, Markus Armbruster wrote:
> Collin Walling writes:
>
>> As s390 CPU models progress and deprecated properties are dropped
>> outright, it will be cumbersome for management apps to query the host
>> for a comprehensive list of deprecated propert
the entire list of deprecated
properties regardless if they are supported on the model.
Suggested-by: Jiri Denemark
Signed-off-by: Collin Walling
---
Changelog:
v2
- Changed commit message
- Added documentation reflecting this change
- Made code changes that more accurately
On 7/12/24 1:23 AM, Markus Armbruster wrote:
> Collin Walling writes:
>
>> It is beneficial to provide an interface to retrieve *all* deprecated
>> features in one go. Management applications will need this information
>> to determine which features need to be disabled r
On 7/11/24 5:10 PM, David Hildenbrand wrote:
> On 11.07.24 22:32, Collin Walling wrote:
>> It is beneficial to provide an interface to retrieve *all* deprecated
>> features in one go. Management applications will need this information
>> to determine which features need to b
ing a static
expansion. All deperecated features are reported on a full expansion.
Suggested-by: Jiri Denemark
Signed-off-by: Collin Walling
---
target/s390x/cpu_models_sysemu.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/target/s390x/cpu_models_sysemu.c b/t
[...]
Thanks everyone! The RFC for the analogous libvirt patches have been
posted under the subject:
[RFC PATCH 0/1] support deprecated-props from query-cpu-model-expansion
Any and all feedback is welcome.
--
Regards,
Collin
[...]
Thank you all for the valuable feedback. Since the QEMU interface seems
stable, I will rework my libvirt (not upstream) and post as an RFC.
--
Regards,
Collin
Changelog
v4
- updated cover letter to show example output
- deprecated features are now a subset of the full CPU model's
list of features
- value:
1. no longer listing the deprecated features for CPU
models that nev
Add the CONSTRAINT_TRANSACTIONAL_EXE (cte) and TRANSACTIONAL_EXE (te)
to the list of deprecated features.
Signed-off-by: Collin Walling
---
target/s390x/cpu_features.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
index
ey": false,
"vxpdeh2": false
}
}
}
}
It is recommended that s390 guests operate with these features
explicitly disabled to ensure compatability with future hardware.
Signed-off-by: Collin Walling
---
qapi/machine-target.json |
On 4/26/24 13:35, Collin Walling wrote:
> On 4/26/24 04:42, Markus Armbruster wrote:
>> Collin Walling writes:
>>
>>> Retain a list of deprecated features disjoint from any particular
>>> CPU model. A query-cpu-model-expansion reply will now provide a list of
&g
On 4/26/24 13:45, David Hildenbrand wrote:
> On 26.04.24 19:44, David Hildenbrand wrote:
>> On 24.04.24 23:56, Collin Walling wrote:
>>> Retain a list of deprecated features disjoint from any particular
>>> CPU model. A query-cpu-model-expansion reply will now provide a
On 4/26/24 04:42, Markus Armbruster wrote:
> Collin Walling writes:
>
>> Retain a list of deprecated features disjoint from any particular
>> CPU model. A query-cpu-model-expansion reply will now provide a list of
>> properties (i.e. features) that are flagge
On 4/25/24 02:31, Markus Armbruster wrote:
> Collin Walling writes:
>
>> On 4/24/24 02:19, Markus Armbruster wrote:
>>> Collin Walling writes:
>>>
>>>> This optional parameter for query-cpu-model-expansion enables CPU
>>>> model fea
On 4/25/24 04:10, David Hildenbrand wrote:
> On 24.04.24 20:33, Collin Walling wrote:
>> On 4/24/24 03:24, David Hildenbrand wrote:
>>> On 23.04.24 23:06, Collin Walling wrote:
>>>> Retain a list of deprecated features disjoint from any particular
>>>> C
On 4/25/24 09:35, Daniel P. Berrangé wrote:
> On Wed, Apr 24, 2024 at 03:12:42PM -0400, Collin Walling wrote:
>> On 4/24/24 13:51, Collin Walling wrote:
>>> On 4/24/24 04:20, Daniel P. Berrangé wrote:
>>>> On Tue, Apr 23, 2024 at 05:06:53PM -0400, Collin Wall
Add the CONSTRAINT_TRANSACTIONAL_EXE (cte) and TRANSACTIONAL_EXE (te)
to the list of deprecated features.
Signed-off-by: Collin Walling
---
target/s390x/cpu_features.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
index
ey": false,
"vxpdeh2": false
}
}
}
}
It is recommended that s390 guests operate with these features
explicitly disabled to ensure compatability with future hardware.
Signed-off-by: Collin Walling
---
qapi/machine-target.json
On 4/24/24 17:56, Collin Walling wrote:
>
> Check patch #2 description for an example output.
>
I meant patch #1, sorry. Forgot I dropped a patch in this series.
--
Regards,
Collin
Previous version here (different subject line):
https://mail.gnu.org/archive/html/qemu-devel/2024-04/msg03200.html
Changelog
v3
- removed optional disable-deprecated-feats argument
- added deprecated-props array to CpuModelInfo struct
- amended cover letter language t
On 4/24/24 13:51, Collin Walling wrote:
> On 4/24/24 04:20, Daniel P. Berrangé wrote:
>> On Tue, Apr 23, 2024 at 05:06:53PM -0400, Collin Walling wrote:
>>> This optional parameter for query-cpu-model-expansion enables CPU
>>> model features flagged as deprecated
On 4/24/24 03:24, David Hildenbrand wrote:
> On 23.04.24 23:06, Collin Walling wrote:
>> Retain a list of deprecated features disjoint from any particular
>> CPU model. When a query-cpu-model-expansion is provided with the
>> "disable-deprecated-feats" option set
On 4/24/24 04:20, Daniel P. Berrangé wrote:
> On Tue, Apr 23, 2024 at 05:06:53PM -0400, Collin Walling wrote:
>> This optional parameter for query-cpu-model-expansion enables CPU
>> model features flagged as deprecated to appear in the resulting
>> list of properties.
>&
On 4/24/24 02:19, Markus Armbruster wrote:
> Collin Walling writes:
>
>> This optional parameter for query-cpu-model-expansion enables CPU
>> model features flagged as deprecated to appear in the resulting
>> list of properties.
>>
>> This commit does not add
uot;bpb": false, "csske": false, ...}
It is recommended that s390 guests operate with these features
explicitly disabled to ensure compatability with future hardware.
Signed-off-by: Collin Walling
---
target/s390x/cpu_features.c | 14 ++
target/s390x/cpu_featur
Add the CONSTRAINT_TRANSACTIONAL_EXE (cte) and TRANSACTIONAL_EXE (te)
to the list of deprecated features.
Signed-off-by: Collin Walling
---
target/s390x/cpu_features.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
index
The current implementation of query-cpu-model-expansion is lacking a way to
conditionally retrieve CPU models with properties (i.e. features) that are
flagged as deprecated set to disabled. To remedy this, a new optional boolean
"disable-deprecated-feats" argument has been added to the query.
Here
this option is not supported.
Signed-off-by: Collin Walling
---
qapi/machine-target.json | 7 ++-
target/arm/arm-qmp-cmds.c| 7 +++
target/i386/cpu-sysemu.c | 7 +++
target/s390x/cpu_models_sysemu.c | 7 +++
4 files changed, 27 insertions(+), 1 deletion
On 9/12/23 02:57, David Hildenbrand wrote:
> On 11.09.23 22:52, Collin Walling wrote:
>
> Patch subject is wrong (should contain "static-recommended")
>
>> Newer S390 machines may drop support for features completely, rendering
>> guests operating with older
Add the CONSTRAINT_TRANSACTIONAL_EXE (cte) and TRANSACTIONAL_EXE (te)
under the list of deprecated features.
Signed-off-by: Collin Walling
---
target/s390x/cpu_features.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
index
ned within QEMU, and a new "static-recommended" CPU model expansion
type has been created to allow a query of the host-model with deprecated
features explicitly disabled.
Signed-off-by: Collin Walling
---
qapi/machine-target.json | 8 +++-
target/s390x/cpu_
On 11/23/21 01:14, Christian Borntraeger wrote:
>
> Am 22.11.21 um 23:33 schrieb Collin Walling:
>> DIAGNOSE 0318 is invoked only once during IPL. As such, the
>> diag318 info will only change once initially and during resets.
>> Let's only sync the register to
On 12/2/21 04:23, Thomas Huth wrote:
> On 01/12/2021 19.45, Collin Walling wrote:
>> Polite ping. I may have missed if this patch was picked already. Thanks!
>
> I've already queued it to my s390x-next branch:
>
> https://gitlab.com/thuth/qemu/-/commits/s390x-next/
Polite ping. I may have missed if this patch was picked already. Thanks!
--
Regards,
Collin
Stay safe and stay healthy
On 11/22/21 17:33, Collin Walling wrote:
> DIAGNOSE 0318 is invoked only once during IPL. As such, the
> diag318 info will only change once initially and during resets.
> Let's only sync the register to convey the info to KVM if and
> only if the diag318 info has changed. Only
The migration handler will invoke the set_diag318 helper on
post_load to ensure the info is set on the destination machine.
Signed-off-by: Collin Walling
---
target/s390x/kvm/kvm.c | 5 -
target/s390x/machine.c | 14 ++
2 files changed, 14 insertions(+), 5 deletions(-)
diff --
On 11/17/21 02:43, Christian Borntraeger wrote:
> Am 09.11.21 um 21:56 schrieb Collin Walling:
>> The CPNC portion of the diag 318 data is erroneously reset during an
>> initial CPU reset caused by SIGP. Let's go ahead and relocate the
>> diag318_info field within the
n the configuration after the diag318 instruction
has been invoked.
The s390_machine_reset code already takes care of zeroing the diag318
data on VM resets, which also cover resets caused by diag308.
Signed-off-by: Collin Walling
Fixes: fabdada9357b ("s390: guest support for diagnose 0x318&quo
On 11/10/21 07:42, Janosch Frank wrote:
> On 11/9/21 21:56, Collin Walling wrote:
>> The CPNC portion of the diag 318 data is erroneously reset during an
>> initial CPU reset caused by SIGP. Let's go ahead and relocate the
>> diag318_info field within the CPUS390XSt
n the configuration after the diag 318 instruction
has been invoked.
Signed-off-by: Collin Walling
Fixes: fabdada9357b ("s390: guest support for diagnose 0x318")
Reported-by: Christian Borntraeger
---
Changelog:
v2
- handler uses run_on_cpu again
- reworded commit message sligh
On 11/9/21 12:01, Janosch Frank wrote:
> On 11/9/21 16:58, Collin Walling wrote:
>> On 11/9/21 05:48, Janosch Frank wrote:
>>> On 11/9/21 08:32, Christian Borntraeger wrote:
>>>>
>>>>
>>>> Am 08.11.21 um 22:13 schrieb Collin Walling:
>>&g
On 11/9/21 05:48, Janosch Frank wrote:
> On 11/9/21 08:32, Christian Borntraeger wrote:
>>
>>
>> Am 08.11.21 um 22:13 schrieb Collin Walling:
>>> The CPNC portion of the diag 318 data is erroneously reset during an
>>> initial CPU reset caused b
n the configuration after the diag 318 instruction
has been invoked.
Additionally, the diag 318 data reset is handled via the CPU reset
code during a clear reset. This means some of the diag 318-specific
reset code can now be removed.
Signed-off-by: Collin Walling
Fixes: fabdada9357b ("s390: gue
On 11/8/21 12:40, Christian Borntraeger wrote:
>
>
> Am 08.11.21 um 18:02 schrieb Janosch Frank:
>> On 11/5/21 23:46, Collin Walling wrote:
>>> The CPNC portion of the diag 318 data is erroneously reset during an
>>> initial CPU reset caused by SIGP
On 11/8/21 12:02, Janosch Frank wrote:
> On 11/5/21 23:46, Collin Walling wrote:
>> The CPNC portion of the diag 318 data is erroneously reset during an
>> initial CPU reset caused by SIGP. Let's go ahead and relocate the
>> diag318_info field within the CPUS390XSt
On 11/8/21 03:07, Christian Borntraeger wrote:
>
>
> Am 05.11.21 um 23:46 schrieb Collin Walling:
>> The CPNC portion of the diag 318 data is erroneously reset during an
>> initial CPU reset caused by SIGP. Let's go ahead and relocate the
>> diag318_info field
On 11/5/21 18:46, Collin Walling wrote:
> The CPNC portion of the diag 318 data is erroneously reset during an
> initial CPU reset caused by SIGP. Let's go ahead and relocate the
> diag318_info field within the CPUS390XState struct such that it is
> only zeroed during a clear res
n the configuration after the diag 318 instruction
has been invoked by the kernel.
Additionally, the diag 318 data reset is handled via the CPU reset
code. The set_diag318 code can be merged into the handler function
and the helper functions can consequently be removed.
Signed-off-by: Collin Walling
--
On 11/16/20 7:12 AM, Cornelia Huck wrote:
> On Fri, 13 Nov 2020 17:10:22 -0500
> Collin Walling wrote:
>
> [please remember to put qemu-devel on cc: as well]
>
>> The Control Program Name Code (CPNC) portion of the diag318
>> info must be set within the SI
, 7 deletions(-)
>
Thanks for correcting this. You've certainly received plenty of reviews
and ack's, but since this touches code I worked on:
Reviewed-by: Collin Walling
--
Regards,
Collin
Stay safe and stay healthy
On 9/16/20 1:15 PM, Collin Walling wrote:
> On 9/16/20 11:53 AM, Cornelia Huck wrote:
>
> [...]
>
>>>
>>
>> Thanks, applied.
>>
>>
>
> Thanks Conny.
>
> Much appreciated for everyone's patience and review. The only thing I'd
&
On 9/16/20 11:53 AM, Cornelia Huck wrote:
[...]
>>
>
> Thanks, applied.
>
>
Thanks Conny.
Much appreciated for everyone's patience and review. The only thing I'd
like to hold out on for now is for someone to take a peek at patch #3
with respect to the protected virtualization stuff. I don't
On 9/16/20 3:10 AM, Thomas Huth wrote:
> On 15/09/2020 21.44, Collin Walling wrote:
>> Rework the SCLP boundary check to account for different SCLP commands
>> (eventually) allowing different boundary sizes.
>>
>> Signed-off-by: Collin Walling
>> Acked-by: Janosc
On 9/16/20 11:52 AM, Cornelia Huck wrote:
> On Tue, 15 Sep 2020 15:44:15 -0400
> Collin Walling wrote:
>
>> Signed-off-by: Collin Walling
>> ---
>> linux-headers/asm-s390/kvm.h | 7 +--
>> linux-headers/linux/kvm.h| 1 +
>> 2 files changed, 6
ilable CPU entries after migration (such as during re-ipl).
Signed-off-by: Collin Walling
Acked-by: Cornelia Huck
Reviewed-by: Thomas Huth
---
hw/s390x/sclp.c | 43 +
include/hw/s390x/sclp.h | 1 +
target/s390x/cpu_features_def.
Signed-off-by: Collin Walling
---
linux-headers/asm-s390/kvm.h | 7 +--
linux-headers/linux/kvm.h| 1 +
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/linux-headers/asm-s390/kvm.h b/linux-headers/asm-s390/kvm.h
index 0138ccb0d8..f053b8304a 100644
--- a/linux-headers/asm
Rework the SCLP boundary check to account for different SCLP commands
(eventually) allowing different boundary sizes.
Signed-off-by: Collin Walling
Acked-by: Janosch Frank
Reviewed-by: Cornelia Huck
---
hw/s390x/sclp.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion
n inside a macro.
Fixes: 832be0d8a3bb ("s390x: sclp: Report insufficient SCCB length")
Signed-off-by: Collin Walling
Reviewed-by: Janosch Frank
Reviewed-by: David Hildenbrand
Reviewed-by: Cornelia Huck
Reviewed-by: Thomas Huth
---
hw/s390x/sclp.c | 26 ++
away.
Read CPU Info is unlikely to ever change, so let's not bother
accounting for the offset there.
Signed-off-by: Collin Walling
Reviewed-by: Thomas Huth
Reviewed-by: Cornelia Huck
---
hw/s390x/sclp.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/hw/s390x/scl
Functions within read scp/cpu info will need access to the machine
state. Let's make a call to retrieve the machine state once and
pass the appropriate data to the respective functions.
Signed-off-by: Collin Walling
Reviewed-by: David Hildenbrand
Reviewed-by: Thomas Huth
Reviewed-by: Ja
an extended-length SCCB.
This feature is not supported in protected virtualization mode.
Signed-off-by: Collin Walling
Acked-by: Janosch Frank
---
hw/s390x/sclp.c | 5
include/hw/s390x/sclp.h | 8 ++
target/s390x/cpu.h | 2 ++
target
Changelog:
v6
• sccb_verify_boundary function:
• s/len/sccb_len
• removed the endian check/conversion of the sccb_len from within
this function (caller is now responsible)
• proper endian conversion when using header length to malloc
• use g_autofree f
SCCB length is sufficent to store a full response and that
the length does not cross any explicitly-set boundaries.
Signed-off-by: Collin Walling
---
hw/s390x/event-facility.c | 2 +-
hw/s390x/sclp.c | 55 ++-
include/hw/s390x/sclp.h | 2 +-
3
On 9/11/20 11:08 AM, Thomas Huth wrote:
> On 10/09/2020 11.36, Collin Walling wrote:
>> DIAGNOSE 0x318 (diag318) is an s390 instruction that allows the storage
>> of diagnostic information that is collected by the firmware in the case
>> of hardware/firmware service events.
&
On 9/12/20 2:28 AM, Thomas Huth wrote:
> On 11/09/2020 20.16, Collin Walling wrote:
>> On 9/10/20 1:56 PM, Collin Walling wrote:
>>> On 9/10/20 1:50 PM, Thomas Huth wrote:
>>>> On 10/09/2020 11.36, Collin Walling wrote:
>>>>> The header contained wi
On 9/10/20 1:56 PM, Collin Walling wrote:
> On 9/10/20 1:50 PM, Thomas Huth wrote:
>> On 10/09/2020 11.36, Collin Walling wrote:
>>> The header contained within the SCCB passed to the SCLP service call
>>> contains the actual length of the SCCB. Instead of allocating a
On 9/11/20 9:54 AM, Thomas Huth wrote:
> On 11/09/2020 15.41, Thomas Huth wrote:
>> On 10/09/2020 11.36, Collin Walling wrote:
>>> As more features and facilities are added to the Read SCP Info (RSCPI)
>>> response, more space is required to store them. The space
On 9/11/20 6:24 AM, Cornelia Huck wrote:
> On Thu, 10 Sep 2020 19:45:01 +0200
> Thomas Huth wrote:
>
>> On 10/09/2020 11.36, Collin Walling wrote:
>>> Rework the SCLP boundary check to account for different SCLP commands
>>> (eventually) allowing different boun
On 9/10/20 1:50 PM, Thomas Huth wrote:
> On 10/09/2020 11.36, Collin Walling wrote:
>> The header contained within the SCCB passed to the SCLP service call
>> contains the actual length of the SCCB. Instead of allocating a static
>> 4K size for the work sccb, let's
an extended-length SCCB.
This feature is not supported in protected virtualization mode.
Signed-off-by: Collin Walling
Acked-by: Janosch Frank
---
hw/s390x/sclp.c | 5 +
include/hw/s390x/sclp.h | 3 +++
target/s390x/cpu.h | 2 ++
target
ilable CPU entries after migration (such as during re-ipl).
Signed-off-by: Collin Walling
---
hw/s390x/sclp.c | 43 +
include/hw/s390x/sclp.h | 1 +
target/s390x/cpu_features_def.h.inc | 1 +
target/s390x/gen-features.c | 1
n inside a macro.
Fixes: 832be0d8a3bb ("s390x: sclp: Report insufficient SCCB length")
Signed-off-by: Collin Walling
Reviewed-by: Janosch Frank
Reviewed-by: David Hildenbrand
Reviewed-by: Cornelia Huck
Reviewed-by: Thomas Huth
---
hw/s390x/sclp.c | 26 ++
SCCB length is sufficent to store a full response and that
the length does not cross any explicitly-set boundaries.
Signed-off-by: Collin Walling
---
hw/s390x/event-facility.c | 2 +-
hw/s390x/sclp.c | 58 ++-
include/hw/s390x/sclp.h | 2 +-
3
Signed-off-by: Collin Walling
---
linux-headers/asm-s390/kvm.h | 7 +--
linux-headers/linux/kvm.h| 1 +
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/linux-headers/asm-s390/kvm.h b/linux-headers/asm-s390/kvm.h
index 0138ccb0d8..f053b8304a 100644
--- a/linux-headers/asm
Functions within read scp/cpu info will need access to the machine
state. Let's make a call to retrieve the machine state once and
pass the appropriate data to the respective functions.
Signed-off-by: Collin Walling
Reviewed-by: David Hildenbrand
Reviewed-by: Thomas Huth
Reviewed-by: Ja
Rework the SCLP boundary check to account for different SCLP commands
(eventually) allowing different boundary sizes.
Signed-off-by: Collin Walling
Acked-by: Janosch Frank
Reviewed-by: Cornelia Huck
---
hw/s390x/sclp.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion
away.
Read CPU Info is unlikely to ever change, so let's not bother
accounting for the offset there.
Signed-off-by: Collin Walling
---
hw/s390x/sclp.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c
index 12829bdd05..803fdd5ed4 1
1 - 100 of 284 matches
Mail list logo
