Public bug reported:
When using qemu , SMI trigger causes hang/reboot under following
conditions:
1. No KVM but there are more than 1 threads (-smp > 1)
2. When using KVM.
Info:
qemu-system-x86_64 --version
QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.29)
Copyright (c) 2003-2017
This looks like an infrastructure issue. Nothing in the log seems to indicate
an issue.
checkpatch was run locally, and passed.
# ./scripts/checkpatch.pl
0001-target-ppc-Fix-SPE-unavailable-exception-triggering.patch
total: 0 errors, 0 warnings, 192 lines checked
This patch implements functionality for following time64 syscalls:
*mq_timedsend_time64()
This is a year 2038 safe vairant of syscall:
int mq_timedsend(mqd_t mqdes, const char *msg_ptr,
size_t msg_len, unsigned int msg_prio,
const struct
This two patch series introduces functionality for a group
of 4 2038 safe syscalls.
The list of implemented syscalls and implementation details
can be found in the patch commit messages.
Testing method:
The implementation of the implemented syscalls was tested
using already existing
This patch implements functionality for following time64 syscall:
*clock_nanosleep_time64()
This is a year 2038 safe vairant of syscall:
int clock_nanosleep(clockid_t clockid, int flags,
const struct timespec *request,
struct timespec
This patch implements functionality for following time64 syscalls:
*rt_sigtimedwait_time64()
This is a year 2038 safe variant of syscall:
int rt_sigtimedwait(const sigset_t *set, siginfo_t *info,
const struct timespec *timeout, size_t sigsetsize)
Public bug reported:
When using...
a) Intel virtualized graphics (iGVT-g) with dmabuf output
b) QEMU's GTK display with GL output enabled (-display gtk,gl=on)
c) A Wayland compositor (Sway in my case)
a segfault occurs at some point on boot (I guess as soon as the guest starts
using the
Patchew URL:
https://patchew.org/QEMU/20200725191436.31828-1-matthieu.bucchian...@leostella.com/
Hi,
This series failed build test on FreeBSD host. Please find the details below.
The full log is available at
Patchew URL:
https://patchew.org/QEMU/20200725191436.31828-1-matthieu.bucchian...@leostella.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20200725191436.31828-1-matthieu.bucchian...@leostella.com
Subject:
When emulating certain floating point instructions or vector instructions on
PowerPC machines, QEMU did not properly generate the SPE/Embedded Floating-
Point Unavailable interrupt. See the buglink further below for references to
the relevant NXP documentation.
This patch fixes the behavior of
On Sat, Jul 25, 2020 at 9:48 PM Aleksandar Markovic
wrote:
>
>
>
> On Saturday, July 25, 2020, Ahmed Karaman
> wrote:
>>
>> On Sat, Jul 25, 2020 at 2:31 PM Aleksandar Markovic
>> wrote:
>>>
>>>
>>> Hi, Ahmed.
>>>
>>> Yes, somewhat related to John's hints on these comments, it is customary to
** Changed in: qemu
Assignee: (unassigned) => Matthieu Bucchianeri (matthieu-bucchianeri)
** Changed in: qemu
Status: New => In Progress
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
** Changed in: qemu
Status: New => In Progress
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1888918
Title:
qemu-system-ppc: Floating point instructions do not properly generate
the
On Saturday, July 25, 2020, Ahmed Karaman
wrote:
> On Sat, Jul 25, 2020 at 2:31 PM Aleksandar Markovic <
> aleksandar.qemu.de...@gmail.com> wrote:
>
>>
>> Hi, Ahmed.
>>
>> Yes, somewhat related to John's hints on these comments, it is customary
>> to have just a brief description before
Testing performed on the patch sent to the mailing list:
1) make check
2) Run the "spe-bug.c" userspace program, observed the correct result:
# qemu/ppc-softmmu/qemu-system-ppc -nographic -machine mpc8544ds -kernel
buildroot/output/images/uImage -hda buildroot/output/images/rootfs.cpio -append
On Fri, 24 Jul 2020 at 17:43, Gerd Hoffmann wrote:
>
> The following changes since commit 09e0cd773723219d21655587954da2769f64ba01:
>
> Merge remote-tracking branch
> 'remotes/alistair/tags/pull-riscv-to-apply-20200722-1' into staging
> (2020-07-23 19:00:42 +0100)
>
> are available in the Git
Your pipeline has failed.
Project: QEMU ( https://gitlab.com/qemu-project/qemu )
Branch: master ( https://gitlab.com/qemu-project/qemu/-/commits/master )
Commit: 8226a4b8 (
https://gitlab.com/qemu-project/qemu/-/commit/8226a4b88b35aab2d7c95f9dbe2fcd662276685a
)
Commit Message:
> Note that on the MPC8548, it is observed that the "brinc"
> instruction does generate the interrupt, which contradicts
> section 4.2.3 SPE/Embedded Floating-Point Unavailable Interrupt
> of the Signal Processing Engine (SPE) Programming Environments
> Manual, Rev. 0 (see the quote in the
Your pipeline has failed.
Project: QEMU ( https://gitlab.com/qemu-project/qemu )
Branch: master ( https://gitlab.com/qemu-project/qemu/-/commits/master )
Commit: e68808a7 (
https://gitlab.com/qemu-project/qemu/-/commit/e68808a797d0c585b0e82e4a788d1ba8899b01eb
)
Commit Message: Merge
On Fri, 24 Jul 2020 at 17:31, John Snow wrote:
>
> On 7/20/20 4:20 PM, Eduardo Habkost wrote:
> > On Mon, Jul 20, 2020 at 12:02:52PM -0400, John Snow wrote:
> >> 3 seconds is too short for some tests running inside busy VMs. Build it
> >> out to
> >> a rather generous 30 seconds to find out
On Fri, 24 Jul 2020 at 14:47, Markus Armbruster wrote:
>
> The following changes since commit 09e0cd773723219d21655587954da2769f64ba01:
>
> Merge remote-tracking branch
> 'remotes/alistair/tags/pull-riscv-to-apply-20200722-1' into staging
> (2020-07-23 19:00:42 +0100)
>
> are available in the
We forgot to update cc_op before these branch insns,
which lead to losing track of the current eflags.
Buglink: https://bugs.launchpad.net/qemu/+bug/1888165
Reviewed-by: Alex Bennée
Signed-off-by: Richard Henderson
Message-Id: <20200720154028.477457-1-richard.hender...@linaro.org>
---
From: Alex Bennée
I missed Emilio's review comments:
Message-ID: <20200718205107.GA994221@sff>
and the patch got merged. Correcting the comments now.
Reviewed-by: Emilio G. Cota
Signed-off-by: Alex Bennée
Message-Id: <20200720122358.26881-1-alex.ben...@linaro.org>
Signed-off-by: Richard
Two temps allocated but not freed. Do enough subtractions
within a single TB and one can run out of temps entirely.
Fixes: b2167459ae ("target-hppa: Implement basic arithmetic")
Buglink: https://bugs.launchpad.net/qemu/+bug/1880287
Tested-by: Sven Schnelle
Reviewed-by: Philippe Mathieu-Daudé
-tcg-20200725
for you to fetch changes up to 3cb3a7720b01830abd5fbb81819dbb9271bf7821:
target/i386: Save cc_op before loop insns (2020-07-24 14:29:35 -0700)
Fix some cputlb commentary
Fix an hppa temporary leak
Fix an i386
The minimum granularity of PMP is 4 bytes, it is small than 4KB page
size, therefore, the pmp checking would be ignored if its range doesn't
start from the alignment of one page. This patch detects the pmp entries
and sets the small page size to TLB if there is a PMP entry which cover
the page
On Fri, Jul 24, 2020 at 5:22 PM Bin Meng wrote:
>
> Hi Zong,
>
> On Fri, Jul 24, 2020 at 5:08 PM Zong Li wrote:
> >
> > On RV64, the reg_index is 2 (pmpcfg2 CSR) after the seventh pmp
> > entry, it is not 1 (pmpcfg1 CSR) like RV32. In the original
> > implementation, the second parameter of
The real physical address should add the 12 bits page offset. It also
causes the PMP wrong checking due to the minimum granularity of PMP is
4 byte, but we always get the physical address which is 4KB alignment,
that means, we always use the start address of the page to check PMP for
all addresses
On RV64, the reg_index is 2 (pmpcfg2 CSR) after the seventh pmp
entry, it is not 1 (pmpcfg1 CSR) like RV32. In the original
implementation, the second parameter of pmp_write_cfg is
"reg_index * sizeof(target_ulong)", and we get the the result
which is started from 16 if reg_index is 2, but we
The range of Physical Memory Protection should be from CSR_PMPCFG0
to CSR_PMPCFG3, not to CSR_PMPADDR9.
Signed-off-by: Zong Li
Reviewed-by: Alistair Francis
Reviewed-by: Bin Meng
---
target/riscv/csr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/riscv/csr.c
This patch set contains the fixes for wrong index of pmpcfg CSR on rv64,
and the pmp range in CSR function table. After 3rd version of this patch
series, we also fix the PMP issues such as wrong physical address
translation and ignoring PMP checking.
Changed in v5:
- Pick the suggestion which
I noticed that when running the BSD VMs, the Python script that launches
QEMU seems to eat CPU:
peter.m+ 19024 0.0 0.0 20296 11692 pts/12 S+ 15:04 0:00
\_ make -C build vm-build-openbsd J=8 V=1
peter.m+ 19858 98.8 0.0 126272 15220 pts/12 Sl+ 15:04 12:04
\_ /usr/bin/python3
The i440fx and q35 machines integrate i440FX or MCH PCI device by default.
Refer to i440FX and ICH9-LPC spcifications, there are some reserved
configuration registers can used to save/restore PCIHostState.config_reg.
It's nasty but friendly to old ones.
Signed-off-by: Hogan Wang
---
The pci host config register is used to save PCI address for
read/write config data. If guest write a value to config register,
and then pause the vcpu to migrate, After the migration, the guest
continue to write pci config data, and the write data will be ignored
because of new qemu process lost
On Sat, Jul 25, 2020 at 2:31 PM Aleksandar Markovic <
aleksandar.qemu.de...@gmail.com> wrote:
>
> Hi, Ahmed.
>
> Yes, somewhat related to John's hints on these comments, it is customary
> to have just a brief description before "Copyright" lines. This means one
> sentence, or a short paragraph
On Wednesday, July 22, 2020, Ahmed Karaman
wrote:
> Python script that locates the commit that caused a performance
> degradation or improvement in QEMU using the git bisect command
> (binary search).
>
> Syntax:
> bisect.py [-h] -s,--start START [-e,--end END] [-q,--qemu QEMU] \
> --target
On Wednesday, July 15, 2020, Jon Doron wrote:
> Signed-off-by: Jon Doron
> ---
> hw/hyperv/vmbus.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/hw/hyperv/vmbus.c b/hw/hyperv/vmbus.c
> index 34392e892a..c28bb4201b 100644
> --- a/hw/hyperv/vmbus.c
> +++
I was trying to configure latencies and bandwidths between nodes in a NUMA
emulation using QEMU 5.0.0.
Host: Ubuntu 20.04 64 bit
Guest: Ubuntu 18.04 64 bit
The machine configured has 2 nodes. Each node has 2 CPUs and has been
allocated 3GB of memory. The memory access latencies and bandwidths
Public bug reported:
I was trying to configure latencies and bandwidths between nodes in a
NUMA emulation using QEMU 5.0.0.
Host : Ubuntu 20.04 64 bit
Guest : Ubuntu 18.04 64 bit
The machine configured has 2 nodes. Each node has 2 CPUs and has been
allocated 3GB of memory. The memory access
39 matches
Mail list logo
