Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: 546d574b11e02bfd5b15cdf1564842c14516dfab
https://github.com/qemu/qemu/commit/546d574b11e02bfd5b15cdf1564842c14516dfab
Author: Frederik van Hövell <[email protected]>
Date: 2024-07-29 (Mon, 29 Jul 2024)
Changed paths:
M hw/char/bcm2835_aux.c
Log Message:
-----------
hw/char/bcm2835_aux: Fix assert when receive FIFO fills up
When a bare-metal application on the raspi3 board reads the
AUX_MU_STAT_REG MMIO register while the device's buffer is
at full receive FIFO capacity
(i.e. `s->read_count == BCM2835_AUX_RX_FIFO_LEN`) the
assertion `assert(s->read_count < BCM2835_AUX_RX_FIFO_LEN)`
fails.
Reported-by: Cryptjar <[email protected]>
Suggested-by: Cryptjar <[email protected]>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/459
Signed-off-by: Frederik van Hövell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
[PMM: commit message tweaks]
Signed-off-by: Peter Maydell <[email protected]>
Commit: 8deba2f36e9f7e34bf1805b08e69699486481c8a
https://github.com/qemu/qemu/commit/8deba2f36e9f7e34bf1805b08e69699486481c8a
Author: Mostafa Saleh <[email protected]>
Date: 2024-07-29 (Mon, 29 Jul 2024)
Changed paths:
M hw/arm/smmuv3-internal.h
Log Message:
-----------
hw/arm/smmuv3: Assert input to oas2bits() is valid
Coverity has spotted a possible problem with the OAS handling
(CID 1558464), where the error return of oas2bits() -1 is not
checked, which can cause an overflow in oas value.
oas2bits() is only called with valid inputs, harden the function
to assert that.
Reported-By: Peter Maydell <[email protected]>
Signed-off-by: Mostafa Saleh <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Eric Auger <[email protected]>
Message-id: [email protected]
Link:
https://lore.kernel.org/qemu-devel/CAFEAcA-H=n-3mhc+el6yjfl1m+x+b+fk3mkgzbn74wnxiff...@mail.gmail.com/
Signed-off-by: Mostafa Saleh <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Commit: 613d0b8ebbf1fa32f8037cb02b7c82f96011ef2d
https://github.com/qemu/qemu/commit/613d0b8ebbf1fa32f8037cb02b7c82f96011ef2d
Author: Akihiko Odaki <[email protected]>
Date: 2024-07-29 (Mon, 29 Jul 2024)
Changed paths:
M target/arm/kvm.c
Log Message:
-----------
target/arm/kvm: Set PMU for host only when available
target/arm/kvm.c checked PMU availability but unconditionally set the
PMU feature flag for the host CPU model, which is confusing. Set the
feature flag only when available.
Signed-off-by: Akihiko Odaki <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Commit: 0d2aac4ab1777162c7a7ecd5a6d5d4de93842116
https://github.com/qemu/qemu/commit/0d2aac4ab1777162c7a7ecd5a6d5d4de93842116
Author: Akihiko Odaki <[email protected]>
Date: 2024-07-29 (Mon, 29 Jul 2024)
Changed paths:
M target/arm/kvm.c
Log Message:
-----------
target/arm/kvm: Do not silently remove PMU
kvm_arch_init_vcpu() used to remove PMU when it is not available even
if the CPU model needs one. It is semantically incorrect, and may
continue execution on a misbehaving host that advertises a CPU model
while lacking its PMU. Keep the PMU when the CPU model needs one, and
let kvm_arm_vcpu_init() fail if the KVM implementation mismatches with
our expectation.
Signed-off-by: Akihiko Odaki <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Commit: e9e640148c676ac2c087a3dd93e3917c8fca25ea
https://github.com/qemu/qemu/commit/e9e640148c676ac2c087a3dd93e3917c8fca25ea
Author: Akihiko Odaki <[email protected]>
Date: 2024-07-29 (Mon, 29 Jul 2024)
Changed paths:
M target/arm/hvf/hvf.c
Log Message:
-----------
hvf: arm: Raise an exception for sysreg by default
Any sysreg access results in an exception unless defined otherwise so
we should raise an exception by default.
Signed-off-by: Akihiko Odaki <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Commit: e6fd3192edb8178613e61f7f0242a774ad8ffa2c
https://github.com/qemu/qemu/commit/e6fd3192edb8178613e61f7f0242a774ad8ffa2c
Author: Akihiko Odaki <[email protected]>
Date: 2024-07-29 (Mon, 29 Jul 2024)
Changed paths:
M target/arm/hvf/hvf.c
Log Message:
-----------
hvf: arm: Properly disable PMU
Setting pmu property used to have no effect for hvf so fix it.
Signed-off-by: Akihiko Odaki <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Commit: 05b8d7249109c44a30352ac86d1f079ec0a8506e
https://github.com/qemu/qemu/commit/05b8d7249109c44a30352ac86d1f079ec0a8506e
Author: Akihiko Odaki <[email protected]>
Date: 2024-07-29 (Mon, 29 Jul 2024)
Changed paths:
M target/arm/hvf/hvf.c
Log Message:
-----------
hvf: arm: Do not advance PC when raising an exception
This is identical with commit 30a1690f2402 ("hvf: arm: Do not advance
PC when raising an exception") but for writes instead of reads.
Fixes: a2260983c655 ("hvf: arm: Add support for GICv3")
Signed-off-by: Akihiko Odaki <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Commit: 0892fffc2abaadfb5d8b79bb0250ae1794862560
https://github.com/qemu/qemu/commit/0892fffc2abaadfb5d8b79bb0250ae1794862560
Author: Peter Maydell <[email protected]>
Date: 2024-07-29 (Mon, 29 Jul 2024)
Changed paths:
M hw/misc/bcm2835_property.c
Log Message:
-----------
hw/misc/bcm2835_property: Fix handling of FRAMEBUFFER_SET_PALETTE
The documentation of the "Set palette" mailbox property at
https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface#set-palette
says it has the form:
Length: 24..1032
Value:
u32: offset: first palette index to set (0-255)
u32: length: number of palette entries to set (1-256)
u32...: RGBA palette values (offset to offset+length-1)
We get this wrong in a couple of ways:
* we aren't checking the offset and length are in range, so the guest
can make us spin for a long time by providing a large length
* the bounds check on our loop is wrong: we should iterate through
'length' palette entries, not 'length - offset' entries
Fix the loop to implement the bounds checks and get the loop
condition right. In the process, make the variables local to
this switch case, rather than function-global, so it's clearer
what type they are when reading the code.
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
Commit: 32f1c201eedf992c2ac8033d8af95f1ff1758a4d
https://github.com/qemu/qemu/commit/32f1c201eedf992c2ac8033d8af95f1ff1758a4d
Author: Peter Maydell <[email protected]>
Date: 2024-07-29 (Mon, 29 Jul 2024)
Changed paths:
M hw/misc/bcm2835_property.c
Log Message:
-----------
hw/misc/bcm2835_property: Avoid overflow in OTP access properties
Coverity points out that in our handling of the property
RPI_FWREQ_SET_CUSTOMER_OTP we have a potential overflow. This
happens because we read start_num and number from the guest as
unsigned 32 bit integers, but then the variable 'n' we use as a loop
counter as we iterate from start_num to start_num + number is only an
"int". That means that if the guest passes us a very large start_num
we will interpret it as negative. This will result in an assertion
failure inside bcm2835_otp_set_row(), which checks that we didn't
pass it an invalid row number.
A similar issue applies to all the properties for accessing OTP rows
where we are iterating through with a start and length read from the
guest.
Use uint32_t for the loop counter to avoid this problem. Because in
all cases 'n' is only used as a loop counter, we can do this as
part of the for(), restricting its scope to exactly where we need it.
Resolves: Coverity CID 1549401
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
Commit: 4b648238b8dd9870280b60ff32bf7fe2fe82607f
https://github.com/qemu/qemu/commit/4b648238b8dd9870280b60ff32bf7fe2fe82607f
Author: Peter Maydell <[email protected]>
Date: 2024-07-29 (Mon, 29 Jul 2024)
Changed paths:
M hw/misc/bcm2835_property.c
Log Message:
-----------
hw/misc/bcm2835_property: Restrict scope of start_num, number, otp_row
In the long function bcm2835_property_mbox_push(), the variables
start_num, number and otp_row are used only in the four cases which
access OTP data, and their uses don't overlap with each other.
Make these variables have scope restricted to the cases where they're
used, so it's easier to read each individual case without having to
cross-refer up to the variable declaration at the top of the function
and check whether the variable is also used later in the loop.
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
Commit: 28fe81f052f1fcc651c4c4c098de68af73bbe4f6
https://github.com/qemu/qemu/commit/28fe81f052f1fcc651c4c4c098de68af73bbe4f6
Author: Peter Maydell <[email protected]>
Date: 2024-07-29 (Mon, 29 Jul 2024)
Changed paths:
M hw/misc/bcm2835_property.c
Log Message:
-----------
hw/misc/bcm2835_property: Reduce scope of variables in mbox push function
In bcm2835_property_mbox_push(), some variables are defined at function scope
but used only in a smaller scope of the function:
* tag, bufsize, resplen are used only in the body of the while() loop
* tmp is used only for RPI_FWREQ_SET_POWER_STATE (and is badly named)
Declare these variables in the scope where they're needed, so the code
is easier to read.
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
Commit: 56f1c0db928aae0b83fd91c89ddb226b137e2b21
https://github.com/qemu/qemu/commit/56f1c0db928aae0b83fd91c89ddb226b137e2b21
Author: Peter Maydell <[email protected]>
Date: 2024-07-29 (Mon, 29 Jul 2024)
Changed paths:
M target/arm/tcg/translate-sme.c
Log Message:
-----------
target/arm: Don't assert for 128-bit tile accesses when SVL is 128
For an instruction which accesses a 128-bit element tile when
the SVL is also 128 (for example MOV z0.Q, p0/M, ZA0H.Q[w0,0]),
we will assert in get_tile_rowcol():
qemu-system-aarch64: ../../tcg/tcg-op.c:926: tcg_gen_deposit_z_i32: Assertion
`len > 0' failed.
This happens because we calculate
len = ctz32(streaming_vec_reg_size(s)) - esz;$
but if the SVL and the element size are the same len is 0, and
the deposit operation asserts.
In this case the ZA storage contains exactly one 128 bit
element ZA tile, and the horizontal or vertical slice is just
that tile. This means that regardless of the index value in
the Ws register, we always access that tile. (In pseudocode terms,
we calculate (index + offset) MOD 1, which is 0.)
Special case the len == 0 case to avoid hitting the assertion
in tcg_gen_deposit_z_i32().
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
Commit: ea3f5a90f036734522e9af3bffd77e69e9f47355
https://github.com/qemu/qemu/commit/ea3f5a90f036734522e9af3bffd77e69e9f47355
Author: Peter Maydell <[email protected]>
Date: 2024-07-29 (Mon, 29 Jul 2024)
Changed paths:
M target/arm/tcg/sme_helper.c
Log Message:
-----------
target/arm: Fix UMOPA/UMOPS of 16-bit values
The UMOPA/UMOPS instructions are supposed to multiply unsigned 8 or
16 bit elements and accumulate the products into a 64-bit element.
In the Arm ARM pseudocode, this is done with the usual
infinite-precision signed arithmetic. However our implementation
doesn't quite get it right, because in the DEF_IMOP_64() macro we do:
sum += (NTYPE)(n >> 0) * (MTYPE)(m >> 0);
where NTYPE and MTYPE are uint16_t or int16_t. In the uint16_t case,
the C usual arithmetic conversions mean the values are converted to
"int" type and the multiply is done as a 32-bit multiply. This means
that if the inputs are, for example, 0xffff and 0xffff then the
result is 0xFFFE0001 as an int, which is then promoted to uint64_t
for the accumulation into sum; this promotion incorrectly sign
extends the multiply.
Avoid the incorrect sign extension by casting to int64_t before
the multiply, so we do the multiply as 64-bit signed arithmetic,
which is a type large enough that the multiply can never
overflow into the sign bit.
(The equivalent 8-bit operations in DEF_IMOP_32() are fine, because
the 8-bit multiplies can never overflow into the sign bit of a
32-bit integer.)
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2372
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
Commit: 76916dfa89e8900639c1055c07a295c06628a0bc
https://github.com/qemu/qemu/commit/76916dfa89e8900639c1055c07a295c06628a0bc
Author: Peter Maydell <[email protected]>
Date: 2024-07-29 (Mon, 29 Jul 2024)
Changed paths:
M target/arm/tcg/translate-sve.c
Log Message:
-----------
target/arm: Avoid shifts by -1 in tszimm_shr() and tszimm_shl()
The function tszimm_esz() returns a shift amount, or possibly -1 in
certain cases that correspond to unallocated encodings in the
instruction set. We catch these later in the trans_ functions
(generally with an "a-esz < 0" check), but before we do the
decodetree-generated code will also call tszimm_shr() or tszimm_sl(),
which will use the tszimm_esz() return value as a shift count without
checking that it is not negative, which is undefined behaviour.
Avoid the UB by checking the return value in tszimm_shr() and
tszimm_shl().
Cc: [email protected]
Resolves: Coverity CID 1547617, 1547694
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
Commit: f573ac059ed060234fcef4299fae9e500d357c33
https://github.com/qemu/qemu/commit/f573ac059ed060234fcef4299fae9e500d357c33
Author: Peter Maydell <[email protected]>
Date: 2024-07-29 (Mon, 29 Jul 2024)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Ignore SMCR_EL2.LEN and SVCR_EL2.LEN if EL2 is not enabled
When determining the current vector length, the SMCR_EL2.LEN and
SVCR_EL2.LEN settings should only be considered if EL2 is enabled
(compare the pseudocode CurrentSVL and CurrentNSVL which call
EL2Enabled()).
We were checking against ARM_FEATURE_EL2 rather than calling
arm_is_el2_enabled(), which meant that we would look at
SMCR_EL2/SVCR_EL2 when in Secure EL1 or Secure EL0 even if Secure EL2
was not enabled.
Use the correct check in sve_vqm1_for_el_sm().
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
Commit: b69c95e718ba83fac6d5d725c4a79c4da808ab67
https://github.com/qemu/qemu/commit/b69c95e718ba83fac6d5d725c4a79c4da808ab67
Author: Peter Maydell <[email protected]>
Date: 2024-07-29 (Mon, 29 Jul 2024)
Changed paths:
M target/tricore/op_helper.c
Log Message:
-----------
target/tricore: Use unsigned types for bitops in helper_eq_b()
Coverity points out that in helper_eq_b() we have an int32_t 'msk'
and we end up shifting into its sign bit. This is OK for QEMU because
we use -fwrapv to give this well defined semantics, but when you look
at what this function is doing it's doing bit operations, so we
should be using an unsigned variable anyway. This also matches the
return type of the function.
Make 'ret' and 'msk' uint32_t.
Resolves: Coverity CID 1547758
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
Commit: b42ba4ea4322357fcbfcb0e6e613d79ede84de64
https://github.com/qemu/qemu/commit/b42ba4ea4322357fcbfcb0e6e613d79ede84de64
Author: Peter Maydell <[email protected]>
Date: 2024-07-29 (Mon, 29 Jul 2024)
Changed paths:
M target/xtensa/mmu_helper.c
Log Message:
-----------
target/xtensa: Make use of 'segment' in pptlb helper less confusing
Coverity gets confused about the use of the 'segment' variable in the
pptlb helper function: it thinks that we can take a code path where
we first initialize it:
unsigned segment = XTENSA_MPU_PROBE_B; // 0x40000000
and then use that value as a shift count:
} else if (nhits == 1 && (env->sregs[MPUENB] & (1u << segment))) {
In fact this isn't possible, beacuse xtensa_mpu_lookup() is passed
'&segment', and it uses that as an output value, which it will always
set if it returns nonzero. But the way the code is currently written
is confusing to a human reader as well as to Coverity.
Instead of initializing 'segment' at the top of the function with a
value that's only used in the "nhits == 0" code path, use the
constant value directly in that code path, and don't initialize
segment. This matches the way we use xtensa_mpu_lookup() in its
other callsites in get_physical_addr_mpu().
Resolves: Coverity CID 1547589
Signed-off-by: Peter Maydell <[email protected]>
Acked-by: Max Filippov <[email protected]>
Message-id: [email protected]
Commit: 7d01623a1b0d282430a1e99fbe62068e27a4b4c4
https://github.com/qemu/qemu/commit/7d01623a1b0d282430a1e99fbe62068e27a4b4c4
Author: Peter Maydell <[email protected]>
Date: 2024-07-29 (Mon, 29 Jul 2024)
Changed paths:
M target/m68k/helper.c
Log Message:
-----------
target/m68k: avoid shift into sign bit in dump_address_map()
Coverity complains (CID 1547592) that in dump_address_map() we take a
value stored in a signed integer variable 'i' and shift it by enough
to shift into the sign bit when we construct the value 'logical'.
This isn't a bug for QEMU because we use -fwrapv semantics, but
we can make Coverity happy by using an unsigned type for the loop
variables i, j, k in this function.
While we're changing the declaration of the variables, put them
in the for() loops so their scope is the minimum required (a style
now permitted by our coding style guide).
Resolves: Coverity CID 1547592
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
Commit: bde8adb808eeffb02fdcbd3425f09f1645bdcf4a
https://github.com/qemu/qemu/commit/bde8adb808eeffb02fdcbd3425f09f1645bdcf4a
Author: Peter Maydell <[email protected]>
Date: 2024-07-29 (Mon, 29 Jul 2024)
Changed paths:
M target/i386/tcg/seg_helper.c
Log Message:
-----------
target/i386: Remove dead assignment to ss in do_interrupt64()
Coverity points out that in do_interrupt64() in the "to inner
privilege" codepath we set "ss = 0", but because we also set
"new_stack = 1" there, later in the function we will always override
that value of ss with "ss = 0 | dpl".
Remove the unnecessary initialization of ss, which allows us to
reduce the scope of the variable to only where it is used. Borrow a
comment from helper_lcall_protected() that explains what "0 | dpl"
means here.
Resolves: Coverity CID 1527395
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
Commit: 525650cd71104c046e4260b5acaeb275f520d5c0
https://github.com/qemu/qemu/commit/525650cd71104c046e4260b5acaeb275f520d5c0
Author: Peter Maydell <[email protected]>
Date: 2024-07-29 (Mon, 29 Jul 2024)
Changed paths:
M target/sh4/helper.c
Log Message:
-----------
target/sh4: Avoid shift into sign bit in update_itlb_use()
In update_itlb_use() the variables or_mask and and_mask are uint8_t,
which means that in expressions like "and_mask << 24" the usual C
arithmetic conversions will result in the shift being done as a
signed int type, and so we will shift into the sign bit. For QEMU
this isn't undefined behaviour because we use -fwrapv; but we can
avoid it anyway by using uint32_t types for or_mask and and_mask.
Resolves: Coverity CID 1547628
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Yoshinori Sato <[email protected]>
Message-id: [email protected]
Commit: 73188068d7ba40c8a37b4763db38bb1ce24ca07d
https://github.com/qemu/qemu/commit/73188068d7ba40c8a37b4763db38bb1ce24ca07d
Author: Peter Maydell <[email protected]>
Date: 2024-07-29 (Mon, 29 Jul 2024)
Changed paths:
M system/physmem.c
Log Message:
-----------
system/physmem: Where we assume we have a RAM MR, assert it
In the functions invalidate_and_set_dirty() and
cpu_physical_memory_snapshot_and_clear_dirty(), we assume that we
are dealing with RAM memory regions. In this case we know that
memory_region_get_ram_addr() will succeed. Assert this before we
use the returned ram_addr_t in arithmetic.
This makes Coverity happier about these functions: it otherwise
complains that we might have an arithmetic overflow that stems
from the possible -1 return from memory_region_get_ram_addr().
Resolves: Coverity CID 1547629, 1547715
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Peter Xu <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Message-id: [email protected]
Commit: da4f7b8561e69112171f52279d23b9014902a398
https://github.com/qemu/qemu/commit/da4f7b8561e69112171f52279d23b9014902a398
Author: Richard Henderson <[email protected]>
Date: 2024-07-30 (Tue, 30 Jul 2024)
Changed paths:
M hw/arm/smmuv3-internal.h
M hw/char/bcm2835_aux.c
M hw/misc/bcm2835_property.c
M system/physmem.c
M target/arm/helper.c
M target/arm/hvf/hvf.c
M target/arm/kvm.c
M target/arm/tcg/sme_helper.c
M target/arm/tcg/translate-sme.c
M target/arm/tcg/translate-sve.c
M target/i386/tcg/seg_helper.c
M target/m68k/helper.c
M target/sh4/helper.c
M target/tricore/op_helper.c
M target/xtensa/mmu_helper.c
Log Message:
-----------
Merge tag 'pull-target-arm-20240730' of
https://git.linaro.org/people/pmaydell/qemu-arm into staging
target-arm queue:
* hw/char/bcm2835_aux: Fix assert when receive FIFO fills up
* hw/arm/smmuv3: Assert input to oas2bits() is valid
* target/arm/kvm: Set PMU for host only when available
* target/arm/kvm: Do not silently remove PMU
* hvf: arm: Properly disable PMU
* hvf: arm: Do not advance PC when raising an exception
* hw/misc/bcm2835_property: several minor bugfixes
* target/arm: Don't assert for 128-bit tile accesses when SVL is 128
* target/arm: Fix UMOPA/UMOPS of 16-bit values
* target/arm: Ignore SMCR_EL2.LEN and SVCR_EL2.LEN if EL2 is not enabled
* system/physmem: Where we assume we have a RAM MR, assert it
* sh4, i386, m68k, xtensa, tricore, arm: fix minor Coverity issues
# -----BEGIN PGP SIGNATURE-----
#
# iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAmaotMAZHHBldGVyLm1h
# eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3rsAEACIzQDAMKWy8DlB8o4W+a/l
# yqGijQ5e0JdAifEA2rsDbnaIs/kqDzVxBc0dgIXDxETe5LVZHB742q4vMbaSpSb2
# P8xuL0Q7NRpcIN4THPwLxW0wED+asaJc2TeyImPQRTRhLgk6yn+/4hpqQRkT0mxe
# oxxN8bnx9RssqHZ6pQCv5HYNLex3a7dljXlbjWr4KpRRFSMls1cxPSphsK1aZ1xV
# 3NXh/vgHcM0LquwxdF0uaPdPGQ1SyZb5KZ9khd0o4cpDivkns/hXQpyJ45nHsypK
# kG/TbFQsXPorprWCqBDOXY9rCM6eBDuK89mClKA34EzukIFlSMfIgxfezCzNIXaU
# o/cJCGpSzZnCdvZagEWDzkdryE3QFmmpBFRs8mcS3sb+/gm0O8YyMoCrdV87O3c5
# Y/NY1adOKTVf8FLlT3jR93k4pT6wiqIQND13fN3EbnUqfrGpocSyMD0VsYBj/gij
# PHPBFHAwCEDKVZSq6SViXdkS15arqL2V2mnOogeY1v0jTj2YRG3FyjrPOatg6tF5
# 3MoUBjTAp9ENtYHAY6mCr2vAYw6l1xZTKUwkXiO/i8rc4XQQ+A3AHhQLtWdu2K5+
# dv1E7QKur5O6FDmJxB5s/vGppfnkSUD6EEvViNSCj+hX0U9SyT80e/KClMehgJqQ
# +oME+fRoBHj1DUw4qasWsg==
# =NNxN
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 30 Jul 2024 07:39:12 PM AEST
# gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg: issuer "[email protected]"
# gpg: Good signature from "Peter Maydell <[email protected]>" [full]
# gpg: aka "Peter Maydell <[email protected]>" [full]
# gpg: aka "Peter Maydell <[email protected]>"
[full]
# gpg: aka "Peter Maydell <[email protected]>" [unknown]
* tag 'pull-target-arm-20240730' of
https://git.linaro.org/people/pmaydell/qemu-arm: (21 commits)
system/physmem: Where we assume we have a RAM MR, assert it
target/sh4: Avoid shift into sign bit in update_itlb_use()
target/i386: Remove dead assignment to ss in do_interrupt64()
target/m68k: avoid shift into sign bit in dump_address_map()
target/xtensa: Make use of 'segment' in pptlb helper less confusing
target/tricore: Use unsigned types for bitops in helper_eq_b()
target/arm: Ignore SMCR_EL2.LEN and SVCR_EL2.LEN if EL2 is not enabled
target/arm: Avoid shifts by -1 in tszimm_shr() and tszimm_shl()
target/arm: Fix UMOPA/UMOPS of 16-bit values
target/arm: Don't assert for 128-bit tile accesses when SVL is 128
hw/misc/bcm2835_property: Reduce scope of variables in mbox push function
hw/misc/bcm2835_property: Restrict scope of start_num, number, otp_row
hw/misc/bcm2835_property: Avoid overflow in OTP access properties
hw/misc/bcm2835_property: Fix handling of FRAMEBUFFER_SET_PALETTE
hvf: arm: Do not advance PC when raising an exception
hvf: arm: Properly disable PMU
hvf: arm: Raise an exception for sysreg by default
target/arm/kvm: Do not silently remove PMU
target/arm/kvm: Set PMU for host only when available
hw/arm/smmuv3: Assert input to oas2bits() is valid
...
Signed-off-by: Richard Henderson <[email protected]>
Compare: https://github.com/qemu/qemu/compare/ef009e4b4dc0...da4f7b8561e6
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
