On Thu, 2025-04-10 at 17:09 +0200, Shalini Chellathurai Saroja wrote:
> Implement the Service-Call Logical Processor (SCLP) event
> type Control-Program Identification (CPI) in QEMU. This
> event is used to send CPI identifiers from the guest to the
> host. The CPI identifiers are: system type, sys
On Tue, 2022-12-13 at 16:12 +0100, Christian Borntraeger wrote:
>
> Am 13.12.22 um 14:50 schrieb Christian Borntraeger:
> >
> >
> > Am 12.12.22 um 11:01 schrieb Pierre Morel:
> > >
> > >
> > > On 12/9/22 15:45, Cédric Le Goater wrote:
> > > > On 12/8/22 10:44, Pierre Morel wrote:
> > > > > Hi,
On Tue, 2022-12-13 at 14:41 +0100, Christian Borntraeger wrote:
>
> Am 12.12.22 um 11:17 schrieb Thomas Huth:
> > On 12/12/2022 11.10, Pierre Morel wrote:
> > >
> > >
> > > On 12/12/22 10:07, Thomas Huth wrote:
> > > > On 12/12/2022 09.51, Pierre Morel wrote:
> > > > >
> > > > >
> > > > > On 1
* On Wed, 2022-12-07 at 11:00 +0100, Pierre Morel wrote:
>
> On 12/6/22 22:06, Janis Schoetterl-Glausch wrote:
> > On Tue, 2022-12-06 at 15:35 +0100, Pierre Morel wrote:
> > >
> > > On 12/6/22 14:35, Janis Schoetterl-Glausch wrote:
> > > > On Tue, 202
On Tue, 2022-12-06 at 15:35 +0100, Pierre Morel wrote:
>
> On 12/6/22 14:35, Janis Schoetterl-Glausch wrote:
> > On Tue, 2022-12-06 at 11:32 +0100, Pierre Morel wrote:
> > >
> > > On 12/6/22 10:31, Janis Schoetterl-Glausch wrote:
> > > > On Tue, 202
On Tue, 2022-12-06 at 11:32 +0100, Pierre Morel wrote:
>
> On 12/6/22 10:31, Janis Schoetterl-Glausch wrote:
> > On Tue, 2022-11-29 at 18:42 +0100, Pierre Morel wrote:
> > > We will need a Topology device to transfer the topology
> > > during migration
On Tue, 2022-11-29 at 18:42 +0100, Pierre Morel wrote:
> During a subsystem reset the Topology-Change-Report is cleared
> by the machine.
> Let's ask KVM to clear the Modified Topology Change Report (MTCR)
> bit of the SCA in the case of a subsystem reset.
^ weird space
[...]
On Tue, 2022-11-29 at 18:42 +0100, Pierre Morel wrote:
> The guest uses the STSI instruction to get information on the
> CPU topology.
>
> Let us implement the STSI instruction for the basis CPU topology
> level, level 2.
>
> Signed-off-by: Pierre Morel
> ---
> target/s390x/cpu.h | 77
On Tue, 2022-11-29 at 18:42 +0100, Pierre Morel wrote:
> We will need a Topology device to transfer the topology
> during migration and to implement machine reset.
>
> The device creation is fenced by s390_has_topology().
>
> Signed-off-by: Pierre Morel
> ---
> include/hw/s390x/cpu-topology.h
On Fri, 2022-10-28 at 11:30 +0200, Pierre Morel wrote:
>
> On 10/27/22 22:20, Janis Schoetterl-Glausch wrote:
> > On Wed, 2022-10-26 at 10:34 +0200, Pierre Morel wrote:
> > >
> > > On 10/25/22 21:58, Janis Schoetterl-Glausch wrote:
> > > > On Wed, 202
On Fri, 2022-10-28 at 12:00 +0200, Pierre Morel wrote:
>
> On 10/27/22 22:42, Janis Schoetterl-Glausch wrote:
> > On Wed, 2022-10-12 at 18:21 +0200, Pierre Morel wrote:
> > > The guest can use the STSI instruction to get a buffer filled
> > > with the CPU topology de
On Wed, 2022-10-12 at 18:21 +0200, Pierre Morel wrote:
> The guest can use the STSI instruction to get a buffer filled
> with the CPU topology description.
>
> Let us implement the STSI instruction for the basis CPU topology
> level, level 2.
>
> Signed-off-by: Pierre Morel
> ---
> include/hw/s
On Wed, 2022-10-26 at 10:34 +0200, Pierre Morel wrote:
>
> On 10/25/22 21:58, Janis Schoetterl-Glausch wrote:
> > On Wed, 2022-10-12 at 18:20 +0200, Pierre Morel wrote:
> > > In the S390x CPU topology the core_id specifies the CPU address
> > > and the position of
On Thu, 2022-10-27 at 10:05 +0200, Thomas Huth wrote:
> On 24/10/2022 21.25, Janis Schoetterl-Glausch wrote:
> > On Wed, 2022-10-12 at 18:20 +0200, Pierre Morel wrote:
> > > In the S390x CPU topology the core_id specifies the CPU address
> > > and the position of th
On Wed, 2022-10-12 at 18:20 +0200, Pierre Morel wrote:
> In the S390x CPU topology the core_id specifies the CPU address
> and the position of the core withing the topology.
>
> Let's build the topology based on the core_id.
> s390x/cpu topology: core_id sets s390x CPU topology
>
> In the S390x C
On Wed, 2022-10-19 at 17:39 +0200, Pierre Morel wrote:
>
> On 10/18/22 18:43, Cédric Le Goater wrote:
>
> > >
[...]
> > > Signed-off-by: Pierre Morel
> > > ---
> > > include/hw/s390x/cpu-topology.h | 45 +++
> > > hw/s390x/cpu-topology.c | 132 +++
On Wed, 2022-10-12 at 18:20 +0200, Pierre Morel wrote:
> In the S390x CPU topology the core_id specifies the CPU address
> and the position of the core withing the topology.
>
> Let's build the topology based on the core_id.
> s390x/cpu topology: core_id sets s390x CPU topology
>
> In the S390x C
On Wed, 2022-10-19 at 17:39 +0200, Pierre Morel wrote:
>
> On 10/18/22 18:43, Cédric Le Goater wrote:
[...]
> >
> > > diff --git a/hw/s390x/cpu-topology.c b/hw/s390x/cpu-topology.c
> > > new file mode 100644
> > > index 00..42b22a1831
> > > --- /dev/null
> > > +++ b/hw/s390x/cpu-topology.
I found this version much easier to understand than the previous one.
You could consider splitting up the series into two.
One that introduces support for STSI, PTF, migration, etc.
And a second one that adds support for the maximum-MNist facility and
drawers and books.
This would also make bisec
On Fri, 2022-09-02 at 09:55 +0200, Pierre Morel wrote:
> Add some basic examples for the definition of cpu topology
> in s390x.
>
> Signed-off-by: Pierre Morel
> ---
> docs/system/s390x/cpu_topology.rst | 88 ++
> 1 file changed, 88 insertions(+)
> create mode 100644
On Fri, 2022-09-02 at 09:55 +0200, Pierre Morel wrote:
> Add some basic examples for the definition of cpu topology
> in s390x.
>
> Signed-off-by: Pierre Morel
> ---
> docs/system/s390x/cpu_topology.rst | 88 ++
> 1 file changed, 88 insertions(+)
> create mode 100644
TOPOLOGY KVM extension.
>
> The PTF instructions with function code 0 and 1 are intercepted
> and must be emulated by the userland hypervizor.
>
> Signed-off-by: Pierre Morel
Reviewed-by: Janis Schoetterl-Glausch
See note below.
> ---
> hw/s39
On Fri, 2022-09-02 at 09:55 +0200, Pierre Morel wrote:
> The migration can only take place if both source and destination
> of the migration both use or both do not use the CPU topology
> facility.
>
> We indicate a change in topology during migration postload for the
> case the topology changed b
instance?
And you're doing that because that's just the order in which QEMU does
things? So the machine class is inited before the cpu model?
I wonder if there is a nice way to create the S390Topology only if the
feature is selected.
Anyway:
Reviewed-by: Janis Schoetterl-Glausch
> +
On Fri, 2022-09-02 at 09:55 +0200, Pierre Morel wrote:
> The guest can ask for a topology report on drawer's or book's
> level.
> Let's implement the STSI instruction's handling for the corresponding
> selector values.
>
> Signed-off-by: Pierre Morel
> ---
> hw/s390x/cpu-topology.c | 19
On Fri, 2022-09-02 at 09:55 +0200, Pierre Morel wrote:
> The guest can use the STSI instruction to get a buffer filled
> with the CPU topology description.
>
> Let us implement the STSI instruction for the basis CPU topology
> level, level 2.
>
> Signed-off-by: Pierre Morel
> ---
> hw/s390x/cpu
On Fri, 2022-09-02 at 09:55 +0200, Pierre Morel wrote:
> The guest can use the STSI instruction to get a buffer filled
> with the CPU topology description.
>
> Let us implement the STSI instruction for the basis CPU topology
> level, level 2.
>
> Signed-off-by: Pierre Morel
> ---
> hw/s390x/cpu
On Fri, 2022-09-02 at 09:55 +0200, Pierre Morel wrote:
> In the S390x CPU topology the core_id specifies the CPU address
> and the position of the core withing the topology.
>
> Let's build the topology based on the core_id.
>
> Signed-off-by: Pierre Morel
> ---
> hw/s390x/cpu-topology.c
On Mon, 2022-09-05 at 17:10 +0200, Pierre Morel wrote:
>
> On 9/5/22 13:32, Nico Boehr wrote:
> > Quoting Pierre Morel (2022-09-02 09:55:22)
> > > S390x do not support multithreading in the guest.
> > > Do not let admin falsely specify multithreading on QEMU
> > > smp commandline.
> > >
> > > Sig
On Thu, 2022-08-11 at 12:11 +, Janosch Frank wrote:
> Sometimes dumping a guest from the outside is the only way to get the
> data that is needed. This can be the case if a dumping mechanism like
> KDUMP hasn't been configured or data needs to be fetched at a specific
> point. Dumping a protect
On Thu, 2022-08-11 at 12:11 +, Janosch Frank wrote:
> Let's add a few bits of code which hide the new KVM PV dump API from
> us via new functions.
>
> Signed-off-by: Janosch Frank
Reviewed-by: Janis Schoetterl-Glausch
On Thu, 2022-08-11 at 12:11 +, Janosch Frank wrote:
> Introduce an interface over which we can get information about UV data.
>
> Signed-off-by: Janosch Frank
> Reviewed-by: Steffen Eiden
With the below fixed:
Reviewed-by: Janis Schoetterl-Glausch
> ---
> hw/s390x/pv.c
On Thu, 2022-08-11 at 12:11 +, Janosch Frank wrote:
> Let's split the write from the modification of the elf header so we
> can consolidate the write of the data in one function.
>
> Signed-off-by: Janosch Frank
This is cosmetic only, right?
Reviewed-by: Janis Schoetterl-Glausch
On Thu, 2022-08-11 at 12:11 +, Janosch Frank wrote:
> Add a protected dump capability for later feature checking.
>
> Signed-off-by: Janosch Frank
> Reviewed-by: Steffen Eiden
Reviewed-by: Janis Schoetterl-Glausch
and use the function instead of calculating the size
> ourselves.
>
> Signed-off-by: Janosch Frank
> Reviewed-by: Marc-André Lureau
Reviewed-by: Janis Schoetterl-Glausch
> ---
> dump/dump.c | 22 --
> 1 file changed, 8 insertions(+), 14 deletions(-)
>
On Thu, 2022-08-11 at 12:11 +, Janosch Frank wrote:
> Add hooks which architectures can use to add arbitrary data to custom
> sections.
>
> Signed-off-by: Janosch Frank
> ---
> dump/dump.c| 120 ++---
> include/sysemu/dump-arch.h | 3 +
> 2 f
vant.
Seems like it would make the code a bit simpler.
I would also expect the string data to be written in this patch,
instead you do that in the next.
With that and Steffen's .shstrtab addressed:
Reviewed-by: Janis Schoetterl-Glausch
Some minor suggestions below.
>
> Signed-off-by
On Thu, 2022-08-11 at 12:11 +, Janosch Frank wrote:
> The functions in question do not actually write to the file descriptor
> they set up a buffer which is later written to the fd.
>
> Signed-off-by: Janosch Frank
Reviewed-by: Janis Schoetterl-Glausch
On Thu, 2022-08-11 at 12:11 +, Janosch Frank wrote:
> Currently we're writing the NULL section header if we overflow the
> physical header number in the ELF header. But in the future we'll add
> custom section headers AND section data.
>
> To facilitate this we need to rearange section handlin
lse weird.
>
> Signed-off-by: Janosch Frank
> Reviewed-by: Marc-André Lureau
> Reviewed-by: Janis Schoetterl-Glausch
> ---
> dump/dump.c | 20 ++--
> include/sysemu/dump.h | 2 --
> 2 files changed, 6 insertions(+), 16 deletions(-)
>
On 7/26/22 11:22, Janosch Frank wrote:
> As sections don't have a type like the notes do we need another way to
Having a string table seems like a good idea to me, as we don't know
the requirements any architecture might have, but sections do have sh_type.
Could we use one of those, e.g. one of th
You swapped the headers in patch 8, you just fixing up the elf header in this
patch, right?
Also I don't understand the reason for swapping the headers.
And the comment diagram in dump_begin still reflects the old ordering.
On 7/26/22 11:22, Janosch Frank wrote:
> For the upcoming string table an
.
>
> Signed-off-by: Janosch Frank
Reviewed-by: Janis Schoetterl-Glausch
> ---
> include/sysemu/dump.h | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/include/sysemu/dump.h b/include/sysemu/dump.h
> index 6ce3c24197..24ebb02660 100644
&
On 7/26/22 11:22, Janosch Frank wrote:
> Allocating the header lets us write it at a later time and hence also
> allows us to change section and segment table offsets until we
> finally write it.
>
Where are you making use of this?
You set e_shstrndx in prepare_elf_section_hdrs, but that is not re
On 7/26/22 11:22, Janosch Frank wrote:
> Let's move ELF related members into one block and guest memory related
> ones into another to improve readability.
>
> Signed-off-by: Janosch Frank
> Reviewed-by: Richard Henderson
> Reviewed-by: Marc-André Lureau
> ---
> include/sysemu/dump.h | 16
On 7/26/22 11:22, Janosch Frank wrote:
> By splitting the writing of the section headers and (future) section
> data we prepare for the addition of a string table section and
> architecture sections.
>
> At the same time we move the writing of the section to the end of the
> dump process. This all
On 7/26/22 11:22, Janosch Frank wrote:
> By splitting the writing of the section headers and (future) section
> data we prepare for the addition of a string table section and
> architecture sections.
>
> At the same time we move the writing of the section to the end of the
> dump process. This all
ft is the validation of the start block so it only
> makes sense to re-name the function to validate_start_block()
>
> Signed-off-by: Janosch Frank
Reviewed-by: Janis Schoetterl-Glausch
See suggenstions below.
> ---
> dump/dump.c | 20 ++--
> 1 file changed, 6
on of the offset and length out by
> using the dump_get_memblock_*() functions.
>
> Signed-off-by: Janosch Frank
Reviewed-by: Janis Schoetterl-Glausch
> ---
> dump/dump.c | 51 +++
> 1 file changed, 11 insertions(+), 40 deleti
On 7/26/22 11:22, Janosch Frank wrote:
> Let's make it a bit clearer that we write the program headers of the
> PT_LOAD type.
>
> Signed-off-by: Janosch Frank
> Reviewed-by: Marc-André Lureau
Reviewed-by: Janis Schoetterl-Glausch
> ---
> dump/dump.c | 6 +
x27;t it?
With that addressed:
Reviewed-by: Janis Schoetterl-Glausch
See minor stuff below.
>
> Additionally we move the calculation of the offset and length out by
> using the dump_get_memblock_*() functions.
>
> Signed-off-by: Janosch Frank
&
On 7/21/22 13:41, Pierre Morel wrote:
>
>
> On 7/21/22 10:16, Janis Schoetterl-Glausch wrote:
>> On 7/21/22 09:58, Pierre Morel wrote:
>>>
>>>
>
> ...snip...
>
>>>
>>> You are right, numa is redundant for us as we specify the topo
On 7/21/22 09:58, Pierre Morel wrote:
>
>
> On 7/20/22 19:24, Janis Schoetterl-Glausch wrote:
>> On 7/15/22 15:07, Pierre Morel wrote:
>>>
>>>
>>> On 7/15/22 11:11, Janis Schoetterl-Glausch wrote:
>>>> On 7/14/22 22:17, Pierre Morel wrote
On 6/20/22 16:03, Pierre Morel wrote:
> The handling of STSI is enhanced with the interception of the
> function code 15 for storing CPU topology.
>
> Using the objects built during the plugging of CPU, we build the
> SYSIB 15_1_x structures.
>
> With this patch the maximum MNEST level is 2, this
On 7/15/22 15:07, Pierre Morel wrote:
>
>
> On 7/15/22 11:11, Janis Schoetterl-Glausch wrote:
>> On 7/14/22 22:17, Pierre Morel wrote:
>>>
>>>
>>> On 7/14/22 16:57, Janis Schoetterl-Glausch wrote:
>>>> On 6/20/22 16:03, Pierre More
On 7/15/22 15:47, Pierre Morel wrote:
>
>
> On 7/15/22 11:31, Janis Schoetterl-Glausch wrote:
>> On 7/14/22 22:05, Pierre Morel wrote:
>>>
>>>
>>> On 7/14/22 20:43, Janis Schoetterl-Glausch wrote:
>>>> On 6/20/22 16:03, Pierre Morel wrote:
On 7/14/22 22:05, Pierre Morel wrote:
>
>
> On 7/14/22 20:43, Janis Schoetterl-Glausch wrote:
>> On 6/20/22 16:03, Pierre Morel wrote:
>>> Hi,
>>>
>>> This new spin is essentially for coherence with the last Linux CPU
>>> Topology pat
On 7/14/22 22:17, Pierre Morel wrote:
>
>
> On 7/14/22 16:57, Janis Schoetterl-Glausch wrote:
>> On 6/20/22 16:03, Pierre Morel wrote:
>>> S390x CPU Topology allows a non uniform repartition of the CPU
>>> inside the topology containers, sockets, books and draw
On 6/20/22 16:03, Pierre Morel wrote:
> Hi,
>
> This new spin is essentially for coherence with the last Linux CPU
> Topology patch, function testing and coding style modifications.
>
> Forword
> ===
>
> The goal of this series is to implement CPU topology for S390, it
> improves the preceed
On 6/20/22 16:03, Pierre Morel wrote:
> S390x CPU Topology allows a non uniform repartition of the CPU
> inside the topology containers, sockets, books and drawers.
>
> We use numa to place the CPU inside the right topology container
> and report the non uniform topology to the guest.
>
> Note th
On 7/14/22 13:25, Pierre Morel wrote:
[...]
>
> That is sure.
> I thought about put a fatal error report during the initialization in the
> s390_topology_setup()
>
>> And you can set thread > 1 today, so we'd need to handle that. (increase the
>> number of cpus instead and print a warning?)
>
On 7/13/22 16:59, Pierre Morel wrote:
>
>
> On 7/12/22 17:40, Janis Schoetterl-Glausch wrote:
>> On 6/20/22 16:03, Pierre Morel wrote:
>>> We use new objects to have a dynamic administration of the CPU topology.
>>> The highest level object in this implementation
On 6/20/22 16:03, Pierre Morel wrote:
> We use new objects to have a dynamic administration of the CPU topology.
> The highest level object in this implementation is the s390 book and
> in this first implementation of CPU topology for S390 we have a single
> book.
> The book is built as a SYSBUS br
According to the architecture, SET PREFIX must try to access the new
prefix area and recognize an addressing exception if the area is not
accessible.
For qemu this check prevents a crash in cpu_map_lowcore after an
inaccessible prefix area has been set.
Signed-off-by: Janis Schoetterl-Glausch
On 6/27/22 18:27, David Hildenbrand wrote:
> On 27.06.22 15:12, Janis Schoetterl-Glausch wrote:
>> According to the architecture, SET PREFIX must try to access the new
>> prefix area and recognize an addressing exception if the area is not
>> accessible.
>> For qemu thi
According to the architecture, SET PREFIX must try to access the new
prefix area and recognize an addressing exception if the area is not
accessible.
For qemu this check prevents a crash in cpu_map_lowcore after an
inaccessible prefix area has been set.
Signed-off-by: Janis Schoetterl-Glausch
On 5/24/22 13:21, Thomas Huth wrote:
> On 24/05/2022 13.10, Christian Borntraeger wrote:
>>
>>
>> Am 24.05.22 um 12:43 schrieb Thomas Huth:
>>> On 19/05/2022 15.53, Janis Schoetterl-Glausch wrote:
>>>> On 5/19/22 12:05, Thomas Huth wrote:
>>>>
On 5/19/22 12:05, Thomas Huth wrote:
> On 06/05/2022 17.39, Janis Schoetterl-Glausch wrote:
>> Storage key controlled protection is currently not honored when
>> emulating instructions.
>> If available, enable key protection for the MEM_OP ioctl, thereby
>> enabling it
On 5/9/22 10:06, Cornelia Huck wrote:
> On Fri, May 06 2022, Janis Schoetterl-Glausch wrote:
>
>> Make use of the storage key support of the MEMOP ioctl, if available,
>> in order to support storage key checking during emulation.
>>
>> I did not update all the heade
because no partial store is
possible, because the operand cannot span multiple pages.
* PCISTB
* MPCIFC
* STPCIFC
Signed-off-by: Janis Schoetterl-Glausch
---
target/s390x/kvm/kvm.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/target/s390x/kvm/kvm.c b/target/s390x/kvm/kvm.c
index
Since a full update of the linux headers pulls in changes in vfio.h that
break compilation, pull in only the required changes for storage key
support.
Signed-off-by: Janis Schoetterl-Glausch
---
linux-headers/linux/kvm.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff
Make use of the storage key support of the MEMOP ioctl, if available,
in order to support storage key checking during emulation.
I did not update all the headers, since that broke the build,
not sure what the best way of dealing with that is.
Janis Schoetterl-Glausch (2):
Pull in MEMOP changes
On 5/2/22 12:17, Janis Schoetterl-Glausch wrote:
> On 5/2/22 10:25, Thomas Huth wrote:
>> TPROT allows to specify an access key that should be used for checking
>> with the storage key of the destination page, to see whether an access
>> is allowed or not. Honor this storag
On 5/2/22 10:25, Thomas Huth wrote:
> TPROT allows to specify an access key that should be used for checking
> with the storage key of the destination page, to see whether an access
> is allowed or not. Honor this storage key checking now in the emulated
> TPROT instruction, too.
>
> Since we need
74 matches
Mail list logo
