From: Jean-Philippe Brucker
AMD IOMMU PTEs have a special mode allowing to specify an arbitrary page
size. Quoting the AMD IOMMU specification: "When the Next Level bits [of
a pte] are 7h, the size of the page is determined by the first zero bit
in the page address, starting from bit 12."
So if
From: Igor Mammedov
Do the same as in commit
(4d027afeb3a97 Virt: ACPI: fix qemu assert due to re-assigned table data
address)
for remaining tables that happen to use saved at
the beginning pointer to build header to avoid assert
when table_data is relocated due to implicit re-size.
In this ca
On Thu, 22 Apr 2021 at 18:23, Andreas Gustafsson
<1743...@bugs.launchpad.net> wrote:
>
> Ottavio Caruso wrote:
> > I am currently using:
> >
> > $ qemu-system-x86_64 --version
> > QEMU emulator version 5.2.0
> >
> > And I have no problem selecting from menu in serial console, so I
> > assume this i
Alpha had two bugs, one with the non-ka_restorer fallback
using the wrong offset, and the other with the ka_restorer
value getting lost in do_sigaction.
Sparc had another bug, where the ka_restorer field was
written to user memory.
Version 2 splits patch 2 into 6.
r~
Richard Henderson (7):
We incorrectly used the offset of the non-rt sigframe.
Reviewed-by: Laurent Vivier
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Richard Henderson
---
linux-user/alpha/signal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/linux-user/alpha/signal.c b/linux-user/alpha
There's no longer a difference between the alpha code and
the generic code.
There is a type difference in target_old_sigaction.sa_flags,
which can be resolved with a very much smaller ifdef, which
allows us to finish sharing the target_sigaction definition.
Signed-off-by: Richard Henderson
---
This means that we can share the TARGET_NR_rt_sigaction code,
and the target_rt_sigaction structure is unused. Untangling
the ifdefs so that target_sigaction can be shared will wait
until the next patch.
Signed-off-by: Richard Henderson
---
linux-user/alpha/target_signal.h | 1 +
linux-user/sy
Use ka_restorer, in line with TARGET_ARCH_HAS_KA_RESTORER
vs TARGET_ARCH_HAS_SA_RESTORER, since Alpha passes this
field as a syscall argument.
Signed-off-by: Richard Henderson
---
linux-user/syscall_defs.h | 2 +-
linux-user/alpha/signal.c | 8
linux-user/syscall.c | 4 ++--
3 file
The value of ka_restorer needs to be saved in sigact_table.
At the moment, the attempt to save it in do_syscall is
improperly clobbering user memory.
Signed-off-by: Richard Henderson
---
linux-user/syscall_defs.h | 2 +-
linux-user/signal.c | 5 -
linux-user/syscall.c | 19 +
Do not access a field that may not be present. This will
become an issue when sharing more code in the next patch.
Signed-off-by: Richard Henderson
---
linux-user/syscall.c | 4
1 file changed, 4 insertions(+)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 36169a0ded..89d6
Initialize variables instead of elses.
Use an else instead of a goto.
Add braces.
Signed-off-by: Richard Henderson
---
linux-user/syscall.c | 32 +---
1 file changed, 13 insertions(+), 19 deletions(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 9bc
Patchew URL:
https://patchew.org/QEMU/20210422230227.314751-1-richard.hender...@linaro.org/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210422230227.314751-1-richard.hender...@linaro.org
Subject: [PATCH v2 0/7] li
On 4/22/21 12:38 PM, Philippe Mathieu-Daudé wrote:
Migration is specific to system emulation.
Restrict current DeviceClass::vmsd to sysemu using #ifdef'ry,
and assert in cpu_exec_realizefn() that dc->vmsd not set under
user emulation.
Signed-off-by: Philippe Mathieu-Daudé
---
cpu.c
On 4/22/21 12:38 PM, Philippe Mathieu-Daudé wrote:
Quoting Peter Maydell [*]:
There are two ways to handle migration for
a CPU object:
(1) like any other device, so it has a dc->vmsd that covers
migration for the whole object. As usual for objects that are a
subclass of a parent
On 4/22/21 12:38 PM, Philippe Mathieu-Daudé wrote:
See rationale in previous commit. Targets should use the vmsd field
of DeviceClass, not CPUClass. As migration is not important on the
avr/lm32/moxie targets, break the migration compatibility and set
the DeviceClass vmsd field.
Signed-off-by: P
On 4/22/21 12:38 PM, Philippe Mathieu-Daudé wrote:
Migration is specific to system emulation.
- Move the CPUClass::vmsd field to SysemuCPUOps,
- restrict VMSTATE_CPU() macro to sysemu,
- vmstate_dummy is now unused, remove it.
Signed-off-by: Philippe Mathieu-Daudé
---
Reviewed-by: Richard He
在 2021/4/23 上午5:34, Cole Robinson 写道:
On 4/22/21 5:42 AM, Bin Meng wrote:
On Thu, Apr 22, 2021 at 5:36 PM Peter Maydell wrote:
On Thu, 22 Apr 2021 at 05:29, Bin Meng wrote:
On Thu, Apr 22, 2021 at 12:36 AM Philippe Mathieu-Daudé
wrote:
Cc'ing Bin.
On 4/21/21 5:22 PM, Cole Robinson wrote
On 4/21/2021 11:18 PM, Eduardo Habkost wrote:
On Wed, Apr 21, 2021 at 10:50:10PM +0800, Xiaoyao Li wrote:
On 4/21/2021 10:12 PM, Eduardo Habkost wrote:
On Wed, Apr 21, 2021 at 02:26:42PM +0800, Chenyi Qiang wrote:
Hi, Eduardo, thanks for your comments!
On 4/21/2021 12:34 AM, Eduardo Habko
The last branch recording (LBR) is a performance monitor unit (PMU)
feature on Intel processors that records a running trace of the most
recent branches taken by the processor in the LBR stack. The QEMU
could configure whether it's enabled or not for each guest via CLI.
The LBR feature would be en
Instead of hardcoding the PERF_CAPABILITIES rules in this loop,
this could become a FeatureWordInfo field. It would be very useful
for other features like intel-pt, where we need some bits to match
the host bits too.
Suggested-by: Eduardo Habkost
Signed-off-by: Like Xu
---
target/i386/cpu.c | 2
There could be case that peer is NULL. This can happen when during
network device hot-add where net device needs to be added first. So
the patch check the existence of peer before trying to do the pad.
Fixes: 969e50b61a285 ("net: Pad short frames to minimum size before sending
from SLiRP/TAP")
Si
On Fri, Apr 23, 2021 at 11:18 AM Jason Wang wrote:
>
> There could be case that peer is NULL. This can happen when during
> network device hot-add where net device needs to be added first. So
> the patch check the existence of peer before trying to do the pad.
>
> Fixes: 969e50b61a285 ("net: Pad s
On Thu, Apr 22, 2021 at 04:35:34PM -0300, Fabiano Rosas wrote:
> Bruno Piazera Larsen writes:
>
> >> > You are correct! I've just tweaked the code that defines spr_register and
> >> > it should be working now. I'm still working in splitting the SPR
> >> > functions
> >> > from translate_init, si
[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/1879425
Title:
The thread
[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/1642421
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/1820247
Title:
QEMU random
[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/1725707
Title:
QEMU sends
[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/1615212
Title:
SDL UI swit
[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/1778966
Title:
Windows 180
[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/1395217
Title:
Networking
Ok, thanks for answering! So I'm closing this issue now. In case anybody
still has similar issues, please open a new bug ticket instead.
** Changed in: qemu
Status: Incomplete => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscr
This is inspired by the discussion with Jason on below patchset.
https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg09020.html
The new HMP command is introduced to dump the MSI-X table and PBA.
Initially, I was going to add new option to "info pci". However, as the
number of entries is not
This patch is to add the HMP interface to dump MSI-X table and PBA, in
order to help diagnose the loss of IRQ issue in VM (e.g., if an MSI-X
vector is erroneously masked permanently). Here is the example with
vhost-scsi:
(qemu) info msix /machine/peripheral/vscsi0
MSI-X Table
0xfee01004 0x
From: Klaus Jensen
First patch fixes a regression where msix is not correctly uninit'ed
when an nvme device is hotplugged with device_del. When viewed in
conjunction with the commit that introduced the bug (commit
1901b4967c3f), I think the fix looks relatively obvious.
Second patch disables hot
From: Klaus Jensen
If a controller is linked to a subsystem, do not allow it to be
hotplugged since this will mess up the (possibly shared) namespaces.
Signed-off-by: Klaus Jensen
---
hw/block/nvme.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/block/nvme.c b/hw/block/nvme.c
inde
From: Klaus Jensen
Commit 1901b4967c3f changed the nvme device from using a bar exclusive
for MSI-x to sharing it on bar0.
Unfortunately, the msix_uninit_exclusive_bar() call remains in
nvme_exit() which causes havoc when the device is removed with, say,
device_del. Fix this.
Additionally, a su
Am 23.04.21 um 05:18 schrieb Jason Wang:
There could be case that peer is NULL. This can happen when during
network device hot-add where net device needs to be added first. So
the patch check the existence of peer before trying to do the pad.
Fixes: 969e50b61a285 ("net: Pad short frames to mini
There was a customer request for const_tsc support on AMD guests. Right
now this feature is turned off by default for QEMU x86 CPU types (in
CPUID_Fn8007_EDX[8]). However we are seeing a discrepancy in guest
VM behavior between Intel and AMD.
In Linux kernel, Intel x86 code enables X86_FEA
在 2021/4/23 下午12:47, Dongli Zhang 写道:
This is inspired by the discussion with Jason on below patchset.
https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg09020.html
The new HMP command is introduced to dump the MSI-X table and PBA.
Initially, I was going to add new option to "info pci"
在 2021/4/23 下午1:42, Stefan Weil 写道:
Am 23.04.21 um 05:18 schrieb Jason Wang:
There could be case that peer is NULL. This can happen when during
network device hot-add where net device needs to be added first. So
the patch check the existence of peer before trying to do the pad.
Fixes: 969e50
On Thu, Apr 22, 2021 at 06:54:21PM +0200, Philippe Mathieu-Daudé wrote:
On 4/22/21 6:07 PM, Thomas Huth wrote:
On 22/04/2021 17.52, Stefano Garzarella wrote:
On Thu, Apr 22, 2021 at 05:38:26PM +0200, Thomas Huth wrote:
On 22/04/2021 16.31, Philippe Mathieu-Daudé wrote:
On 4/22/21 2:41 PM, Chr
On Mon, Feb 8, 2021 at 10:41 PM Bin Meng wrote:
>
> On Thu, Jan 21, 2021 at 10:18 PM Francisco Iglesias
> wrote:
> >
> > Hi Bin,
> >
> > On [2021 Jan 21] Thu 16:59:51, Bin Meng wrote:
> > > Hi Francisco,
> > >
> > > On Thu, Jan 21, 2021 at 4:50 PM Francisco Iglesias
> > > wrote:
> > > >
> > > >
On 23.04.21 08:40, Stefano Garzarella wrote:
On Thu, Apr 22, 2021 at 06:54:21PM +0200, Philippe Mathieu-Daudé wrote:
On 4/22/21 6:07 PM, Thomas Huth wrote:
On 22/04/2021 17.52, Stefano Garzarella wrote:
On Thu, Apr 22, 2021 at 05:38:26PM +0200, Thomas Huth wrote:
On 22/04/2021 16.31, Phili
Hey... new to this list. I was looking for a way to use Unix domain sockets
as a network transport between local VMs.
I'm part of a team where we run dozens if not hundreds of VMs on a single
compute instance which are highly interconnected.
In the current implementation, I use UDP sockets (e
301 - 344 of 344 matches
Mail list logo
