On 09/01/2018 05:07 AM, Peter Maydell wrote:
> On 1 September 2018 at 06:11, Wei Huang wrote:
>> This patch adds migration test support for aarch64. The test code, which
>> implements the same functionality as x86, is booted as a kernel in qemu.
>> Here are the design choices we make for
Convert to Binary - counterparts of the already implemented Convert
to Decimal (CVD*) instructions.
Example from the Principles of Operation: 25594C becomes 63FA.
Signed-off-by: Pavel Zbitskiy
---
target/s390x/helper.h | 1 +
target/s390x/insn-data.def | 4 +++
Changes since v4:
* Simplified alignment checks by using tcg_gen_qemu_ld_i64 and
MO_ALIGN*.
Pavel Zbitskiy (3):
target/s390x: use regular spaces in translate.c
target/s390x: exception on non-aligned LPSW(E)
target/s390x: implement CVB, CVBY and CVBG
target/s390x/helper.h | 1
In a few places translate.c contains non-breaking spaces (0xc2 0xa0)
instead of regular ones (0x20):
7c 7c c2 a0 63 63
7c 7c 2063 63
| |c c
This confuses some text editors.
Signed-off-by: Pavel Zbitskiy
Reviewed-by: Thomas Huth
Reviewed-by: David Hildenbrand
---
Both LPSW and LPSWE should raise a specification exception when their
operand is not doubleword aligned.
Signed-off-by: Pavel Zbitskiy
---
target/s390x/translate.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/target/s390x/translate.c b/target/s390x/translate.c
index
Spotted by ASAN:
=
==11893==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1120 byte(s) in 28 object(s) allocated from:
#0 0x7fd0515b0c48 in malloc (/lib64/libasan.so.5+0xeec48)
#1 0x7fd050ffa3c5 in g_malloc
Virtual SMMUv3 requires physical nested stages for VFIO integration.
Let's advertise this.
Signed-off-by: Eric Auger
---
hw/arm/smmuv3.c | 12
1 file changed, 12 insertions(+)
diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
index bb6a24e9b8..80aa4f3793 100644
--- a/hw/arm/smmuv3.c
In case we detect the address space is translated by
a virtual IOMMU which requires nested stages, let's set up
the container with the VFIO_TYPE1_NESTING_IOMMU iommu_type.
Signed-off-by: Eric Auger
---
hw/vfio/common.c | 23 ---
1 file changed, 20 insertions(+), 3
At the point smmu_find_add_as() gets called, the bus number might
not be computed. Let's change the name of IOMMU memory region and
just use the devfn and an incrementing index.
The name only is used for debug.
Signed-off-by: Eric Auger
---
hw/arm/smmu-common.c | 6 +++---
1 file changed, 3
To prepare for testing yet another extension, let's
refactor the code. We introduce vfio_iommu_get_type()
helper which selects the richest API (v2 first). Then
vfio_init_container() does the SET_CONTAINER and
SET_IOMMU ioctl calls. So we end up with a switch/case
on the iommu_type which should be
Update the script to import the new iommu.h uapi header.
Signed-off-by: Eric Auger
---
scripts/update-linux-headers.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/update-linux-headers.sh b/scripts/update-linux-headers.sh
index 0a964fe240..3f11e49758 100755
---
Le's rename those notification functions to clearly discriminate
iotlb notifications from looming config notifications.
Signed-off-by: Eric Auger
---
hw/arm/smmu-common.c | 2 +-
hw/arm/smmuv3.c | 2 +-
hw/i386/intel_iommu.c| 10 +-
hw/misc/tz-mpc.c | 8
Current IOMMUNotifiers dedicate to IOTLB related notifications.
We want to introduce notifiers for virtual IOMMU config changes.
Let's create a new IOMMUIOLTBNotifier datatype. This paves the way
to the introduction of an IOMMUConfigNotifier. IOMMUNotifier
now has an iotlb_notifier field. We
The default implementation of memory_region_iommu_replay() shall
not be used as it forces the translation of the whole RAM range.
The purpose of this function is to update the shadow page tables.
However in case of nested stage, there is no shadow page table so
we can simply return.
This code is going to be duplicated soon, so let's introduce
an helper which dma (unp)maps a ram memory section.
No functional change.
Signed-off-by: Eric Auger
---
hw/vfio/common.c | 198 ++-
hw/vfio/trace-events | 4 +-
2 files changed, 123
Up to now vSMMUv3 has not been integrated with VFIO. VFIO
integration requires to program the physical IOMMU consistently
with the guest mappings. However, as opposed to VTD, SMMUv3 has
no "Caching Mode" which allows easy trapping of guest mappings.
This means the vSMMUV3 cannot use the same VFIO
We introduce a new IOMMU Memory Region attribute, IOMMU_ATTR_VFIO_NESTED
which tells whether the virtual IOMMU requires physical nested
stages for VFIO integration. Intel virtual IOMMU supports Caching
Mode and does not require 2 stages at physical level. However virtual
ARM SMMU does not
In case IOMMU config notifiers are attached to the
IOMMU memory region, we execute them, passing as argument
the iommu_guest_stage_config struct updated with the new
viommu translation config. Config notifiers are called on
STE and CD changes. At physical level, they translate into
CMD_CFGI_STE_*
When the MSI route is setup, we know the MSI IOVA and
the doorbell GPA . At that point we can communicate this guest
stage 1 binding to the host. Then the host will be able
to construct a stage 2 binding taking as input address the
doorbell GPA.
We also directly use the iommu memory region
This imports both the iommu.h and vfio.h headers found on branch
https://github.com/eauger/linux/tree/v4.18-2stage-rfc++
Signed-off-by: Eric Auger
---
linux-headers/linux/iommu.h | 157
linux-headers/linux/vfio.h | 28 ++-
2 files changed, 182
In nested mode, legacy vfio_iommu_map_notify MAP/UNMAP notifier
cannot be used anymore. Indeed there is no caching mode in
place that allows to trap MAP events. Only configuration change
and UNMAP events can be trapped. As such we register
- one configuration notifier, whose role is to propagate
Soon this code will be called several times. So let's introduce
an helper.
Signed-off-by: Eric Auger
---
hw/vfio/common.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index 7bd3cc250d..2342bccf38 100644
---
For VFIO integration we will need to pass the
context descriptor table GPA to the host. So let's
decode and store it.
Signed-off-by: Eric Auger
---
hw/arm/smmuv3.c | 1 +
include/hw/arm/smmu-common.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/hw/arm/smmuv3.c
With this patch, an IOMMUNotifier can now be either
an IOTLB notifier or a config notifier. A config notifier
is supposed to be called on guest translation config change.
This gives host a chance to update the physical IOMMU
configuration so that is consistent with the guest view.
The notifier is
As we enable the vectors, we shall have an MSI route setup.
The notification of the stage 1 binding is done on MSI
route setup.
Signed-off-by: Eric Auger
---
hw/vfio/pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 056f3a887a..040a2f39f8 100644
---
Register a MAP notifier to propage MSI stage 1 bindings to
the host. When the notifier gets called, we pass the guest
stage 1 MSI binding to the host. The host can then build
a S2 binding whose entry is the guest MSI doorbell GPA.
Signed-off-by: Eric Auger
---
hw/vfio/common.c | 29
SMMUv3 now is integrated with VFIO by enable the 2 stages of
the physical SMMUv3. This relies on a MAP notifier for MSI
stage 1 binding notification. So let's remove this warning.
Signed-off-by: Eric Auger
---
hw/arm/smmuv3.c | 8
1 file changed, 8 deletions(-)
diff --git
Spotted by ASAN doing some manual testing:
Direct leak of 48 byte(s) in 1 object(s) allocated from:
#0 0x7f5fcdc75e50 in calloc (/lib64/libasan.so.5+0xeee50)
#1 0x7f5fcd47241d in g_malloc0 (/lib64/libglib-2.0.so.0+0x5241d)
#2 0x55f989be92ce in timer_new
** Changed in: qemu
Assignee: (unassigned) => Andy (andyliuliming)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1790268
Title:
the vhd generated by qemu-img not align with MB again.
Status
'D' packets are used by GDB to detach from a process. In multiprocess
mode, the PID to detach from is sent in the request.
Signed-off-by: Luc Michel
---
gdbstub.c | 55 ---
1 file changed, 48 insertions(+), 7 deletions(-)
diff --git
Add multiprocess extension support by enabling multiprocess mode when
the peer requests it, and by replying that we actually support it in the
qSupported reply packet.
Signed-off-by: Luc Michel
---
gdbstub.c | 4
1 file changed, 4 insertions(+)
diff --git a/gdbstub.c b/gdbstub.c
index
Add a structure GDBProcess that represent processes from the GDB
semantic point of view.
CPUs can be split into different processes, by grouping them under a QOM
container named after the GDB_CPU_GROUP_NAME macro (`gdb-group[*]').
Each occurrence of such a container implies the existence of the
Add the gdb_first_cpu() and gdb_next_cpu() to iterate over all
the CPUs in currently attached processes.
Add the gdb_first_cpu_in_process() and gdb_next_cpu_in_process() to
iterate over CPUs of a given process.
Use them to add multiprocess extension support to vCont packets.
Signed-off-by: Luc
When gdb_set_stop_cpu() is called with a CPU associated to a process
currently not attached by the GDB client, return without modifying the
stop CPU. Otherwise, GDB get confused if it receives packets with a
thread-id it does not know about.
Signed-off-by: Luc Michel
---
gdbstub.c | 9 +
Create two separate QOM containers for APUs and RPUs to indicate to the
GDB stub that those CPUs should be put in different processes.
Signed-off-by: Luc Michel
---
hw/arm/xlnx-zynqmp.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/hw/arm/xlnx-zynqmp.c
The gdb_get_cpu_pid() function does the PID lookup for the given CPU. It
checks if the CPU is in a QOM container named after the
GDB_CPU_GROUP_NAME macro. If found, it returns the correponding PID,
which is the group ID plus one (group IDs start at 0, GDB PIDs at 1).
When the CPU is not a child of
This series adds support for the multiprocess extension of the GDB
remote protocol in the QEMU GDB stub.
This extension is useful to split QEMU emulated CPUs in different
processes from the point of view of the GDB client. It adds the
possibility to debug different kind of processors (e.g. an
When a new connection is established, we set the first process to be
attached, and the others detached. The first CPU of the first process
is selected as the current CPU.
Signed-off-by: Luc Michel
---
gdbstub.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff
Change the thread info related packets handling to support multiprocess
extension.
Add the CPUs class name in the extra info to help differentiate
them in multiprocess mode.
Signed-off-by: Luc Michel
---
gdbstub.c | 32 ++--
1 file changed, 22 insertions(+), 10
Change the sC packet handling to support the multiprocess extension.
Instead of returning the first thread, we return the first thread of the
current process.
Signed-off-by: Luc Michel
---
gdbstub.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/gdbstub.c
Change the Xfer:features:read: packet handling to support the
multiprocess extension. This packet is used to request the XML
description of the CPU. In multiprocess mode, different descriptions can
be sent for different processes.
This function now takes the process to send the description for as
Add a couple of helper functions to cope with GDB threads and processes.
The gdb_get_process() function looks for a process given a pid.
The gdb_get_cpu() function returns the CPU corresponding to the (pid,
tid) pair given as parameters.
The read_thread_id() function parses the thread-id sent
Add support for the vAttach packets. In multiprocess mode, GDB sends
them to attach to additional processes.
Signed-off-by: Luc Michel
---
gdbstub.c | 32
1 file changed, 32 insertions(+)
diff --git a/gdbstub.c b/gdbstub.c
index 4bed0a85f3..4874d65a30 100644
Add support for multiprocess extension in gdb_vm_state_change()
function.
Signed-off-by: Luc Michel
---
gdbstub.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/gdbstub.c b/gdbstub.c
index 761cb051c8..4ccd1153ce 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@
Add support for the '!' extended mode packet. This is required for the
multiprocess extension.
Signed-off-by: Luc Michel
---
gdbstub.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gdbstub.c b/gdbstub.c
index af8864e251..4bed0a85f3 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -1281,10
On Sat, Sep 1, 2018 at 12:59 PM, Markus Armbruster wrote:
> Marc-André Lureau writes:
>
>> Let qmp_dispatch() copy the 'id' field. That way any qmp client will
>> conform to the specification, including QGA. Furthermore, it
>> simplifies the work for qemu monitor.
>>
>> Signed-off-by: Marc-André
** Changed in: qemu
Status: New => Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1790268
Title:
the vhd generated by qemu-img not align with MB again.
Status in QEMU:
Invalid
From: Marc-André Lureau
Signed-off-by: Marc-André Lureau
Reviewed-by: Markus Armbruster
Message-Id: <20180829134043.31706-2-marcandre.lur...@redhat.com>
Signed-off-by: Markus Armbruster
---
monitor.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/monitor.c
From: Marc-André Lureau
A chardev may stop trying to write if the associated can_read()
callback returned 0. This happens when the monitor is suspended.
The frontend is supposed to call qemu_chr_fe_accept_input() when it is
ready to accept data again.
An issue was observed with a spice port:
From: Marc-André Lureau
This reverts commit abe3cd0ff7f774966da6842620806ab7576fe4f3.
There is no need to add an additional queue to send the reply to the
IOThread, because QMP response is thread safe, and chardev write path
is thread safe. It will schedule the watcher in the associated
From: Peter Xu
When we reach monitor_qmp_setup_handlers_bh() we must be using the
IOThread then, so no need to check against it any more. Instead, we
assert.
Reviewed-by: Markus Armbruster
Signed-off-by: Peter Xu
Message-Id: <20180815133747.25032-2-pet...@redhat.com>
[Insufficiently useful
From: Marc-André Lureau
There is no need for per-command need_resume granularity, it should
resume after running an non-oob command on oob-disabled monitor.
Signed-off-by: Marc-André Lureau
Reviewed-by: Markus Armbruster
Message-Id: <20180829134043.31706-5-marcandre.lur...@redhat.com>
The following changes since commit 19b599f7664b2ebfd0f405fb79c14dd241557452:
Merge remote-tracking branch 'remotes/armbru/tags/pull-error-2018-08-27-v2'
into staging (2018-08-27 16:44:20 +0100)
are available in the Git repository at:
git://repo.or.cz/qemu/armbru.git
From: Marc-André Lureau
Signed-off-by: Marc-André Lureau
Reviewed-by: Markus Armbruster
Message-Id: <20180829134043.31706-3-marcandre.lur...@redhat.com>
Signed-off-by: Markus Armbruster
---
include/qapi/qmp/dispatch.h | 2 +-
qapi/qmp-dispatch.c | 2 +-
2 files changed, 2
Marc-André Lureau writes:
> Let qmp_dispatch() copy the 'id' field. That way any qmp client will
> conform to the specification, including QGA. Furthermore, it
> simplifies the work for qemu monitor.
>
> Signed-off-by: Marc-André Lureau
> Reviewed-by: Markus Armbruster
> Reviewed-by: Michael
>On Mon, Aug 27, 2018 at 11:17:49PM +0800, peng.h...@zte.com.cn wrote:
>> >On Mon, Aug 27, 2018 at 04:25:00PM +0800, peng.h...@zte.com.cn wrote:
>> >> >
>> >> >Is there a reason to not register this port as coalesced PIO also for
>> >> >Q35?
>> >> >In q35_host_realize()?
>> >> >If not, I would
On 1 September 2018 at 06:11, Wei Huang wrote:
> This patch adds migration test support for aarch64. The test code, which
> implements the same functionality as x86, is booted as a kernel in qemu.
> Here are the design choices we make for aarch64:
>
> * We choose this -kernel approach because
** Description changed:
I'm using this version on xenial,
andy@bastion:~/temp$ qemu-img -h
qemu-img version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.31), Copyright (c)
2004-2008 Fabrice Bellard
steps to repro:
dd if=/dev/zero of=/tmp/azure_config_disk_image20180901-22672-16zxelu
John Snow writes:
> On 08/31/2018 02:08 AM, Markus Armbruster wrote:
>> Eric Blake writes:
>>
>>> On 08/29/2018 08:57 PM, John Snow wrote:
Jobs presently use both an Error object in the case of the create job,
and char strings in the case of generic errors elsewhere.
Unify
Public bug reported:
this is a problem in the qemu-binfmt-conf.sh script and maybe somewhere
else. the version i checked is the current github mirror
https://github.com/qemu/qemu/blob/master/scripts/qemu-binfmt-conf.sh
i am running linux mint 19 32bit on a 32bit x86 cpu and i want to run
some
** Summary changed:
- the vhd generated by qemu-img not align with MiB again.
+ the vhd generated by qemu-img not align with MB 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/1790268
Title:
and even the format is raw:
andy@bastion:~/temp$ qemu-img info papapa2.vhd
image: papapa2.vhd
file format: raw
virtual size: 24M (25166336 bytes)
disk size: 152K
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
last bug report and fixed is
https://bugs.launchpad.net/qemu/+bug/1490611
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1790268
Title:
the vhd generated by qemu-img not align with MiB again.
Public bug reported:
I'm using this version on xenial,
andy@bastion:~/temp$ qemu-img -h
qemu-img version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.31), Copyright (c)
2004-2008 Fabrice Bellard
steps to repro:
dd if=/dev/zero of=/tmp/azure_config_disk_image20180901-22672-16zxelu
bs=1048576 count=24
I'm using this version on xenial,
andy@bastion:~/temp$ qemu-img -h
qemu-img version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.31), Copyright (c)
2004-2008 Fabrice Bellard
qemu-img convert -f raw -O vpc -o subformat=fixed,force_size
/tmp/azure_config_disk_image20180901-22672-16zxelu papapa2.vhd
65 matches
Mail list logo
