On Fri, 29 Nov 2019 15:08:58 +0100
Janosch Frank wrote:
> On 11/29/19 1:40 PM, Thomas Huth wrote:
> > On 29/11/2019 10.47, Janosch Frank wrote:
> > [...]
> >> Subcodes 8-10 are not valid in protected mode, we have to do a subcode
> >> 3 and then the 8 and 10 combination for a protected reboot.
On 11/29/19 1:40 PM, Thomas Huth wrote:
> On 29/11/2019 10.47, Janosch Frank wrote:
> [...]
>> Subcodes 8-10 are not valid in protected mode, we have to do a subcode
>> 3 and then the 8 and 10 combination for a protected reboot.
>
> So if 8-10 are not valid in protected mode...
>
>> @@ -59,6 +61,
On 29/11/2019 10.47, Janosch Frank wrote:
[...]
> Subcodes 8-10 are not valid in protected mode, we have to do a subcode
> 3 and then the 8 and 10 combination for a protected reboot.
So if 8-10 are not valid in protected mode...
> @@ -59,6 +61,9 @@ int handle_diag_288(CPUS390XState *env, uint64_t
On Fri, 29 Nov 2019 12:18:56 +0100
Janosch Frank wrote:
> On 11/29/19 11:09 AM, David Hildenbrand wrote:
> >> @@ -94,6 +115,7 @@ enum s390_reset {
> >> S390_RESET_REIPL,
> >> S390_RESET_MODIFIED_CLEAR,
> >> S390_RESET_LOAD_NORMAL,
> >> +S390_RESET_PV,
> >
> > I do wonder if
On 11/29/19 11:09 AM, David Hildenbrand wrote:
> [...]
>>
>> +struct IPLBlockPVComp {
>> +uint64_t tweak_pref;
>> +uint64_t addr;
>> +uint64_t size;
>> +} QEMU_PACKED;
>
> QEMU_PACKED should not be needed.
>
>> +typedef struct IPLBlockPVComp IPLBlockPVComp;
>> +
>> +struct IPLBlock
[...]
>
> +struct IPLBlockPVComp {
> +uint64_t tweak_pref;
> +uint64_t addr;
> +uint64_t size;
> +} QEMU_PACKED;
QEMU_PACKED should not be needed.
> +typedef struct IPLBlockPVComp IPLBlockPVComp;
> +
> +struct IPLBlockPV {
> +uint8_t reserved[84];
"reserved0"
> +uint8_t
For diag308 subcodes 8 - 10 we have a new ipib of type 5. The ipib
holds the address and length of the secure execution header, as well
as a list of guest components.
Each component is a block of memory, for example kernel or initrd,
which needs to be decrypted by the Ultravisor in order to run a
