On 5/3/22 04:27, Steven Lee wrote:
Per ast1030_v7.pdf, AST1030 HACE engine is identical to AST2600's HACE
engine.
Signed-off-by: Steven Lee
Reviewed-by: Cédric Le Goater
Thanks
C.
---
hw/misc/aspeed_hace.c | 20
include/hw/misc/aspeed_hace.h | 2 ++
2
On Thu, Apr 28, 2022 at 4:43 PM Bin Meng wrote:
>
> On Fri, Apr 22, 2022 at 11:00 AM Bin Meng wrote:
> >
> > +Richard
> >
> > On Wed, Apr 20, 2022 at 4:16 PM Bin Meng wrote:
> > >
> > > On Tue, Apr 12, 2022 at 9:11 AM Bin Meng wrote:
> > > >
> > > > On Thu, Mar 24, 2022 at 9:48 PM Bin Meng
On Tue, Apr 26, 2022 at 9:41 AM Bin Meng wrote:
>
> +Mark
>
>
> On Mon, Apr 25, 2022 at 10:27 PM Bin Meng wrote:
> >
> > At present there is no Windows support for 9p file system.
> > This series adds initial Windows support for 9p file system.
> >
> > 'local' file system backend driver is
Per ast1030_v7.pdf, AST1030 HACE engine is identical to AST2600's HACE
engine.
Please help to review.
Thanks,
Steven
Based-on: 20220426021120.28255-3-steven_...@aspeedtech.com
([v6,2/3] aspeed/hace: Support AST2600 HACE)
Steven Lee (1):
aspeed/hace: Support AST1030 HACE
Per ast1030_v7.pdf, AST1030 HACE engine is identical to AST2600's HACE
engine.
Signed-off-by: Steven Lee
---
hw/misc/aspeed_hace.c | 20
include/hw/misc/aspeed_hace.h | 2 ++
2 files changed, 22 insertions(+)
diff --git a/hw/misc/aspeed_hace.c
On Mon, May 02, 2022 at 09:12:53PM -0300, Leonardo Bras Soares Passos wrote:
> Hello Peter,
>
> On Mon, May 2, 2022 at 8:52 PM Peter Xu wrote:
> >
> > Leo,
> >
> > On Fri, Apr 29, 2022 at 11:40:44PM -0300, Leonardo Bras Soares Passos wrote:
> > > Does anyone else have any further suggestions, or
On Mon, May 2, 2022 at 6:29 PM Edgar E. Iglesias
wrote:
> 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
Hello Peter,
On Mon, May 2, 2022 at 8:52 PM Peter Xu wrote:
>
> Leo,
>
> On Fri, Apr 29, 2022 at 11:40:44PM -0300, Leonardo Bras Soares Passos wrote:
> > Does anyone else have any further suggestions, or know how this kind of
> > issue
> > is generally solved in qemu?
>
> I've no solid idea why
On 5/2/22 16:28, Jason A. Donenfeld wrote:
This appears to be a copy and paste error. The UART size was used
instead of the much smaller OMPIC size.
Signed-off-by: Jason A. Donenfeld
---
hw/openrisc/openrisc_sim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Richard
On 5/2/22 15:52, Jason A. Donenfeld wrote:
OpenRISC defines various nop instructions in or1k as meaning shutdown or
reset. Implement these in TCG. This has been tested with Linux and
confirmed to work.
No, OpenRISC does not define various nop instructions, etc.
OpenRISC defines a Power
Leo,
On Fri, Apr 29, 2022 at 11:40:44PM -0300, Leonardo Bras Soares Passos wrote:
> Does anyone else have any further suggestions, or know how this kind of issue
> is generally solved in qemu?
I've no solid idea why it can't see MSG_ZEROCOPY defined in the specific
environment, but when I was
This appears to be a copy and paste error. The UART size was used
instead of the much smaller OMPIC size.
Signed-off-by: Jason A. Donenfeld
---
hw/openrisc/openrisc_sim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/openrisc/openrisc_sim.c b/hw/openrisc/openrisc_sim.c
The 8250 serial controller supports 4 serial ports, so wire them all up,
so that we can have more than one basic I/O channel.
Cc: Stafford Horne
Signed-off-by: Jason A. Donenfeld
---
hw/openrisc/openrisc_sim.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff
OpenRISC defines various nop instructions in or1k as meaning shutdown or
reset. Implement these in TCG. This has been tested with Linux and
confirmed to work.
Cc: Stafford Horne
Signed-off-by: Jason A. Donenfeld
---
target/openrisc/helper.h | 1 +
target/openrisc/sys_helper.c | 18
On 5/2/22 07:39, Víctor Colombo wrote:
Add FIELDs macros for msr bits that had an unused msr_* before.
Signed-off-by: Víctor Colombo
Acked-by: Richard Henderson
r~
On 5/2/22 07:39, Víctor Colombo wrote:
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
Reviewed-by: Richard
On 5/2/22 07:39, Víctor Colombo wrote:
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
Reviewed-by: Richard Henderson
r~
On 5/2/22 07:39, Víctor Colombo wrote:
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
Reviewed-by: Richard Henderson
r~
On 5/2/22 14:38, Richard Henderson wrote:
On 5/2/22 07:39, Víctor Colombo wrote:
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
On 5/2/22 07:39, Víctor Colombo wrote:
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
Reviewed-by: Richard Henderson
r~
On 5/2/22 07:39, Víctor Colombo wrote:
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
Reviewed-by: Richard Henderson
r~
On 5/2/22 07:39, Víctor Colombo wrote:
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
Reviewed-by: Richard Henderson
r~
On 5/2/22 07:39, Víctor Colombo wrote:
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
Reviewed-by: Richard Henderson
r~
On 5/2/22 07:39, Víctor Colombo wrote:
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
Reviewed-by: Richard Henderson
r~
On 5/2/22 07:39, Víctor Colombo wrote:
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
Reviewed-by: Richard Henderson
r~
On 5/2/22 07:39, Víctor Colombo wrote:
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
Reviewed-by: Richard Henderson
r~
On 5/2/22 07:39, Víctor Colombo wrote:
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
On 5/2/22 07:39, Víctor Colombo wrote:
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
On 5/2/22 07:39, Víctor Colombo wrote:
-if (unlikely((value >> MSR_EP) & 1) != msr_ep) {
-env->excp_prefix = ((value >> MSR_EP) & 1) * 0xFFF0;
+if (unlikely(!(value & env->msr & R_MSR_EP_MASK))) {
Needs xor.
+env->excp_prefix = FIELD_EX64(env->msr, MSR, EP) *
On 5/2/22 07:39, Víctor Colombo wrote:
if (!(value & env->msr & R_MSR_IR_MASK) ||
-((value >> MSR_DR) & 1) != msr_dr) {
+!(value & env->msr & R_MSR_DR_MASK)) {
Xor, but then this becomes
(value ^ env->msr) & (R_MSR_IR_MASK | R_MSR_DR_MASK)
r~
On 5/2/22 07:39, Víctor Colombo wrote:
-if (((value >> MSR_IR) & 1) != msr_ir ||
+if (!(value & env->msr & R_MSR_IR_MASK) ||
Likewise needs xor.
r~
On 5/2/22 07:39, Víctor Colombo wrote:
-((value >> MSR_GS) & 1) != msr_gs) {
+!(value & env->msr & R_MSR_GS_MASK)) {
This isn't right. I think you wanted
(value ^ env->msr) & R_MSR_GS_MASK
r~
On 5/2/22 07:39, Víctor Colombo wrote:
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
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
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
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
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
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
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
> >>
> >>
> 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
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
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)
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
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
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_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
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
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_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
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
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
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_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_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_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_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
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
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
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_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
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
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
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
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
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,
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 +-
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
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
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
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,
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
> >
Queued, thanks.
Paolo
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
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
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
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 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
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):
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
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
@@
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
PATCH 1-5 queued, because no-brainers :)
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.
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
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
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
---
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
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
`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 +-
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
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
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
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
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(-)
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
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
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
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(-)
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
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
1 - 100 of 135 matches
Mail list logo
