On Fri, Nov 20, 2020 at 11:39 AM Paolo Bonzini wrote:
> Pass the boolean option directly instead of writing
> CONFIG_MINIKCONF_MODE to config-host.mak.
>
> Signed-off-by: Paolo Bonzini
> ---
> configure | 12
> meson.build | 5 +++--
> meson_options.txt | 2 ++
> 3
Pass the boolean option directly instead of writing
CONFIG_MINIKCONF_MODE to config-host.mak.
Signed-off-by: Paolo Bonzini
---
configure | 12
meson.build | 5 +++--
meson_options.txt | 2 ++
3 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/configure
If expected_args is 0, qtest frees the argument vector and then returns it
nevertheless. Coverity complains; in practice this is not an issue because
expected_args == 0 means that the caller is not interested in the argument
vector, but it would be a potential problem if somebody wanted to add
On 20/11/20 01:27, Bruce Rogers wrote:
config USB_XHCI_SYSBUS
bool
-default y if USB_XHCI
-select USB
+default y
+select USB_XHCI
config USB_MUSB
bool
I was reviewing what device changes are happening between v5.1.0 and
v5.2.0 for the QEMU arch's we support
This issue is about the Qemu
Will the Qemu work on the new m1 macbook pro?
And if yes, when will the arm version of Qemu be available for public
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index 0bbfd7f4574..bc29e118c6d 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -438,6 +438,9 @@ static void riscv_cpu_realize(DeviceState *dev, Error
> **errp)
> if (cpu->cfg.ext_h) {
> target_misa |=
> > config USB_XHCI
> > -default y if PCI_DEVICES
> > config USB_XHCI_SYSBUS
> > +default y
> I was reviewing what device changes are happening between v5.1.0 and
> v5.2.0 for the QEMU arch's we support and noticed for s390x system
> emulation that usb devices have appeared in the info
Eduardo Habkost writes:
> On Thu, Nov 19, 2020 at 11:39:14AM +0100, Markus Armbruster wrote:
>> Marc-André Lureau writes:
>>
>> > On Tue, Nov 17, 2020 at 2:48 AM Eduardo Habkost
>> > wrote:
>> >
>> >> Use QNumValue to represent QNums, so we can also support uint64_t
>> >> and double QNum
Eduardo Habkost writes:
> On Thu, Nov 19, 2020 at 11:27:40AM +0100, Markus Armbruster wrote:
> [...]
>> > +bool qnum_is_equal(const QObject *x, const QObject *y)
>> > +{
>> > +const QNum *qnum_x = qobject_to(QNum, x);
>> > +const QNum *qnum_y = qobject_to(QNum, y);
>>
>> Humor me: blank
On 19/11/2020 22.11, Eric Farman wrote:
>
>
> On 11/19/20 3:20 PM, Thomas Huth wrote:
>> On 19/11/2020 17.57, Eric Farman wrote:
>>> Let's look at the Reset PSW first instead of the contents of memory.
>>> It might be leftover from an earlier system boot when processing
>>> a chreipl.
>>>
>>>
Eduardo Habkost writes:
> On Thu, Nov 19, 2020 at 11:24:52AM +0100, Markus Armbruster wrote:
>> Marc-André Lureau writes:
>>
>> > On Tue, Nov 17, 2020 at 6:42 PM Eduardo Habkost
>> > wrote:
>> >
>> >> On Tue, Nov 17, 2020 at 12:37:56PM +0400, Marc-André Lureau wrote:
>> >> > On Tue, Nov 17,
v1 -> v2:
fix codestyle checked by checkpatch.pl
This patch modify virtio-blk seg_max when host has VIRTIO_RING_F_INDIRECT_DESC
feature, when read/write virtio-blk disk in direct mode,
this patch can make the bio reach 512k but not 504k if the user buffer physical
segments are all
Hi, Philippe,
On Wed, Nov 18, 2020 at 1:17 AM Philippe Mathieu-Daudé wrote:
>
> Hi Huacai,
>
> On 10/7/20 10:39 AM, Huacai Chen wrote:
> > After converting from configure to meson, KVM support is lost for MIPS,
> > so re-enable it in meson.build.
> >
> > Fixes: fdb75aeff7c212e1afaaa3a43
** Description changed:
peeked message size is not equal to read message size
Bug in the code at line:
https://github.com/qemu/qemu/blob/master/hw/net/lan9118.c#L1209
s->tx_status_fifo_head should be s->rx_status_fifo_head
+ Could also be a security bug, as the user could
Replace all fprintf(stderr...) calls in hw/display/vmware_vga.c
witherror_report().
Remove the "\n" from strings passed to all modified calls, since error_report()
appends one.
Signed-off-by: Alex Chen
---
hw/display/vmware_vga.c | 23 ---
1 file changed, 12 insertions(+),
We should use printf format specifier "%u" instead of "%d" for
argument of type "unsigned int".
Reported-by: Euler Robot
Signed-off-by: Alex Chen
Reviewed-by: Philippe Mathieu-Daudé
---
hw/display/vmware_vga.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Optimized some code for vmware_vga:
patch1 fixes a bad printf format specifier and
patch2 replaces fprintf(stderr, "*\n") with error_report()
Alex Chen (2):
display/vmware_vga: Fix bad printf format specifiers
display/vmware_vga: Replace fprintf(stderr, "*\n") with error_report()
Public bug reported:
peeked message size is not equal to read message size
Bug in the code at line:
https://github.com/qemu/qemu/blob/master/hw/net/lan9118.c#L1209
s->tx_status_fifo_head should be s->rx_status_fifo_head
Thanks,
Alfred
** Affects: qemu
Importance: Undecided
On Tue, 17 Nov 2020 04:26:05 +0100
Eric Farman wrote:
> Now that the vfio-ccw code has a notifier interface to request that
> a device be unplugged, let's wire that together.
I'm aware of the fact that performing an unplug is what vfio-pci does,
but I was not aware of this before, and I became
Hi Alex,
Thanks for offering to help, but I submitted a patch to the maillist
yesterday. Thank you again.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1904486
Title:
resource leak in /net/tap.c
A patch has been submitted at https://lists.nongnu.org/archive/html
/qemu-trivial/2020-11/msg00355.html
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1904486
Title:
resource leak in /net/tap.c
Hi yuanjungong,
If you don't have time to submit a patch, can I submit a patch to fix
it?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1904486
Title:
resource leak in /net/tap.c
Status in QEMU:
On Fri, Nov 20, 2020 at 6:26 AM Richard Henderson <
richard.hender...@linaro.org> wrote:
> On 11/18/20 12:29 AM, frank.ch...@sifive.com wrote:
> > This patchset implements RISC-V B-extension latest draft version
> > (2020.10.26) Zbb, Zbs and Zba subset instructions.
>
> With some additional
On Tue, 2020-10-20 at 09:48 +0200, Gerd Hoffmann wrote:
> USB_XHCI does not depend on PCI any more.
> USB_XHCI_SYSBUS must select USB_XHCI not USB.
>
> Signed-off-by: Gerd Hoffmann
> ---
> hw/usb/Kconfig | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git
On 11/11/20 3:27 AM, Markus Armbruster wrote:
John Snow writes:
On 11/10/20 1:22 AM, Markus Armbruster wrote:
John Snow writes:
The QMP specification states:
NOTE: Some errors can occur before the Server is able to read the "id"
member, in these cases the "id" member will not be part of
On 11/18/20 9:10 AM, Thomas Huth wrote:
> This check can be done in a much shorter way in meson.build. And while
> we're at it, rename the #define to HAVE_BTRFS_H to match the other
> HAVE_someheader_H symbols that we already have.
>
> Signed-off-by: Thomas Huth
> ---
> configure
On 11/18/20 9:10 AM, Thomas Huth wrote:
> This check can be done in a much shorter way in meson.build. And while
> we're at it, rename the #define to HAVE_SYS_KCOV_H to match the other
> HAVE_someheader_H symbols that we already have.
>
> Signed-off-by: Thomas Huth
> ---
> configure
On 11/18/20 9:10 AM, Thomas Huth wrote:
> This check can be done in a much shorter way in meson.build
>
> Signed-off-by: Thomas Huth
> ---
> configure | 10 --
> meson.build | 1 +
> 2 files changed, 1 insertion(+), 10 deletions(-)
Reviewed-by: Richard Henderson
r~
On 11/18/20 9:10 AM, Thomas Huth wrote:
> This check can be done in a much shorter way in meson.build
>
> Signed-off-by: Thomas Huth
> ---
> configure | 10 --
> meson.build | 1 +
> 2 files changed, 1 insertion(+), 10 deletions(-)
Reviewed-by: Richard Henderson
r~
On 11/18/20 9:10 AM, Thomas Huth wrote:
> This check can be done in a much shorter way in meson.build
>
> Signed-off-by: Thomas Huth
> ---
> configure | 9 -
> meson.build | 1 +
> 2 files changed, 1 insertion(+), 9 deletions(-)
Reviewed-by: Richard Henderson
r~
On 11/18/20 9:10 AM, Thomas Huth wrote:
> The code that used HAVE_IFADDRS_H has been removed in commit
> 0a27af918b ("io: use bind() to check for IPv4/6 availability"),
> so we don't need this check in the configure script anymore.
>
> Signed-off-by: Thomas Huth
> ---
> configure | 11
On Thu, Nov 19, 2020 at 11:44:42AM +0100, Kevin Wolf wrote:
> Am 18.11.2020 um 20:48 hat Masayoshi Mizuma geschrieben:
> > On Wed, Nov 18, 2020 at 02:10:36PM -0500, Masayoshi Mizuma wrote:
> > > On Wed, Nov 18, 2020 at 04:42:47PM +0100, Kevin Wolf wrote:
> > > > Am 06.11.2020 um 05:01 hat
On 11/19/20 8:17 AM, Philippe Mathieu-Daudé wrote:
> ... but this is wrong as the same header matches MIPS32 o32 ELFs...
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
Yeah, I don't think you'll be able to include this.
r~
On 11/19/20 3:08 PM, Richard Henderson wrote:
> On 11/19/20 8:17 AM, Philippe Mathieu-Daudé wrote:
>> +#if defined(TARGET_ABI_MIPSO32)
>> +#define TARGET_SYSCALL_OFFSET 4000
>> +#include "syscall_o32_nr.h"
>
> Where does this get built?
Ah, I see, next patch.
Reviewed-by: Richard Henderson
r~
On 11/19/20 8:17 AM, Philippe Mathieu-Daudé wrote:
> +#if defined(TARGET_ABI_MIPSO32)
> +#define TARGET_SYSCALL_OFFSET 4000
> +#include "syscall_o32_nr.h"
Where does this get built?
r~
On 11/19/20 8:17 AM, Philippe Mathieu-Daudé wrote:
> 64-bit MIPS targets lost setup_frame() during the refactor in commit
> 8949bef18b9. Restore it declaring TARGET_ARCH_HAS_SETUP_FRAME, to be
> able to build the o32 ABI target.
>
> Fixes: 8949bef18b9 ("linux-user: move mips/mips64 signal.c parts
On Thu, 29 Oct 2020 19:08:26 -0500
Taylor Simpson wrote:
> +from hex_common import *
I'd suggest to avoid `import *`.
See:
python -c 'import this' | sed -n '4p'
--
Alessandro Di Federico
rev.ng
On Thu, 29 Oct 2020 19:08:28 -0500
Taylor Simpson wrote:
> +if __name__ == '__main__':
> +f = io.StringIO()
> +print_tree(f, dectree_normal)
> +print_tree(f, dectree_16bit)
> +if subinsn_groupings:
> +print_tree(f, dectree_subinsn_groupings)
> +for (name,
On 11/19/20 8:05 AM, Philippe Mathieu-Daudé wrote:
> Currently MIPS exceptions are displayed as string in system-mode
> emulation, but as number in user-mode.
> Unify by extracting the current system-mode code as excp_name()
> and use that in user-mode.
>
> Signed-off-by: Philippe Mathieu-Daudé
On 11/18/20 7:04 AM, Rémi Denis-Courmont wrote:
> From: Rémi Denis-Courmont
>
> Using a target unsigned long would limit the Input Address to a LPAE
> page-walk to 32 bits on AArch32 and 64 bits on AArch64. This is okay
> for stage 1 or on AArch64, but it is insufficient for stage 2 on
>
I've been doodling a new Asyncio-based QMP library that might fix some
of the problems[1][2] with our older, non-async QMP library and provide
a better basis for a proper distributable python package for people to
write their own toy scripts to control QEMU.
It's a very early prototype, but I
On 11/18/20 12:29 AM, frank.ch...@sifive.com wrote:
> This patchset implements RISC-V B-extension latest draft version
> (2020.10.26) Zbb, Zbs and Zba subset instructions.
With some additional instructions from Zbp, it seems. Although the document
isn't completely coherent, with various
On 11/19/20 10:56 PM, Peter Maydell wrote:
> Correct a typo in the name we give the NVIC object.
>
> Signed-off-by: Peter Maydell
> ---
> hw/arm/armv7m.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Philippe Mathieu-Daudé
For v8.1M the architecture mandates that CPUs must provide at
least the "minimal RAS implementation" from the Reliability,
Availability and Serviceability extension. This consists of:
* an ESB instruction which is a NOP
-- since it is in the HINT space we need only add a comment
* an RFSR
v8.1M introduces a new TRD flag in the CCR register, which enables
checking for stack frame integrity signatures on SG instructions.
Add the code in the SG insn implementation for the new behaviour.
Signed-off-by: Peter Maydell
---
target/arm/m_helper.c | 86
On 11/18/20 12:29 AM, frank.ch...@sifive.com wrote:
> +addwu 101 .. 000 . 0111011 @r
> +subwu 0100101 .. 000 . 0111011 @r
> +addu_w 100 .. 000 . 0111011 @r
>
> sbsetiw0010100 .. 001 . 0011011 @sh5
> sbclriw0100100
v8.1M adds new encodings of VLLDM and VLSTM (where bit 7 is set).
The only difference is that:
* the old T1 encodings UNDEF if the implementation implements 32
Dregs (this is currently architecturally impossible for M-profile)
* the new T2 encodings have the implementation-defined option to
v8.1M introduces a new TRD flag in the CCR register, which enables
checking for stack frame integrity signatures on SG instructions.
This bit is not banked, and is always RAZ/WI to Non-secure code.
Adjust the code for handling CCR reads and writes to handle this.
Signed-off-by: Peter Maydell
---
On 11/19/20 10:56 PM, Peter Maydell wrote:
> Factor out the code which handles M-profile lazy FP state preservation
> from full_vfp_access_check(); accesses to the FPCXT_NS register are
> a special case which need to do just this part (corresponding in the
> pseudocode to the PreserveFPState()
The CCR is a register most of whose bits are banked between security
states but where BFHFNMIGN is not, and we keep it in the non-secure
entry of the v7m.ccr[] array. The logic which tries to handle this
bit fails to implement the "RAZ/WI from Nonsecure if AIRCR.BFHFNMINS
is zero" requirement;
In commit 077d7449100d824a4 we added code to handle the v8M
requirement that returns from NMI or HardFault forcibly deactivate
those exceptions regardless of what interrupt the guest is trying to
deactivate. Unfortunately this broke the handling of the "illegal
exception return because the
In v8.1M a REVIDR register is defined, which is at address 0xe00ecfc
and is a read-only IMPDEF register providing implementation specific
minor revision information, like the v8A REVIDR_EL1. Implement this.
Signed-off-by: Peter Maydell
---
hw/intc/armv7m_nvic.c | 5 +
1 file changed, 5
Thanks Alex,
do you think you could also give it a try linking with LLD?
just add --extra-ldflags="-fuse-ld=lld"
I do see some small differences when moving from BFD ro LLD, but they
should not be of importance. The position of the data.fuzz* is kept.
size -A on qemu-fuzz-i386, LTO DISABLED:
In v8.1M a new exception return check is added which may cause a NOCP
UsageFault (see rule R_XLTP): before we clear s0..s15 and the FPSCR
we must check whether access to CP10 from the Security state of the
returning exception is disabled; if it is then we must take a fault.
(Note that for our
The FPDSCR register has a similar layout to the FPSCR. In v8.1M it
gains new fields FZ16 (if half-precision floating point is supported)
and LTPSIZE (always reads as 4). Update the reset value and the code
that handles writes to this register accordingly.
Signed-off-by: Peter Maydell
---
Now that we have implemented all the features needed by the v8.1M
architecture, we can add the model of the Cortex-M55. This is the
configuration without MVE support; we'll add MVE later.
Signed-off-by: Peter Maydell
---
target/arm/cpu_tcg.c | 42 ++
1
Hi Alex,
Yeah I assumed it was an older version because the errors triggered by
clang11 stop the compilation.
I checked again and for oss-fuzz, you disable failing on warnings.
So again, these patches are not directly connected to CFI and therefore
could land independently.
On 11/6/2020 9:58
The RAS feature has a block of memory-mapped registers at offset
0x5000 within the PPB. For a "minimal RAS" implementation we provide
no error records and so the only registers that exist in the block
are ERRIIDR and ERRDEVID.
The "RAZ/WI for privileged, BusFault for nonprivileged" behaviour
of
Implement the v8.1M FPCXT_NS floating-point system register. This is
a little more complicated than FPCXT_S, because it has specific
handling for "current FP state is inactive", and it only wants to do
PreserveFPState(), not the full set of actions done by
ExecuteFPCheck() which
Correct a typo in the name we give the NVIC object.
Signed-off-by: Peter Maydell
---
hw/arm/armv7m.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/arm/armv7m.c b/hw/arm/armv7m.c
index 944f261dd05..8224d4ade9f 100644
--- a/hw/arm/armv7m.c
+++ b/hw/arm/armv7m.c
@@ -136,7
In v8.1M, vector table fetch failures don't set HFSR.FORCED (see rule
R_LLRP). (In previous versions of the architecture this was either
required or IMPDEF.)
Signed-off-by: Peter Maydell
---
target/arm/m_helper.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
Factor out the code which handles M-profile lazy FP state preservation
from full_vfp_access_check(); accesses to the FPCXT_NS register are
a special case which need to do just this part (corresponding in the
pseudocode to the PreserveFPState() function), and not the full
set of actions matching
Implement the new-in-v8.1M FPCXT_S floating point system register.
This is for saving and restoring the secure floating point context,
and it reads and writes bits [27:0] from the FPSCR and the
CONTROL.SFPA bit in bit [31].
Signed-off-by: Peter Maydell
---
target/arm/translate-vfp.c.inc | 58
v8.1M defines a new FP system register FPSCR_nzcvqc; this behaves
like the existing FPSCR, except that it reads and writes only bits
[31:27] of the FPSCR (the N, Z, C, V and QC flag bits). (Unlike the
FPSCR, the special case for Rt=15 of writing the CPSR.NZCV is not
permitted.)
Implement the
In v8.0M, on exception entry the registers R0-R3, R12, APSR and EPSR
are zeroed for an exception taken to Non-secure state; for an
exception taken to Secure state they become UNKNOWN, and we chose to
leave them at their previous values.
In v8.1M the behaviour is specified more tightly and these
Implement the v8.1M VSCCLRM insn, which zeros floating point
registers if there is an active floating point context.
This requires support in write_neon_element32() for the MO_32
element size, so add it.
Because we want to use arm_gen_condlabel(), we need to move
the definition of that function
Implement the new-in-v8.1M VLDR/VSTR variants which directly
read or write FP system registers to memory.
Signed-off-by: Peter Maydell
---
target/arm/vfp.decode | 14 ++
target/arm/translate-vfp.c.inc | 89 ++
2 files changed, 103 insertions(+)
diff
We defined a constant name for the mask of NZCV bits in the FPCR/FPSCR
in the previous commit; use it in a couple of places in existing code,
where we're masking out everything except NZCV for the "load to Rt=15
sets CPSR.NZCV" special case.
Signed-off-by: Peter Maydell
Reviewed-by: Richard
For M-profile before v8.1M, the only valid register for VMSR/VMRS is
the FPSCR. We have a comment that states this, but the actual logic
to forbid accesses for any other register value is missing, so we
would end up with A-profile style behaviour. Add the missing check.
Signed-off-by: Peter
In v8.1M the new CLRM instruction allows zeroing an arbitrary set of
the general-purpose registers and APSR. Implement this.
The encoding is a subset of the LDMIA T2 encoding, using what would
be Rn=0b (which UNDEFs for LDMIA).
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
The constant-expander functions like negate, plus_2, etc, are
generally useful; move them up in translate.c so we can use them in
the VFP/Neon decoders as well as in the A32/T32/T16 decoders.
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
---
target/arm/translate.c | 46
In arm_cpu_realizefn() we check whether the board code disabled EL3
via the has_el3 CPU object property, which we create if the CPU
starts with the ARM_FEATURE_EL3 feature bit. If it is disabled, then
we turn off ARM_FEATURE_EL3 and also zero out the relevant fields in
the ID_PFR1 and ID_AA64PFR0
Currently M-profile borrows the A-profile code for VMSR and VMRS
(access to the FP system registers), because all it needs to support
is the FPSCR. In v8.1M things become significantly more complicated
in two ways:
* there are several new FP system registers; some have side effects
on read,
In v8.1M the PXN architecture extension adds a new PXN bit to the
MPU_RLAR registers, which forbids execution of code in the region
from a privileged mode.
This is another feature which is just in the generic "in v8.1M" set
and has no ID register field indicating its presence.
Signed-off-by:
This is a v2 because it's a respin of "target/arm: More v8.1M
features". The bad news is it's nearly doubled in length. The good
news is that this is because the new patches on the end are enough to
implement all the remaining missing v8.1M specifics to the point
where we can provide a
For M-profile CPUs, the range from 0xe000 to 0xe00f is the
Private Peripheral Bus range, which includes all of the memory mapped
devices and registers that are part of the CPU itself, including the
NVIC, systick timer, and debug and trace components like the Data
Watchpoint and Trace unit
On 11/18/20 12:29 AM, frank.ch...@sifive.com wrote:
> From: Kito Cheng
>
> Signed-off-by: Kito Cheng
> Signed-off-by: Frank Chang
> ---
> target/riscv/insn32-64.decode | 3 +++
> target/riscv/insn32.decode | 3 +++
> target/riscv/insn_trans/trans_rvb.c.inc | 23
On 11/18/20 12:29 AM, frank.ch...@sifive.com wrote:
> +static target_ulong do_gorc(target_ulong rs1,
> +target_ulong rs2,
> +const target_ulong masks[])
Similar comments to grev. I'll also say that the masks array should *not* be
local to
On 11/18/20 12:29 AM, frank.ch...@sifive.com wrote:
> +static target_ulong do_grev(target_ulong rs1,
> +target_ulong rs2,
> +const target_ulong masks[])
> +{
I think the masks should be placed here, and not passed in.
What you should pass in
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch
On 11/19/20 3:20 PM, Thomas Huth wrote:
On 19/11/2020 17.57, Eric Farman wrote:
Let's look at the Reset PSW first instead of the contents of memory.
It might be leftover from an earlier system boot when processing
a chreipl.
Signed-off-by: Eric Farman
---
pc-bios/s390-ccw/jump2ipl.c | 20
On 11/19/20 12:35 PM, Richard Henderson wrote:
> On 11/18/20 12:29 AM, frank.ch...@sifive.com wrote:
>> +static bool trans_sbset(DisasContext *ctx, arg_sbset *a)
>> +{
>> +REQUIRE_EXT(ctx, RVB);
>> +return gen_arith(ctx, a, _sbset);
>> +}
>> +
>> +static bool trans_sbseti(DisasContext
On 11/18/20 12:29 AM, frank.ch...@sifive.com wrote:
> +static bool trans_rori(DisasContext *ctx, arg_rori *a)
> +{
> +REQUIRE_EXT(ctx, RVB);
> +
> +if (a->shamt >= TARGET_LONG_BITS) {
> +return false;
> +}
> +
> +return gen_arith_shamt_tl(ctx, a, _gen_rotr_tl);
> +}
We
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch
Sorry, since nobody seems to have capacity to work on this, it's
unlikely that this will ever be implemented in QEMU. Thus I'm closing
this as WontFix for now.
** Changed in: qemu
Status: New => Won't Fix
** Changed in: libvirt (Ubuntu)
Status: Confirmed => Invalid
--
You
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch
On 11/18/20 12:29 AM, frank.ch...@sifive.com wrote:
> +static bool trans_slo(DisasContext *ctx, arg_slo *a)
> +{
> +REQUIRE_EXT(ctx, RVB);
> +return gen_arith(ctx, a, _slo);
> +}
> +
> +static bool trans_sloi(DisasContext *ctx, arg_sloi *a)
> +{
> +REQUIRE_EXT(ctx, RVB);
> +
> +if
On Thu, 19 Nov 2020 at 20:30, Alistair Francis wrote:
>
> On Thu, Nov 5, 2020 at 9:58 AM Alex Bennée wrote:
> > +Currently the only supported machines which use FDT data to boot are
> > +the ARM and RiscV `virt` machines.
>
> RISC-V.
If we're going to be picky, also "Arm" :-)
-- PMM
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch
On Thu, Nov 19, 2020 at 01:21:58PM -0500, Eduardo Habkost wrote:
> On Thu, Nov 19, 2020 at 11:24:52AM +0100, Markus Armbruster wrote:
[...]
> > >> > > +return qnum_from_value((QNumValue) QNUM_VAL_INT(value));
> >
> > No space between between (type) and its operand, please.
> >
> > Could we
On 11/18/20 12:29 AM, frank.ch...@sifive.com wrote:
> +static bool trans_sbset(DisasContext *ctx, arg_sbset *a)
> +{
> +REQUIRE_EXT(ctx, RVB);
> +return gen_arith(ctx, a, _sbset);
> +}
> +
> +static bool trans_sbseti(DisasContext *ctx, arg_sbseti *a)
> +{
> +REQUIRE_EXT(ctx, RVB);
> +
On Thu, Nov 19, 2020 at 04:39:15PM +0100, David Hildenbrand wrote:
> int ram_block_discard_disable(bool state)
> {
> -int old;
> +int ret = 0;
>
> +ram_block_discard_disable_mutex_lock();
> if (!state) {
> -qatomic_dec(_block_discard_disabled);
> -return 0;
> +
19.11.2020 22:31, Vladimir Sementsov-Ogievskiy wrote:
19.11.2020 22:30, Vladimir Sementsov-Ogievskiy wrote:
19.11.2020 19:11, Vladimir Sementsov-Ogievskiy wrote:
16.11.2020 20:59, Peter Maydell wrote:
On Mon, 16 Nov 2020 at 17:34, Alberto Garcia wrote:
Do you know if there is a core dump or
I'm going to close this bug as it seems like the issue that RTOS Pharos
raised is not an issue.
@Teodori Serge please open a new issue if you have a bug. Make sure to
include as much detail as possible and steps to reproduce it.
** Changed in: qemu
Status: New => Invalid
--
You received
I've switched hosts so I would have to run a series of tests to compare.
There are a number of new variables:
1. Windows 10 release (I'm now on Windows 2004)
2. My host OS is now Manjaro
3. CPU is now AMD Ryzen 3900X (before it was Intel 3930k)
4. Kernel is 5.8.18-1-MANJARO
5. qemu 5.1.0
6.
As commented on the patch submission, this should already be handled:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg718331.html
Can you attach the test case that is failing?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
On 19/11/2020 17.57, Eric Farman wrote:
> Let's look at the Reset PSW first instead of the contents of memory.
> It might be leftover from an earlier system boot when processing
> a chreipl.
>
> Signed-off-by: Eric Farman
> ---
> pc-bios/s390-ccw/jump2ipl.c | 20 ++--
> 1 file
1 - 100 of 313 matches
Mail list logo
