the mailman interface with no luck so far
--
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
/Kind Regards
Viktor Mihajlovski
IBM Deutschland Research Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
this, I have no idea whether 'z900' would be a correct
choice for a CPU model or not.
--
Mit freundlichen Grüßen/Kind Regards
Viktor Mihajlovski
IBM Deutschland Research Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
ately
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 that flow, so that you don't confus
4 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 perf
ain.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 included
-by: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>
---
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/
lable_features(cpu_list_data->model, sc->model,
>> + >unavailable_features);
>> + }
>> + object_unref(obj);
>> +}
>>
> Looks good to me and produced the expected result under TCG.
>
> Feel fr
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
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
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 <mihaj...@linux.vnet.ibm.com>
---
target/s390x/c
zeof(*entry));
>> entry->value = info;
>> entry->next = *cpu_list;
>> *cpu_list = entry;
>> +object_unref(obj);
>> }
>>
>> CpuDefinitionInfoList *arch_query_cpu_definitions(Error **errp)
>> {
>> -CpuDefiniti
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 <mihaj...@linux.vnet.ibm.com>
---
v1 -> v2:
Account for model generation and
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
n 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 Research & Deve
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
/assignments/dhcpv6-parameters
Signed-off-by: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>
---
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
--
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
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 Deutschland Research
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 review.
--
M
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 17:22, Luiz Capitulino wrote:
> On Thu, 8 Feb 2018 16:52:28 +0100
> Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com> wrote:
>
>> diff --git a/qapi-schema.json b/qapi-schema.json
>> index 12c7dc8..0b36860 100644
>> --- a/qapi-schema.json
>> +++
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
el();
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
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 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
y 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
set by 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 goo
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
");
> +*timeout = 0x;
> +return;
> +}
> +
> +*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(>iplb);> +
Maybe it would be safer wrt migration to move that to
s390_ipl_prepare_cpu()?
> return true;
> }
>
[...]
--
Regards,
Viktor Mihajlovski
halted": false, "thread_id": 63115},
{"arch": "s390", "current": false,
"props": {"core-id": 1}, "cpu-state": "stopped", "CPU": 1,
"qom_path": "/machine/unattached/
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-fast
cpus.c
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 with the
"arch"
o Drop field "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 <lcapitul...@redhat.com&
re 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 12.02.2018 16:52, Cornelia Huck wrote:
> On Mon, 12 Feb 2018 13:14:30 +0100
> Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com> wrote:
>
>> Presently s390x is the only architecture not exposing specific
>> CPU information via QMP query-cpus. Upstream discussion has
On 12.02.2018 16:38, Cornelia Huck wrote:
> On Mon, 12 Feb 2018 13:14:29 +0100
> Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com> wrote:
>
>> This series consolidates patches around a performance issue
>> caused by the usage of QMP query-cpus.
>
> Thank you for
On 12.02.2018 19:15, Luiz Capitulino wrote:
> On Mon, 12 Feb 2018 13:14:32 +0100
> Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com> wrote:
>
>> -{ 'struct': 'CpuInfoFast',
>> - 'data': {'cpu-index': 'int', 'qom-path': 'str',
>> - 'thread-id': 'int',
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 <mihaj...@linux.vnet.ibm.com> wrote:
>>
>>> Presently s390x is the only architecture not exposing specific
&g
*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 <dgilb...@redhat.com>
>
[...]
--
Regards,
Viktor Mihajlovski
gt;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
tch 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-fast
cpu
uot;arch"
and "halted"
o Rename some fields for better clarification & proper naming
standard
Signed-off-by: Luiz Capitulino <lcapitul...@redhat.com>
Signed-off-by: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>
---
cpus.c | 38 ++
halted": false, "thread_id": 63115},
{"arch": "s390", "current": false,
"props": {"core-id": 1}, "cpu-state": "stopped", "CPU": 1,
"qom_path": "/machine/unattached/
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 with the
n's if no v3 is required.
--
Regards,
Viktor Mihajlovski
On 14.02.2018 16:27, Cornelia Huck wrote:
> On Wed, 14 Feb 2018 09:15:23 -0600
> Eric Blake <ebl...@redhat.com> wrote:
>
>> On 02/14/2018 04:15 AM, Cornelia Huck wrote:
>>> On Tue, 13 Feb 2018 18:18:48 +0100
>>> Viktor Mihajlovski <mihaj...@linux.vnet.i
ata': { '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
On 09.02.2018 14:49, Luiz Capitulino wrote:
> On Fri, 9 Feb 2018 08:56:19 +0100
> Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com> wrote:
>
>> On 08.02.2018 21:33, Eduardo Habkost wrote:
>>> On Thu, Feb 08, 2018 at 11:17:32AM -0500, Luiz Capitulino wrote:
>&
>> +# @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 16:30, Luiz Capitulino wrote:
> On Thu, 8 Feb 2018 16:21:26 +0100
> Cornelia Huck <coh...@redhat.com> wrote:
>
>> On Thu, 8 Feb 2018 09:09:04 -0500
>> Luiz Capitulino <lcapitul...@redhat.com> wrote:
>>
>>> On Thu, 8 Feb 2
o 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
st 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-specific CPU info
qmp: add architecture specific cpu data for query-cpus-fast
qemu-doc:
Start the deprecation period for QAPI query-cpus (replaced by
query-cpus-fast) beginning with 2.12.0.
Signed-off-by: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>
---
qapi-schema.json | 4
qemu-doc.texi| 4
2 files changed, 8 insertions(+)
diff --git a/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
struct to 512 bytes here? If so, I think that
> 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
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 <mihaj...@linux.vnet.ibm.com>
you might want to add your s-o-b here ...
[...]
--
Regards,
Viktor Mihajlovski
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":"op
or guaranteed
to be stable.
Signed-off-by: Luiz Capitulino <lcapitul...@redhat.com>
Signed-off-by: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>
Reviewed-by: Cornelia Huck <coh...@redhat.com>
Acked-by: Eric Blake <ebl...@redhat.com>
---
cpus.c | 38 +++
lients 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-specific CPU info
qmp: add architecture specific cp
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":"op
halted": false, "thread_id": 63115},
{"arch": "s390", "current": false,
"props": {"core-id": 1}, "cpu-state": "stopped", "CPU": 1,
"qom_path": "/machine/unattached/device[1
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 <mihaj...@linux.vnet.ibm.com>
---
hmp-commands-info.hx | 4 ++--
qapi-schema.json | 4
standard
Signed-off-by: Luiz Capitulino <lcapitul...@redhat.com>
Signed-off-by: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>
Reviewed-by: Cornelia Huck <coh...@redhat.com>
Acked-by: Dr. David Alan Gilbert <dgilb...@redhat.com>
Acked-by: Eric Blake <ebl...@redhat.com>
-
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 <lcapitul...@redhat.com>
>>>>
>
On 15.02.2018 15:19, Eric Blake wrote:
> On 02/15/2018 04:20 AM, Viktor Mihajlovski wrote:
>> From: Luiz Capitulino <lcapitul...@redhat.com>
>>
>> The query-cpus command has an extremely serious side effect:
>> it always interrupts all running vCPUs so that they
set by 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.
>>
>> Sign
nge the
error message to indicate that -device bootindex is needed to activate
the menu, at least for the time being.
[...]
--
Regards,
Viktor Mihajlovski
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
>>> ---
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
boot_menu_flags;
+timeout = >qipl.boot_menu_timeout;
break;
default:
error_report("boot menu is not supported for this device type.");
@@ -482,7 +482,7 @@ void s390_ipl_prepare_cpu(S390CPU *cpu)
}
ipl->qipl.netboot_start_addr = cpu_to_be64
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'm
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
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
Start the deprecation period for QAPI query-cpus (replaced by
query-cpus-fast) beginning with 2.12.0.
Signed-off-by: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>
Reviewed-by: Eric Blake <ebl...@redhat.com>
---
qapi-schema.json | 4
qemu-doc.texi| 4
2 file
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":"op
-by: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>
---
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 @
ay 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
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
>>>
standard
Signed-off-by: Luiz Capitulino <lcapitul...@redhat.com>
Signed-off-by: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>
---
cpus.c | 38 ++
qapi-schema.json | 70
2 files changed,
ll.
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):
qmp: expose s390-specific CPU info
qmp: add architecture specific cpu data for query-cpus-fast
qemu-doc: dep
On 16.02.2018 15:03, Eric Blake wrote:
> On 02/16/2018 06:04 AM, Viktor Mihajlovski wrote:
>> From: Luiz Capitulino <lcapitul...@redhat.com>
>>
>> The query-cpus command has an extremely serious side effect:
>> it always interrupts all running vCPUs so that they
t_boot_menu(S390IPLState *ipl)
> *flags |= QIPL_FLAG_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
390-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
maps 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 Mihajlovsk
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 <mihaj...@linux.vnet.ibm.com>
---
hw/s390x/ipl.c | 31 +--
1 file chang
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 <mihaj...@linux.vnet.ibm.
Splitting out the the CCW device extraction allows reuse.
Signed-off-by: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>
---
hw/s390x/ipl.c | 81 --
1 file changed, 51 insertions(+), 30 deletions(-)
diff --git a/hw/s390x/ipl.c b/hw
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: Do not pass
vnet.ibm.com>
>>>
>>> This commit 137b5cb6ab565cb3781d5337591e155932b4230e
>>> 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.
>>>
>>&g
thing 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
w", _abort))) {
> +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
On 19.02.2018 15:57, Cornelia Huck wrote:
> On Fri, 16 Feb 2018 17:08:40 +0100
> Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com> wrote:
>
>> Start the deprecation period for QAPI query-cpus (replaced by
>> query-cpus-fast) beginning with 2.12.0.
>>
>> S
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
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
r 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 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
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
1 - 100 of 103 matches
Mail list logo