equent reboots are correctly
resetting the APQNs. I also successfully tested the case direct kernel
boot -> chreipl -> disk boot.
If you want you can add
Tested-by: Viktor Mihajlovski
On 7/28/20 8:37 PM, Thomas Huth wrote:
If the user did not specify a "bootindex" property, the s390-ccw bios
tries to find a bootable device on its own. Unfortunately, it alwasy
stops at the very first device that it can find, no matter whether it's
bootable or not. That causes some weird beha
system_reset_request(SHUTDOWN_CAUSE_SUBSYSTEM_RESET);
} else {
I agree that the observable behavior is more logical this way, as the
transition to secure mode is more like to kexec (transfer control to an
in-memory kernel) than to the other IPL methods (boot from a device).
Acked-by: Viktor Mihajlovs
On 6/10/20 12:24 PM, David Hildenbrand wrote:
On 10.06.20 12:07, David Gibson wrote:
On Wed, Jun 10, 2020 at 09:22:45AM +0200, David Hildenbrand wrote:
On 10.06.20 06:31, David Gibson wrote:
On Tue, Jun 09, 2020 at 12:44:39PM -0400, Michael S. Tsirkin wrote:
On Tue, Jun 09, 2020 at 06:28:3
On 3/9/20 12:21 PM, Janosch Frank wrote:
The unpack facility provides the means to setup a protected guest. A
protected guest can not be introspected by the hypervisor or any
user/administrator of the machine it is running on.
Protected guests are encrypted at rest and need a special boot
mec
t/user supplied loadparm with the stale
value.
Signed-off-by: Halil Pasic
Fixes: 7104bae9de "hw/s390x: provide loadparm property for the machine"
Reported-by: Marc Hartmayer
Reviewed-by: Janosch Frank
Reviewed-by: Viktor Mihajlovski
Tested-by: Marc Hartmayer
---
hw/s390x/ipl.c | 21
On 11/29/19 3:02 PM, Janosch Frank wrote:
[...]
As a mgmt app I think there will be a need to be able to determine
whether a host + QEMU combo is actually able to support protected
machines. If the mgmt app is given an image and the users says it
required protected mode, then the mgmt app nee
On 9/30/19 10:45 AM, Dr. David Alan Gilbert wrote:
> * Sergio Lopez (s...@redhat.com) wrote:
>> Hi,
>>
>> Commit 137b5cb6ab565cb3781d5337591e155932b4230e (hmp: change
>> hmp_info_cpus to use query-cpus-fast) updated the "info cpus" commit to
>> make it more lightweight, but also removed the abili
Splitting out the the CCW device extraction allows reuse.
Signed-off-by: Viktor Mihajlovski
---
hw/s390x/ipl.c | 81 --
1 file changed, 51 insertions(+), 30 deletions(-)
diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c
index fdeaec3..58e33c5
parameter type to 0x02 (CCW) to prevent
this. Pre-existing Linux has looked up the IPL parameters only in
the case of FCP IPL. This means that the behavior should stay
the same even if Linux checks for the IPL type unconditionally.
Signed-off-by: Viktor Mihajlovski
---
pc-bios/s390-ccw/bootmap.c
equence
the BIOS can use the boot LUN from the IPL information block.
In case a different SCSI device has been set, the BIOS will find
and use the first available LUN.
Signed-off-by: Viktor Mihajlovski
---
hw/s390x/ipl.c | 31 +--
1 file changed, 29 insertions(+),
ously used
diag308 to store the IPL info but is changed to do so, a
user-observable change in behavior will happen.
The following patches address the issues above.
Viktor Mihajlovski (3):
s390: Refactor IPL parameter block generation
s390: Ensure IPL from SCSI works as expected
s390: D
>>> refactors info cpus output and changes output format from
>>> 'thread_id' to 'thread-id', this would break parsing
>>> of output in above layers like libvirt, test framework etc.
>>>
>>> This patch just reverts back output format
On 19.02.2018 15:57, Cornelia Huck wrote:
> On Fri, 16 Feb 2018 17:08:40 +0100
> Viktor Mihajlovski wrote:
>
>> Start the deprecation period for QAPI query-cpus (replaced by
>> query-cpus-fast) beginning with 2.12.0.
>>
>> Signed-off-by: Viktor Mihajl
qdev_prop_set_string(dev, "netboot_fw", netboot_fw);
> +}
> object_property_add_child(qdev_get_machine(), TYPE_S390_IPL,
>new, NULL);
> object_unref(new);
>
--
Regards,
Viktor Mihajlovski
something like 'exiting' or 'terminating' here, to make
clear that the situation is terminal? Sometimes errors are reported and
processing continues nonetheless.
> +exit(1);
> }
> ipl->iplb.ccw.netboot_start_addr = cpu_to_be64(ipl->start_addr);
> }
>
--
Regards,
Viktor Mihajlovski
+
> pc-bios/s390-ccw/s390-ccw.h | 10 ++
> pc-bios/s390-ccw/sclp.c | 39 ---
> pc-bios/s390-ccw/virtio.c | 2 +-
> 13 files changed, 756 insertions(+), 126 deletions(-)
> create mode 100644 pc-bios/s390-ccw/libc.c
> create mode 100644 pc-bios/s390-ccw/menu.c
>
Series looks good to me (the break nit in 13/13 notwithstanding).
--
Regards,
Viktor Mihajlovski
BM_OPTS_ZIPL;
> return;
> }
break still missing here ...
> +case S390_IPL_TYPE_QEMU_SCSI:
> break;
> default:
> error_report("boot menu is not supported for this device type.");
otherwise, LGTM
--
Regards,
Viktor Mihajlovski
bootmaps as if
a boot menu has been specified.
The following patch fixes this. Collin might want to have a say in this matter
as well.
The scsi program table was erroneously evaluated as implicit
boot menu. This patch adds a per-bootmap-type menu_is_enabled
function.
Signed-off-by: Viktor Miha
indicate that -device bootindex is needed to activate
the menu, at least for the time being.
[...]
--
Regards,
Viktor Mihajlovski
QEMU. The data is stored at location 204 (dec)
>> and can contain up to 7 32-bit words. This area is available to
>> programming in the z/Architecture Principles of Operation and
>> can thus safely be used by the firmware until the IPL has completed.
>>
>> Signed-off-by:
On 19.02.2018 21:39, Collin L. Walling wrote:
> On 02/19/2018 10:52 AM, Viktor Mihajlovski wrote:
>> On 16.02.2018 23:07, Collin L. Walling wrote:
>> [...]
>>> diff --git a/hw/s390x/ipl.h b/hw/s390x/ipl.h
>>> index 74469b1..f632c59 100644
>>> ---
t reserved2[16];
> +} __attribute__ ((packed));
> +typedef struct QemuIplParameters QemuIplParameters;
> +
> +extern QemuIplParameters qipl;
> +
> #define S390_IPL_TYPE_FCP 0x00
> #define S390_IPL_TYPE_CCW 0x02
> #define S390_IPL_TYPE_QEMU_SCSI 0xff
[...]
--
Regards,
Viktor Mihajlovski
uint8_t reserved1[3];
> +uint32_t boot_menu_timeout;
> uint64_t netboot_start_addr;
> -uint8_t reserved2[16];
> +uint8_t reserved2[12];
> } __attribute__ ((packed));
> typedef struct QemuIplParameters QemuIplParameters;
>
same here.
--
Regards,
Viktor Mihajlovski
ipl_prepare_cpu(S390CPU *cpu)
}
ipl->qipl.netboot_start_addr = cpu_to_be64(ipl->start_addr);
}
-s390_ipl_set_boot_menu(&ipl->iplb);
+s390_ipl_set_boot_menu(ipl);
s390_ipl_prepare_qipl(cpu);
}
--
Regards,
Viktor Mihajlovski
On 19.02.2018 09:50, Viktor Mihajlovski wrote:
> On 17.02.2018 09:11, Thomas Huth wrote:
> [...]
>>
>> I still think that the information should *not* be stored within the
>> IplParameterBlock to avoid that we pass it via DIAG 0x308, too.
>> If we do it like this, I
his change is to move non-standard data out of the
guest-visible IPLB to avoid compatibility problems in the future, while
still catering for features like network boot and boot menus. I have no
bias against other solutions achieving this objective. If you and
Christian think we need a new field, it's all right with me.
--
Regards,
Viktor Mihajlovski
On 16.02.2018 17:44, Collin L. Walling wrote:
> On 02/16/2018 11:36 AM, Viktor Mihajlovski wrote:
>> On 16.02.2018 17:20, Thomas Huth wrote:
>> [...]
>>>> diff --git a/hw/s390x/ipl.h b/hw/s390x/ipl.h
>>>> index cab8a97..7c3cab8 100644
>>>
ock
may not be larger than 28 bytes) in a comment block.
>> -uint8_t reserved2[16];
>> + uint8_t reserved2[14];
>> } QEMU_PACKED;
>> typedef struct QemuIplParameters QemuIplParameters;
>
> Thomas
>
--
Regards,
Viktor Mihajlovski
cpu state.
Signed-off-by: Viktor Mihajlovski
---
hmp.c | 41 +++--
monitor.c | 13 ++---
2 files changed, 17 insertions(+), 37 deletions(-)
diff --git a/hmp.c b/hmp.c
index 7870d6a..ae86bfb 100644
--- a/hmp.c
+++ b/hmp.c
@@ -360,50 +360,23 @@ void hm
Start the deprecation period for QAPI query-cpus (replaced by
query-cpus-fast) beginning with 2.12.0.
Signed-off-by: Viktor Mihajlovski
Reviewed-by: Eric Blake
---
qapi-schema.json | 4
qemu-doc.texi| 4
2 files changed, 8 insertions(+)
diff --git a/qapi-schema.json b/qapi
halted": false, "thread_id": 63115},
{"arch": "s390", "current": false,
"props": {"core-id": 1}, "cpu-state": "stopped", "CPU": 1,
"qom_path": "/machine/unattached/device[1]"
arch":"s390","cpu-state":"operating",
"qom-path":"/machine/unattached/device[0]","cpu-index":0},
{"thread-id":64302,"props":{"core-id":1},
"arch":"s390","cpu-state":&quo
of hmp info cpus_fast to match that of
info cpus. This makes it easier for clients to switch to
the fast call.
Patch 3/3:
o Same formatting change for info cpus_fast as in 2/3, only
for s390-specific cpu state.
Luiz Capitulino (1):
qmp: add query-cpus-fast
Viktor Mihajlovski (4):
needs
o Drop "halted" field as it can not be retrieved in a fast
way on most architectures
o Drop irrelevant fields such as "current", "pc" and "arch"
o Rename some fields for better clarification & proper naming
standard
Signed-off-by: Luiz C
On 16.02.2018 15:03, Eric Blake wrote:
> On 02/16/2018 06:04 AM, Viktor Mihajlovski wrote:
>> From: Luiz Capitulino
>>
>> The query-cpus command has an extremely serious side effect:
>> it always interrupts all running vCPUs so that they can run
>> ioctl calls.
available to
> programming in the z/Architecture Principles of Operation and
> can thus safely be used by the firmware until the IPL has completed.
>
> Signed-off-by: Viktor Mihajlovski
you might want to add your s-o-b here ...
[...]
--
Regards,
Viktor Mihajlovski
hat
> should have been "uint32_t" instead of "uint8_t" or "480" instead of "120" ?
>
Should probably be uint8_t[480] then to stay in style with other
reserved field definitions.
>> } __attribute__ ((packed)) ScsiMbr;
>>
>> #define ZIPL_MAGIC "zIPL"
>>
>
> Thomas
>
--
Regards,
Viktor Mihajlovski
Start the deprecation period for QAPI query-cpus (replaced by
query-cpus-fast) beginning with 2.12.0.
Signed-off-by: Viktor Mihajlovski
---
qapi-schema.json | 4
qemu-doc.texi| 4
2 files changed, 8 insertions(+)
diff --git a/qapi-schema.json b/qapi-schema.json
index e6ca63f
arch":"s390","cpu-state":"operating",
"qom-path":"/machine/unattached/device[0]","cpu-index":0},
{"thread-id":64302,"props":{"core-id":1},
"arch":"s390","cpu-state":&
s_fast to match that of
info cpus. This makes it easier for clients to switch to
the fast call.
Patch 3/3:
o Same formatting change for info cpus_fast as in 2/3, only
for s390-specific cpu state.
Luiz Capitulino (1):
qmp: add query-cpus-fast
Viktor Mihajlovski (3):
qmp: expose s3
halted": false, "thread_id": 63115},
{"arch": "s390", "current": false,
"props": {"core-id": 1}, "cpu-state": "stopped", "CPU": 1,
"qom_path": "/machine/unattached/device
t;info cpus" implementation is changed to
use the new QMP interface to avoid the side effects caused
by query-cpus. This means that only a reduced subset of cpu
information will be reported, which is acceptable as
the content of "info cpus" is not documented or guaranteed
to b
On 15.02.2018 15:53, Eric Blake wrote:
> On 02/15/2018 08:40 AM, Viktor Mihajlovski wrote:
>> On 15.02.2018 15:19, Eric Blake wrote:
>>> On 02/15/2018 04:20 AM, Viktor Mihajlovski wrote:
>>>> From: Luiz Capitulino
>>>>
>>>> The query-cpus
On 15.02.2018 15:19, Eric Blake wrote:
> On 02/15/2018 04:20 AM, Viktor Mihajlovski wrote:
>> From: Luiz Capitulino
>>
>> The query-cpus command has an extremely serious side effect:
>> it always interrupts all running vCPUs so that they can run
>> ioctl calls.
Start the deprecation period for QAPI query-cpus (replaced by
query-cpus-fast) and HMP 'info cpus' (replaced by 'info cpus_fast')
beginning with 2.12.0.
Signed-off-by: Viktor Mihajlovski
---
hmp-commands-info.hx | 4 ++--
qapi-schema.json | 4
qemu-doc.texi
needs
o Drop "halted" field as it can not retrieved in a fast
way on most architectures
o Drop irrelevant fields such as "current", "pc" and "arch"
o Rename some fields for better clarification & proper naming
standard
Signed-off-by: Luiz C
halted": false, "thread_id": 63115},
{"arch": "s390", "current": false,
"props": {"core-id": 1}, "cpu-state": "stopped", "CPU": 1,
"qom_path": "/machine/unattached/device
arch":"s390","cpu-state":"operating",
"qom-path":"/machine/unattached/device[0]","cpu-index":0},
{"thread-id":64302,"props":{"core-id":1},
"arch":"s390","cpu-state":"
match that of
info cpus. This makes it easier for clients to switch to
the fast call.
Patch 3/3:
o Same formatting change for info cpus_fast as in 2/3, only
for s390-specific cpu state.
Luiz Capitulino (1):
qmp: add query-cpus-fast
Viktor Mihajlovski (3):
qmp: expose s390-sp
he time a user has to interact with the BIOS before it starts
booting the OS.
BTW: we could have a nice ASCII art splash image (nah ... just kidding)
## # ####
# # # # # # # # #
# # # # # # #
# # # ## # #
# # # # # #
# # # # # # # # #
# ## ####
[...]
--
Regards,
Viktor Mihajlovski
On 14.02.2018 16:27, Cornelia Huck wrote:
> On Wed, 14 Feb 2018 09:15:23 -0600
> Eric Blake wrote:
>
>> On 02/14/2018 04:15 AM, Cornelia Huck wrote:
>>> On Tue, 13 Feb 2018 18:18:48 +0100
>>> Viktor Mihajlovski wrote:
>>>
>>
>>>> A
h Christian's if no v3 is required.
--
Regards,
Viktor Mihajlovski
the slow and fast variants.
A suggestion was made on the mailing list to enhance the QAPI
code generation to support two layers of unions. This would
allow to specify the common fields once and avoid the duplication
in the leaf unions.
On the other hand, the slow query-cpus should be deprecated
along wit
ch to
the fast call.
Patch 3/3:
o Same formatting change for info cpus_fast as in 2/3, only
for s390-specific cpu state.
Luiz Capitulino (1):
qmp: add query-cpus-fast
Viktor Mihajlovski (2):
qmp: expose s390-specific CPU info
qmp: add architecture specific cpu data for query-cpus-
uot;halted"
o Rename some fields for better clarification & proper naming
standard
Signed-off-by: Luiz Capitulino
Signed-off-by: Viktor Mihajlovski
---
cpus.c | 38
hmp-commands-info.hx | 14 +++
hmp.c| 14 +++
halted": false, "thread_id": 63115},
{"arch": "s390", "current": false,
"props": {"core-id": 1}, "cpu-state": "stopped", "CPU": 1,
"qom_path": "/machine/unattached/devi
t; +info->value->u.s390.cpu_state = env->cpu_state;
>> +#endif
>> if (!cur_item) {
>> head = cur_item = info;
>> } else {
>
> As you mentioned in the patch description, the duplication is a bit
> awkward. I'll let the QAPI experts judge that; otherwise, this looks
> fine to me.
>
--
Regards,
Viktor Mihajlovski
; +++ b/hmp.h
>> @@ -29,6 +29,7 @@ void hmp_info_migrate_capabilities(Monitor *mon, const
>> QDict *qdict);
>> void hmp_info_migrate_parameters(Monitor *mon, const QDict *qdict);
>> void hmp_info_migrate_cache_size(Monitor *mon, const QDict *qdict);
>> void hmp_info_cpus(Monitor *mon, const QDict *qdict);
>> +void hmp_info_cpus_fast(Monitor *mon, const QDict *qdict);
>> void hmp_info_block(Monitor *mon, const QDict *qdict);
>> void hmp_info_blockstats(Monitor *mon, const QDict *qdict);
>> void hmp_info_vnc(Monitor *mon, const QDict *qdict);
>
> For HMP:
>
> Acked-by: Dr. David Alan Gilbert
>
[...]
--
Regards,
Viktor Mihajlovski
On 12.02.2018 19:15, Luiz Capitulino wrote:
> On Mon, 12 Feb 2018 13:14:32 +0100
> Viktor Mihajlovski wrote:
>
>> -{ 'struct': 'CpuInfoFast',
>> - 'data': {'cpu-index': 'int', 'qom-path': 'str',
>>
On 13.02.2018 12:16, David Hildenbrand wrote:
> On 12.02.2018 19:03, Luiz Capitulino wrote:
>> On Mon, 12 Feb 2018 13:14:30 +0100
>> Viktor Mihajlovski wrote:
>>
>>> Presently s390x is the only architecture not exposing specific
>>> CPU information via
On 12.02.2018 16:38, Cornelia Huck wrote:
> On Mon, 12 Feb 2018 13:14:29 +0100
> Viktor Mihajlovski wrote:
>
>> This series consolidates patches around a performance issue
>> caused by the usage of QMP query-cpus.
>
> Thank you for consolidating this; it was a bit har
On 12.02.2018 16:52, Cornelia Huck wrote:
> On Mon, 12 Feb 2018 13:14:30 +0100
> Viktor Mihajlovski wrote:
>
>> Presently s390x is the only architecture not exposing specific
>> CPU information via QMP query-cpus. Upstream discussion has shown
>> that it cou
the slow and fast variants.
A suggestion was made on the mailing list to enhance the QAPI
code generation to support two layers of unions. This would
allow to specify the common fields once and avoid the duplication
in the leaf unions.
On the other hand, the slow query-cpus should be deprecated
along wit
"halted" since it can't be provided fast reliably
and is too volatile on most architectures to be really useful
o Rename some fields for better clarification & proper naming
standard
Signed-off-by: Luiz Capitulino
Signed-off-by: Viktor Mihajlovski
---
cpus.c
halted": false, "thread_id": 63115},
{"arch": "s390", "current": false,
"props": {"core-id": 1}, "cpu-state": "stopped", "CPU": 1,
"qom_path": "/machine/unattached/devi
n of field definitions from CpuInfo
to CpuInfoFast. This should be tolerable if CpuInfo is deprecated and
eventually removed.
Luiz Capitulino (1):
qmp: add query-cpus-fast
Viktor Mihajlovski (2):
qmp: expose s390-specific CPU info
qmp: add architecture specific cpu data for query-cpus-fas
-kernel
>irqchip, you are already excluding most users.
>
>
Given that nobody (including myself) sees a need for halted we can
remove it for the fast version of query-cpus without surprising anyone.
[...]
--
Regards,
Viktor Mihajlovski
On 09.02.2018 14:49, Luiz Capitulino wrote:
> On Fri, 9 Feb 2018 08:56:19 +0100
> Viktor Mihajlovski wrote:
>
>> On 08.02.2018 21:33, Eduardo Habkost wrote:
>>> On Thu, Feb 08, 2018 at 11:17:32AM -0500, Luiz Capitulino wrote:
>>> [...]
>>>> The &qu
t; 'ppc': 'CpuInfoPPC',
> 'mips': 'CpuInfoMIPS',
> 'tricore': 'CpuInfoTricore',
> 'other': 'CpuInfoOther' } }
>
> # fields that are always returned by query-cpus-fast
> { 'struct': 'FastCpuInfoBase',
> 'base': 'BothCpuInfoBase',
> 'data': { 'arch': 'CpuInfoArch' } }
>
> # return value of query-cpus-fast
> { 'union': 'FastCpuInfo',
> 'base': 'FastCpuInfoBase',
> 'discriminator': 'arch',
> 'data': { 'x86': 'CpuInfoOther',
> 's390': 'FastCpuInfoS390',
> 'sparc': 'CpuInfoOther',
> 'ppc': 'CpuInfoOther',
> 'mips': 'CpuInfoOther',
> 'tricore': 'CpuInfoOther',
> 'other': 'CpuInfoOther' } }
>
> # fields returned by both query-cpus and query-cpus-fast on s390
> { 'struct': 'FastCpuInfoS390',
> 'data': { 'fast_field': 'int' } }
>
> # fields returned by query-cpus on s390
> { 'struct': 'CpuInfoS390',
> 'base': 'FastCpuInfoS390',
> 'data': { 'slow_field': 'int' } }
>
This is not exactly pretty, but would provide the functionality (and
flexibility) I'd expect.
--
Regards,
Viktor Mihajlovski
e so sure that simply checking for
> !kvm_irqchip_in_kernel() is enough on all targets.
>
Right, the present patch effectively disables halted anyway (including
s390). So it may be cleaner to just drop it right now.
Assuming the presence of architecure-specific data, libvirt can derive a
halted state (or an equivalent thereof) from query-cpus-fast returned
information.
--
Regards,
Viktor Mihajlovski
On 08.02.2018 17:43, Viktor Mihajlovski wrote:
> Presently s390x is the only architecture not exposing specific
> CPU information via QMP query-cpus. Upstream discussion has shown
> that it could make sense to report the architecture specific CPU
> state, e.g. to detect that a CPU has
On 08.02.2018 17:22, Luiz Capitulino wrote:
> On Thu, 8 Feb 2018 16:52:28 +0100
> Viktor Mihajlovski wrote:
>
>> diff --git a/qapi-schema.json b/qapi-schema.json
>> index 12c7dc8..0b36860 100644
>> --- a/qapi-schema.json
>> +++ b/qapi-schema.json
>> @@
halted": false, "thread_id": 63115},
{"arch": "s390", "current": false,
"props": {"core-id": 1}, "cpu-state": "stopped", "CPU": 1,
"qom_path": "/machine/unattached/device[1]"
On 08.02.2018 16:30, Luiz Capitulino wrote:
> On Thu, 8 Feb 2018 16:21:26 +0100
> Cornelia Huck wrote:
>
>> On Thu, 8 Feb 2018 09:09:04 -0500
>> Luiz Capitulino wrote:
>>
>>> On Thu, 8 Feb 2018 10:48:08 +0100
>>> Viktor Mihajlovski wrote:
>>
gt; +# @CpuInfoS390:
>> +#
>> +# Additional information about a virtual S390 CPU
>> +#
>> +# @cpu_state: the CPUs state
>> +#
>> +# Since: 2.12
>> +##
>> +{ 'struct': 'CpuInfoS390', 'data': { 'cpu_state': 'CpuInfoS390State' } }
>
> Likewise for 'cpu-state'
>
--
Regards,
Viktor Mihajlovski
On 08.02.2018 08:41, Viktor Mihajlovski wrote:
> On 07.02.2018 18:50, Luiz Capitulino wrote:
>> The query-cpus command has an extremely serious side effect:
>> it always interrupt all running vCPUs so that they can run
>> ioctl calls. This can cause a huge performance de
halted": false, "thread_id": 63115},
{"arch": "s390", "current": false,
"props": {"core-id": 1}, "cpu_state": "stopped", "CPU": 1,
"qom_path": "/machine/unattached/device[1]&q
!kvm_irqchip_in_kernel();
This is definitely not true for s390. Externally observable CPU state
changes are handled by QEMU there. We may still drop halted if we add a
more appropriate arch-specific field.
> +if (info->value->has_halted) {
> +info->value->halted = cpu->halted;
> +}
[...]
--
Regards,
Viktor Mihajlovski
QEMU. The data is stored at location 204 (dec)
>> and can contain up to 7 32-bit words. This area is available to
>> programming in the z/Architecture Principles of Operation and
>> can thus safely be used by the firmware until the IPL has completed.
>
> Sounds like a good i
eturn;
> +}
> +
> +*timeout = cpu_to_be16(result);
> +}
> +}
> +
> static bool s390_gen_initial_iplb(S390IPLState *ipl)
> {
> DeviceState *dev_st;
> @@ -273,6 +322,9 @@ static bool s390_gen_initial_iplb(S390IPLState *ipl)
> if (!s390_ipl_set_loadparm(ipl->iplb.loadparm)) {
> ipl->iplb.flags |= DIAG308_FLAGS_LP_VALID;
> }
> +
> +s390_ipl_set_boot_menu(&ipl->iplb);> +
Maybe it would be safer wrt migration to move that to
s390_ipl_prepare_cpu()?
> return true;
> }
>
[...]
--
Regards,
Viktor Mihajlovski
ontent is set by QEMU/the ccw bios on every IPL, so we do not
> have to change anything for migration. Correct?
>
Hm ... this is true for the netboot start address, but I am not sure
about the boot menu parameters added in a follow on patch. I'll comment
there...
[...]
--
Regards,
Viktor Mihajlovski
>> that.)
>
> FWIW, I think it would also be good to add a sentence about the need to
> specify "bootindex" somewhere (I remember trying to use "-boot n" the
> first time I wanted to use it) ...
>
Good points, I'll add more context ... thanks for the
LINUX-like processing has to be built as
described in
[https://github.com/ibm-s390-tools/s390-tools/tree/master/netboot]. The
site also contains a script assisting in the creation of such an initial
ramdisk.
--
Mit freundlichen Grüßen/Kind Regards
Viktor Mihajlovski
IBM Deutschlan
On 11.09.2017 15:58, Thomas Huth wrote:
> On 11.09.2017 12:33, Viktor Mihajlovski wrote:
>> Setting the client architecture DHCP option to 0x001f (s390 Basic) [1]
>> allows the DHCP server to return a s390-specific bootfile if wanted.
>> DHCP servers not configured for t
/assignments/dhcpv6-parameters
Signed-off-by: Viktor Mihajlovski
---
pc-bios/s390-ccw/netboot.mak | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pc-bios/s390-ccw/netboot.mak b/pc-bios/s390-ccw/netboot.mak
index a9e1374..a25d238 100644
--- a/pc-bios/s390-ccw/netboot.mak
+++ b
100644 pc-bios/s390-ccw/libc.h
> create mode 100644 pc-bios/s390-ccw/netboot.mak
> create mode 100644 pc-bios/s390-ccw/netmain.c
> create mode 100644 pc-bios/s390-ccw/virtio-blkdev.c
> create mode 100644 pc-bios/s390-ccw/virtio-net.c
>
With the patches applied I could successfully
/netmain.c
>>> create mode 100644 pc-bios/s390-ccw/virtio-blkdev.c
>>> create mode 100644 pc-bios/s390-ccw/virtio-net.c
>>>
>>
>> Was going to apply but then I updated the slof thing but building fails. Not
>> sure yet why.
>>
>> In file inc
On 04.07.2017 13:22, Viktor Mihajlovski wrote:
> On 04.07.2017 11:35, David Hildenbrand wrote:
>>> +
>>> static void create_cpu_model_list(ObjectClass *klass, void *opaque)
>>> {
>>> -CpuDefinitionInfoList **cpu_list = opaque;
>>> +struct C
check_unavailable_features(cpu_list_data->model, sc->model,
>> + &info->unavailable_features);
>> +}
>> +object_unref(obj);
>> +}
>>
> Looks good to me and produced the expected result
z10EC-base
z9EC-base
z196.2-base
z900-base
z990
...
to
...
z10EC-base
z9EC-base
z196.2-base
z900-base
z990
...
Signed-off-by: Viktor Mihajlovski
---
v1 -> v2:
Account for model generation and GA level, not only on features.
entry = g_malloc0(sizeof(*entry));
>> entry->value = info;
>> entry->next = *cpu_list;
>> *cpu_list = entry;
>> +object_unref(obj);
>> }
>>
>> CpuDefinitionInfoList *arch_query_cpu_definitions(Error **errp)
>> {
z10EC-base
z9EC-base
z196.2-base
z900-base
z990
...
to
...
z10EC-base
z9EC-base
z196.2-base
z900-base
z990
...
Signed-off-by: Viktor Mihajlovski
---
target/s390x/cpu_models.c | 58 +++
On 30.06.2017 18:47, David Hildenbrand wrote:
> On 30.06.2017 15:25, Viktor Mihajlovski wrote:
>> The response for query-cpu-definitions didn't include the
>> unavailable-features field, which is used by libvirt to figure
>> out whether a certain cpu model is usa
d-off-by: Viktor Mihajlovski
---
target/s390x/cpu_models.c | 51 ++-
1 file changed, 46 insertions(+), 5 deletions(-)
diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index 63903c2..dc3371f 100644
--- a/target/s390x/cpu_models.c
+++ b/t
On 29.06.2017 09:58, Thomas Huth wrote:
> On 28.06.2017 17:02, Viktor Mihajlovski wrote:
>> On 28.06.2017 12:56, Thomas Huth wrote:
>>> On 28.06.2017 10:02, Thomas Huth wrote:
>>>> On 28.06.2017 09:28, Viktor Mihajlovski wrote:
>>>&g
On 28.06.2017 12:56, Thomas Huth wrote:
> On 28.06.2017 10:02, Thomas Huth wrote:
>> On 28.06.2017 09:28, Viktor Mihajlovski wrote:
>>> On 27.06.2017 23:40, Thomas Huth wrote:
>>> [...]
>>>>>> - Is it OK to require loading an .INS file first? Or does an
ent instead?
>> I don't have an opinion on whether HTTP, FTP, etc is needed, but at some
>> point in time it would definitely be cool to have IPv6 support. Not sure
>> whether SLOF has that included.
>
> Yes, IPv6 is included in this networking stack.
>
> Thomas
>
--
Mit freundlichen Grüßen/Kind Regards
Viktor Mihajlovski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
I don't have an opinion on whether HTTP, FTP, etc is needed, but at some
point in time it would definitely be cool to have IPv6 support. Not sure
whether SLOF has that included.
>
> Thomas
>
>
[...]
--
Mit freundlichen Grüßen/Kind Regards
Viktor Mihajlovski
IBM Deutschland
syslinux equivalent, and to immediately
fetch the PXELINUX config file from the TFT next server aka siaddr and
load the kernel and ramdisk specified therein.
I.e. a simulation of the PXELINUX process is done in a similar fashion
to petitboot PXE boot.
>
> It would be very good to stick to
1 - 100 of 103 matches
Mail list logo