On 28/04/2022 11.46, David Hildenbrand wrote:
Implement Vector-Enhancements Facility 2 for s390x
resolves: https://gitlab.com/qemu-project/qemu/-/issues/738
implements:
VECTOR LOAD ELEMENTS REVERSED (VLER)
VECTOR LOAD BYTE REVERSED ELEMENTS (VLBR)
VECTOR LO
Andrea Bolognani writes:
> On Thu, Apr 28, 2022 at 03:50:55PM +0200, Markus Armbruster wrote:
>> Andrea Bolognani writes:
>> > One concern that I have is about naming struct members: things like
>> > SpiceInfo.MouseMode and most others are translated from the QAPI
>> > schema exactly the way you
29.04.2022 17:18, Paolo Bonzini wrote:
Avoids the following bogus warning:
pvh_main.c: In function ‘pvh_load_kernel’:
pvh_main.c:101:42: warning: array subscript 0 is outside array bounds of
‘uint16_t[0]’ {aka ‘short unsigned int[]’} [-Warray-bounds]
101 | uint32_t ebda_paddr = ((uin
Hi Peter and maintainers,
On 4/25/22 11:27 AM, Gavin Shan wrote:
When the CPU-to-NUMA association isn't provided by user, the default NUMA
node ID for the specific CPU is returned from virt_get_default_cpu_node_id().
Unfortunately, the default NUMA node ID breaks socket boundary and leads to
the
On 4/22/22 14:10, Matthew Rosato wrote:
On 4/22/22 5:39 AM, Pierre Morel wrote:
On 4/4/22 20:17, Matthew Rosato wrote:
Use the associated kvm ioctl operation to enable adapter event
notification
and forwarding for devices when requested. This feature will be set up
with or without firmwa
Hi Daniel
On Tue, Apr 26, 2022 at 1:27 PM wrote:
> From: Marc-André Lureau
>
> Hi,
>
> v2:
> - add patches to replace pipe() with g_unix_open_pipe()
>
Since you suggested this change, could you review the "replace pipe()"
patches?
thanks!
> - add patch "Replace fcntl(0_NONBLOCK) with g_unix_
Am 30/04/2022 um 07:48 schrieb Stefan Hajnoczi:
> On Fri, Apr 29, 2022 at 10:37:54AM +0200, Emanuele Giuseppe Esposito wrote:
>> Am 28/04/2022 um 15:45 schrieb Stefan Hajnoczi:
>>> On Tue, Apr 26, 2022 at 04:51:09AM -0400, Emanuele Giuseppe Esposito wrote:
+static int has_writer;
>>>
>>> bo
Am 30/04/2022 um 07:17 schrieb Stefan Hajnoczi:
> On Thu, Apr 28, 2022 at 11:56:09PM +0200, Emanuele Giuseppe Esposito wrote:
>>
>>
>> Am 28/04/2022 um 12:45 schrieb Stefan Hajnoczi:
>>> On Wed, Apr 27, 2022 at 08:55:35AM +0200, Emanuele Giuseppe Esposito wrote:
Am 26/04/2022 um 1
I was setting gpioV4-7 to "1110" using the QOM pin property handler and
noticed that lowering gpioV7 was inadvertently lowering gpioV4-6 too.
(qemu) qom-set /machine/soc/gpio gpioV4 true
(qemu) qom-set /machine/soc/gpio gpioV5 true
(qemu) qom-set /machine/soc/gpio gpioV6 true
(qemu
On 28/04/2022 11.47, David Hildenbrand wrote:
From: David Miller
Signed-off-by: David Miller
Signed-off-by: Richard Henderson
Tested-by: Thomas Huth
Signed-off-by: David Hildenbrand
---
tests/tcg/s390x/Makefile.target | 8 ++
tests/tcg/s390x/vx.h| 19 +
tests/tcg/s390
Andrea Bolognani writes:
> Signed-off-by: Andrea Bolognani
> ---
> qapi/run-state.json | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/qapi/run-state.json b/qapi/run-state.json
> index 8124220bd9..15d6c9a2ed 100644
> --- a/qapi/run-state.json
> +++ b/qapi/run-state.json
Andrea Bolognani writes:
> It should start on the very first column.
>
> Signed-off-by: Andrea Bolognani
Reviewed-by: Markus Armbruster
Hi
On Mon, Apr 11, 2022 at 8:32 PM Stefan Berger wrote:
>
>
> On 4/11/22 10:47, Anthony PERARD wrote:
> > From: Anthony PERARD
> >
> > At the moment, there doesn't seems to be any way to know that QEMU
> > made modification to the command buffer. This is potentially an issue
> > on Xen while mi
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 the absolute address of the page (for getting t
Andrea Bolognani writes:
> Signed-off-by: Andrea Bolognani
Reviewed-by: Markus Armbruster
Andrea Bolognani writes:
> Signed-off-by: Andrea Bolognani
Suggest to mention this is just for source readability, and the
generated documentation doesn't change.
Reviewed-by: Markus Armbruster
Andrea Bolognani writes:
> Signed-off-by: Andrea Bolognani
Blank lines ones between doc comment and definition are clearly
unwanted.
Blank lines between two things *might* be intentional visual
separators. I'm not sure we should care.
Reviewed-by: Markus Armbruster
Andrea Bolognani writes:
> Care was taken not to break vertical alignment.
>
> Signed-off-by: Andrea Bolognani
> ---
> qapi/block-core.json | 62 +-
> qapi/block-export.json | 2 +-
> qapi/block.json| 2 +-
> qapi/char.json | 2 +-
>
On Mon, 25 Apr 2022 11:27:59 +0800
Gavin Shan wrote:
> The CPU topology isn't enabled on arm/virt machine yet, but we're
> going to do it in next patch. After the CPU topology is enabled by
> next patch, "thrad-id=1" becomes invalid because the CPU core is
^^^ typo
> preferred o
On Mon, May 02, 2022 at 09:21:36AM +0200, Markus Armbruster wrote:
> Andrea Bolognani writes:
> > The wire protocol would still retain the unappealing name, but at
> > least client libraries could hide the uglyness from users.
>
> At the price of mild inconsistency between the library interface an
On 02/05/2022 10.12, Thomas Huth wrote:
On 28/04/2022 11.47, David Hildenbrand wrote:
From: David Miller
Signed-off-by: David Miller
Signed-off-by: Richard Henderson
Tested-by: Thomas Huth
Signed-off-by: David Hildenbrand
---
tests/tcg/s390x/Makefile.target | 8 ++
tests/tcg/s390x/vx.
On Mon, 2022-05-02 at 09:48 +0200, Pierre Morel wrote:
>
> On 4/22/22 14:10, Matthew Rosato wrote:
> > On 4/22/22 5:39 AM, Pierre Morel wrote:
> > >
> > > On 4/4/22 20:17, Matthew Rosato wrote:
> > > > Use the associated kvm ioctl operation to enable adapter event
> > > > notification
> > > > an
On 28/04/2022 11.47, David Hildenbrand wrote:
From: David Miller
Signed-off-by: David Miller
Signed-off-by: Richard Henderson
Tested-by: Thomas Huth
Signed-off-by: David Hildenbrand
---
[...]
diff --git a/tests/tcg/s390x/vxeh2_vlstr.c b/tests/tcg/s390x/vxeh2_vlstr.c
new file mode 100644
i
From: Eric Auger
Using a VFIODevice handle local variable to improve the code readability.
no functional change intended
Signed-off-by: Eric Auger
Signed-off-by: Yi Liu
---
hw/vfio/pci.c | 49 +
1 file changed, 25 insertions(+), 24 deletions(-)
The three patches were part of iommufd RFC series, sent separately per
Kevin's suggestion.
https://lore.kernel.org/kvm/bn9pr11mb5276085cdf750807005a775b8c...@bn9pr11mb5276.namprd11.prod.outlook.com/
Regards,
Yi Liu
Eric Auger (2):
hw/vfio/pci: fix vfio_pci_hot_reset_result trace point
vfio/p
Rename VFIOGuestIOMMU iommu field into iommu_mr. Then it becomes clearer
it is an IOMMU memory region.
no functional change intended
Signed-off-by: Yi Liu
---
hw/vfio/common.c | 16
include/hw/vfio/vfio-common.h | 2 +-
2 files changed, 9 insertions(+), 9 deletion
From: Eric Auger
Properly output the errno string.
Signed-off-by: Eric Auger
Signed-off-by: Yi Liu
---
hw/vfio/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 9fd9faee1d..4a66376be6 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@
On 30/04/2022 00:31, Murilo Opsfelder Araujo wrote:
When CONFIG_MOS6522 is not set, building ppc64-softmmu target fails:
/usr/bin/ld: libqemu-ppc64-softmmu.fa.p/monitor_misc.c.o:(.data+0x1158):
undefined reference to `hmp_info_via'
clang-13: error: linker command failed with exit cod
On 5/2/22 09:37, Michael Tokarev wrote:
pvh_main.c: In function ‘pvh_load_kernel’:
pvh_main.c:101:42: warning: array subscript 0 is outside array bounds
of ‘uint16_t[0]’ {aka ‘short unsigned int[]’} [-Warray-bounds]
101 | uint32_t ebda_paddr = ((uint32_t)*((uint16_t
*)EBDA_BASE_ADDR
Hi Igor,
On 5/2/22 4:52 PM, Igor Mammedov wrote:
On Mon, 25 Apr 2022 11:27:59 +0800
Gavin Shan wrote:
The CPU topology isn't enabled on arm/virt machine yet, but we're
going to do it in next patch. After the CPU topology is enabled by
next patch, "thrad-id=1" becomes invalid because the CPU c
On 4/26/22 04:11, Steven Lee wrote:
The aspeed ast2600 accumulative mode is described in datasheet
ast2600v10.pdf section 25.6.4:
1. Allocating and initiating accumulative hash digest write buffer
with initial state.
* Since QEMU crypto/hash api doesn't provide the API to set initial
On Thu, Apr 28, 2022 at 5:43 PM wrote:
> From: Frank Chang
>
> Add Xilinx AXI CDMA model, which follows
> AXI Central Direct Memory Access v4.1 spec:
> https://docs.xilinx.com/v/u/en-US/pg034-axi-cdma
>
> Supports both Simple DMA and Scatter Gather modes.
>
Hi Frank,
Thanks for modeling this!
According to v-spec, tail agnostic behavior can be either kept as
undisturbed or set elements' bits to all 1s. To distinguish the
difference of tail policies, QEMU should be able to simulate the tail
agnostic behavior as "set tail elements' bits to all 1s". An option
'rvv_ta_all_1s' is added to ena
From: eopXD
Signed-off-by: eop Chen
Reviewed-by: Frank Chang
Reviewed-by: Weiwei Li
---
target/riscv/insn_trans/trans_rvv.c.inc | 11 +++
target/riscv/vector_helper.c| 11 +++
2 files changed, 22 insertions(+)
diff --git a/target/riscv/insn_trans/trans_rvv.c.inc
From: eopXD
Destination register of unit-stride mask load and store instructions are
always written with a tail-agnostic policy.
A vector segment load / store instruction may contain fractional lmul
with nf * lmul > 1. The rest of the elements in the last register should
be treated as tail eleme
From: eopXD
No functional change intended in this commit.
Signed-off-by: eop Chen
Reviewed-by: Frank Chang
Reviewed-by: Weiwei Li
Reviewed-by: Alistair Francis
---
target/riscv/vector_helper.c | 76 ++--
1 file changed, 38 insertions(+), 38 deletions(-)
diff
From: eopXD
Signed-off-by: eop Chen
Reviewed-by: Frank Chang
Reviewed-by: Weiwei Li
---
target/riscv/vector_helper.c | 220 ++-
1 file changed, 114 insertions(+), 106 deletions(-)
diff --git a/target/riscv/vector_helper.c b/target/riscv/vector_helper.c
index 8
From: eopXD
The tail elements in the destination mask register are updated under
a tail-agnostic policy.
Signed-off-by: eop Chen
Reviewed-by: Frank Chang
Reviewed-by: Weiwei Li
---
target/riscv/insn_trans/trans_rvv.c.inc | 6 +
target/riscv/vector_helper.c| 30 ++
From: eopXD
According to v-spec (section 5.4):
When vstart ≥ vl, there are no body elements, and no elements are
updated in any destination vector register group, including that
no tail elements are updated with agnostic values.
vmsbf.m, vmsif.m, vmsof.m, viota.m, vcompress instructions themselv
From: eopXD
No functional change intended in this commit.
Signed-off-by: eop Chen
Reviewed-by: Frank Chang
Reviewed-by: Weiwei Li
Reviewed-by: Alistair Francis
---
target/riscv/vector_helper.c | 1132 +-
1 file changed, 565 insertions(+), 567 deletions(-)
di
From: eopXD
According to v-spec, tail agnostic behavior can be either kept as
undisturbed or set elements' bits to all 1s. To distinguish the
difference of tail policies, QEMU should be able to simulate the tail
agnostic behavior as "set tail elements' bits to all 1s".
There are multiple possibi
From: eopXD
According to v-spec, tail agnostic behavior can be either kept as
undisturbed or set elements' bits to all 1s. To distinguish the
difference of tail policies, QEMU should be able to simulate the tail
agnostic behavior as "set tail elements' bits to all 1s".
There are multiple possibi
From: eopXD
Signed-off-by: eop Chen
Reviewed-by: Frank Chang
Reviewed-by: Weiwei Li
---
target/riscv/insn_trans/trans_rvv.c.inc | 44 +
target/riscv/vector_helper.c| 20 +++
2 files changed, 64 insertions(+)
diff --git a/target/riscv/insn_trans/tra
From: eopXD
Compares write mask registers, and so always operate under a tail-
agnostic policy.
Signed-off-by: eop Chen
Reviewed-by: Frank Chang
Reviewed-by: Weiwei Li
---
target/riscv/vector_helper.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/target/riscv/vector
From: eopXD
`vmadc` and `vmsbc` produces a mask value, they always operate with
a tail agnostic policy.
Signed-off-by: eop Chen
Reviewed-by: Frank Chang
Reviewed-by: Weiwei Li
---
target/riscv/insn_trans/trans_rvv.c.inc | 29 +++
target/riscv/internals.h| 5 +-
target/risc
From: eopXD
Compares write mask registers, and so always operate under a tail-
agnostic policy.
Signed-off-by: eop Chen
Reviewed-by: Frank Chang
Reviewed-by: Weiwei Li
---
target/riscv/insn_trans/trans_rvv.c.inc | 15 +
target/riscv/vector_helper.c| 440 +---
From: eopXD
Signed-off-by: eop Chen
Reviewed-by: Frank Chang
Reviewed-by: Weiwei Li
---
target/riscv/insn_trans/trans_rvv.c.inc | 22 ++
target/riscv/vector_helper.c| 40 +
2 files changed, 62 insertions(+)
diff --git a/target/riscv/insn_trans/
From: eopXD
Signed-off-by: eop Chen
Reviewed-by: Frank Chang
Reviewed-by: Weiwei Li
---
target/riscv/vector_helper.c | 20
1 file changed, 20 insertions(+)
diff --git a/target/riscv/vector_helper.c b/target/riscv/vector_helper.c
index f67ec1f249..a319cda969 100644
--- a/
On 5/2/22 11:19, Niklas Schnelle wrote:
On Mon, 2022-05-02 at 09:48 +0200, Pierre Morel wrote:
On 4/22/22 14:10, Matthew Rosato wrote:
On 4/22/22 5:39 AM, Pierre Morel wrote:
On 4/4/22 20:17, Matthew Rosato wrote:
Use the associated kvm ioctl operation to enable adapter event
notificatio
Andrea Bolognani writes:
> On Mon, May 02, 2022 at 09:21:36AM +0200, Markus Armbruster wrote:
>> Andrea Bolognani writes:
>> > The wire protocol would still retain the unappealing name, but at
>> > least client libraries could hide the uglyness from users.
>>
>> At the price of mild inconsistenc
Markus Armbruster writes:
> "Since X.Y" is not recognized as a tagged section, and therefore not
> formatted as such in generated documentation. Fix by adding the
> required colon.
>
> Signed-off-by: Markus Armbruster
Queued.
PATCH 1-5 queued, because no-brainers :)
Joao Martins writes:
> Expand dirtyrate measurer that is accessible via HMP calc_dirty_rate
> or QMP 'calc-dirty-rate' to receive a @scope argument. The scope
> then restricts the dirty tracking to be done at devices only,
> while neither enabling or using the KVM (CPU) dirty tracker.
> The defau
Without this (at least in Fedora 35) it don't detect mremap()
correctly.
Signed-off-by: Juan Quintela
---
meson.build | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meson.build b/meson.build
index 1fe7d257ff..f96da78741 100644
--- a/meson.build
+++ b/meson.build
@@ -2041,7
On 5/2/22 10:02, Emanuele Giuseppe Esposito wrote:
Are you saying rdlock isn't necessary in the main loop because nothing
can take the wrlock while our code is executing in the main loop?
Yes, that's the idea.
If I am not mistaken (and I hope I am not), only the main loop currently
modifies/is a
Hi, Mark.
Thanks for reviewing. Comments below.
On 5/2/22 06:43, Mark Cave-Ayland wrote:
On 30/04/2022 00:31, Murilo Opsfelder Araujo wrote:
When CONFIG_MOS6522 is not set, building ppc64-softmmu target fails:
/usr/bin/ld: libqemu-ppc64-softmmu.fa.p/monitor_misc.c.o:(.data+0x1158):
un
On 15/03/2022 12.20, Thomas Huth wrote:
From: Ilya Leoshkevich
Add a small test in order to prevent regressions.
Signed-off-by: Ilya Leoshkevich
Message-Id: <20220314104232.675863-4-...@linux.ibm.com>
Reviewed-by: Richard Henderson
Reviewed-by: David Hildenbrand
Signed-off-by: Thomas Huth
On 9/25/21 22:48, Nicholas Ngai wrote:
libslirp provides a newer slirp_*_hostxfwd API meant for
address-agnostic forwarding instead of the is_udp parameter which is
limited to just TCP/UDP.
Signed-off-by: Nicholas Ngai
Reviewed-by: Samuel Thibault
Tested-by: Breno Leitao
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
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 storage key checking now in the
On Mon, May 02, 2022 at 01:46:23PM +0200, Markus Armbruster wrote:
> Andrea Bolognani writes:
> >> > The wire protocol would still retain the unappealing name, but at
> >> > least client libraries could hide the uglyness from users.
> >>
> >> At the price of mild inconsistency between the library
Queued, thanks.
Paolo
On Mon, May 02, 2022 at 10:50:07AM +0200, Markus Armbruster wrote:
> Andrea Bolognani writes:
> > -# @writeback: true if writeback mode is enabled
> > -# @direct: true if the host page cache is bypassed (O_DIRECT)
> > -# @no-flush:true if flush requests are ignored for the device
> > +#
On Mon, 2 May 2022 02:42:21 -0700
Yi Liu wrote:
> From: Eric Auger
>
> Properly output the errno string.
More explanation please, why is it broken and how does this fix it?
Thanks,
Alex
> Signed-off-by: Eric Auger
> Signed-off-by: Yi Liu
> ---
> hw/vfio/pci.c | 2 +-
> 1 file changed, 1
On Sat, 23 Apr 2022, BALATON Zoltan wrote:
During trying to implement via-ac97 I did some small clean ups to ac97
which is in this series. The via-ac97 is not working yet so that's not
included but these unrelated clean ups could be merged now.
v3: Fixed misalignments and drop spaces before comm
On 5/2/22 13:54, Markus Armbruster wrote:
> Joao Martins writes:
>
>> Expand dirtyrate measurer that is accessible via HMP calc_dirty_rate
>> or QMP 'calc-dirty-rate' to receive a @scope argument. The scope
>> then restricts the dirty tracking to be done at devices only,
>> while neither enabling
By running the grep command `git grep -nr 'define \(fpscr\|msr\)_[a-z0-9]\+\>'`
we can find multiple macros that use `env->fpscr` and `env->msr` but doesn't
take *env as a parameter.
Richard Henderson said [1] that these macros hiding the usage of *env "are
evil".
This patch series remove them a
fpscr_* defined macros are hiding the usage of *env behind them.
Substitute the usage of these macros with `env->fpscr & FP_*` to make
the code cleaner.
Suggested-by: Richard Henderson
Reviewed-by: Richard Henderson
Signed-off-by: Víctor Colombo
---
target/ppc/cpu.c| 2 +-
target/ppc/
On Mon, May 02, 2022 at 02:43:52PM +0200, Markus Armbruster wrote:
> PATCH 1-5 queued, because no-brainers :)
Thanks!
How do you want me to handle respinning 6/7 and 7/7? Send out the
entire series again with those two patches tweaked, wait for your
pull request to make it into the tree, somethin
Some msr_* macros are not used anywhere. Remove them as part of
the work to remove all hidden usage of *env.
Suggested-by: Richard Henderson
Reviewed-by: Richard Henderson
Signed-off-by: Víctor Colombo
---
target/ppc/cpu.h | 21 -
1 file changed, 21 deletions(-)
diff --git
msr_ds macro hides the usage of env->msr, which is a bad behavior
Substitute it with FIELD_EX64 calls that explicitly use env->msr
as a parameter.
Suggested-by: Richard Henderson
Signed-off-by: Víctor Colombo
---
v2: Remove M_MSR_DS and use FIELD_EX64 instead
Signed-off-by: Víctor Colombo
---
msr_pr macro hides the usage of env->msr, which is a bad behavior
Substitute it with FIELD_EX64 calls that explicitly use env->msr
as a parameter.
Suggested-by: Richard Henderson
Signed-off-by: Víctor Colombo
---
v2: Remove M_MSR_PR and use FIELD_EX64 instead
Signed-off-by: Víctor Colombo
---
Add FIELDs macros for msr bits that had an unused msr_* before.
Signed-off-by: Víctor Colombo
---
v2: Remove M_MSR_* and use FIELD macro now.
Signed-off-by: Víctor Colombo
---
target/ppc/cpu.h | 26 ++
1 file changed, 26 insertions(+)
diff --git a/target/ppc/cpu.h b/t
msr_ce macro hides the usage of env->msr, which is a bad behavior
Substitute it with FIELD_EX64 calls that explicitly use env->msr
as a parameter.
Suggested-by: Richard Henderson
Signed-off-by: Víctor Colombo
---
v2: Remove M_MSR_CE and use FIELD_EX64 instead
Signed-off-by: Víctor Colombo
---
msr_ee macro hides the usage of env->msr, which is a bad behavior
Substitute it with FIELD_EX64 calls that explicitly use env->msr
as a parameter.
Suggested-by: Richard Henderson
Signed-off-by: Víctor Colombo
---
v2: Remove M_MSR_EE and use FIELD_EX64 instead
Signed-off-by: Víctor Colombo
---
msr_le macro hides the usage of env->msr, which is a bad behavior
Substitute it with FIELD_EX64 calls that explicitly use env->msr
as a parameter.
Suggested-by: Richard Henderson
Signed-off-by: Víctor Colombo
---
v2: Remove M_MSR_LE and use FIELD_EX64 instead
Signed-off-by: Víctor Colombo
---
Hi Alex,
On 5/2/22 16:35, Alex Williamson wrote:
> On Mon, 2 May 2022 02:42:21 -0700
> Yi Liu wrote:
>
>> From: Eric Auger
>>
>> Properly output the errno string.
> More explanation please, why is it broken and how does this fix it?
> Thanks,
"%m" format specifier is not interpreted by the trac
msr_pow macro hides the usage of env->msr, which is a bad behavior
Substitute it with FIELD_EX64 calls that explicitly use env->msr
as a parameter.
Suggested-by: Richard Henderson
Signed-off-by: Víctor Colombo
---
v2: Remove M_MSR_POW and use FIELD_EX64 instead
Signed-off-by: Víctor Colombo
-
msr_ile macro hides the usage of env->msr, which is a bad behavior
Substitute it with FIELD_EX64 calls that explicitly use env->msr
as a parameter.
Suggested-by: Richard Henderson
Signed-off-by: Víctor Colombo
---
v2: Remove M_MSR_ILE and use FIELD_EX64 instead
Signed-off-by: Víctor Colombo
-
msr_fp macro hides the usage of env->msr, which is a bad behavior
Substitute it with FIELD_EX64 calls that explicitly use env->msr
as a parameter.
Suggested-by: Richard Henderson
Signed-off-by: Víctor Colombo
---
v2: Remove M_MSR_FP and use FIELD_EX64 instead
Signed-off-by: Víctor Colombo
---
msr_me macro hides the usage of env->msr, which is a bad behavior
Substitute it with FIELD_EX64 calls that explicitly use env->msr
as a parameter.
Suggested-by: Richard Henderson
Signed-off-by: Víctor Colombo
---
v2: Remove M_MSR_ME and use FIELD_EX64 instead
Signed-off-by: Víctor Colombo
---
msr_me macro hides the usage of env->msr, which is a bad behavior
Substitute it with FIELD_EX64 calls that explicitly use env->msr
as a parameter.
Suggested-by: Richard Henderson
Signed-off-by: Víctor Colombo
---
v2: Remove M_MSR_CM and use FIELD_EX64 instead
Signed-off-by: Víctor Colombo
---
msr_gs macro hides the usage of env->msr, which is a bad behavior
Substitute it with FIELD_EX64 calls that explicitly use env->msr
as a parameter.
Suggested-by: Richard Henderson
Signed-off-by: Víctor Colombo
---
v2: Remove M_MSR_GS and use FIELD_EX64 instead
Signed-off-by: Víctor Colombo
---
On 5/2/22 16:39, Víctor Colombo wrote:
By running the grep command `git grep -nr 'define \(fpscr\|msr\)_[a-z0-9]\+\>'`
we can find multiple macros that use `env->fpscr` and `env->msr` but doesn't
take *env as a parameter.
Richard Henderson said [1] that these macros hiding the usage of *env "are
msr_dr macro hides the usage of env->msr, which is a bad behavior
Substitute it with FIELD_EX64 calls that explicitly use env->msr
as a parameter.
Suggested-by: Richard Henderson
Signed-off-by: Víctor Colombo
---
v2: Remove M_MSR_DR and use FIELD_EX64 instead
Signed-off-by: Víctor Colombo
---
msr_ir macro hides the usage of env->msr, which is a bad behavior
Substitute it with FIELD_EX64 calls that explicitly use env->msr
as a parameter.
Suggested-by: Richard Henderson
Signed-off-by: Víctor Colombo
---
v2: Remove M_MSR_IR and use FIELD_EX64 instead
Signed-off-by: Víctor Colombo
---
msr_ep macro hides the usage of env->msr, which is a bad behavior
Substitute it with FIELD_EX64 calls that explicitly use env->msr
as a parameter.
Also, this macro was called in a specific place where it was being
used 'kinda' like a mask: (value >> MSR_EP) & 1) != msr_ep. The setup
to use FIELD_E
msr_fe0 and msr_fe1 macros hide the usage of env->msr, which is a bad
behavior. Substitute it with FIELD_EX64 calls that explicitly use
env->msr as a parameter.
Suggested-by: Richard Henderson
Signed-off-by: Víctor Colombo
---
v2: Remove M_MSR_FE* and use FIELD_EX64 instead. As the bit numbers
msr_ts macro hides the usage of env->msr, which is a bad
behavior. Substitute it with FIELD_EX64 calls that explicitly use
env->msr as a parameter.
Suggested-by: Richard Henderson
Signed-off-by: Víctor Colombo
---
v2: Remove M_MSR_TS* and use FIELD_EX64 instead.
Signed-off-by: Víctor Colombo
msr_hv macro hides the usage of env->msr, which is a bad
behavior. Substitute it with FIELD_EX64 calls that explicitly use
env->msr as a parameter.
Suggested-by: Richard Henderson
Signed-off-by: Víctor Colombo
---
v2: Remove M_MSR_HV and use FIELD_EX64 instead.
In this patch I'm having some p
Today we have the issue where MSR_* values are the 'inverted order'
bit numbers from what the ISA specifies. e.g. MSR_LE is bit 63 but
is defined as 0 in QEMU.
Add a macro to be used to convert from QEMU order to ISA order.
This solution requires less changes than to use the already defined
PPC_B
On 5/2/22 10:08, Peter Delevoryas wrote:
I was setting gpioV4-7 to "1110" using the QOM pin property handler and
noticed that lowering gpioV7 was inadvertently lowering gpioV4-6 too.
(qemu) qom-set /machine/soc/gpio gpioV4 true
(qemu) qom-set /machine/soc/gpio gpioV5 true
(qemu) q
On 02.05.22 09:20, Thomas Huth wrote:
> On 28/04/2022 11.46, David Hildenbrand wrote:
>> Implement Vector-Enhancements Facility 2 for s390x
>>
>> resolves: https://gitlab.com/qemu-project/qemu/-/issues/738
>>
>> implements:
>> VECTOR LOAD ELEMENTS REVERSED (VLER)
>> VECTOR L
> On May 2, 2022, at 8:09 AM, Cédric Le Goater wrote:
>
> On 5/2/22 10:08, Peter Delevoryas wrote:
>> I was setting gpioV4-7 to "1110" using the QOM pin property handler and
>> noticed that lowering gpioV7 was inadvertently lowering gpioV4-6 too.
>> (qemu) qom-set /machine/soc/gpio gpioV4 true
There was also the patch that had them as .insn in the other series of emails.
On Mon, May 2, 2022 at 11:52 AM David Hildenbrand wrote:
>
> On 02.05.22 09:20, Thomas Huth wrote:
> > On 28/04/2022 11.46, David Hildenbrand wrote:
> >> Implement Vector-Enhancements Facility 2 for s390x
> >>
> >> res
Binutils >=2.37 and Clang do not accept (. - 0x1) PCRel32
constants. While this looks like a bug that needs fixing, use a
different notation (-0x1) as a workaround.
Reported-by: Thomas Huth
Signed-off-by: Ilya Leoshkevich
---
tests/tcg/s390x/branch-relative-long.c | 4 ++--
1 fi
Andrea Bolognani writes:
> On Mon, May 02, 2022 at 10:50:07AM +0200, Markus Armbruster wrote:
>> Andrea Bolognani writes:
>> > -# @writeback: true if writeback mode is enabled
>> > -# @direct: true if the host page cache is bypassed (O_DIRECT)
>> > -# @no-flush:true if flush requests
Andrea Bolognani writes:
> On Mon, May 02, 2022 at 02:43:52PM +0200, Markus Armbruster wrote:
>> PATCH 1-5 queued, because no-brainers :)
>
> Thanks!
>
> How do you want me to handle respinning 6/7 and 7/7? Send out the
> entire series again with those two patches tweaked, wait for your
> pull re
On 5/2/22 7:30 AM, Pierre Morel wrote:
On 5/2/22 11:19, Niklas Schnelle wrote:
On Mon, 2022-05-02 at 09:48 +0200, Pierre Morel wrote:
On 4/22/22 14:10, Matthew Rosato wrote:
On 4/22/22 5:39 AM, Pierre Morel wrote:
On 4/4/22 20:17, Matthew Rosato wrote:
Use the associated kvm ioctl operat
On Fri, Apr 29, 2022 at 02:49:35PM +0200, Kevin Wolf wrote:
...
> > Or a multi-pathed connection to network storage, where one QEMU
> > process accesses the network device, but those accesses may
> > round-robin which server they reach, and where any caching at an
> > individual server may be incon
1 - 100 of 134 matches
Mail list logo
