On 1/29/21 9:15 PM, Stefan Weil wrote:
> If someone decides to use TCG_TARGET_HAS_div2_i64 instead of
> TCG_TARGET_HAS_div_i64 with TCI, that lines (in addition to the implementation
> of the opcodes) would be needed again.
How can you know if those lines are even correct, when there is no
infrast
On 1/29/21 8:36 PM, Eduardo Habkost wrote:
> On Fri, Jan 29, 2021 at 09:19:00AM -1000, Richard Henderson wrote:
>> On 1/28/21 11:00 PM, Claudio Fontana wrote:
>>> Do you think I should redo the series anyway? I would have started this way
>>> in the first place, but I tried not to redo Eduardo's wo
On Fri, Jan 29, 2021 at 11:57 PM Iris Johnson wrote:
>
> Currently, the chardev backend code will prepare for IO polling to occur
> by potentially adding or removing a watch of the backing channel for the
> chardev. The chardev poll is added if the fd_can_read() function reports
> more than 0 byte
Hi
On Fri, Jan 29, 2021 at 11:56 PM Paolo Bonzini wrote:
>
> On 29/01/21 20:49, Peter Maydell wrote:
> > On Fri, 29 Jan 2021 at 11:33, Paolo Bonzini wrote:
> >>
> >> The following changes since commit
> >> 0bcd12fb1513bad44f05f2d3a8eef2a99b3077b6:
> >>
> >>Merge remote-tracking branch 'remo
Hi Philippe,
On Fri, Jan 29, 2021 at 10:11 PM Philippe Mathieu-Daudé wrote:
>
> Hi Bin,
>
> On 1/29/21 9:51 AM, Bin Meng wrote:
> > From: Bin Meng
> >
> > Unlike SD mode, when SD card is working in SPI mode, the argument
> > of CMD13 is stuff bits. Hence we should bypass the RCA check.
>
> Is th
On 1/29/21 1:13 AM, Richard Henderson wrote:
> On 1/28/21 6:29 AM, Philippe Mathieu-Daudé wrote:
>> On 1/28/21 5:08 PM, Alex Bennée wrote:
>>>
>>> Claudio Fontana writes:
>>>
On 1/28/21 2:03 PM, Philippe Mathieu-Daudé wrote:
> On 1/28/21 10:28 AM, Claudio Fontana wrote:
>>>
>> +
On Sat, 30 Jan 2021 at 10:11, Marc-André Lureau
wrote:
> That's weird,
> https://patchew.org/QEMU/20210129111814.566629-1-pbonz...@redhat.com/20210129111814.566629-24-pbonz...@redhat.com/
>
> -Subproject commit 8f43a99191afb47ca3f3c6972f6306209f367ece
> +Subproject commit 5dce846e3ee82d93462bc637
From: Prasad J Pandit
While activating device in vmxnet3_acticate_device(), it does not
validate guest supplied configuration values against predefined
minimum - maximum limits. This may lead to integer overflow or
OOB access issues. Add checks to avoid it.
Fixes: CVE-2021-20203
Buglink: https:/
** Information type changed from Private Security to Public Security
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1913873
Title:
QEMU: net: vmxnet: integer overflow may crash guest
Status in QEMU
+-- On Sat, 23 Jan 2021, P J P wrote --+
| From: Prasad J Pandit
|
| While processing ioport command in 'fdctrl_write_dor', device
| controller may select a drive which is not initialised with a
| block device. This may result in a NULL pointer dereference.
| Add checks to avoid it.
|
| Fixes: C
On 1/30/21 2:52 AM, Philippe Mathieu-Daudé wrote:
> KVM requires a cpu based on (at least) the ARMv7 architecture.
>
> Only enable the following ARMv4 CPUs when TCG is available:
>
> - StrongARM (SA1100/1110)
> - OMAP1510 (TI925T)
>
> The following machines are no more built when TCG is disa
I already used this github URL for PRs before and will continue to use it in
foreseeable future.
Signed-off-by: Christian Schoenebeck
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index bcd88668bc..e8f49aeebd 100644
--- a/MAINTAINERS
+++ b/MAINTAIN
On Sat, 30 Jan 2021 at 01:52, Philippe Mathieu-Daudé wrote:
>
> KVM requires a cpu based on (at least) the ARMv7 architecture.
These days it requires ARMv8, because we dropped 32-bit host
support, and all 64-bit host CPUs are v8.
thanks
-- PMM
>
> > I don't think this works well enough: if the source isn't removed, but
> fd_can_read() returns 0, there is a potential busy loop on the next
> > fd_read().
>
This shouldn't happen. The sources all get set to non-blocking mode, the
only
blocking code is the poll itself. If fd_can_read() retu
bsd-user: Add new mainatiners
The FreeBSD project has a number of enhancements to bsd-user. Add myself
as maintainer and Kyle Evans as a reviewer. Also add our github repo.
Signed-off-by: Warner Losh
---
MAINTAINERS | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/MAINTAI
I was working on preparing this test case for the virt machine (I've been
using a test machine based around the exynos UART).
While looking at the uart code for the virt to find which serial peripheral
it uses (and the register layout), I noticed that the pl011
uart code calls qemu_chr_fe_accept_i
Hi Peter,
On 1/30/21 4:37 PM, Peter Maydell wrote:
> On Sat, 30 Jan 2021 at 01:52, Philippe Mathieu-Daudé wrote:
>>
>> KVM requires a cpu based on (at least) the ARMv7 architecture.
>
> These days it requires ARMv8, because we dropped 32-bit host
> support, and all 64-bit host CPUs are v8.
Oh,
When the frontend device has no space for a read the fd is removed
from polling to allow time for the guest to read and clear the buffer.
Without the call to qemu_chr_fe_accept_input(), the poll will not be
broken out of when the guest has cleared the buffer causing significant
IO delays that get w
On Jan 29 22:23, Aaron Lindsay wrote:
> 1. Is this considered a bug or a "feature"?
> 2.a. If a bug, is there a good way to detect this from inside the
>tcg/plugin infrastructure and avoid calling the callback for the
>faulting execution of the instruction?
> 2.b. If a "feature", is
On Sat, 30 Jan 2021 at 18:36, Philippe Mathieu-Daudé wrote:
>
> Hi Peter,
>
> On 1/30/21 4:37 PM, Peter Maydell wrote:
> > On Sat, 30 Jan 2021 at 01:52, Philippe Mathieu-Daudé
> > wrote:
> >>
> >> KVM requires a cpu based on (at least) the ARMv7 architecture.
> >
> > These days it requires ARMv8
On 1/30/21 12:53 AM, Claudio Fontana wrote:
> To summarize:
>
> 1) accel->cpu_realizefn extends the current cpu target-specific realize
> functions with accelerator-specific code,
>which currently does not make use of errp at all (thus, the temptation to
> remove errp from the interface unti
Hi all,
In light of attempts to get Linux bootstrapped on the new M1 macs I've
been working on supporting them in QEMU as a new machine type, I think
this has benefits for testing and potentially there is desire for an
M1 Mac running QEMU to natively support emulating an M1 Mac and
potentially boo
Public bug reported:
QEMU development version, git commit
74208cd252c5da9d867270a178799abd802b9338. Behaviour has been noted in
5.2.0 generally.
Certain 16-bit windows programs crash WINE under QEMU linux-user with:
0084:err:seh:segv_handler Got unexpected trap -1
wine: Unhandled illegal instruc
Is this the same as https://bugs.launchpad.net/qemu/+bug/1890152 ?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1913873
Title:
QEMU: net: vmxnet: integer overflow may crash guest
Status in QEMU:
Public bug reported:
Reproducer:
cat << EOF | ./qemu-system-aarch64 \
-machine virt,accel=qtest -qtest stdio
write 0x800 0x1 0x02
write 0x801 0x1 0x03
write 0x8010004 0x1 0x10
write 0x8000f2f 0x1 0x0
writel 0x8000f00 0x2065559
write 0x8000d56 0x1 0x0
readl 0x801000b
EOF
Stacktrace:
SUMMAR
Public bug reported:
Reproducer:
cat << EOF | ./qemu-system-aarch64 \
-machine virt,accel=qtest -qtest stdio
writel 0x8000f00 0xff4affb0
writel 0x8000f00 0xf2f8017f
writeq 0x801000e 0x5a5a5a6c8ff7004b
writeq 0x8010010 0x5a5a5a5a73ba2f00
writel 0x800 0x3bf5a03
writel 0x800 0x3bf5a03
writeq
Public bug reported:
Reproducer:
cat << EOF | ./qemu-system-aarch64 \
-machine virt,accel=qtest -qtest stdio
writel 0x8000f00 0x81818191
write 0x4010008004 0x1 0x06
EOF
Stacktrace:
../hw/intc/arm_gic.c:1498:13: runtime error: index 401 out of bounds for type
'uint8_t [16][8]'
SUMMARY: UndefinedB
Public bug reported:
Reproducer:
cat << EOF | ./qemu-system-aarch64 \
-machine virt,accel=qtest -qtest stdio
writel 0x8000f00 0x5affaf
write 0x8000eff 0x1 0x0
EOF
Stacktrace:
../hw/intc/arm_gic.c:1419:17: runtime error: index 3068 out of bounds for type
'gic_irq_state [1020]'
SUMMARY: UndefinedB
** Summary changed:
- arm-virt: Null-ptr dereference through virtio_write_config
+ aarc64-virt: Null-ptr dereference through virtio_write_config
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1913915
Public bug reported:
Reproducer:
cat << EOF | ./qemu-system-aarch64 -qtest stdio \
-machine raspi3b,accel=qtest -m 1G
write 0x3f30002c 0x1 0x25
write 0x3f34 0x1 0x01
write 0x3f36 0x1 0xc0
write 0x3f3c 0x1 0x22
write 0x3f3e 0x1 0x20
write 0x3f3f 0x1 0x0
write 0x3f30 0x1 0x4
Hi John,
Thank you, this is indeed strange. Do you use homebrew? Could you try
the homebrew version and see how that goes?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1913505
Title:
Windows XP s
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1804961
Title:
qemu-system
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1805697
Title:
egl-headles
Public bug reported:
Hello,
I found an assertion failure in hw/net/vmxnet3.c:1793
This was found in latest version 5.2.0.
my reproduced is as follows:
cat << EOF | ./qemu-system-x86_64 \
-device vmxnet3 \
-display none -nodefaults -qtest stdio
outl 0xcf8 0x80001014
outl 0xcfc 0xf0001000
outl
Public bug reported:
# System Details
AMD Ryzen 7 3700U
Ubuntu 20.04 Focal Focus
# Dockerfile
FROM arm32v7/debian:bullseye
RUN apt-get update && apt-get install -y mesa-utils
ENTRYPOINT glxgears
# Instructions For Reproduction
1. Install Docker
2. Build Docker Image: docker build --tag mesa-a
Yes, from the trace looks same.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1913873
Title:
QEMU: net: vmxnet: integer overflow may crash guest
Status in QEMU:
New
Bug description:
* Gaoning
*** This bug is a duplicate of bug 1913873 ***
https://bugs.launchpad.net/bugs/1913873
** This bug has been marked a duplicate of bug 1913873
QEMU: net: vmxnet: integer overflow may crash guest
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subs
From: Vincent Fazio
Previously, pgd_find_hole_fallback assumed that if the build host's libc
had MAP_FIXED_NOREPLACE defined that the address returned by mmap would
match the requested address. This is not a safe assumption for Linux
kernels prior to 4.17
Now, we always compare mmap's resultant
From: Vincent Fazio
Previously, if the build host's libc did not define MAP_FIXED_NOREPLACE
or if the running kernel didn't support that flag, it was possible for
pgd_find_hole_fallback to munmap an incorrect address which could lead to
SIGSEGV if the range happened to overlap with the mapped add
From: Vincent Fazio
Previously, guest_loaddr was not taken into account when returning an
address from pgb_find_hole when /proc/self/maps was unavailable which
caused an improper guest_base address to be calculated.
This could cause a SIGSEGV later in load_elf_image -> target_mmap for
ET_EXEC ty
40 matches
Mail list logo
