Re: [Qemu-devel] [Qemu-block] [PATCH for-2.8] block: Let write zeroes fallback work even with small max_transfer
Am 10.11.2016 um 03:11 hat Fam Zheng geschrieben: > On Wed, 11/09 14:06, Eric Blake wrote: > > On 11/09/2016 07:49 AM, Stefan Hajnoczi wrote: > > > On Tue, Nov 08, 2016 at 04:52:15PM -0600, Eric Blake wrote: > > >> Commit 443668ca rewrote the write_zeroes logic to guarantee that > > >> an unaligned request never crosses a cluster boundary. But > > >> in the rewrite, the new code assumed that at most one iteration > > >> would be needed to get to an alignment boundary. > > >> > > >> However, it is easy to trigger an assertion failure: the Linux > > >> kernel limits loopback devices to advertise a max_transfer of > > >> only 64k. Any operation that requires falling back to writes > > >> rather than more efficient zeroing must obey max_transfer during > > >> that fallback, which means an unaligned head may require multiple > > >> iterations of the write fallbacks before reaching the aligned > > >> boundaries, when layering a format with clusters larger than 64k > > >> atop the protocol of file access to a loopback device. > > >> > > >> Test case: > > >> > > >> $ qemu-img create -f qcow2 -o cluster_size=1M file 10M > > >> $ losetup /dev/loop2 /path/to/file > > >> $ qemu-io -f qcow2 /dev/loop2 > > >> qemu-io> w 7m 1k > > >> qemu-io> w -z 8003584 2093056 > > > > > > Please include a qemu-iotests test case to protect against regressions. > > > > None of the existing qemu-iotests use losetup; I guess the closest thing > > to do is crib from a test that uses passwordless sudo? > > > > It will certainly be a separate commit, but I'll give it my best shot to > > post something soon. > > Alternatively, maybe add a blkdebug option to emulate a small max_transfer at > the protocol layer? This sounds like the better option indeed. Kevin
Re: [Qemu-devel] [PATCH v11 09/22] vfio iommu type1: Add task structure to vfio_dma
* Kirti Wankhede [2016-11-05 02:40:43 +0530]:
Hi Kirti,
[...]
> static int vfio_dma_do_map(struct vfio_iommu *iommu,
> struct vfio_iommu_type1_dma_map *map)
> {
> dma_addr_t iova = map->iova;
> unsigned long vaddr = map->vaddr;
> size_t size = map->size;
> - long npage;
> int ret = 0, prot = 0;
> uint64_t mask;
> struct vfio_dma *dma;
> - unsigned long pfn;
> + struct vfio_addr_space *addr_space;
> + struct mm_struct *mm;
> + bool free_addr_space_on_err = false;
>
> /* Verify that none of our __u64 fields overflow */
> if (map->size != size || map->vaddr != vaddr || map->iova != iova)
> @@ -608,47 +685,56 @@ static int vfio_dma_do_map(struct vfio_iommu *iommu,
> mutex_lock(&iommu->lock);
>
> if (vfio_find_dma(iommu, iova, size)) {
> - mutex_unlock(&iommu->lock);
> - return -EEXIST;
> + ret = -EEXIST;
> + goto do_map_err;
> + }
> +
> + mm = get_task_mm(current);
> + if (!mm) {
> + ret = -ENODEV;
> + goto do_map_err;
> + }
> +
> + addr_space = vfio_find_addr_space(iommu, mm);
> + if (addr_space) {
> + atomic_inc(&addr_space->ref_count);
> + mmput(mm);
> + } else {
> + addr_space = kzalloc(sizeof(*addr_space), GFP_KERNEL);
> + if (!addr_space) {
> + ret = -ENOMEM;
No need to call (?):
mmput(mm);
> + goto do_map_err;
> + }
> + addr_space->mm = mm;
> + atomic_set(&addr_space->ref_count, 1);
> + list_add(&addr_space->next, &iommu->addr_space_list);
> + free_addr_space_on_err = true;
> }
>
> dma = kzalloc(sizeof(*dma), GFP_KERNEL);
> if (!dma) {
> - mutex_unlock(&iommu->lock);
> - return -ENOMEM;
> + if (free_addr_space_on_err) {
> + mmput(mm);
> + list_del(&addr_space->next);
> + kfree(addr_space);
> + }
> + ret = -ENOMEM;
> + goto do_map_err;
> }
>
> dma->iova = iova;
> dma->vaddr = vaddr;
> dma->prot = prot;
> + dma->addr_space = addr_space;
> + get_task_struct(current);
> + dma->task = current;
> + dma->mlock_cap = capable(CAP_IPC_LOCK);
>
> /* Insert zero-sized and grow as we map chunks of it */
> vfio_link_dma(iommu, dma);
>
> - while (size) {
> - /* Pin a contiguous chunk of memory */
> - npage = __vfio_pin_pages_remote(vaddr + dma->size,
> - size >> PAGE_SHIFT, prot, &pfn);
> - if (npage <= 0) {
> - WARN_ON(!npage);
> - ret = (int)npage;
> - break;
> - }
> -
> - /* Map it! */
> - ret = vfio_iommu_map(iommu, iova + dma->size, pfn, npage, prot);
> - if (ret) {
> - __vfio_unpin_pages_remote(pfn, npage, prot, true);
> - break;
> - }
> -
> - size -= npage << PAGE_SHIFT;
> - dma->size += npage << PAGE_SHIFT;
> - }
> -
> - if (ret)
> - vfio_remove_dma(iommu, dma);
> -
> + ret = vfio_pin_map_dma(iommu, dma, size);
> +do_map_err:
> mutex_unlock(&iommu->lock);
> return ret;
> }
> --
> 2.7.0
>
--
Dong Jia
[Qemu-devel] [PATCH] qtest: fix a memory leak
Spotted by ASAN. Signed-off-by: Marc-André Lureau --- qtest.c | 1 + 1 file changed, 1 insertion(+) diff --git a/qtest.c b/qtest.c index 46b99ae..39a73c4 100644 --- a/qtest.c +++ b/qtest.c @@ -240,6 +240,7 @@ static void GCC_FMT_ATTR(2, 3) qtest_sendf(CharBackend *chr, va_start(ap, fmt); buffer = g_strdup_vprintf(fmt, ap); qtest_send(chr, buffer); +g_free(buffer); va_end(ap); } -- 2.10.0
[Qemu-devel] [PATCH] tests: fix qmp response leak
Spotted by ASAN.
Signed-off-by: Marc-André Lureau
---
tests/libqos/usb.c | 1 +
tests/postcopy-test.c | 2 +-
tests/pvpanic-test.c | 1 +
tests/test-filter-mirror.c | 2 +-
tests/test-filter-redirector.c | 4 ++--
tests/virtio-blk-test.c| 15 +--
6 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/tests/libqos/usb.c b/tests/libqos/usb.c
index 72d7a96..98408d9 100644
--- a/tests/libqos/usb.c
+++ b/tests/libqos/usb.c
@@ -64,4 +64,5 @@ void usb_test_hotplug(const char *hcd_id, const int port,
g_assert(response);
g_assert(qdict_haskey(response, "event"));
g_assert(!strcmp(qdict_get_str(response, "event"), "DEVICE_DELETED"));
+QDECREF(response);
}
diff --git a/tests/postcopy-test.c b/tests/postcopy-test.c
index d6613c5..985d797 100644
--- a/tests/postcopy-test.c
+++ b/tests/postcopy-test.c
@@ -478,7 +478,7 @@ static void test_migrate(void)
usleep(10 * 1000);
} while (dest_byte_a == dest_byte_b);
-qmp("{ 'execute' : 'stop'}");
+qmp_discard_response("{ 'execute' : 'stop'}");
/* With it stopped, check nothing changes */
qtest_memread(to, start_address, &dest_byte_c, 1);
sleep(1);
diff --git a/tests/pvpanic-test.c b/tests/pvpanic-test.c
index 3bfa678..71ebb5c 100644
--- a/tests/pvpanic-test.c
+++ b/tests/pvpanic-test.c
@@ -27,6 +27,7 @@ static void test_panic(void)
data = qdict_get_qdict(response, "data");
g_assert(qdict_haskey(data, "action"));
g_assert_cmpstr(qdict_get_str(data, "action"), ==, "pause");
+QDECREF(response);
}
int main(int argc, char **argv)
diff --git a/tests/test-filter-mirror.c b/tests/test-filter-mirror.c
index ffaaffa..9f84402 100644
--- a/tests/test-filter-mirror.c
+++ b/tests/test-filter-mirror.c
@@ -57,7 +57,7 @@ static void test_mirror(void)
};
/* send a qmp command to guarantee that 'connected' is setting to true. */
-qmp("{ 'execute' : 'query-status'}");
+qmp_discard_response("{ 'execute' : 'query-status'}");
ret = iov_send(send_sock[0], iov, 2, 0, sizeof(size) + sizeof(send_buf));
g_assert_cmpint(ret, ==, sizeof(send_buf) + sizeof(size));
close(send_sock[0]);
diff --git a/tests/test-filter-redirector.c b/tests/test-filter-redirector.c
index c63b68f..0c4b8d5 100644
--- a/tests/test-filter-redirector.c
+++ b/tests/test-filter-redirector.c
@@ -99,7 +99,7 @@ static void test_redirector_tx(void)
g_assert_cmpint(recv_sock, !=, -1);
/* send a qmp command to guarantee that 'connected' is setting to true. */
-qmp("{ 'execute' : 'query-status'}");
+qmp_discard_response("{ 'execute' : 'query-status'}");
struct iovec iov[] = {
{
@@ -184,7 +184,7 @@ static void test_redirector_rx(void)
send_sock = unix_connect(sock_path1, NULL);
g_assert_cmpint(send_sock, !=, -1);
/* send a qmp command to guarantee that 'connected' is setting to true. */
-qmp("{ 'execute' : 'query-status'}");
+qmp_discard_response("{ 'execute' : 'query-status'}");
ret = iov_send(send_sock, iov, 2, 0, sizeof(size) + sizeof(send_buf));
g_assert_cmpint(ret, ==, sizeof(send_buf) + sizeof(size));
diff --git a/tests/virtio-blk-test.c b/tests/virtio-blk-test.c
index 0e32e41..10a92b4 100644
--- a/tests/virtio-blk-test.c
+++ b/tests/virtio-blk-test.c
@@ -409,8 +409,9 @@ static void pci_config(void)
qvirtio_set_driver_ok(&dev->vdev);
-qmp("{ 'execute': 'block_resize', 'arguments': { 'device': 'drive0', "
-" 'size': %d } }", n_size);
+qmp_discard_response("{ 'execute': 'block_resize', "
+ " 'arguments': { 'device': 'drive0', "
+ " 'size': %d } }", n_size);
qvirtio_wait_config_isr(&dev->vdev, QVIRTIO_BLK_TIMEOUT_US);
capacity = qvirtio_config_readq(&dev->vdev, 0);
@@ -458,8 +459,9 @@ static void pci_msix(void)
qvirtio_set_driver_ok(&dev->vdev);
-qmp("{ 'execute': 'block_resize', 'arguments': { 'device': 'drive0', "
-" 'size': %d } }", n_size);
+qmp_discard_response("{ 'execute': 'block_resize', "
+ " 'arguments': { 'device': 'drive0', "
+ " 'size': %d } }", n_size);
qvirtio_wait_config_isr(&dev->vdev, QVIRTIO_BLK_TIMEOUT_US);
@@ -691,8 +693,9 @@ static void mmio_basic(void)
test_basic(&dev->vdev, alloc, vq);
-qmp("{ 'execute': 'block_resize', 'arguments': { 'device': 'drive0', "
-" 'size': %d } }", n_size);
+qmp_discard_response("{ 'execute': 'block_resize', "
+ " 'arguments': { 'device': 'drive0', "
+ " 'size': %d } }", n_size);
qvirtio_wait_queue_isr(&dev->vdev, vq, QVIRTIO_BLK_TIMEOUT_US);
--
2.10.0
Re: [Qemu-devel] [PATCH] test-uuid: fix leak
On Wed, 11/09 15:02, Marc-André Lureau wrote: > ASAN spotted: > SUMMARY: AddressSanitizer: 74 byte(s) leaked in 2 allocation(s). > > Signed-off-by: Marc-André Lureau > --- > tests/test-uuid.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tests/test-uuid.c b/tests/test-uuid.c > index 77dcdc4..d3a2791 100644 > --- a/tests/test-uuid.c > +++ b/tests/test-uuid.c > @@ -161,6 +161,7 @@ static void test_uuid_unparse_strdup(void) > } > out = qemu_uuid_unparse_strdup(&uuid_test_data[i].uuid); > g_assert_cmpstr(uuid_test_data[i].uuidstr, ==, out); > +g_free(out); > } > } > > -- > 2.10.0 > Thanks, applied: https://github.com/famz/qemu/tree/staging Fam
[Qemu-devel] [PATCH] spapr-vty: Fix bad assert() statement
When using the serial console in the GTK interface of QEMU (and
QEMU has been compiled with CONFIG_VTE), it is possible to trigger
the assert() statement in vty_receive() in spapr_vty.c by pasting
a chunk of text with length > 16 into the QEMU window.
Most of the other serial backends seem to simply drop characters
that they can not handle, so I think we should also do the same in
spapr-vty to fix this issue. And since it is quite ugly when pasted
text is chopped after 16 bytes, we also increase the size of the
input buffer here so that we can at least handle a couple of text
lines.
Buglink: https://bugs.launchpad.net/qemu/+bug/1639322
Signed-off-by: Thomas Huth
---
hw/char/spapr_vty.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/hw/char/spapr_vty.c b/hw/char/spapr_vty.c
index 31822fe..bee6c34 100644
--- a/hw/char/spapr_vty.c
+++ b/hw/char/spapr_vty.c
@@ -1,4 +1,5 @@
#include "qemu/osdep.h"
+#include "qemu/error-report.h"
#include "qapi/error.h"
#include "qemu-common.h"
#include "cpu.h"
@@ -7,7 +8,7 @@
#include "hw/ppc/spapr.h"
#include "hw/ppc/spapr_vio.h"
-#define VTERM_BUFSIZE 16
+#define VTERM_BUFSIZE 2048
typedef struct VIOsPAPRVTYDevice {
VIOsPAPRDevice sdev;
@@ -37,7 +38,15 @@ static void vty_receive(void *opaque, const uint8_t *buf,
int size)
qemu_irq_pulse(spapr_vio_qirq(&dev->sdev));
}
for (i = 0; i < size; i++) {
-assert((dev->in - dev->out) < VTERM_BUFSIZE);
+if (dev->in - dev->out >= VTERM_BUFSIZE) {
+static bool reported;
+if (!reported) {
+error_report("VTY input buffer exhausted - characters dropped."
+ " (input size = %i)", size);
+reported = true;
+}
+break;
+}
dev->buf[dev->in++ % VTERM_BUFSIZE] = buf[i];
}
}
--
1.8.3.1
[Qemu-devel] [Bug 1639322] Re: pasting into ppc64 serial console kills qemu
OK, seems like you need to compile QEMU with CONFIG_VTE enabled (i.e. with the vte-devel packages installed before running configure) to get copy-n-paste support in the GTK interface, that's why I was initially not able to reproduce this issue. Anyway, now I can trigger the assert(), too, and I've suggested a patch here: http://marc.info/?i=1478768797-26401-1-git-send-email-th...@redhat.com ** Changed in: qemu Assignee: (unassigned) => Thomas Huth (th-huth) ** Changed in: qemu Status: New => Confirmed ** Changed in: qemu Importance: Undecided => Medium -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1639322 Title: pasting into ppc64 serial console kills qemu Status in QEMU: Confirmed Bug description: - run qemu-system-ppc64 - when X window appears press Ctrl+Alt+3 - paste any text longer than 16 characters qemu-system-ppc64: /home/abuild/rpmbuild/BUILD/qemu-2.6.1/hw/char/spapr_vty.c:40: vty_receive: Assertion `(dev->in - dev->out) < 16' failed. Aborted (core dumped) Broken in SUSE Leap 42.2 and git 4eb28abd52d48657cff6ff45e8dbbbefe4dbb414 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1639322/+subscriptions
[Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot
Can this issue still be reproduced with the latest version of QEMU, or can we close this bug nowadays? ** Changed in: qemu Status: Confirmed => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1021649 Title: qemu 1.1.0 waits for a keypress at boot Status in QEMU: Incomplete Status in qemu-kvm package in Debian: Fix Released Bug description: qemu 1.1.0 waits for a keypress at boot. Please don't ever do this. Try the attached test script. When run it will initially print nothing, until you hit a key on the keyboard. Removing -nographic fixes the problem. Using virtio-scsi instead of virtio-blk fixes the problem. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1021649/+subscriptions
[Qemu-devel] [Bug 660060] Re: virtio block read errors
You can close this bug: it has been fixed long ago. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/660060 Title: virtio block read errors Status in QEMU: Incomplete Bug description: Context : - Gentoo Linux distribution on host and guests. - qemu-kvm-0.12.5-r1 - 2.6.34-gentoo-r11 host kernel - 2.6.29-gentoo-r5 guest kernels - VM boots from and uses a single virtio block device. On the old kvm bugtracker there was a discussion about a bug with virtio block devices : http://sourceforge.net/tracker/?func=detail&atid=893831&aid=2933400&group_id=180599 I was affected (user gyver in the above discussion) and believed that the problem was fully solved : we had the read error problems on 4 physical hosts . I migrated 3 of the 4 hosts to Gentoo's qemu-kvm-0.12.5-r1 which fixed the problems and allowed us to use virtio block devices instead of emulated PIIX. It seems there's a corner case left or another bug with similar consequences. I just used a maintenance window on the last physical host (one hard disk switched for repair in a RAID1 array) to migrate the ancient kvm-85 (which worked for us with virtio) to 0.12.5. The read errors in virtio block mode came back instantly. We have 3 VMs on this 4th host, 2 are x86, 1 is x86_64. All of them try to boot from a virtio block device and fail to do so with Gentoo's qemu-kvm-0.12.5-r1. They report read errors on /dev/vda and remount the root fs read-only. Reconfiguring them to use emulated PIIX works. There's something interesting about PIIX mode that I'm not sure I've seen before though: there are errors reported by the ATA stack during the boot and the guest kernels switch to PIO after resetting the ide0 interface. More on that later. Booting all these VMs works properly with Gentoo's 0.11.1-r1 with virtio block. Two details that might help : 1/ We use DRBD devices for all our virtual disks (on all 4 physical hosts), 2/ The "failing" host has different hardware, main differences : - Core2 Duo architecture instead of Core i7, - hardware RAID controller: a 3ware 8006-2LP with two SATA disks in RAID-1 mode instead of plain AHCI SATA controllers and software raid 1. Currently the controller on the "failing" host is rebuilding the array after we switched a failing disk with a brand new one. Although there's no read error on the physical host as far as its kernel is concerned, read performance is suffering : 5MB/s top from the guest point of view with 0.11.1-r1 and virtio block with a dd if=/dev/vda (only one VM running and host idle to avoid interferences other than the RAID rebuild), ... This poor read performance might explain the problem we saw in the guest kernel with PIIX emulation on qemu-kvm-0.12.5-r1 (slow reads might be confused with buggy DMA transfers explaining the PIO fallback). We didn't have time to test PIIX emulation after the RAID array was fully synchronized but can do on request. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/660060/+subscriptions
Re: [Qemu-devel] [PATCH v13 1/2] virtio-crypto: Add virtio crypto device specification
Hi,
I attach a diff for next version in order to review more convenient, with
- Drop the all gap stuff;
- Drop all structures undefined in virtio_crypto.h
- re-describe per request for per crypto service avoid confusion
Pls review, thanks!
diff --git a/virtio-crypto.tex b/virtio-crypto.tex
index 448296e..ab17e7b 100644
--- a/virtio-crypto.tex
+++ b/virtio-crypto.tex
@@ -69,13 +69,13 @@ The following services are defined:
\begin{lstlisting}
/* CIPHER service */
-#define VIRTIO_CRYPTO_SERVICE_CIPHER (0)
+#define VIRTIO_CRYPTO_SERVICE_CIPHER 0
/* HASH service */
-#define VIRTIO_CRYPTO_SERVICE_HASH (1)
+#define VIRTIO_CRYPTO_SERVICE_HASH 1
/* MAC (Message Authentication Codes) service */
-#define VIRTIO_CRYPTO_SERVICE_MAC(2)
+#define VIRTIO_CRYPTO_SERVICE_MAC2
/* AEAD (Authenticated Encryption with Associated Data) service */
-#define VIRTIO_CRYPTO_SERVICE_AEAD (3)
+#define VIRTIO_CRYPTO_SERVICE_AEAD 3
\end{lstlisting}
The last driver-read-only fields specify detailed algorithms masks
@@ -210,7 +210,7 @@ data that should be utilized in operations, and input data
is equal to
The general header for controlq is as follows:
\begin{lstlisting}
-#define VIRTIO_CRYPTO_OPCODE(service, op) ((service << 8) | (op))
+#define VIRTIO_CRYPTO_OPCODE(service, op) (((service) << 8) | (op))
struct virtio_crypto_ctrl_header {
#define VIRTIO_CRYPTO_CIPHER_CREATE_SESSION \
@@ -380,20 +380,18 @@ struct virtio_crypto_mac_session_para {
le32 auth_key_len;
le32 padding;
};
-struct virtio_crypto_mac_session_output {
-le64 auth_key_addr; /* guest key physical address */
-};
struct virtio_crypto_mac_create_session_req {
/* Device-readable part */
struct virtio_crypto_mac_session_para para;
-struct virtio_crypto_mac_session_output out;
+/* The authenticated key buffer */
+/* output data here */
+
/* Device-writable part */
struct virtio_crypto_session_input input;
};
\end{lstlisting}
-The output data are
\subparagraph{Session operation: Symmetric algorithms
session}\label{sec:Device Types / Crypto Device / Device
Operation / Control Virtqueue / Session operation / Session operation:
Symmetric algorithms session}
@@ -413,13 +411,13 @@ struct virtio_crypto_cipher_session_para {
le32 padding;
};
-struct virtio_crypto_cipher_session_output {
-le64 key_addr; /* guest key physical address */
-};
-
struct virtio_crypto_cipher_session_req {
+/* Device-readable part */
struct virtio_crypto_cipher_session_para para;
-struct virtio_crypto_cipher_session_output out;
+/* The cipher key buffer */
+/* Output data here */
+
+/* Device-writable part */
struct virtio_crypto_session_input input;
};
\end{lstlisting}
@@ -448,18 +446,20 @@ struct virtio_crypto_alg_chain_session_para {
le32 padding;
};
-struct virtio_crypto_alg_chain_session_output {
-struct virtio_crypto_cipher_session_output cipher;
-struct virtio_crypto_mac_session_output mac;
-};
-
struct virtio_crypto_alg_chain_session_req {
+/* Device-readable part */
struct virtio_crypto_alg_chain_session_para para;
-struct virtio_crypto_alg_chain_session_output out;
+/* The cipher key buffer */
+/* The authenticated key buffer */
+/* Output data here */
+
+/* Device-writable part */
struct virtio_crypto_session_input input;
};
\end{lstlisting}
+The output data includs both cipher key buffer and authenticated key buffer.
+
The packet for symmetric algorithm is as follows:
\begin{lstlisting}
@@ -503,13 +503,13 @@ struct virtio_crypto_aead_session_para {
le32 padding;
};
-struct virtio_crypto_aead_session_output {
-le64 key_addr; /* guest key physical address */
-};
-
struct virtio_crypto_aead_create_session_req {
+/* Device-readable part */
struct virtio_crypto_aead_session_para para;
-struct virtio_crypto_aead_session_output out;
+/* The cipher key buffer */
+/* Output data here */
+
+/* Device-writeable part */
struct virtio_crypto_session_input input;
};
\end{lstlisting}
@@ -568,19 +568,13 @@ struct virtio_crypto_op_data_req {
The header is the general header and the union is of the algorithm-specific
type,
which is set by the driver. All properties in the union are shown as follows.
-There is a unified idata structure for all symmetric algorithms, including
CIPHER, HASH, MAC, and AEAD.
+There is a unified idata structure for all service, including CIPHER, HASH,
MAC, and AEAD.
The structure is defined as follows:
\begin{lstlisting}
-struct virtio_crypto_sym_input {
-/* Destination data guest address, it's useless for plain HASH and MAC */
-le64 dst_data_addr;
-/* Digest result guest address, it's useless for plain cipher algos */
-le64 digest_result_addr;
-
-le32 status;
-le32 padding;
+struct virtio_crypto_inhdr {
+u8 status;
};
\end{lstlisting}
@@ -595,39 +589,29 @@ struct virtio_crypto_hash_para {
[Qemu-devel] [Bug 1212402] Re: Enabling KVM with recent QEMU builds from GIT hang at boot on Ubuntu Precise AMD64 kernel 3.8.0
According to comment #1, this has been fixed with kernel 3.9, so setting the status to "Fix released" now. ** Changed in: qemu Status: New => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1212402 Title: Enabling KVM with recent QEMU builds from GIT hang at boot on Ubuntu Precise AMD64 kernel 3.8.0 Status in QEMU: Fix Released Bug description: When I compile QEMU from GIT and run it with './x86_64-softmmu/qemu-system-x86_64 -enable-kvm' it just hangs, the QEMU screen stays black. (Everything else in the GTK UI is responsive though, I can use the QEMU console as well.) I'm running Ubuntu Precise with kernel 3.8.0-27-generic on an Intel Core2 Duo P9500. With bisecting, I found this commit caused the problem: 235e8982ad393e5611cb892df54881c872eea9e1 is the first bad commit commit 235e8982ad393e5611cb892df54881c872eea9e1 Author: Jordan Justen Date: Wed May 29 01:27:26 2013 -0700 kvm: support using KVM_MEM_READONLY flag for regions For readonly memory regions and rom devices in romd_mode, we make use of the KVM_MEM_READONLY. A slot that uses KVM_MEM_READONLY can be read from and code can execute from the region, but writes will exit to qemu. For rom devices with !romd_mode, we force the slot to be removed so reads or writes to the region will exit to qemu. (Note that a memory region in this state is not executable within kvm.) v7: * Update for readable => romd_mode rename (5f9a5ea1) Signed-off-by: Jordan Justen Reviewed-by: Xiao Guangrong (v4) Reviewed-by: Paolo Bonzini (v5) Message-id: 1369816047-16384-4-git-send-email-jordan.l.jus...@intel.com Signed-off-by: Anthony Liguori :100644 100644 327ae12f08b9dddc796d753d8adfb1f70c78b2c1 8e7bbf8698f6bcaa5ae945ef86e7b51effde06fe M kvm-all.c To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1212402/+subscriptions
[Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot
No this refers to a very old version of qemu. This bug should be closed. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1021649 Title: qemu 1.1.0 waits for a keypress at boot Status in QEMU: Fix Released Status in qemu-kvm package in Debian: Fix Released Bug description: qemu 1.1.0 waits for a keypress at boot. Please don't ever do this. Try the attached test script. When run it will initially print nothing, until you hit a key on the keyboard. Removing -nographic fixes the problem. Using virtio-scsi instead of virtio-blk fixes the problem. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1021649/+subscriptions
Re: [Qemu-devel] Sphinx for QEMU docs? (and a doc-comment format question)
- Original Message - > From: "Fam Zheng" > To: "Stefan Hajnoczi" > Cc: "John Snow" , "Peter Maydell" > , "QEMU Developers" > , "Stefan Hajnoczi" , "Paolo > Bonzini" > Sent: Thursday, November 10, 2016 4:39:14 AM > Subject: Re: [Qemu-devel] Sphinx for QEMU docs? (and a doc-comment format > question) > > On Wed, 11/09 11:32, Stefan Hajnoczi wrote: > > No doc comments -> error. > > I'm not sure that is a good idea. For example all .bdrv_co_flush_to_disk > implementations have the same semantics and signature, requiring doc comments > everywhere might be too much. The check would be only on specific files. However, I find it hard to implement it if we place doc comments for types in headers and those for functions in .c files (with automatically generated docs, most of the advantages of doc comments in headers go away). Paolo
[Qemu-devel] [PULL 4/6] MAINTAINERS: Add an entry for the CHRP NVRAM files
I recently added new files to the source tree that are not covered by any maintainer yet -- and since every new source file should have a maintainer nowadays, I volunteer to look after these files now, too. Reviewed-by: David Gibson Reviewed-by: Stefan Hajnoczi Signed-off-by: Thomas Huth --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 5d8b584..05b1c97 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1093,6 +1093,13 @@ S: Maintained F: hw/core/generic-loader.c F: include/hw/core/generic-loader.h +CHRP NVRAM +M: Thomas Huth +S: Maintained +F: hw/nvram/chrp_nvram.c +F: include/hw/nvram/chrp_nvram.h +F: tests/prom-env-test.c + Subsystems -- Audio -- 1.8.3.1
[Qemu-devel] [PULL 0/6] Fixes for the MAINTAINERS file
The following changes since commit 9b4b0350264d8164996265d635c8b9599673afb4: Merge remote-tracking branch 'public/tags/tracing-pull-request' into staging (2016-11-09 12:44:16 +) are available in the git repository at: https://github.com/huth/qemu.git tags/maintainers-20161110 for you to fetch changes up to 275196e9a2b13e3e24fd6cf638c02a6454071b8a: MAINTAINERS: Remove obsolete stable branches (2016-11-10 10:27:19 +0100) Fixes for the MAINTAINERS file for QEMU 2.8 John Snow (1): MAINTAINERS: Add Fam and Jsnow for Bitmap support Thomas Huth (5): MAINTAINERS: Add some ARM related files to the corresponding sections sparc: Add slavio_misc.c and eccmemctl.c to the MAINTAINERS file m68k: Update the 68k sections in the MAINTAINERS file MAINTAINERS: Add an entry for the CHRP NVRAM files MAINTAINERS: Remove obsolete stable branches MAINTAINERS | 59 +++ 1 file changed, 35 insertions(+), 24 deletions(-) -- 1.8.3.1
[Qemu-devel] [PULL 3/6] m68k: Update the 68k sections in the MAINTAINERS file
disas/m68k.c obviously belong to the m68k CPU section in the MAINTAINERS file, but remove the hw/m68k/ directory here since it only contains machine (not CPU) related files, as requested by Laurent. Add the machine related files to the right machine sections instead. Reviewed-by: Laurent Vivier Reviewed-by: Stefan Hajnoczi Signed-off-by: Thomas Huth --- MAINTAINERS | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 451e7cc..5d8b584 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -148,7 +148,7 @@ M68K M: Laurent Vivier S: Maintained F: target-m68k/ -F: hw/m68k/ +F: disas/m68k.c MicroBlaze M: Edgar E. Iglesias @@ -550,6 +550,7 @@ M68K Machines an5206 S: Orphan F: hw/m68k/an5206.c +F: hw/m68k/mcf5206.c dummy_m68k S: Orphan @@ -558,6 +559,9 @@ F: hw/m68k/dummy_m68k.c mcf5208 S: Orphan F: hw/m68k/mcf5208.c +F: hw/m68k/mcf_intc.c +F: hw/char/mcf_uart.c +F: hw/net/mcf_fec.c MicroBlaze Machines --- -- 1.8.3.1
[Qemu-devel] [PULL 1/6] MAINTAINERS: Add some ARM related files to the corresponding sections
The files w/cpu/a*mpcore.c are already assigned to the ARM CPU section, but the corresponding headers include/hw/cpu/a*mpcore.h are still missing. The file hw/*/imx* are already assigned to the i.MX31 machine, but the corresponding header files include/hw/*/imx* are still missing. The file hw/misc/arm_integrator_debug.c seems to belong to Integrator CP, hw/cpu/realview_mpcore.c seems to belong to Real View, and hw/misc/mst_fpga.c seems to belong to PXA2XX. And the files hw/misc/zynq* and include/hw/misc/zynq* seem to belong to the Xilinx Zynq machine. Reviewed-by: Alistair Francis Acked-by: Peter Maydell Reviewed-by: Stefan Hajnoczi Signed-off-by: Thomas Huth --- MAINTAINERS | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 82c814a..d7eef43 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -118,6 +118,7 @@ S: Maintained F: target-arm/ F: hw/arm/ F: hw/cpu/a*mpcore.c +F: include/hw/cpu/a*mpcore.h F: disas/arm.c F: disas/arm-a64.cc F: disas/libvixl/ @@ -420,6 +421,7 @@ M: Peter Chubb L: qemu-...@nongnu.org S: Odd fixes F: hw/*/imx* +F: include/hw/*/imx* F: hw/arm/kzm.c F: include/hw/arm/fsl-imx31.h @@ -428,6 +430,7 @@ M: Peter Maydell L: qemu-...@nongnu.org S: Maintained F: hw/arm/integratorcp.c +F: hw/misc/arm_integrator_debug.c Musicpal M: Jan Kiszka @@ -452,6 +455,7 @@ M: Peter Maydell L: qemu-...@nongnu.org S: Maintained F: hw/arm/realview* +F: hw/cpu/realview_mpcore.c F: hw/intc/realview_gic.c F: include/hw/intc/realview_gic.h @@ -464,6 +468,7 @@ F: hw/arm/spitz.c F: hw/arm/tosa.c F: hw/arm/z2.c F: hw/*/pxa2xx* +F: hw/misc/mst_fpga.c F: include/hw/arm/pxa.h Stellaris @@ -485,7 +490,8 @@ L: qemu-...@nongnu.org S: Maintained F: hw/*/xilinx_* F: hw/*/cadence_* -F: hw/misc/zynq_slcr.c +F: hw/misc/zynq* +F: include/hw/misc/zynq* X: hw/ssi/xilinx_* Xilinx ZynqMP -- 1.8.3.1
[Qemu-devel] [PULL 6/6] MAINTAINERS: Remove obsolete stable branches
There are only very old and orphaned stable branches listed in the MAINTAINERS file - so this section is pretty useless nowadays. Let's remove it. Reviewed-by: John Snow Signed-off-by: Thomas Huth --- MAINTAINERS | 22 -- 1 file changed, 22 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index d8575ab..4a60579 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1574,28 +1574,6 @@ F: tcg/tci/ F: tci.c F: disas/tci.c -Stable branches -Stable 1.0 -L: qemu-sta...@nongnu.org -T: git git://git.qemu-project.org/qemu-stable-1.0.git -S: Orphan - -Stable 0.15 -L: qemu-sta...@nongnu.org -T: git git://git.qemu-project.org/qemu-stable-0.15.git -S: Orphan - -Stable 0.14 -L: qemu-sta...@nongnu.org -T: git git://git.qemu-project.org/qemu-stable-0.14.git -S: Orphan - -Stable 0.10 -L: qemu-sta...@nongnu.org -T: git git://git.qemu-project.org/qemu-stable-0.10.git -S: Orphan - Block drivers - VMDK -- 1.8.3.1
[Qemu-devel] [PULL 2/6] sparc: Add slavio_misc.c and eccmemctl.c to the MAINTAINERS file
Both files seem to belong to the Sun4m machine. Reviewed-by: Stefan Hajnoczi Signed-off-by: Thomas Huth --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index d7eef43..451e7cc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -710,6 +710,8 @@ S: Maintained F: hw/sparc/sun4m.c F: hw/dma/sparc32_dma.c F: hw/dma/sun4m_iommu.c +F: hw/misc/eccmemctl.c +F: hw/misc/slavio_misc.c F: include/hw/sparc/sparc32_dma.h F: include/hw/sparc/sun4m.h F: pc-bios/openbios-sparc32 -- 1.8.3.1
[Qemu-devel] [PULL 5/6] MAINTAINERS: Add Fam and Jsnow for Bitmap support
From: John Snow These files are currently unmaintained. I'm proposing that Fam and I co-maintain them; under the model that whomever between us isn't authoring a given series will be responsible for reviewing it. Signed-off-by: John Snow Acked-by: Fam Zheng Acked-by: Max Reitz Reviewed-by: Stefan Hajnoczi Signed-off-by: Thomas Huth --- MAINTAINERS | 14 ++ 1 file changed, 14 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 05b1c97..d8575ab 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1158,6 +1158,20 @@ F: block/qapi.c F: qapi/block*.json T: git git://repo.or.cz/qemu/armbru.git block-next +Dirty Bitmaps +M: Fam Zheng +M: John Snow +L: qemu-bl...@nongnu.org +S: Supported +F: util/hbitmap.c +F: block/dirty-bitmap.c +F: include/qemu/hbitmap.h +F: include/block/dirty-bitmap.h +F: tests/test-hbitmap.c +F: docs/bitmaps.md +T: git git://github.com/famz/qemu.git bitmaps +T: git git://github.com/jnsnow/qemu.git bitmaps + Character device backends M: Paolo Bonzini S: Maintained -- 1.8.3.1
[Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot
** Changed in: qemu Status: Incomplete => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1021649 Title: qemu 1.1.0 waits for a keypress at boot Status in QEMU: Fix Released Status in qemu-kvm package in Debian: Fix Released Bug description: qemu 1.1.0 waits for a keypress at boot. Please don't ever do this. Try the attached test script. When run it will initially print nothing, until you hit a key on the keyboard. Removing -nographic fixes the problem. Using virtio-scsi instead of virtio-blk fixes the problem. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1021649/+subscriptions
[Qemu-devel] [Bug 660060] Re: virtio block read errors
Thanks for your response! So I'm closing this ticket now... ** Changed in: qemu Status: Incomplete => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/660060 Title: virtio block read errors Status in QEMU: Fix Released Bug description: Context : - Gentoo Linux distribution on host and guests. - qemu-kvm-0.12.5-r1 - 2.6.34-gentoo-r11 host kernel - 2.6.29-gentoo-r5 guest kernels - VM boots from and uses a single virtio block device. On the old kvm bugtracker there was a discussion about a bug with virtio block devices : http://sourceforge.net/tracker/?func=detail&atid=893831&aid=2933400&group_id=180599 I was affected (user gyver in the above discussion) and believed that the problem was fully solved : we had the read error problems on 4 physical hosts . I migrated 3 of the 4 hosts to Gentoo's qemu-kvm-0.12.5-r1 which fixed the problems and allowed us to use virtio block devices instead of emulated PIIX. It seems there's a corner case left or another bug with similar consequences. I just used a maintenance window on the last physical host (one hard disk switched for repair in a RAID1 array) to migrate the ancient kvm-85 (which worked for us with virtio) to 0.12.5. The read errors in virtio block mode came back instantly. We have 3 VMs on this 4th host, 2 are x86, 1 is x86_64. All of them try to boot from a virtio block device and fail to do so with Gentoo's qemu-kvm-0.12.5-r1. They report read errors on /dev/vda and remount the root fs read-only. Reconfiguring them to use emulated PIIX works. There's something interesting about PIIX mode that I'm not sure I've seen before though: there are errors reported by the ATA stack during the boot and the guest kernels switch to PIO after resetting the ide0 interface. More on that later. Booting all these VMs works properly with Gentoo's 0.11.1-r1 with virtio block. Two details that might help : 1/ We use DRBD devices for all our virtual disks (on all 4 physical hosts), 2/ The "failing" host has different hardware, main differences : - Core2 Duo architecture instead of Core i7, - hardware RAID controller: a 3ware 8006-2LP with two SATA disks in RAID-1 mode instead of plain AHCI SATA controllers and software raid 1. Currently the controller on the "failing" host is rebuilding the array after we switched a failing disk with a brand new one. Although there's no read error on the physical host as far as its kernel is concerned, read performance is suffering : 5MB/s top from the guest point of view with 0.11.1-r1 and virtio block with a dd if=/dev/vda (only one VM running and host idle to avoid interferences other than the RAID rebuild), ... This poor read performance might explain the problem we saw in the guest kernel with PIIX emulation on qemu-kvm-0.12.5-r1 (slow reads might be confused with buggy DMA transfers explaining the PIO fallback). We didn't have time to test PIIX emulation after the RAID array was fully synchronized but can do on request. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/660060/+subscriptions
Re: [Qemu-devel] virtIO question
On Wed, Nov 09, 2016 at 06:58:16PM +0800, zhun...@gmail.com wrote: > I want to ask a another question,why a virt_queue in virtio include in_sgs > and out_sgs,for example,send_queue of virtIO net driver have in_sgs and > out_sgs，when transmit data,It add buffer to out_sgs of send_queue,but how it > to use in_sgs?? You can think of every virtqueue buffer as having two scatter-gather lists: 1. out_sgs are driver->device buffers (e.g. tx packet payload) 2. in_sgs are device->driver buffers (e.g. rx packet payload) Look at the virtio-net ctrl virtqueue (see spec and virtio_net_handle_ctrl() for details). Each buffer has: 1. struct virtio_net_ctrl_hdr (out_sgs) 2. request-specific fields (out_sgs) 3. virtio_net_ctrl_ack status byte (in_sgs) The device parses the request and performs the operation. Then it fills in the result (success or error code) in the status byte. Processing ctrl virtqueue buffers therefore requires both guest memory reads (out_sgs) and writes (in_sgs). Most of the other virtio devices also use bi-directional buffers. This may not be obvious if you only consider the virtio-net tx virtqueue, for example, where buffers use out_sgs only. Hope this makes sense. If not, look at the specification again and think about how virtio-net ctrl request processing works. signature.asc Description: PGP signature
Re: [Qemu-devel] [PATCHv2 0/3] Allow ISA to be disabled on some platforms
On Wed, Nov 09, 2016 at 11:22:01PM +1100, David Gibson wrote: > This is a rebase and revision of a series I wrote quite some time ago. > This makes some cleanups that are a start on allowing ISA to be > compiled out for platforms which don't use it. > > Unfortunately, a lot of the pieces here don't have a clear maintainer. > So, I'm hoping to get some Acked-bys from the maintainers of the > affected targets, then I intend to send a pull request direct to Peter. Looks good to me: Reviewed-by: Edgar E. Iglesias Best regards, Edgar > > Notes: > * Patch 3/3 triggers a style warning, but that's just because I'm > moving a C++ // comment verbatim from one file to another > > Changes since v1: > * Fixed some silly compile errors in 3/3 exposed by some > changes in other headers > > David Gibson (3): > Split serial-isa into its own config option > Allow ISA bus to be configured out > Split ISA and sysbus versions of m48t59 device > > default-configs/alpha-softmmu.mak | 1 + > default-configs/arm-softmmu.mak | 1 + > default-configs/i386-softmmu.mak| 1 + > default-configs/mips-softmmu-common.mak | 1 + > default-configs/moxie-softmmu.mak | 2 + > default-configs/pci.mak | 3 + > default-configs/ppc-softmmu.mak | 1 + > default-configs/ppc64-softmmu.mak | 1 + > default-configs/ppcemb-softmmu.mak | 1 + > default-configs/sh4-softmmu.mak | 1 + > default-configs/sh4eb-softmmu.mak | 1 + > default-configs/sparc-softmmu.mak | 1 + > default-configs/sparc64-softmmu.mak | 1 + > default-configs/unicore32-softmmu.mak | 1 + > default-configs/x86_64-softmmu.mak | 1 + > hw/char/Makefile.objs | 3 +- > hw/isa/Makefile.objs| 2 +- > hw/timer/Makefile.objs | 3 + > hw/timer/m48t59-internal.h | 82 > hw/timer/m48t59-isa.c | 181 + > hw/timer/m48t59.c | 228 > +++- > 21 files changed, 305 insertions(+), 212 deletions(-) > create mode 100644 hw/timer/m48t59-internal.h > create mode 100644 hw/timer/m48t59-isa.c > > -- > 2.7.4 >
Re: [Qemu-devel] [PULL for-2.8 0/1] ipxe: update to 20161108 snapshot.
On Wed, Nov 09, 2016 at 10:09:24AM +0100, Gerd Hoffmann wrote: > Hi, > > This rebases ipxe to latest master. ipxe qemu builds will not use > fxsave/fxrestore any more, which caused problems on older intel cpus > due to kvm not emulating these instructions. > > Special thanks to Laszlo for pushing these patches to ipxe upstream, > they finally landed in ipxe master yesterday. > > please pull, > Gerd > > The following changes since commit 207faf24c58859f5240f66bf6decc33b87a1776e: > > Merge remote-tracking branch 'pm215/tags/pull-target-arm-20161107' into > staging (2016-11-07 14:02:15 +) > > are available in the git repository at: > > > git://git.kraxel.org/qemu tags/pull-ipxe-20161109-1 > > for you to fetch changes up to 129fa54c734f4dbaf8d3bb9ca47283a2add2e4dc: > > ipxe: update to 20161108 snapshot (2016-11-09 09:49:33 +0100) > > > ipxe: update to 20161108 snapshot. > > > Gerd Hoffmann (1): > ipxe: update to 20161108 snapshot > > pc-bios/efi-e1000.rom| Bin 209408 -> 209920 bytes > pc-bios/efi-e1000e.rom | Bin 209408 -> 209920 bytes > pc-bios/efi-eepro100.rom | Bin 209920 -> 209920 bytes > pc-bios/efi-ne2k_pci.rom | Bin 208384 -> 208896 bytes > pc-bios/efi-pcnet.rom| Bin 208384 -> 208896 bytes > pc-bios/efi-rtl8139.rom | Bin 211456 -> 212480 bytes > pc-bios/efi-virtio.rom | Bin 211456 -> 212480 bytes > pc-bios/efi-vmxnet3.rom | Bin 205312 -> 206848 bytes > roms/ipxe| 2 +- > 9 files changed, 1 insertion(+), 1 deletion(-) > Thanks, applied to my staging tree: https://github.com/stefanha/qemu/commits/staging Stefan signature.asc Description: PGP signature
Re: [Qemu-devel] Sphinx for QEMU docs? (and a doc-comment format question)
On Thu, Nov 10, 2016 at 05:08:03AM -0500, Paolo Bonzini wrote: > > > - Original Message - > > From: "Fam Zheng" > > To: "Stefan Hajnoczi" > > Cc: "John Snow" , "Peter Maydell" > > , "QEMU Developers" > > , "Stefan Hajnoczi" , "Paolo > > Bonzini" > > Sent: Thursday, November 10, 2016 4:39:14 AM > > Subject: Re: [Qemu-devel] Sphinx for QEMU docs? (and a doc-comment format > > question) > > > > On Wed, 11/09 11:32, Stefan Hajnoczi wrote: > > > No doc comments -> error. > > > > I'm not sure that is a good idea. For example all .bdrv_co_flush_to_disk > > implementations have the same semantics and signature, requiring doc > > comments > > everywhere might be too much. > > The check would be only on specific files. However, I find it hard to > implement it if we place doc comments for types in headers and those for > functions in .c files (with automatically generated docs, most of the > advantages of doc comments in headers go away). Another reason for using .h file for all API docs - we have APIs declared for crypto impls in .h files, but there are 3 separate implementation files chosen between at build time, so no single .c file is "right" for holding the docs. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o-http://search.cpan.org/~danberr/ :|
Re: [Qemu-devel] [PULL for-2.8 0/2] usb: two memory leak fixes.
On Wed, Nov 09, 2016 at 02:33:29PM +0100, Gerd Hoffmann wrote: > Hi, > > Here is the usb patch queue, fixing two memory leaks. > > please pull, > Gerd > > The following changes since commit 207faf24c58859f5240f66bf6decc33b87a1776e: > > Merge remote-tracking branch 'pm215/tags/pull-target-arm-20161107' into > staging (2016-11-07 14:02:15 +) > > are available in the git repository at: > > > git://git.kraxel.org/qemu tags/pull-usb-20161109-1 > > for you to fetch changes up to f0bf4999eae156142a86290fda45de4094e3e8b4: > > usbredir: free vm_change_state_handler in usbredir destroy dispatch > (2016-11-08 15:01:23 +0100) > > > usb: two memory leak fixes. > > > Li Qiang (2): > usb: ehci: fix memory leak in ehci_init_transfer > usbredir: free vm_change_state_handler in usbredir destroy dispatch > > hw/usb/hcd-ehci.c | 1 + > hw/usb/redirect.c | 5 - > 2 files changed, 5 insertions(+), 1 deletion(-) > Thanks, applied to my staging tree: https://github.com/stefanha/qemu/commits/staging Stefan signature.asc Description: PGP signature
Re: [Qemu-devel] [PULL for-2.8 0/3] ui: bugfixes for gtk, curses and hid emulation.
On Wed, Nov 09, 2016 at 03:38:40PM +0100, Gerd Hoffmann wrote: > Hi, > > Here is the UI patch queue with three bugfixes, > most importantly the cursesw configure fix. > > please pull, > Gerd > > The following changes since commit 207faf24c58859f5240f66bf6decc33b87a1776e: > > Merge remote-tracking branch 'pm215/tags/pull-target-arm-20161107' into > staging (2016-11-07 14:02:15 +) > > are available in the git repository at: > > > git://git.kraxel.org/qemu tags/pull-ui-20161109-1 > > for you to fetch changes up to ba60f2d18e976ef99238ebce019e26719f2b597c: > > Fix cursesw detection (2016-11-09 14:35:47 +0100) > > > ui: bugfixes for gtk, curses and hid emulation. > > > Peter Korsgaard (1): > hw/input/hid: support alternative sysrq/break scancodes for gtk-vnc > > Samuel Thibault (1): > Fix cursesw detection > > Thomas Huth (1): > ui/gtk: Fix build with older versions of gtk > > configure | 7 ++- > hw/input/hid.c | 4 ++-- > ui/gtk.c | 3 ++- > 3 files changed, 10 insertions(+), 4 deletions(-) > Thanks, applied to my staging tree: https://github.com/stefanha/qemu/commits/staging Stefan signature.asc Description: PGP signature
Re: [Qemu-devel] [PATCH] qtest: fix a memory leak
On Thu, Nov 10, 2016 at 12:25:36PM +0400, Marc-André Lureau wrote: > Spotted by ASAN. > > Signed-off-by: Marc-André Lureau > --- > qtest.c | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Stefan Hajnoczi signature.asc Description: PGP signature
Re: [Qemu-devel] [PULL 0/6] Fixes for the MAINTAINERS file
On Thu, Nov 10, 2016 at 11:11:37AM +0100, Thomas Huth wrote: > The following changes since commit 9b4b0350264d8164996265d635c8b9599673afb4: > > Merge remote-tracking branch 'public/tags/tracing-pull-request' into > staging (2016-11-09 12:44:16 +) > > are available in the git repository at: > > > https://github.com/huth/qemu.git tags/maintainers-20161110 > > for you to fetch changes up to 275196e9a2b13e3e24fd6cf638c02a6454071b8a: > > MAINTAINERS: Remove obsolete stable branches (2016-11-10 10:27:19 +0100) > > > Fixes for the MAINTAINERS file for QEMU 2.8 > > > John Snow (1): > MAINTAINERS: Add Fam and Jsnow for Bitmap support > > Thomas Huth (5): > MAINTAINERS: Add some ARM related files to the corresponding sections > sparc: Add slavio_misc.c and eccmemctl.c to the MAINTAINERS file > m68k: Update the 68k sections in the MAINTAINERS file > MAINTAINERS: Add an entry for the CHRP NVRAM files > MAINTAINERS: Remove obsolete stable branches > > MAINTAINERS | 59 +++ > 1 file changed, 35 insertions(+), 24 deletions(-) > > -- > 1.8.3.1 > > Thanks, applied to my staging tree: https://github.com/stefanha/qemu/commits/staging Stefan signature.asc Description: PGP signature
Re: [Qemu-devel] [PATCH] tests: fix qmp response leak
On Thu, Nov 10, 2016 at 12:36:29PM +0400, Marc-André Lureau wrote: > Spotted by ASAN. > > Signed-off-by: Marc-André Lureau > --- > tests/libqos/usb.c | 1 + > tests/postcopy-test.c | 2 +- > tests/pvpanic-test.c | 1 + > tests/test-filter-mirror.c | 2 +- > tests/test-filter-redirector.c | 4 ++-- > tests/virtio-blk-test.c| 15 +-- > 6 files changed, 15 insertions(+), 10 deletions(-) Reviewed-by: Stefan Hajnoczi signature.asc Description: PGP signature
Re: [Qemu-devel] [PULL for-2.8 0/1] ipxe: update to 20161108 snapshot.
On Wed, Nov 09, 2016 at 10:09:24AM +0100, Gerd Hoffmann wrote: > This rebases ipxe to latest master. ipxe qemu builds will not use > fxsave/fxrestore any more, which caused problems on older intel cpus > due to kvm not emulating these instructions. > > Special thanks to Laszlo for pushing these patches to ipxe upstream, > they finally landed in ipxe master yesterday. > > please pull, > Gerd > > The following changes since commit 207faf24c58859f5240f66bf6decc33b87a1776e: > > Merge remote-tracking branch 'pm215/tags/pull-target-arm-20161107' into > staging (2016-11-07 14:02:15 +) > > are available in the git repository at: > > > git://git.kraxel.org/qemu tags/pull-ipxe-20161109-1 > > for you to fetch changes up to 129fa54c734f4dbaf8d3bb9ca47283a2add2e4dc: > > ipxe: update to 20161108 snapshot (2016-11-09 09:49:33 +0100) > > > ipxe: update to 20161108 snapshot. Gerd, This pull request broke the staging tree because git.qemu-project.org/ipxe.git didn't have the commit you pointed to yet. You don't need to do anything now since I have manually kicked the ipxe mirror. In the future please only send submodule pull requests after the commits appear in our mirror repositories. Thanks, Stefan signature.asc Description: PGP signature
Re: [Qemu-devel] [RFC PATCH 2/4] vhost-user: add the vhost-user extension to support the vhost-pci based inter-vm communication
Hi
On Thu, Nov 10, 2016 at 6:47 AM Wei Wang wrote:
> This is the slave part of vhost-user implemented in QEMU, with an extension
> to support vhost-pci.
>
Instead of implementing "another vhost-user slave", it would be worth
investigating using libvhost-user instead (
https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg03990.html). This
is just a suggestion, it is quite fine for vhost-pci to have its own
smaller/specific vhost-user slave implementation (without virtio rings
handlings etc). (libvhost-user is also very young, not yet in qemu, we
should be able shape it for vhost-pci needs)
> Signed-off-by: Wei Wang
> ---
> hw/virtio/Makefile.objs | 1 +
> hw/virtio/vhost-pci-server.c | 469
> +++
> hw/virtio/vhost-user.c | 86 +--
> include/hw/virtio/vhost-pci-server.h | 45
> include/hw/virtio/vhost-user.h | 110
> include/sysemu/sysemu.h | 1 +
> qemu-options.hx | 4 +
> vl.c | 26 ++
> 8 files changed, 657 insertions(+), 85 deletions(-)
> create mode 100644 hw/virtio/vhost-pci-server.c
> create mode 100644 include/hw/virtio/vhost-pci-server.h
> create mode 100644 include/hw/virtio/vhost-user.h
>
> diff --git a/hw/virtio/Makefile.objs b/hw/virtio/Makefile.objs
> index 3e2b175..e44feb8 100644
> --- a/hw/virtio/Makefile.objs
> +++ b/hw/virtio/Makefile.objs
> @@ -2,6 +2,7 @@ common-obj-y += virtio-rng.o
> common-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o
> common-obj-y += virtio-bus.o
> common-obj-y += virtio-mmio.o
> +common-obj-y += vhost-pci-server.o
>
> obj-y += virtio.o virtio-balloon.o
> obj-$(CONFIG_LINUX) += vhost.o vhost-backend.o vhost-user.o
> diff --git a/hw/virtio/vhost-pci-server.c b/hw/virtio/vhost-pci-server.c
> new file mode 100644
> index 000..6ce8516
> --- /dev/null
> +++ b/hw/virtio/vhost-pci-server.c
> @@ -0,0 +1,469 @@
> +/*
> + * Vhost-pci server
> + *
> + * Copyright Intel Corp. 2016
> + *
> + * Authors:
> + * Wei Wang
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or
> later.
> + * See the COPYING file in the top-level directory.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "sysemu/char.h"
> +#include "qapi/error.h"
> +#include "hw/virtio/vhost-pci-server.h"
> +#include "qemu/option.h"
> +#include "monitor/qdev.h"
> +#include "hw/virtio/vhost-user.h"
> +#include "hw/qdev.h"
> +
> +#define VHOST_PCI_FEATURE_BITS (1ULL << VIRTIO_F_VERSION_1)
> +
> +#define VHOST_PCI_NET_FEATURE_BITS (1ULL << VIRTIO_NET_F_MRG_RXBUF) | \
> + (1ULL << VIRTIO_NET_F_CTRL_VQ) | \
> + (1ULL << VIRTIO_NET_F_MQ)
> +
> +#define VHOST_USER_SET_PEER_CONNECTION_OFF 0
> +#define VHOST_USER_SET_PEER_CONNECTION_ON 1
> +#define VHOST_USER_SET_PEER_CONNECTION_INIT 2
> +
> +VhostPCIServer *vp_server;
> +
> +QemuOptsList qemu_vhost_pci_server_opts = {
> +.name = "vhost-pci-server",
> +.implied_opt_name = "chardev",
> +.head = QTAILQ_HEAD_INITIALIZER(qemu_vhost_pci_server_opts.head),
> +.desc = {
> +/*
> + * no elements => accept any
> + * sanity checking will happen later
> + * when setting device properties
> + */
> +{ /* end of list */ }
> +},
> +};
> +
> +static int vhost_pci_server_write(CharDriverState *chr, VhostUserMsg *msg)
> +{
> +int size = msg->size + VHOST_USER_HDR_SIZE;
> +
> +if (!msg)
> +return 0;
> +
> +msg->flags &= ~VHOST_USER_VERSION_MASK;
> +msg->flags |= VHOST_USER_VERSION;
> +
> +return qemu_chr_fe_write_all_n(chr, msg->conn_id,
> + (const uint8_t *)msg, size) == size ? 0
> : -1;
> +}
> +
> +PeerConnectionTable *vp_server_find_table_ent(const char *dev_id)
> +{
> +int i;
> +PeerConnectionTable *ent;
> +uint64_t max_connections = vp_server->chr->max_connections;
> +
> +for (i = 0; i < max_connections; i++) {
> +ent = &vp_server->peer_table[i];
> +if (!strcmp(dev_id, ent->dev_id))
> +return ent;
> +}
> +return NULL;
> +}
> +
> +static void vhost_pci_init_peer_table(uint64_t id)
> +{
> +PeerConnectionTable *ent = &vp_server->peer_table[id];
> +
> +ent->peer_feature_bits |= 1ULL << VHOST_USER_F_PROTOCOL_FEATURES;
> +QLIST_INIT(&ent->vq_list);
> +ent->vq_num = 0;
> +}
> +
> +static int vhost_pci_get_conn_id(CharDriverState *chr, VhostUserMsg *msg)
> +{
> +unsigned long *conn_bitmap = chr->conn_bitmap;
> +unsigned long *old_conn_bitmap = vp_server->old_conn_bitmap;
> +uint64_t nbits = chr->max_connections;
> +uint64_t id;
> +int r;
> +
> +bitmap_xor(old_conn_bitmap, old_conn_bitmap, conn_bitmap,
> (long)nbits);
> +
> +for (id = find_first_bit(old_conn_bitmap, nbits); id < nbits;
> + id = find_next_bit(old_conn_bitmap, nbits,
Re: [Qemu-devel] [RFC PATCH 1/4] qemu-char: add the "1-server-N-client" support
Hi
On Thu, Nov 10, 2016 at 6:47 AM Wei Wang wrote:
> This patch enables a qemu server socket to be connected by multiple
> client sockets.
>
> Thanks for sharing this early version of the series, I hope some early
feedback will help you. I'll be waiting for a more complete implementation
for detailed review.
Is this patch necessary as a first step? I would rather start with a
vhost-pci 1-1 Master-Slave series. Keep 1-n for a following improvement.
This would also probably post-pone the discussion regarding connection-id,
or uuid.
In short, I think it would help if you can break your proposal in smaller
independant steps.
Signed-off-by: Wei Wang
> ---
> include/sysemu/char.h | 64 ++-
> qapi-schema.json | 3 +-
> qemu-char.c | 512
> ++
> 3 files changed, 456 insertions(+), 123 deletions(-)
>
> diff --git a/include/sysemu/char.h b/include/sysemu/char.h
> index ee7e554..ff5dda6 100644
> --- a/include/sysemu/char.h
> +++ b/include/sysemu/char.h
> @@ -58,17 +58,24 @@ struct ParallelIOArg {
>
> typedef void IOEventHandler(void *opaque, int event);
>
> +#define MAX_CLIENTS 256
> +#define ANONYMOUS_CLIENT (~((uint64_t)0))
> struct CharDriverState {
> QemuMutex chr_write_lock;
> void (*init)(struct CharDriverState *s);
> int (*chr_write)(struct CharDriverState *s, const uint8_t *buf, int
> len);
> +int (*chr_write_n)(struct CharDriverState *s, uint64_t id, const
> uint8_t *buf, int len);
> int (*chr_sync_read)(struct CharDriverState *s,
> const uint8_t *buf, int len);
> +int (*chr_sync_read_n)(struct CharDriverState *s, uint64_t id,
> + const uint8_t *buf, int len);
> GSource *(*chr_add_watch)(struct CharDriverState *s, GIOCondition
> cond);
> void (*chr_update_read_handler)(struct CharDriverState *s);
> int (*chr_ioctl)(struct CharDriverState *s, int cmd, void *arg);
> int (*get_msgfds)(struct CharDriverState *s, int* fds, int num);
> +int (*get_msgfds_n)(struct CharDriverState *s, uint64_t id, int* fds,
> int num);
> int (*set_msgfds)(struct CharDriverState *s, int *fds, int num);
> +int (*set_msgfds_n)(struct CharDriverState *s, uint64_t id, int *fds,
> int num);
> int (*chr_add_client)(struct CharDriverState *chr, int fd);
> int (*chr_wait_connected)(struct CharDriverState *chr, Error **errp);
> IOEventHandler *chr_event;
> @@ -77,6 +84,7 @@ struct CharDriverState {
> void *handler_opaque;
> void (*chr_close)(struct CharDriverState *chr);
> void (*chr_disconnect)(struct CharDriverState *chr);
> +void (*chr_disconnect_n)(struct CharDriverState *chr, uint64_t id);
> void (*chr_accept_input)(struct CharDriverState *chr);
> void (*chr_set_echo)(struct CharDriverState *chr, bool echo);
> void (*chr_set_fe_open)(struct CharDriverState *chr, int fe_open);
> @@ -91,7 +99,10 @@ struct CharDriverState {
> int explicit_be_open;
> int avail_connections;
> int is_mux;
> -guint fd_in_tag;
> +guint fd_in_tag[MAX_CLIENTS];
> +uint64_t max_connections;
> +unsigned long *conn_bitmap;
> +uint64_t conn_id;
> QemuOpts *opts;
> bool replay;
> QTAILQ_ENTRY(CharDriverState) next;
> @@ -281,6 +292,20 @@ int qemu_chr_fe_write(CharDriverState *s, const
> uint8_t *buf, int len);
> int qemu_chr_fe_write_all(CharDriverState *s, const uint8_t *buf, int
> len);
>
> /**
> + * @qemu_chr_fe_write_all_n:
> + *
> + * Write data to the selected character backend from the front end.
> + *
> + * @id the connection id of the character backend
> + * @buf the data
> + * @len the number of bytes to send
> + *
> + * Returns: the number of bytes consumed
> + */
> +int qemu_chr_fe_write_all_n(CharDriverState *s, uint64_t id,
> +const uint8_t *buf, int len);
> +
> +/**
> * @qemu_chr_fe_read_all:
> *
> * Read data to a buffer from the back end.
> @@ -293,6 +318,20 @@ int qemu_chr_fe_write_all(CharDriverState *s, const
> uint8_t *buf, int len);
> int qemu_chr_fe_read_all(CharDriverState *s, uint8_t *buf, int len);
>
> /**
> + * @qemu_chr_fe_read_all_n:
> + *
> + * Read data to a buffer from the selected back end.
> + *
> + * @id the connection id
> + * @buf the data buffer
> + * @len the number of bytes to read
> + *
> + * Returns: the number of bytes read
> + */
> +int qemu_chr_fe_read_all_n(CharDriverState *s, uint64_t id,
> + uint8_t *buf, int len);
> +
> +/**
> * @qemu_chr_fe_ioctl:
> *
> * Issue a device specific ioctl to a backend. This function is
> thread-safe.
> @@ -331,6 +370,19 @@ int qemu_chr_fe_get_msgfd(CharDriverState *s);
> */
> int qemu_chr_fe_get_msgfds(CharDriverState *s, int *fds, int num);
>
> +
> +/**
> + * @qemu_chr_fe_get_msgfds_n:
> + *
> + * The multi-client version of @qemu_chr_fe_get_msgfds.
> + *
> + * Returns: -1 if fd passing isn't supported or there are no pending fil
Re: [Qemu-devel] [PATCH 0/3] target-arm: cache tbflags in CPUARMState
Paolo Bonzini writes: > Computing TranslationBlock flags is pretty expensive on ARM, especially > 32-bit. Because tbflags are computed on every tb lookup, it is not > unlikely to see cpu_get_tb_cpu_state close to the top of the profile > now that QHT makes the hash table much more efficient. > > However, most tbflags only change when the EL is switched or after > MSR instructions. Based on this observation, this series caches these > tbflags in CPUARMState, resulting in a 10-15% speedup on 32-bit code. Hi, I'm starting to clear out my review queue but I notice these now longer apply cleanly to master. Where you going to re-issue the series once you'd addressed Peter's concerns? My general comments are I think this is a good idea but my concern is ensuring state changes get picked up and we don't end up with inconsistent state between real and cached values. I still have the scars from my last attempt to rationalise cpu.h pstate, aarch64, uncached_cpsr and spsr! Cheers, -- Alex Bennée
Re: [Qemu-devel] [QEMU PATCH v2] kvmclock: advance clock by time window between vm_stop and pre_save
GOn Wed, Nov 09, 2016 at 05:23:50PM +0100, Paolo Bonzini wrote: > > > On 08/11/2016 11:22, Dr. David Alan Gilbert wrote: > > * Marcelo Tosatti (mtosa...@redhat.com) wrote: > >> On Mon, Nov 07, 2016 at 08:03:50PM +, Dr. David Alan Gilbert wrote: > >>> * Marcelo Tosatti (mtosa...@redhat.com) wrote: > On Mon, Nov 07, 2016 at 03:46:11PM +, Dr. David Alan Gilbert wrote: > > * Marcelo Tosatti (mtosa...@redhat.com) wrote: > >> This patch, relative to pre-copy migration codepath, > >> measures the time between vm_stop() and pre_save(), > >> which includes copying the remaining RAM to destination, > >> and advances the clock by that amount. > >> > >> In a VM with 5 seconds downtime, this reduces the guest > >> clock difference on destination from 5s to 0.2s. > >> > >> Tested with Linux and Windows 2012 R2 guests with -cpu XXX,+hv-time. > > > > One thing that bothers me is that it's only this clock that's > > getting corrected; doesn't it cause things to get upset when > > one clock moves and the others dont? > > If you are correlating the clocks, then yes. > > Older Linux guests get upset (marking the TSC clocksource unstable > because the watchdog checks TSC vs kvmclock), but there is a workaround > for it > in newer guests > (kvmclock interface to notify watchdog to not complain). > > Note marking TSC clocksource unstable on older guests is harmless > because kvmclock is the standard clocksource. > > For Windows guests, i don't know that Windows correlates between > different > clocks. > > That is, there is relative control as to which software reads kvmclock > or Windows TIMER MSR, so i don't see the need to advance every clock > exposed. > > > Shouldn't the pause delay be recorded somewhere architecturally > > independent and then be a thing that kvm-clock happens to use and > > other clocks might as well? > > In theory, yes. In practice, i don't see the need for this... > >>> > >>> It seems unlikely to me that x86 is the only one that will want > >>> to do something similar. > >> > >> Can't they copy what kvmclock is doing today? > > > > We shouldn't have copies of code all over should we? > > Let's cross the bridge when we get there. > > For now I'm more interested in having a version of the patch that is > clean and doesn't need advance_clock. > > Paolo Destination has to run the following logic: If (source has KVM_CAP_ADVANCE_CLOCK) use KVM_GET_CLOCK value Else read pvclock from guest To support migration from older QEMU versions which do not have KVM_CAP_ADVANCE_CLOCK (or new QEMU versions running on old hosts without KVM_CAP_ADVANCE_CLOCK). I don't see any clean way to give that information, except changing the migration format to pass "host: kvm_cap_advance_clock=true/false" information. Ideas?
Re: [Qemu-devel] [QEMU PATCH v12 2/4] migration: migrate QTAILQ
On 11/08/2016 01:06 AM, Jianjun Duan wrote:
> Currently we cannot directly transfer a QTAILQ instance because of the
> limitation in the migration code. Here we introduce an approach to
> transfer such structures. We created VMStateInfo vmstate_info_qtailq
> for QTAILQ. Similar VMStateInfo can be created for other data structures
> such as list.
>
> When a QTAILQ is migrated from source to target, it is appended to the
> corresponding QTAILQ structure, which is assumed to have been properly
> initialized.
>
> This approach will be used to transfer pending_events and ccs_list in spapr
> state.
>
> We also create some macros in qemu/queue.h to access a QTAILQ using pointer
> arithmetic. This ensures that we do not depend on the implementation
> details about QTAILQ in the migration code.
>
> Signed-off-by: Jianjun Duan
> ---
> include/migration/vmstate.h | 20 +
> include/qemu/queue.h| 60 +++
> migration/trace-events | 4 +++
> migration/vmstate.c | 69
> +
> 4 files changed, 153 insertions(+)
>
> diff --git a/include/migration/vmstate.h b/include/migration/vmstate.h
> index eafc8f2..6289327 100644
> --- a/include/migration/vmstate.h
> +++ b/include/migration/vmstate.h
> @@ -253,6 +253,7 @@ extern const VMStateInfo vmstate_info_timer;
> extern const VMStateInfo vmstate_info_buffer;
> extern const VMStateInfo vmstate_info_unused_buffer;
> extern const VMStateInfo vmstate_info_bitmap;
> +extern const VMStateInfo vmstate_info_qtailq;
>
> #define type_check_2darray(t1,t2,n,m) ((t1(*)[n][m])0 - (t2*)0)
> #define type_check_array(t1,t2,n) ((t1(*)[n])0 - (t2*)0)
> @@ -664,6 +665,25 @@ extern const VMStateInfo vmstate_info_bitmap;
> .offset = offsetof(_state, _field),\
> }
>
> +/* For QTAILQ that need customized handling.
What do you mean by customized handling? How does non-customized
handling look like?
I would also add something like works only for movable
elements/nodes to make it clear that scenarios like Juan has
pointed out previously are not currently supported.
> + * Target QTAILQ needs be properly initialized.
Could this restriction be avoided by doing (1)?
> + * _type: type of QTAILQ element
> + * _next: name of QTAILQ entry field in QTAILQ element
> + * _vmsd: VMSD for QTAILQ element
> + * size: size of QTAILQ element
> + * start: offset of QTAILQ entry in QTAILQ element
> + */
> +#define VMSTATE_QTAILQ_V(_field, _state, _version, _vmsd, _type, _next) \
> +{\
> +.name = (stringify(_field)), \
> +.version_id = (_version), \
> +.vmsd = &(_vmsd),\
> +.size = sizeof(_type), \
> +.info = &vmstate_info_qtailq,\
> +.offset = offsetof(_state, _field),\
> +.start= offsetof(_type, _next), \
> +}
> +
> /* _f : field name
> _f_n : num of elements field_name
> _n : num of elements
> diff --git a/include/qemu/queue.h b/include/qemu/queue.h
> index 342073f..75616e1 100644
> --- a/include/qemu/queue.h
> +++ b/include/qemu/queue.h
> @@ -438,4 +438,64 @@ struct {
>\
> #define QTAILQ_PREV(elm, headname, field) \
> (*(((struct headname *)((elm)->field.tqe_prev))->tqh_last))
>
> +#define field_at_offset(base, offset, type)
> \
> +((type) (((char *) (base)) + (offset)))
> +
> +typedef struct DUMMY_Q_ENTRY DUMMY_Q_ENTRY;
> +typedef struct DUMMY_Q DUMMY_Q;
> +
> +struct DUMMY_Q_ENTRY {
> +QTAILQ_ENTRY(DUMMY_Q_ENTRY) next;
> +};
> +
> +struct DUMMY_Q {
> +QTAILQ_HEAD(DUMMY_Q_HEAD, DUMMY_Q_ENTRY) head;
> +};
> +
> +#define dummy_q ((DUMMY_Q *) 0)
> +#define dummy_qe ((DUMMY_Q_ENTRY *) 0)
> +
> +/*
> + * Offsets of layout of a tail queue head.
> + */
> +#define QTAILQ_FIRST_OFFSET (offsetof(typeof(dummy_q->head), tqh_first))
> +#define QTAILQ_LAST_OFFSET (offsetof(typeof(dummy_q->head), tqh_last))
> +/*
> + * Raw access of elements of a tail queue
> + */
> +#define QTAILQ_RAW_FIRST(head)
> \
> +(*field_at_offset(head, QTAILQ_FIRST_OFFSET, void **))
> +#define QTAILQ_RAW_LAST(head)
> \
> +(*field_at_offset(head, QTAILQ_LAST_OFFSET, void ***))
> +
> +/*
> + * Offsets of layout of a tail queue element.
> + */
> +#define QTAILQ_NEXT_OFFSET (offsetof(typeof(dummy_qe->next), tqe_next))
> +#define QTAILQ_PREV_OFFSET (offsetof(typeof(dummy_qe->next), tqe_prev))
> +
> +/*
> + * Raw access of elements of a tail entry
> + */
> +#d
[Qemu-devel] [Bug 616769] Re: interrupt problem x86_64
Hello Thomas, it happens some years ago and now I'm not able to reproduce it. I'm sorry, thanks again, Paolo -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/616769 Title: interrupt problem x86_64 Status in QEMU: Incomplete Bug description: Hello. I'm studing the x86_64 arch to port colinux to this new architecture. For who does not know, colinux is a port of linux that runs on windows NATIVELY. Colinux is 1) a small windows driver 2) a kernel patched 3) some windows user-space application that talk with linux kernel (network, console, ...) I have written the more internal part of colinux, that is the code that switch between windows and linux. This is done saving and restore the machine state : 1) CR3 2) IDT 3) registers The problem I see is that after the switch I see the reboot of my virtual machine. I would say that the new IDT and/or CR3 is not flushed. My code is written in asm/C so I can follow the code step by step. I can say exactly the instruction that is broken. All my code runs nicely on bochs. I don't have an x86_64 real PC. If someone wants to repair this bug I'm here. Paolo Minazzi To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/616769/+subscriptions
Re: [Qemu-devel] virtIO question
From this point of view ,I think it make sense well, thank you very much! but I have another question about notify mechanism between virtIO driver and qemu. according the source code of Linux and qemu, when driver add a sg buffer to send queue named sq, sq->vq->vring.avail->idx++ vq->num_added++ and then use virtqueue_kick_prepare to make sure if need notify qemu. it (new_idx-event_idx)<(new_idx-old_idx) if it is true,then notify other side. However,every time driver add a sg,then virtqueue_kick_prepare is called,and vq->num_added is reseted to 0,so in fact ,I think vq->num_added is always 0 or 1。 as to qemu side,every time when pop a elem from virtqueue,it set VRingUsed.ring[vring.num] to the lastest VRingAvail.idx, this according the arithmetic ((new_idx-event_idx)<(new_idx-old_idx)),it seems that this mechanism does not make sense I do not know if I describe it clearly.or can you give me an example to prove how it make sense!! thanks a lot! zhun...@gmail.com From: Stefan Hajnoczi Date: 2016-11-10 18:32 To: zhun...@gmail.com CC: jkhasdev; qemu Subject: Re: [Qemu-devel] virtIO question On Wed, Nov 09, 2016 at 06:58:16PM +0800, zhun...@gmail.com wrote: > I want to ask a another question,why a virt_queue in virtio include in_sgs > and out_sgs,for example,send_queue of virtIO net driver have in_sgs and > out_sgs，when transmit data,It add buffer to out_sgs of send_queue,but how it > to use in_sgs?? You can think of every virtqueue buffer as having two scatter-gather lists: 1. out_sgs are driver->device buffers (e.g. tx packet payload) 2. in_sgs are device->driver buffers (e.g. rx packet payload) Look at the virtio-net ctrl virtqueue (see spec and virtio_net_handle_ctrl() for details). Each buffer has: 1. struct virtio_net_ctrl_hdr (out_sgs) 2. request-specific fields (out_sgs) 3. virtio_net_ctrl_ack status byte (in_sgs) The device parses the request and performs the operation. Then it fills in the result (success or error code) in the status byte. Processing ctrl virtqueue buffers therefore requires both guest memory reads (out_sgs) and writes (in_sgs). Most of the other virtio devices also use bi-directional buffers. This may not be obvious if you only consider the virtio-net tx virtqueue, for example, where buffers use out_sgs only. Hope this makes sense. If not, look at the specification again and think about how virtio-net ctrl request processing works.
Re: [Qemu-devel] [PATCH 0/3] target-arm: cache tbflags in CPUARMState
On 10/11/2016 12:42, Alex Bennée wrote: > > Paolo Bonzini writes: > >> Computing TranslationBlock flags is pretty expensive on ARM, especially >> 32-bit. Because tbflags are computed on every tb lookup, it is not >> unlikely to see cpu_get_tb_cpu_state close to the top of the profile >> now that QHT makes the hash table much more efficient. >> >> However, most tbflags only change when the EL is switched or after >> MSR instructions. Based on this observation, this series caches these >> tbflags in CPUARMState, resulting in a 10-15% speedup on 32-bit code. > > Hi, > > I'm starting to clear out my review queue but I notice these now longer > apply cleanly to master. Where you going to re-issue the series once > you'd addressed Peter's concerns? Yes, I didn't want to send them two days before soft freeze and Peter's vacation. :) Paolo
[Qemu-devel] [PATCH] tests: add XSCOM tests for the PowerNV machine
Add a couple of tests on the XSCOM bus of the PowerNV machine for the
the POWER8 and POWER9 CPUs. The first tests reads the CFAM identifier
of the chip. The second test goes further in the XSCOM address space
and reaches the cores to read their DTS registers. This last one is
disabled on P9 for the moment as the EQ/EX/EC XSCOM mapping needs more
work to be functional.
Signed-off-by: Cédric Le Goater
---
tests/Makefile.include | 1 +
tests/pnv-xscom-test.c | 138 +
2 files changed, 139 insertions(+)
create mode 100644 tests/pnv-xscom-test.c
diff --git a/tests/Makefile.include b/tests/Makefile.include
index de516341fd44..90c9ad9ac6e1 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -270,6 +270,7 @@ gcov-files-ppc64-y = ppc64-softmmu/hw/ppc/spapr_pci.c
check-qtest-ppc64-y += tests/endianness-test$(EXESUF)
check-qtest-ppc64-y += tests/boot-order-test$(EXESUF)
check-qtest-ppc64-y += tests/prom-env-test$(EXESUF)
+check-qtest-ppc64-y += tests/pnv-xscom-test$(EXESUF)
check-qtest-ppc64-y += tests/drive_del-test$(EXESUF)
check-qtest-ppc64-y += tests/postcopy-test$(EXESUF)
check-qtest-ppc64-y += tests/boot-serial-test$(EXESUF)
diff --git a/tests/pnv-xscom-test.c b/tests/pnv-xscom-test.c
new file mode 100644
index ..994dd015c425
--- /dev/null
+++ b/tests/pnv-xscom-test.c
@@ -0,0 +1,138 @@
+/*
+ * QTest testcase for PowerNV XSCOM bus
+ *
+ * Copyright (c) 2016, IBM Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or
+ * later. See the COPYING file in the top-level directory.
+ */
+#include "qemu/osdep.h"
+
+#include "libqtest.h"
+
+typedef enum PnvChipType {
+PNV_CHIP_POWER8E, /* AKA Murano (default) */
+PNV_CHIP_POWER8, /* AKA Venice */
+PNV_CHIP_POWER8NVL, /* AKA Naples */
+PNV_CHIP_POWER9, /* AKA Nimbus */
+} PnvChipType;
+
+#define PNV_XSCOM_EX_BASE 0x1000
+#define PNV_XSCOM_EX_CORE_BASE(i) (PNV_XSCOM_EX_BASE | (((uint64_t)i) << 24))
+
+static const struct pnv_chip {
+PnvChipType chip_type;
+const char *cpu_model;
+uint64_txscom_base;
+uint64_tcfam_id;
+uint32_tfirst_core;
+} pnv_chips[] = {
+{
+.chip_type = PNV_CHIP_POWER8,
+.cpu_model = "POWER8",
+.xscom_base = 0x003fc00ull,
+.cfam_id= 0x220ea0498000ull,
+.first_core = 0x1,
+},
+{
+.chip_type = PNV_CHIP_POWER8NVL,
+.cpu_model = "POWER8NVL",
+.xscom_base = 0x003fc00ull,
+.cfam_id= 0x120d30498000ull,
+.first_core = 0x1,
+},
+{
+.chip_type = PNV_CHIP_POWER9,
+.cpu_model = "POWER9",
+.xscom_base = 0x00603fcull,
+.cfam_id= 0x100d10498000ull,
+.first_core = 0x20,
+},
+};
+
+static uint64_t pnv_xscom_addr(const struct pnv_chip *chip, uint32_t pcba)
+{
+uint64_t addr = chip->xscom_base;
+
+if (chip->chip_type == PNV_CHIP_POWER9) {
+return addr | ((uint64_t) pcba << 3);
+} else {
+return addr | (((uint64_t) pcba << 4) & ~0xfful) |
+(((uint64_t) pcba << 3) & 0x78);
+}
+}
+
+static void test_xscom_cfam_id(const struct pnv_chip *chip)
+{
+uint64_t f000f = readq(pnv_xscom_addr(chip, 0xf000f));
+
+g_assert_cmphex(f000f, ==, chip->cfam_id);
+}
+
+static void test_cfam_id(const void *data)
+{
+char *args;
+const struct pnv_chip *chip = data;
+
+args = g_strdup_printf("-M powernv,accel=tcg -cpu %s", chip->cpu_model);
+
+qtest_start(args);
+test_xscom_cfam_id(chip);
+qtest_quit(global_qtest);
+
+g_free(args);
+}
+
+static void test_xscom_core(const struct pnv_chip *chip)
+{
+uint32_t first_core_dts0 =
+PNV_XSCOM_EX_CORE_BASE(chip->first_core) | 0x5;
+uint64_t dts0 = readq(pnv_xscom_addr(chip, first_core_dts0));
+
+g_assert_cmphex(dts0, ==, 0x26f024f023full);
+}
+
+static void test_core(const void *data)
+{
+char *args;
+const struct pnv_chip *chip = data;
+
+args = g_strdup_printf("-M powernv,accel=tcg -cpu %s", chip->cpu_model);
+
+qtest_start(args);
+test_xscom_core(chip);
+qtest_quit(global_qtest);
+
+g_free(args);
+}
+
+int main(int argc, char **argv)
+{
+int i;
+
+g_test_init(&argc, &argv, NULL);
+
+for (i = 0; i < ARRAY_SIZE(pnv_chips); i++) {
+char *name = g_strdup_printf("pnv-xscom/cfam_id/%s",
+ pnv_chips[i].cpu_model);
+qtest_add_data_func(name, &pnv_chips[i], test_cfam_id);
+g_free(name);
+}
+
+for (i = 0; i < ARRAY_SIZE(pnv_chips); i++) {
+/*
+ * Discard P9 for the moment as EQ/EX/EC XSCOM mapping needs a
+ * rework
+ */
+if (pnv_chips[i].chip_type == PNV_CHIP_POWER9) {
+continue;
+}
+
+char *name = g_strdup_printf("pnv-xscom/core/%s",
+ pnv_chips[i].cpu_model)
Re: [Qemu-devel] [virtio-comment] Re: [PATCH v1] docs/vhost-user: extend the vhost-user protocol to support the vhost-pci based inter-vm communication
Hi Wei On Wed, Nov 9, 2016 at 12:32 PM Wei Wang wrote: > On 11/08/2016 08:17 PM, Marc-André Lureau wrote: > > > > > > > > Message Specification > > > - > > > > > > Note that all numbers are in the machine native byte order. A > > > vhost-user message > > > -consists of 3 header fields and a payload: > > > +consists of 4 header fields and a payload: > > > > > > - > > > -| request | flags | size | payload | > > > - > > > +-- > > > +| request | flags | conn_id | size | payload | > > > +-- > > > > > > * Request: 32-bit type of the request > > > * Flags: 32-bit bit field: > > > - Lower 2 bits are the version (currently 0x01) > > > - - Bit 2 is the reply flag - needs to be sent on each reply > > > from the slave > > > + - Bit 2 is the reply flag - needs to be sent on each reply > > > - Bit 3 is the need_reply flag - see > > > VHOST_USER_PROTOCOL_F_REPLY_ACK for > > > details. > > > + * Conn_id: 64-bit connection id to indentify a client socket > > > connection. It is > > > +introduced in version 0x02 to support the > > > "1-server-N-client" model > > > +and an asynchronous client read implementation. > The > > > connection id, > > > +0x, is used by an anonymous client > > > (e.g. a client who > > > +has not got its connection id from the server > > in the > > > initial talk) > > > > > > > > > I don't understand why you need a connection id, on each message. > > > What's the purpose? Since the communication is unicast, a single > > > message should be enough. > > > > Sure, please let me explain more: > > The QEMU socket is going to be upgraded to support 1 server socket > > being > > connected by multiple client sockets (I've made patches to achieve > > this). In other words, here, multiple masters will connect to one > > slave, > > and the slave creates a vhost-pci device for each master after > > receiving > Before handling hotplugging and multiple vhost-pci, I think it would be simpler to support 1-1. > > the necessary message info. The slave needs to know which master it > is > > talking to when receiving a message, as it maintains multiple > > connections at the same time. > > > > > > You should be able to identify each connection in the slave (as a > > socket server), without a need for connection id: connected sockets > > are independent from each others. > > > Yes, that's doable. But why couldn't we do it from the protocol layer? I > think it will be easier. > Since it can be done by implementation, I would rather not change the protocol with unnecessary data. > > Please check below my thoughts about the implementation if we do it in > the slave: > > The interface for receiving a msg is - tcp_chr_read(QIOChannel *chan, > GIOCondition cond, void *opaque) > > QIOChannel is the one that we can use to identify the master connection > who sends this msg (the socket server now has an array of QIOChannel, > ioc[MAX_CLIENTS]). Everytime a msg is received, the tcp_chr_read() needs > to compare *chan and the ioc[] array, to find out the id (indexed into > the ioc[]), and passes the id to qemu_chr_be_write(), and all the way > down to the final slave handler where the msg is parsed and handled. > This needs modifications to the existing APIs, for example, the > mentioned qemu_chr_be_write() will need one more parameter, "id". This > will not be compatible with the existing implementation, because all > other implementations which invoke qemu_chr_be_write() will need to be > patched to use the new qemu_chr_be_write(,"id",). > We could have the "id" set with the CharBackend. But again, it's an implementation detail, and I would rather treat it as a seperate enhacement. > > > > > > * Size - 32-bit size of the payload > > > > > > > > > @@ -97,6 +106,13 @@ Depending on the request type, payload > > can be: > > > log offset: offset from start of supplied file descriptor > > > where logging starts (i.e. where guest address 0 > > would be > > > logged) > > > > > > +* Device info > > > + > > > + | virito id | uuid | > > > + > > > + Virtio id: 16-bit virtio id of the device > > > + UUID: 128-bit UUID to identify the QEMU instance that > > creates > > > the device > > > + > > > > > > > > > I wonder if UUID should be a different
[Qemu-devel] [PATCH v2 0/1] vfio-pci: fix assert fail in host property if unused
Changes since v1: * Wrap commit log at 70 chars. Commit 4a946268 changed the default value of the structure (PCIHostDeviceAddress) underlying the host property in vfio-pci to be ~0 in all fields. Since this structure has excess bits for representing a standard BDF (:FF:FF.F) this triggers an assert check designed to catch such invalid BDFs in the get function of the property. This makes any code that attempts to use get on the property fatal if the host device isn't specified using the now optional host property. To see the bug assign a vfio-pci device using the sysfsdev property instead of the host property so that host gets the default "not present," value. Attempts to display the property then crash the working emulation. qemu-system-x86_64 -device vfio-pci,id=gfxfn0,sysfsdev='/sys/bus/pci/devices/:01:00.0' -monitor stdio QEMU 2.7.50 monitor - type 'help' for more information (qemu) info qtree bus: main-system-bus Omitted for brevity... bus: pci.0 type PCI dev: vfio-pci, id "gfxfn0" qemu-system-x86_64: /home/xochip/source/qemu.git/hw/core/qdev-properties.c:717: get_pci_host_devaddr: Assertion `rc == sizeof(buffer) - 1' failed. The bug is minor because the structure involved is presumably insufficient and redundant given the introduction of the new sysfsdev property. Since I'm new to the code, I resisted the urge to make a mess by cleaning it up and attach a totally minimal fix in the hope it makes the problem clearer and easier to ignore. Happy to redo or leave it to somebody else as required. Regards, Dan. Daniel Oram (1): Fix assert in PCI address property when used by vfio-pci hw/core/qdev-properties.c | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) -- 2.10.2
[Qemu-devel] [PATCH v2 1/1] Fix assert in PCI address property when used by vfio-pci
Allow the PCIHostDeviceAddress structure to work as the host property
in vfio-pci when it has it's default value of all fields set to ~0. In
this form the property indicates a non-existant device but given the
field bit sizes gets asserted as excess (and invalid) precision
overflows the string buffer. The BDF of an invalid device
":FF:FF.F" is returned instead.
Signed-off-by: Daniel Oram
Reviewed-by: Alex Williamson
---
v2:
- Wrap commit log at 70 chars.
---
hw/core/qdev-properties.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
index 311af6d..ed0d5b0 100644
--- a/hw/core/qdev-properties.c
+++ b/hw/core/qdev-properties.c
@@ -705,13 +705,21 @@ static void get_pci_host_devaddr(Object *obj, Visitor *v,
const char *name,
DeviceState *dev = DEVICE(obj);
Property *prop = opaque;
PCIHostDeviceAddress *addr = qdev_get_prop_ptr(dev, prop);
-char buffer[] = ":xx:xx.x";
+char buffer[] = ":ff:ff.f";
char *p = buffer;
int rc = 0;
-
-rc = snprintf(buffer, sizeof(buffer), "%04x:%02x:%02x.%d",
- addr->domain, addr->bus, addr->slot, addr->function);
-assert(rc == sizeof(buffer) - 1);
+
+/*
+ * Catch "invalid" device reference from vfio-pci and allow the
+ * default buffer representing the non-existant device to be used.
+ */
+if (~addr->domain || ~addr->bus || ~addr->slot || ~addr->function) {
+
+rc = snprintf(buffer, sizeof(buffer), "%04x:%02x:%02x.%0d",
+ addr->domain, addr->bus, addr->slot, addr->function);
+assert(rc == sizeof(buffer) - 1);
+}
+
visit_type_str(v, name, &p, errp);
}
--
2.10.2
Re: [Qemu-devel] Sphinx for QEMU docs? (and a doc-comment format question)
On Thu, Nov 10, 2016 at 11:39:14AM +0800, Fam Zheng wrote: > On Wed, 11/09 11:32, Stefan Hajnoczi wrote: > > No doc comments -> error. > > I'm not sure that is a good idea. For example all .bdrv_co_flush_to_disk > implementations have the same semantics and signature, requiring doc comments > everywhere might be too much. I mean in include/. Stefan signature.asc Description: PGP signature
Re: [Qemu-devel] [RFC 1/3] aio-posix: add aio_set_poll_handler()
On Wed, Nov 09, 2016 at 06:30:11PM +0100, Paolo Bonzini wrote:
Thanks for the feedback. I hope that Karl will be able to find a
QEMU_AIO_POLL_MAX_NS setting that improves the benchmark. At that point
I'll send a new version of this series so we can iron out the details.
> > +static bool run_poll_handlers(AioContext *ctx)
> > +{
> > +int64_t start_time;
> > +unsigned int loop_count = 0;
> > +bool fired = false;
> > +
> > +/* Is there any polling to be done? */
>
> I think the question is not "is there any polling to be done" but rather
> "is there anything that requires looking at a file descriptor". If you
> have e.g. an NBD device on the AioContext you cannot poll. On the other
> hand if all you have is bottom halves (which you can poll with
> ctx->notified), AIO and virtio ioeventfds, you can poll.
This is a good point. Polling should only be done if all resources in
the AioContext benefit from polling - otherwise it adds latency to
resources that don't support polling.
Another thing: only poll if there is work to be done. Linux AIO must
only poll the ring when there are >0 requests outstanding. Currently it
always polls (doh!).
> In particular, testing for bottom halves is necessary to avoid incurring
> extra latency on flushes, which use the thread pool.
The current code uses a half-solution: it uses aio_compute_timeout() to
see if any existing BHs are ready to execute *before* beginning to poll.
Really we should poll BHs since they can be scheduled during the polling
loop.
> Perhaps the poll handler could be a parameter to aio_set_event_notifier?
> run_poll_handlers can just set revents (to G_IO_IN for example) if the
> polling handler returns true, and return true as well. aio_poll can
> then call aio_notify_accept and aio_dispatch, bypassing the poll system
> call altogether.
This is problematic. The poll source != file descriptor so there is a
race condition:
1. Guest increments virtqueue avail.idx
2. QEMU poll notices avail.idx update and marks fd.revents readable.
3. QEMU dispatches fd handler:
void virtio_queue_host_notifier_read(EventNotifier *n)
{
VirtQueue *vq = container_of(n, VirtQueue, host_notifier);
if (event_notifier_test_and_clear(n)) {
virtio_queue_notify_vq(vq);
}
}
4. Guest kicks virtqueue -> ioeventfd is signalled
Unfortunately polling is "too fast" and event_notifier_test_and_clear()
returns false; we won't process the virtqueue!
Pretending that polling is the same as fd monitoring only works when #4
happens before #3. We have to solve this race condition.
The simplest solution is to get rid of the if statement (i.e. enable
spurious event processing). Not sure if that has a drawback though.
Do you have a nicer solution in mind?
signature.asc
Description: PGP signature
Re: [Qemu-devel] [virtio-dev] Re: [PATCH v13 1/2] virtio-crypto: Add virtio crypto device specification
On Thu, Nov 10, 2016 at 02:25:44AM +, Gonglei (Arei) wrote: > > > > > Subject: [virtio-dev] Re: [Qemu-devel] [PATCH v13 1/2] virtio-crypto: Add > > virtio > > crypto device specification > > > > On Wed, Nov 09, 2016 at 01:11:20AM +, Gonglei (Arei) wrote: > > > Nope, Actually I kept those description here is because I wanted to > > > represent > > each packet > > > Intuitionally, otherwise I don't know how to explain them only occupy one > > entry in desc table > > > by indirect table method. > > > > whether to use the indirect method should not be up to device. > > I don't see where does the spec require indirect method, > > ANY_LAYOUT is implied so spec should not dictate that IMO. > > > Yes, I reread the virtio spec. And > > 2.4.4 says: > " The framing of messages with descriptors is independent of the contents of > the buffers." > > 2.4.4.2 says: > "The driver SHOULD NOT use an excessive number of descriptors to describe a > buffer." > > For virtio-crypto, I think I can just add a NOTE to remind people using > indirect method > if they want to get better performance in production environment, can I? > > > Thanks, > -Gonglei I'm not sure why frankly. Is there a reason crypto is special here? > > > So I changed the code completely as Stefan's suggestion and > > > revised the spec a little. > > > > > > This just is a representative of the realization so that the people can > > > easily > > understand what > > > the virtio crypto request's components. It isn't completely same with the > > code. > > > For virtio-scsi device, the struct virtio_scsi_req_cmd also used this way > > > IIUR. > > > > > > Thanks, > > > -Gonglei > > > > - > > To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org > > For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [Qemu-devel] [PATCH] target-m68k: add rol/ror/roxl/roxr instructions
On 11/09/2016 09:22 PM, Laurent Vivier wrote: Le 09/11/2016 à 20:39, Richard Henderson a écrit : On 11/09/2016 07:47 PM, Richard Henderson wrote: On 11/09/2016 06:30 PM, Laurent Vivier wrote: +/* create [src:X:..] */ + +tcg_gen_deposit_i32(t0, QREG_CC_X, src, 1, size); +tcg_gen_shli_i32(t0, t0, 31 - size); + +/* rotate */ + +tcg_gen_rotl_i32(t0, t0, shift); + +/* result is [src:..:src:X] */ + +tcg_gen_andi_i32(X, t0, 1); +tcg_gen_shri_i32(t0, t0, 1); I don't see how this is supposed to work. If you form [src:x:...], and rotate by 0, then X gets garbage. Of course, you're actually forming The result is ignored in the case of a rotate by 0 (see movcond in rotate_reg()). [0:src:x]. But for a rol of 2, the lsb of src gets 0's instead of the msb of src. for a rol of 2 on an 8bit value [12345678]: tcg_gen_deposit_i32(t0, QREG_CC_X, src, 1, size); tcg_gen_shli_i32(t0, t0, 31 - size); t0 = [12345678x000] tcg_gen_rotl_i32(t0, t0, shift); t0 = [345678x00012] tcg_gen_andi_i32(X, t0, 1); X = 2 tcg_gen_shri_i32(t0, t0, 1); t0 = [0345678x0001] tcg_gen_shri_i32(t1, t0, 31 - size); t1 = [345678x0] tcg_gen_or_i32(dest, t0, t1); dest = [0345678x345678x1] -> we keep only 8 bits: [345678x1] Where am I wrong? You aren't. I simply misread this. But still we must only perform this rotate modulo size+1. r~
Re: [Qemu-devel] [PATCH v1 1/1] virtio crypto device specification: asymmetric crypto service
Ping...
Appreciate for any comments for this patch!
Thanks
> -Original Message-
> From: virtio-...@lists.oasis-open.org [mailto:virtio-...@lists.oasis-open.org]
> On Behalf Of Zeng, Xin
> Sent: Thursday, November 3, 2016 8:19 PM
> To: virtio-...@lists.oasis-open.org; qemu-devel@nongnu.org
> Cc: m...@redhat.com; arei.gong...@huawei.com; Keating, Brian A
> ; Griffin, John ; Ma,
> Liang J ; weidong.hu...@huawei.com
> Subject: [virtio-dev] RE: [PATCH v1 1/1] virtio crypto device specification:
> asymmetric crypto service
>
> Ping
> Is there any comment for this patch?
>
> thanks
>
> > -Original Message-
> > From: Zeng, Xin
> > Sent: Friday, October 28, 2016 10:52 AM
> > To: virtio-...@lists.oasis-open.org; qemu-devel@nongnu.org
> > Cc: m...@redhat.com; arei.gong...@huawei.com; Keating, Brian A
> > ; Griffin, John ; Ma,
> > Liang J ; weidong.hu...@huawei.com; Zeng, Xin
> >
> > Subject: [PATCH v1 1/1] virtio crypto device specification: asymmetric
> crypto
> > service
> >
> > This patch introduces asymmetric crypto service into virtio crypto
> > device spec. The asymmetric crypto service can be referred as signature,
> > verification, encryption, decryption, key generation and key exchange.
> > This patch depends on another virtio crypto device spec patch:
> > https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg01744.html
> >
> > Changes since v0:
> > - Use devicenormative/drivernormative instead of self-defined
> > device/driver label. [Lei]
> > - Change the error code of verification to general virtio_crypto
> > error code. [Lei]
> > - Use macro instead of enum in verification result. [Lei]
> > - Fix the incorrect label value for paragraph and section. [Lei]
> >
> > Please help to review, thanks!
> >
> > Signed-off-by: Xin Zeng
> > ---
> > virtio-crypto.tex | 965
> > +-
> > 1 file changed, 962 insertions(+), 3 deletions(-)
> >
> > diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> > index 86e4869..43772da 100644
> > --- a/virtio-crypto.tex
> > +++ b/virtio-crypto.tex
> > @@ -6,7 +6,7 @@ decryption requests are placed in the data queue and
> are
> > ultimately handled by t
> > backend crypto accelerators. The second queue is the control queue used
> to
> > create
> > or destroy sessions for symmetric algorithms and will control some
> advanced
> > features in the future. The virtio crypto device provides the following
> crypto
> > -services: CIPHER, MAC, HASH, and AEAD.
> > +services: CIPHER, MAC, HASH, AEAD and ASYM.
> >
> >
> > \subsection{Device ID}\label{sec:Device Types / Crypto Device / Device ID}
> > @@ -44,7 +44,9 @@ struct virtio_crypto_config {
> > le32 mac_algo_l;
> > le32 mac_algo_h;
> > le32 aead_algo;
> > -le32 reserve;
> > +le32 asym_algo;
> > +le32 rsa_padding;
> > +le32 reserved;
> > };
> > \end{lstlisting}
> >
> > @@ -70,6 +72,8 @@ The following services are defined:
> > #define VIRTIO_CRYPTO_SERVICE_MAC(2)
> > /* AEAD (Authenticated Encryption with Associated Data) service */
> > #define VIRTIO_CRYPTO_SERVICE_AEAD (3)
> > +/* ASYM (Asymmetric crypto algorithms) service */
> > +#define VIRTIO_CRYPTO_SERVICE_ASYM (4)
> > \end{lstlisting}
> >
> > The last driver-read-only fields specify detailed algorithms masks
> > @@ -143,6 +147,28 @@ The following AEAD algorithms are defined:
> > #define VIRTIO_CRYPTO_AEAD_CHACHA20_POLY1305 3
> > \end{lstlisting}
> >
> > +The following asymmetric algorithms are defined:
> > +
> > +\begin{lstlisting}
> > +#define VIRTIO_CRYPTO_ASYM_NONE0
> > +#define VIRTIO_CRYPTO_ASYM_RSA 1
> > +#define VIRTIO_CRYPTO_ASYM_DSA 2
> > +#define VIRTIO_CRYPTO_ASYM_DH 3
> > +#define VIRTIO_CRYPTO_ASYM_ECDSA 4
> > +#define VIRTIO_CRYPTO_ASYM_ECDH 5
> > +\end{lstlisting}
> > +
> > +The following rsa padding capabilities are defined:
> > +
> > +\begin{lstlisting}
> > +#define VIRTIO_CRYPTO_RSA_NO_PADDING 0
> > +#define VIRTIO_CRYPTO_RSA_PKCS1_PADDING 1
> > +#define VIRTIO_CRYPTO_RSA_SSLV23_PADDING 2
> > +#define VIRTIO_CRYPTO_RSA_PKCS1_OAEP_PADDING 3
> > +#define VIRTIO_CRYPTO_RSA_X931_PADDING 4
> > +#define VIRTIO_CRYPTO_RSA_PKCS1_PSS_PADDING 5
> > +\end{lstlisting}
> > +
> > \begin{note}
> > Any other value is reserved for future use.
> > \end{note}
> > @@ -241,6 +267,18 @@ struct virtio_crypto_op_header {
> > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x00)
> > #define VIRTIO_CRYPTO_AEAD_DECRYPT \
> > VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x01)
> > +#define VIRTIO_CRYPTO_ASYM_SIGN\
> > +VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x00)
> > +#define VIRTIO_CRYPTO_ASYM_VERIFY \
> > +VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x01)
> > +#define VIRTIO_CRYPTO_ASYM_ENCRYPT \
> > +VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x02)
> > +#define VIRTIO_CRYPTO_ASYM_DECRYPT \
> > +VIRTIO_CRYPTO_OPCODE(VIRTIO_
Re: [Qemu-devel] [PATCH v13 1/2] virtio-crypto: Add virtio crypto device specification
On Thu, Nov 10, 2016 at 09:37:40AM +, Gonglei (Arei) wrote:
> Hi,
>
> I attach a diff for next version in order to review more convenient, with
>
> - Drop the all gap stuff;
> - Drop all structures undefined in virtio_crypto.h
> - re-describe per request for per crypto service avoid confusion
>
> Pls review, thanks!
>
>
> diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> index 448296e..ab17e7b 100644
> --- a/virtio-crypto.tex
> +++ b/virtio-crypto.tex
> @@ -69,13 +69,13 @@ The following services are defined:
>
> \begin{lstlisting}
> /* CIPHER service */
> -#define VIRTIO_CRYPTO_SERVICE_CIPHER (0)
> +#define VIRTIO_CRYPTO_SERVICE_CIPHER 0
> /* HASH service */
> -#define VIRTIO_CRYPTO_SERVICE_HASH (1)
> +#define VIRTIO_CRYPTO_SERVICE_HASH 1
> /* MAC (Message Authentication Codes) service */
> -#define VIRTIO_CRYPTO_SERVICE_MAC(2)
> +#define VIRTIO_CRYPTO_SERVICE_MAC2
> /* AEAD (Authenticated Encryption with Associated Data) service */
> -#define VIRTIO_CRYPTO_SERVICE_AEAD (3)
> +#define VIRTIO_CRYPTO_SERVICE_AEAD 3
> \end{lstlisting}
>
> The last driver-read-only fields specify detailed algorithms masks
> @@ -210,7 +210,7 @@ data that should be utilized in operations, and input
> data is equal to
> The general header for controlq is as follows:
>
> \begin{lstlisting}
> -#define VIRTIO_CRYPTO_OPCODE(service, op) ((service << 8) | (op))
> +#define VIRTIO_CRYPTO_OPCODE(service, op) (((service) << 8) | (op))
>
> struct virtio_crypto_ctrl_header {
> #define VIRTIO_CRYPTO_CIPHER_CREATE_SESSION \
> @@ -380,20 +380,18 @@ struct virtio_crypto_mac_session_para {
> le32 auth_key_len;
> le32 padding;
> };
> -struct virtio_crypto_mac_session_output {
> -le64 auth_key_addr; /* guest key physical address */
> -};
>
> struct virtio_crypto_mac_create_session_req {
> /* Device-readable part */
> struct virtio_crypto_mac_session_para para;
> -struct virtio_crypto_mac_session_output out;
> +/* The authenticated key buffer */
> +/* output data here */
> +
> /* Device-writable part */
> struct virtio_crypto_session_input input;
> };
> \end{lstlisting}
>
> -The output data are
> \subparagraph{Session operation: Symmetric algorithms
> session}\label{sec:Device Types / Crypto Device / Device
> Operation / Control Virtqueue / Session operation / Session operation:
> Symmetric algorithms session}
>
> @@ -413,13 +411,13 @@ struct virtio_crypto_cipher_session_para {
> le32 padding;
> };
>
> -struct virtio_crypto_cipher_session_output {
> -le64 key_addr; /* guest key physical address */
> -};
> -
> struct virtio_crypto_cipher_session_req {
> +/* Device-readable part */
> struct virtio_crypto_cipher_session_para para;
> -struct virtio_crypto_cipher_session_output out;
> +/* The cipher key buffer */
> +/* Output data here */
> +
> +/* Device-writable part */
> struct virtio_crypto_session_input input;
> };
> \end{lstlisting}
> @@ -448,18 +446,20 @@ struct virtio_crypto_alg_chain_session_para {
> le32 padding;
> };
>
> -struct virtio_crypto_alg_chain_session_output {
> -struct virtio_crypto_cipher_session_output cipher;
> -struct virtio_crypto_mac_session_output mac;
> -};
> -
> struct virtio_crypto_alg_chain_session_req {
> +/* Device-readable part */
> struct virtio_crypto_alg_chain_session_para para;
> -struct virtio_crypto_alg_chain_session_output out;
> +/* The cipher key buffer */
> +/* The authenticated key buffer */
> +/* Output data here */
> +
> +/* Device-writable part */
> struct virtio_crypto_session_input input;
> };
> \end{lstlisting}
>
> +The output data includs both cipher key buffer and authenticated key buffer.
.. includes both the cipher key buffer and the uthenticated key buffer.
> +
> The packet for symmetric algorithm is as follows:
>
> \begin{lstlisting}
> @@ -503,13 +503,13 @@ struct virtio_crypto_aead_session_para {
> le32 padding;
> };
>
> -struct virtio_crypto_aead_session_output {
> -le64 key_addr; /* guest key physical address */
> -};
> -
> struct virtio_crypto_aead_create_session_req {
> +/* Device-readable part */
> struct virtio_crypto_aead_session_para para;
> -struct virtio_crypto_aead_session_output out;
> +/* The cipher key buffer */
> +/* Output data here */
> +
> +/* Device-writeable part */
> struct virtio_crypto_session_input input;
> };
> \end{lstlisting}
> @@ -568,19 +568,13 @@ struct virtio_crypto_op_data_req {
> The header is the general header and the union is of the algorithm-specific
> type,
> which is set by the driver. All properties in the union are shown as follows.
>
> -There is a unified idata structure for all symmetric algorithms, including
> CIPHER, HASH, MAC, and AEAD.
> +There is a unified idata structure for all service, including CIPHER, HASH,
> MAC, and AEAD.
for all services
>
> The structure is defined
Re: [Qemu-devel] [RFC 1/3] aio-posix: add aio_set_poll_handler()
On Thursday, November 10, 2016 11:17:35 AM, Stefan Hajnoczi wrote: > > I think the question is not "is there any polling to be done" but rather > > "is there anything that requires looking at a file descriptor". If you > > have e.g. an NBD device on the AioContext you cannot poll. On the other > > hand if all you have is bottom halves (which you can poll with > > ctx->notified), AIO and virtio ioeventfds, you can poll. > > This is a good point. Polling should only be done if all resources in > the AioContext benefit from polling - otherwise it adds latency to > resources that don't support polling. > > Another thing: only poll if there is work to be done. Linux AIO must > only poll the ring when there are >0 requests outstanding. Currently it > always polls (doh!). Good idea. So the result of polling callback could be one of ready, not ready and not active? Or did you have in mind something else? > > In particular, testing for bottom halves is necessary to avoid incurring > > extra latency on flushes, which use the thread pool. > > The current code uses a half-solution: it uses aio_compute_timeout() to > see if any existing BHs are ready to execute *before* beginning to poll. > > Really we should poll BHs since they can be scheduled during the polling > loop. We should do so for correctness (hopefully with just ctx->notified: there should be no need to walk the BH list during polling). However, the user of the BH should activate polling "manually" by registering its own polling handler: if there are no active polling handlers, just ignore bottom halves and do the poll(). This is because there are always a handful of registered bottom halves, but they are not necessarily "activatable" from other threads. For example the thread pool always has one BH but as you noticed for Linux AIO, it may not have any pending requests. So the thread pool would still have to register with aio_set_poll_handler, even if it uses bottom halves internally for the signaling. I guess it would not need to register an associated IOHandler, since it can just use aio_bh_poll. A couple more random observations: - you can pass the output of aio_compute_timeout(ctx) to run_poll_handlers, like MIN((uint64_t)aio_compute_timeout(ctx), (uint64_t)aio_poll_max_ns). - since we know that all resources are pollable, we don't need to poll() at all if polling succeeds (though we do need aio_notify_accept()+aio_bh_poll()). > > Perhaps the poll handler could be a parameter to aio_set_event_notifier? > > run_poll_handlers can just set revents (to G_IO_IN for example) if the > > polling handler returns true, and return true as well. aio_poll can > > then call aio_notify_accept and aio_dispatch, bypassing the poll system > > call altogether. > > This is problematic. The poll source != file descriptor so there is a > race condition: > > 1. Guest increments virtqueue avail.idx > 2. QEMU poll notices avail.idx update and marks fd.revents readable. > 3. QEMU dispatches fd handler: > 4. Guest kicks virtqueue -> ioeventfd is signalled > > Unfortunately polling is "too fast" and event_notifier_test_and_clear() > returns false; we won't process the virtqueue! > > Pretending that polling is the same as fd monitoring only works when #4 > happens before #3. We have to solve this race condition. > > The simplest solution is to get rid of the if statement (i.e. enable > spurious event processing). Not sure if that has a drawback though. > Do you have a nicer solution in mind? No, I don't. Removing the if seems sensible, but I like the polling handler more now that I know why it's there. The event_notifier_test_and_clear does add a small latency. On one hand, because you need to check if *all* "resources" support polling, you need a common definition of "resource" (e.g. aio_set_fd_handler). But on the other hand it would be nice to have a streamlined polling callback. I guess you could add something like aio_set_handler that takes a struct with all interesting callbacks: - in/out callbacks (for aio_set_fd_handler) - polling handler - polling callback Then there would be simplified interfaces on top, such as aio_set_fd_handler, aio_set_event_notifier and your own aio_set_poll_handler. Paolo
Re: [Qemu-devel] [PATCH 0/3] target-arm: cache tbflags in CPUARMState
Paolo Bonzini writes: > On 10/11/2016 12:42, Alex Bennée wrote: >> >> Paolo Bonzini writes: >> >>> Computing TranslationBlock flags is pretty expensive on ARM, especially >>> 32-bit. Because tbflags are computed on every tb lookup, it is not >>> unlikely to see cpu_get_tb_cpu_state close to the top of the profile >>> now that QHT makes the hash table much more efficient. >>> >>> However, most tbflags only change when the EL is switched or after >>> MSR instructions. Based on this observation, this series caches these >>> tbflags in CPUARMState, resulting in a 10-15% speedup on 32-bit code. >> >> Hi, >> >> I'm starting to clear out my review queue but I notice these now longer >> apply cleanly to master. Where you going to re-issue the series once >> you'd addressed Peter's concerns? > > Yes, I didn't want to send them two days before soft freeze and Peter's > vacation. :) Cool. Well I'll happily look at it while he's away as I think I need to learn more about the flag mechanism anyway. Unless there are any regressions that have come up during soft-freeze that I need to look at? -- Alex Bennée
[Qemu-devel] [PATCH v2 3/3] vus: Introduce a vhost-user-scsi sample application
This commit introduces a vhost-user-scsi backend sample application. It
must be linked with libiscsi and libvhost-user.
To use it, compile with:
make vhost-user-scsi
And run as follows:
./vhost-user-scsi -u /tmp/vus.sock -i iscsi://uri_to_target/
The application is currently limited at one LUN only and it processes
requests synchronously (therefore only achieving QD1). The purpose of
the code is to show how a backend can be implemented and to test the
vhost-user-scsi Qemu implementation.
If a different instance of this vhost-user-scsi application is executed
at a remote host, a VM can be live migrated to such a host.
Signed-off-by: Felipe Franciosi
---
Makefile | 4 +
Makefile.objs | 4 +
configure | 1 +
contrib/vhost-user-scsi/Makefile.objs | 1 +
contrib/vhost-user-scsi/vhost-user-scsi.c | 886 ++
5 files changed, 896 insertions(+)
create mode 100644 contrib/vhost-user-scsi/Makefile.objs
create mode 100644 contrib/vhost-user-scsi/vhost-user-scsi.c
diff --git a/Makefile b/Makefile
index 474cc5e..2d8c195 100644
--- a/Makefile
+++ b/Makefile
@@ -149,6 +149,8 @@ dummy := $(call unnest-vars,, \
qga-obj-y \
ivshmem-client-obj-y \
ivshmem-server-obj-y \
+libvhost-user-obj-y \
+vhost-user-scsi-obj-y \
qga-vss-dll-obj-y \
block-obj-y \
block-obj-m \
@@ -347,6 +349,8 @@ ivshmem-client$(EXESUF): $(ivshmem-client-obj-y)
libqemuutil.a libqemustub.a
$(call LINK, $^)
ivshmem-server$(EXESUF): $(ivshmem-server-obj-y) libqemuutil.a libqemustub.a
$(call LINK, $^)
+vhost-user-scsi$(EXESUF): $(vhost-user-scsi-obj-y)
+ $(call LINK, $^)
module_block.h: $(SRC_PATH)/scripts/modules/module_block.py config-host.mak
$(call quiet-command,$(PYTHON) $< $@ \
diff --git a/Makefile.objs b/Makefile.objs
index ecd6576..1b70d51 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -117,6 +117,10 @@ qga-vss-dll-obj-y = qga/
ivshmem-client-obj-y = contrib/ivshmem-client/
ivshmem-server-obj-y = contrib/ivshmem-server/
libvhost-user-obj-y = contrib/libvhost-user/
+vhost-user-scsi.o-cflags := $(LIBISCSI_CFLAGS)
+vhost-user-scsi.o-libs := $(LIBISCSI_LIBS)
+vhost-user-scsi-obj-y = contrib/vhost-user-scsi/
+vhost-user-scsi-obj-y += contrib/libvhost-user/libvhost-user.o
##
trace-events-y = trace-events
diff --git a/configure b/configure
index 8fd8678..8b84ae0 100755
--- a/configure
+++ b/configure
@@ -4791,6 +4791,7 @@ if test "$want_tools" = "yes" ; then
if [ "$linux" = "yes" -o "$bsd" = "yes" -o "$solaris" = "yes" ] ; then
tools="qemu-nbd\$(EXESUF) $tools"
tools="ivshmem-client\$(EXESUF) ivshmem-server\$(EXESUF) $tools"
+tools="vhost-user-scsi\$(EXESUF) $tools"
fi
fi
if test "$softmmu" = yes ; then
diff --git a/contrib/vhost-user-scsi/Makefile.objs
b/contrib/vhost-user-scsi/Makefile.objs
new file mode 100644
index 000..e83a38a
--- /dev/null
+++ b/contrib/vhost-user-scsi/Makefile.objs
@@ -0,0 +1 @@
+vhost-user-scsi-obj-y = vhost-user-scsi.o
diff --git a/contrib/vhost-user-scsi/vhost-user-scsi.c
b/contrib/vhost-user-scsi/vhost-user-scsi.c
new file mode 100644
index 000..6025df0
--- /dev/null
+++ b/contrib/vhost-user-scsi/vhost-user-scsi.c
@@ -0,0 +1,886 @@
+/*
+ * vhost-user-scsi sample application
+ *
+ * Copyright (c) 2016 Nutanix Inc. All rights reserved.
+ *
+ * Author:
+ * Felipe Franciosi
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 only.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "contrib/libvhost-user/libvhost-user.h"
+#include "hw/virtio/virtio-scsi.h"
+#include "iscsi/iscsi.h"
+
+#include
+
+/* Small compat shim from glib 2.32 */
+#ifndef G_SOURCE_CONTINUE
+#define G_SOURCE_CONTINUE TRUE
+#endif
+#ifndef G_SOURCE_REMOVE
+#define G_SOURCE_REMOVE FALSE
+#endif
+
+//#define VUS_DEBUG 1
+
+/** Log helpers **/
+
+#define PPRE \
+struct timespec ts; \
+char timebuf[64]; \
+struct tm tm; \
+(void)clock_gettime(CLOCK_REALTIME, &ts); \
+(void)strftime(timebuf, 64, "%Y%m%d %T", gmtime_r(&ts.tv_sec, &tm))
+
+#define PEXT(lvl, msg, ...) do { \
+PPRE; \
+fprintf(stderr, "%s.%06ld " lvl ": %s:%s():%d: " msg "\n",\
+timebuf, ts.tv_nsec/1000, \
+__FILE__, __FUNCTION__, __LINE__, ## __VA_ARGS__);\
+} while(0)
+
+#define PNOR(lvl, msg, ...) do {
[Qemu-devel] [PATCH v2 0/3] Introduce vhost-user-scsi and sample application
Based on various discussions on the 2016 KVM Forum, I'm sending over a vhost-user-scsi implementation for your consideration. This patch set introduces a new vhost-user SCSI device. While heavily based on vhost-scsi, it is implemented using vhost's userspace counterpart. The device has been coded and tested to work with live migration. As part of this work, a new vhost-scsi-common device was created and the existing vhost-scsi device moved underneath it. The new vhost-user-scsi device is also placed underneath it. A sample application based on the newly introduced libvhost-user is also included. It makes use of libiscsi for simplicity. For convenience, I'm maintaining an up-to-date version of these patches (including some necessary fixes for libvhost-user and vhost core code still under discussion) on: https://github.com/franciozzy/qemu/tree/vus-upstream See the individual patches for build and use instructions. Signed-off-by: Felipe Franciosi v1 -> v2: - Introduce new vhost-scsi-common device type. - Move vhost-scsi device underneath vhost-scsi-common. - Move sample application from tests/ to contrib/. - Make sample application use the glib event loop. - Minor fixes. Felipe Franciosi (3): vhost-scsi: create a vhost-scsi-common abstraction vus: Introduce vhost-user-scsi host device vus: Introduce a vhost-user-scsi sample application Makefile | 4 + Makefile.objs | 4 + configure | 11 + contrib/vhost-user-scsi/Makefile.objs | 1 + contrib/vhost-user-scsi/vhost-user-scsi.c | 886 ++ hw/scsi/Makefile.objs | 3 +- hw/scsi/vhost-scsi-common.c | 143 + hw/scsi/vhost-scsi.c | 188 ++- hw/scsi/vhost-user-scsi.c | 198 +++ hw/virtio/virtio-pci.c| 58 ++ hw/virtio/virtio-pci.h| 15 + include/hw/virtio/vhost-scsi-common.h | 48 ++ include/hw/virtio/vhost-scsi.h| 11 +- include/hw/virtio/vhost-user-scsi.h | 34 ++ include/hw/virtio/virtio-scsi.h | 7 + 15 files changed, 1466 insertions(+), 145 deletions(-) create mode 100644 contrib/vhost-user-scsi/Makefile.objs create mode 100644 contrib/vhost-user-scsi/vhost-user-scsi.c create mode 100644 hw/scsi/vhost-scsi-common.c create mode 100644 hw/scsi/vhost-user-scsi.c create mode 100644 include/hw/virtio/vhost-scsi-common.h create mode 100644 include/hw/virtio/vhost-user-scsi.h -- 1.9.4
[Qemu-devel] [PATCH v2 2/3] vus: Introduce vhost-user-scsi host device
This commit introduces a vhost-user device for SCSI. This is based
on the existing vhost-scsi implementation, but done over vhost-user
instead. It also uses a chardev to connect to the backend. Unlike
vhost-scsi (today), VMs using vhost-user-scsi can be live migrated.
To use it, one must configure Qemu with --enable-vhost-user-scsi and
start Qemu with a command line equivalent to:
qemu-system-x86_64 \
-chardev socket,id=vus0,path=/tmp/vus.sock \
-device vhost-user-scsi-pci,chardev=vus0,bus=pci.0,addr=...
A separate commit presents a sample application linked with libiscsi to
provide a backend for vhost-user-scsi.
Signed-off-by: Felipe Franciosi
---
configure | 10 ++
hw/scsi/Makefile.objs | 1 +
hw/scsi/vhost-user-scsi.c | 198
hw/virtio/virtio-pci.c | 58 +++
hw/virtio/virtio-pci.h | 15 +++
include/hw/virtio/vhost-user-scsi.h | 34 +++
include/hw/virtio/virtio-scsi.h | 5 +
7 files changed, 321 insertions(+)
create mode 100644 hw/scsi/vhost-user-scsi.c
create mode 100644 include/hw/virtio/vhost-user-scsi.h
diff --git a/configure b/configure
index fd6f898..8fd8678 100755
--- a/configure
+++ b/configure
@@ -228,6 +228,7 @@ xfs=""
vhost_net="no"
vhost_scsi="no"
+vhost_user_scsi="no"
vhost_vsock="no"
kvm="no"
colo="yes"
@@ -678,6 +679,7 @@ Haiku)
kvm="yes"
vhost_net="yes"
vhost_scsi="yes"
+ vhost_user_scsi="yes"
vhost_vsock="yes"
QEMU_INCLUDES="-I\$(SRC_PATH)/linux-headers -I$(pwd)/linux-headers
$QEMU_INCLUDES"
;;
@@ -1024,6 +1026,10 @@ for opt do
;;
--enable-vhost-scsi) vhost_scsi="yes"
;;
+ --disable-vhost-user-scsi) vhost_user_scsi="no"
+ ;;
+ --enable-vhost-user-scsi) vhost_user_scsi="yes"
+ ;;
--disable-vhost-vsock) vhost_vsock="no"
;;
--enable-vhost-vsock) vhost_vsock="yes"
@@ -5048,6 +5054,7 @@ echo "posix_madvise $posix_madvise"
echo "libcap-ng support $cap_ng"
echo "vhost-net support $vhost_net"
echo "vhost-scsi support $vhost_scsi"
+echo "vhost-user-scsi support $vhost_user_scsi"
echo "vhost-vsock support $vhost_vsock"
echo "Trace backends$trace_backends"
if have_backend "simple"; then
@@ -5433,6 +5440,9 @@ fi
if test "$vhost_scsi" = "yes" ; then
echo "CONFIG_VHOST_SCSI=y" >> $config_host_mak
fi
+if test "$vhost_user_scsi" = "yes" ; then
+ echo "CONFIG_VHOST_USER_SCSI=y" >> $config_host_mak
+fi
if test "$vhost_net" = "yes" ; then
echo "CONFIG_VHOST_NET_USED=y" >> $config_host_mak
fi
diff --git a/hw/scsi/Makefile.objs b/hw/scsi/Makefile.objs
index 54d8754..b188f72 100644
--- a/hw/scsi/Makefile.objs
+++ b/hw/scsi/Makefile.objs
@@ -11,4 +11,5 @@ obj-$(CONFIG_PSERIES) += spapr_vscsi.o
ifeq ($(CONFIG_VIRTIO),y)
obj-y += virtio-scsi.o virtio-scsi-dataplane.o
obj-$(CONFIG_VHOST_SCSI) += vhost-scsi-common.o vhost-scsi.o
+obj-$(CONFIG_VHOST_USER_SCSI) += vhost-scsi-common.o vhost-user-scsi.o
endif
diff --git a/hw/scsi/vhost-user-scsi.c b/hw/scsi/vhost-user-scsi.c
new file mode 100644
index 000..6bb3a9c
--- /dev/null
+++ b/hw/scsi/vhost-user-scsi.c
@@ -0,0 +1,198 @@
+/*
+ * vhost-user-scsi host device
+ *
+ * Copyright (c) 2016 Nutanix Inc. All rights reserved.
+ *
+ * Author:
+ * Felipe Franciosi
+ *
+ * This work is largely based on the "vhost-scsi" implementation by:
+ * Stefan Hajnoczi
+ * Nicholas Bellinger
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2 or later.
+ * See the COPYING.LIB file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "migration/vmstate.h"
+#include "qapi/error.h"
+#include "qemu/error-report.h"
+#include "qemu/typedefs.h"
+#include "qom/object.h"
+#include "hw/fw-path-provider.h"
+#include "hw/qdev-core.h"
+#include "hw/virtio/vhost.h"
+#include "hw/virtio/vhost-backend.h"
+#include "hw/virtio/vhost-user-scsi.h"
+#include "hw/virtio/virtio.h"
+#include "hw/virtio/virtio-access.h"
+#include "sysemu/char.h"
+
+/* Features supported by the host application */
+static const int user_feature_bits[] = {
+VIRTIO_F_NOTIFY_ON_EMPTY,
+VIRTIO_RING_F_INDIRECT_DESC,
+VIRTIO_RING_F_EVENT_IDX,
+VIRTIO_SCSI_F_HOTPLUG,
+VHOST_INVALID_FEATURE_BIT
+};
+
+static void vhost_user_scsi_set_status(VirtIODevice *vdev, uint8_t status)
+{
+VHostUserSCSI *s = (VHostUserSCSI *)vdev;
+VHostSCSICommon *vsc = VHOST_SCSI_COMMON(s);
+bool start = (status & VIRTIO_CONFIG_S_DRIVER_OK) && vdev->vm_running;
+
+if (vsc->dev.started == start) {
+return;
+}
+
+if (start) {
+int ret;
+
+ret = vhost_scsi_common_start(vsc);
+if (ret < 0) {
+error_report("unable to start vhost-user-scsi: %s",
strerror(-ret));
+exit(1);
+}
+} else {
+vhost_scsi_common_stop(vsc);
+}
+}
+
+static void vhost_dummy_handle_output(VirtIODevice *vdev, VirtQueue *vq)
+{
+}
+
+static void vhost_user_scsi_save(QEMUFile *f, void *opaque
[Qemu-devel] [PATCH v2 1/3] vhost-scsi: create a vhost-scsi-common abstraction
In order to introduce a new vhost-user-scsi host device type, it makes
sense to abstract part of vhost-scsi into a common parent class. This
commit does exactly that.
Signed-off-by: Felipe Franciosi
---
hw/scsi/Makefile.objs | 2 +-
hw/scsi/vhost-scsi-common.c | 143 ++
hw/scsi/vhost-scsi.c | 188 ++
include/hw/virtio/vhost-scsi-common.h | 48 +
include/hw/virtio/vhost-scsi.h| 11 +-
include/hw/virtio/virtio-scsi.h | 2 +
6 files changed, 249 insertions(+), 145 deletions(-)
create mode 100644 hw/scsi/vhost-scsi-common.c
create mode 100644 include/hw/virtio/vhost-scsi-common.h
diff --git a/hw/scsi/Makefile.objs b/hw/scsi/Makefile.objs
index 5a2248b..54d8754 100644
--- a/hw/scsi/Makefile.objs
+++ b/hw/scsi/Makefile.objs
@@ -10,5 +10,5 @@ obj-$(CONFIG_PSERIES) += spapr_vscsi.o
ifeq ($(CONFIG_VIRTIO),y)
obj-y += virtio-scsi.o virtio-scsi-dataplane.o
-obj-$(CONFIG_VHOST_SCSI) += vhost-scsi.o
+obj-$(CONFIG_VHOST_SCSI) += vhost-scsi-common.o vhost-scsi.o
endif
diff --git a/hw/scsi/vhost-scsi-common.c b/hw/scsi/vhost-scsi-common.c
new file mode 100644
index 000..e41c031
--- /dev/null
+++ b/hw/scsi/vhost-scsi-common.c
@@ -0,0 +1,143 @@
+/*
+ * vhost-scsi-common
+ *
+ * Copyright (c) 2016 Nutanix Inc. All rights reserved.
+ *
+ * Author:
+ * Felipe Franciosi
+ *
+ * This work is largely based on the "vhost-scsi" implementation by:
+ * Stefan Hajnoczi
+ * Nicholas Bellinger
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2 or later.
+ * See the COPYING.LIB file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include
+#include "qapi/error.h"
+#include "qemu/error-report.h"
+#include "migration/migration.h"
+#include "hw/virtio/vhost.h"
+#include "hw/virtio/vhost-scsi-common.h"
+#include "hw/virtio/virtio-scsi.h"
+#include "hw/virtio/virtio-bus.h"
+#include "hw/virtio/virtio-access.h"
+#include "hw/fw-path-provider.h"
+
+int vhost_scsi_common_start(VHostSCSICommon *vsc)
+{
+int ret, i;
+VirtIODevice *vdev = VIRTIO_DEVICE(vsc);
+BusState *qbus = BUS(qdev_get_parent_bus(DEVICE(vdev)));
+VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus);
+
+if (!k->set_guest_notifiers) {
+error_report("binding does not support guest notifiers");
+return -ENOSYS;
+}
+
+ret = vhost_dev_enable_notifiers(&vsc->dev, vdev);
+if (ret < 0) {
+return ret;
+}
+
+ret = k->set_guest_notifiers(qbus->parent, vsc->dev.nvqs, true);
+if (ret < 0) {
+error_report("Error binding guest notifier");
+goto err_host_notifiers;
+}
+
+vsc->dev.acked_features = vdev->guest_features;
+ret = vhost_dev_start(&vsc->dev, vdev);
+if (ret < 0) {
+error_report("Error start vhost dev");
+goto err_guest_notifiers;
+}
+
+/* guest_notifier_mask/pending not used yet, so just unmask
+ * everything here. virtio-pci will do the right thing by
+ * enabling/disabling irqfd.
+ */
+for (i = 0; i < vsc->dev.nvqs; i++) {
+vhost_virtqueue_mask(&vsc->dev, vdev, vsc->dev.vq_index + i, false);
+}
+
+return ret;
+
+err_guest_notifiers:
+k->set_guest_notifiers(qbus->parent, vsc->dev.nvqs, false);
+err_host_notifiers:
+vhost_dev_disable_notifiers(&vsc->dev, vdev);
+return ret;
+}
+
+void vhost_scsi_common_stop(VHostSCSICommon *vsc)
+{
+VirtIODevice *vdev = VIRTIO_DEVICE(vsc);
+BusState *qbus = BUS(qdev_get_parent_bus(DEVICE(vdev)));
+VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus);
+int ret = 0;
+
+vhost_dev_stop(&vsc->dev, vdev);
+
+if (k->set_guest_notifiers) {
+ret = k->set_guest_notifiers(qbus->parent, vsc->dev.nvqs, false);
+if (ret < 0) {
+error_report("vhost guest notifier cleanup failed: %d", ret);
+}
+}
+assert(ret >= 0);
+
+vhost_dev_disable_notifiers(&vsc->dev, vdev);
+}
+
+uint64_t vhost_scsi_common_get_features(VirtIODevice *vdev, uint64_t features,
+Error **errp)
+{
+VHostSCSICommon *vsc = VHOST_SCSI_COMMON(vdev);
+
+return vhost_get_features(&vsc->dev, vsc->feature_bits, features);
+}
+
+void vhost_scsi_common_set_config(VirtIODevice *vdev, const uint8_t *config)
+{
+VirtIOSCSIConfig *scsiconf = (VirtIOSCSIConfig *)config;
+VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(vdev);
+
+if ((uint32_t)virtio_ldl_p(vdev, &scsiconf->sense_size) != vs->sense_size
||
+(uint32_t)virtio_ldl_p(vdev, &scsiconf->cdb_size) != vs->cdb_size) {
+error_report("vhost-scsi does not support changing the sense data and "
+ "CDB sizes");
+exit(1);
+}
+}
+
+/*
+ * Implementation of an interface to adjust firmware path
+ * for the bootindex property handling.
+ */
+char *vhost_scsi_common_get_fw_dev_path(FWPathProvider *p, BusState *bus,
+D
Re: [Qemu-devel] [PATCHv2 0/3] Allow ISA to be disabled on some platforms
On Wed, Nov 09, 2016 at 11:22:01PM +1100, David Gibson wrote: > This is a rebase and revision of a series I wrote quite some time ago. > This makes some cleanups that are a start on allowing ISA to be > compiled out for platforms which don't use it. > > Unfortunately, a lot of the pieces here don't have a clear maintainer. > So, I'm hoping to get some Acked-bys from the maintainers of the > affected targets, then I intend to send a pull request direct to Peter. > > Notes: > * Patch 3/3 triggers a style warning, but that's just because I'm > moving a C++ // comment verbatim from one file to another > > Changes since v1: > * Fixed some silly compile errors in 3/3 exposed by some > changes in other headers Reviewed-by: Michael S. Tsirkin > David Gibson (3): > Split serial-isa into its own config option > Allow ISA bus to be configured out > Split ISA and sysbus versions of m48t59 device > > default-configs/alpha-softmmu.mak | 1 + > default-configs/arm-softmmu.mak | 1 + > default-configs/i386-softmmu.mak| 1 + > default-configs/mips-softmmu-common.mak | 1 + > default-configs/moxie-softmmu.mak | 2 + > default-configs/pci.mak | 3 + > default-configs/ppc-softmmu.mak | 1 + > default-configs/ppc64-softmmu.mak | 1 + > default-configs/ppcemb-softmmu.mak | 1 + > default-configs/sh4-softmmu.mak | 1 + > default-configs/sh4eb-softmmu.mak | 1 + > default-configs/sparc-softmmu.mak | 1 + > default-configs/sparc64-softmmu.mak | 1 + > default-configs/unicore32-softmmu.mak | 1 + > default-configs/x86_64-softmmu.mak | 1 + > hw/char/Makefile.objs | 3 +- > hw/isa/Makefile.objs| 2 +- > hw/timer/Makefile.objs | 3 + > hw/timer/m48t59-internal.h | 82 > hw/timer/m48t59-isa.c | 181 + > hw/timer/m48t59.c | 228 > +++- > 21 files changed, 305 insertions(+), 212 deletions(-) > create mode 100644 hw/timer/m48t59-internal.h > create mode 100644 hw/timer/m48t59-isa.c > > -- > 2.7.4
Re: [Qemu-devel] [PATCH v2 3/3] net: virtio-net discards TX data after link down
On Thu, Nov 10, 2016 at 01:56:05AM +0200, Yuri Benditovich wrote:
>
>
> On Wed, Nov 9, 2016 at 10:28 PM, Michael S. Tsirkin wrote:
>
> On Wed, Nov 09, 2016 at 05:22:02PM +0200, yuri.benditov...@daynix.com
> wrote:
> > From: Yuri Benditovich
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1295637
> > Upon set_link monitor command or upon netdev deletion
> > virtio-net sends link down indication to the guest
> > and stops vhost if one is used.
> > Guest driver can still submit data for TX until it
> > recognizes link loss. If these packets not returned by
> > the host, the Windows guest will never be able to finish
> > disable/removal/shutdown.
> > Now each packet sent by guest after NIC indicated link
> > down will be completed immediately.
> >
> > Signed-off-by: Yuri Benditovich
> > ---
> > hw/net/virtio-net.c | 28
> > 1 file changed, 28 insertions(+)
> >
> > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > index 06bfe4b..ab4e18a 100644
> > --- a/hw/net/virtio-net.c
> > +++ b/hw/net/virtio-net.c
> > @@ -218,6 +218,16 @@ static void virtio_net_vnet_endian_status(VirtIONet
> *n, uint8_t status)
> > }
> > }
> >
> > +static void virtio_net_drop_tx_queue_data(VirtIODevice *vdev, VirtQueue
> *vq)
> > +{
> > + VirtQueueElement *elem;
> > + while ((elem = virtqueue_pop(vq, sizeof(VirtQueueElement {
> > + virtqueue_push(vq, elem, 0);
> > + virtio_notify(vdev, vq);
> > + g_free(elem);
> > + }
> > +}
> > +
> > static void virtio_net_set_status(struct VirtIODevice *vdev, uint8_t
> status)
> > {
> > VirtIONet *n = VIRTIO_NET(vdev);
>
> I don't like this part. This does too much queue parsing,
> I would like to just copy head from avail to used ring.
>
> For example, people want to support rings >1K in size.
> Let's add bool virtqueue_drop(vq) and be done with it.
>
>
> Please note that this code works only when link is down.
> For me this was too complicated to write simpler procedure
> with the same result.
Yes - it's somewhat problematic and risky that we process
the ring in qemu, but I don't see an easy way around that.
But at least let's limit the processing and assumptions we
make.
>
>
> > @@ -262,6 +272,14 @@ static void virtio_net_set_status(struct
> VirtIODevice *vdev, uint8_t status)
> > } else {
> > qemu_bh_cancel(q->tx_bh);
> > }
> > + if ((n->status & VIRTIO_NET_S_LINK_UP) == 0 &&
> > + (queue_status & VIRTIO_CONFIG_S_DRIVER_OK)) {
> > + /* if tx is waiting we are likely have some packets in
... we likely have some ...
> tx queue
> > + * and disabled notification */
what does this refer to?
> > + q->tx_waiting = 0;
> > + virtio_queue_set_notification(q->tx_vq, 1);
> > + virtio_net_drop_tx_queue_data(vdev, q->tx_vq);
> > + }
> > }
> > }
> > }
>
> OK but what if guest keeps sending packets? What will drop them?
>
>
> This code fixes following problem in original code (example):
> We are in vhost=off and receive kick ->virtio_net_handle_tx_timer
> -> tx_waiting=1, notification disabled, timer set
> Now we receive link loss, cancel the timer and stay with packets in the queue
> and with
> disabled notification. Nobody will return them. (easy to reproduce with timer
> set to 5ms)
>
> Added code drops packets we already have and ensure we will report them
> as completed to guest. If guest keeps sending packets, they will be dropped
> in virtio_net_handle_tx_timer and in virtio_net_handle_tx_bh (in procedures
> just below)
> as we already with link down.
Yes I get that. I'm just not 100% sure all paths have
us listen on the ioeventfd and handle kicks without races -
this was previously assumed not to matter.
>
>
> > @@ -1319,6 +1337,11 @@ static void virtio_net_handle_tx_timer(
> VirtIODevice *vdev, VirtQueue *vq)
> > VirtIONet *n = VIRTIO_NET(vdev);
> > VirtIONetQueue *q = &n->vqs[vq2q(virtio_get_queue_index(vq))];
> >
> > + if (unlikely((n->status & VIRTIO_NET_S_LINK_UP) == 0)) {
> > + virtio_net_drop_tx_queue_data(vdev, vq);
> > + return;
> > + }
> > +
> > /* This happens when device was stopped but VCPU wasn't. */
> > if (!vdev->vm_running) {
> > q->tx_waiting = 1;
> > @@ -1345,6 +1368,11 @@ static void virtio_net_handle_tx_bh(VirtIODevice
> *vdev, VirtQueue *vq)
> > VirtIONet *n = VIRTIO_NET(vdev);
> > VirtIONetQueue *q = &n->vqs[vq2q(virtio_get_queue_index(vq))];
> >
> > + if (unlikely((n->status & VIRTIO_NET_S_LINK_UP)
Re: [Qemu-devel] [PATCH v2 0/3] Introduce vhost-user-scsi and sample application
On Thu, Nov 10, 2016 at 05:49:16AM -0800, Felipe Franciosi wrote: > Based on various discussions on the 2016 KVM Forum, I'm sending over a > vhost-user-scsi implementation for your consideration. > > This patch set introduces a new vhost-user SCSI device. While heavily > based on vhost-scsi, it is implemented using vhost's userspace > counterpart. The device has been coded and tested to work with live > migration. > > As part of this work, a new vhost-scsi-common device was created and > the existing vhost-scsi device moved underneath it. The new > vhost-user-scsi device is also placed underneath it. > > A sample application based on the newly introduced libvhost-user is > also included. It makes use of libiscsi for simplicity. > > For convenience, I'm maintaining an up-to-date version of these > patches (including some necessary fixes for libvhost-user and vhost > core code still under discussion) on: > > https://github.com/franciozzy/qemu/tree/vus-upstream > > See the individual patches for build and use instructions. > > Signed-off-by: Felipe Franciosi Thanks! I'll review after we put out the release, pls remember to ping then. I would like to get some feedback from storage maintainers on whether they see issues with supporting this. > v1 -> v2: > - Introduce new vhost-scsi-common device type. > - Move vhost-scsi device underneath vhost-scsi-common. > - Move sample application from tests/ to contrib/. > - Make sample application use the glib event loop. > - Minor fixes. > > Felipe Franciosi (3): > vhost-scsi: create a vhost-scsi-common abstraction > vus: Introduce vhost-user-scsi host device > vus: Introduce a vhost-user-scsi sample application > > Makefile | 4 + > Makefile.objs | 4 + > configure | 11 + > contrib/vhost-user-scsi/Makefile.objs | 1 + > contrib/vhost-user-scsi/vhost-user-scsi.c | 886 > ++ > hw/scsi/Makefile.objs | 3 +- > hw/scsi/vhost-scsi-common.c | 143 + > hw/scsi/vhost-scsi.c | 188 ++- > hw/scsi/vhost-user-scsi.c | 198 +++ > hw/virtio/virtio-pci.c| 58 ++ > hw/virtio/virtio-pci.h| 15 + > include/hw/virtio/vhost-scsi-common.h | 48 ++ > include/hw/virtio/vhost-scsi.h| 11 +- > include/hw/virtio/vhost-user-scsi.h | 34 ++ > include/hw/virtio/virtio-scsi.h | 7 + > 15 files changed, 1466 insertions(+), 145 deletions(-) > create mode 100644 contrib/vhost-user-scsi/Makefile.objs > create mode 100644 contrib/vhost-user-scsi/vhost-user-scsi.c > create mode 100644 hw/scsi/vhost-scsi-common.c > create mode 100644 hw/scsi/vhost-user-scsi.c > create mode 100644 include/hw/virtio/vhost-scsi-common.h > create mode 100644 include/hw/virtio/vhost-user-scsi.h > > -- > 1.9.4
Re: [Qemu-devel] [PULL for-2.8 0/1] ipxe: update to 20161108 snapshot.
On 11/10/16 11:48, Stefan Hajnoczi wrote: > On Wed, Nov 09, 2016 at 10:09:24AM +0100, Gerd Hoffmann wrote: >> Hi, >> >> This rebases ipxe to latest master. ipxe qemu builds will not use >> fxsave/fxrestore any more, which caused problems on older intel cpus >> due to kvm not emulating these instructions. >> >> Special thanks to Laszlo for pushing these patches to ipxe upstream, >> they finally landed in ipxe master yesterday. >> >> please pull, >> Gerd >> >> The following changes since commit 207faf24c58859f5240f66bf6decc33b87a1776e: >> >> Merge remote-tracking branch 'pm215/tags/pull-target-arm-20161107' into >> staging (2016-11-07 14:02:15 +) >> >> are available in the git repository at: >> >> >> git://git.kraxel.org/qemu tags/pull-ipxe-20161109-1 >> >> for you to fetch changes up to 129fa54c734f4dbaf8d3bb9ca47283a2add2e4dc: >> >> ipxe: update to 20161108 snapshot (2016-11-09 09:49:33 +0100) >> >> >> ipxe: update to 20161108 snapshot. >> >> >> Gerd Hoffmann (1): >> ipxe: update to 20161108 snapshot >> >> pc-bios/efi-e1000.rom| Bin 209408 -> 209920 bytes >> pc-bios/efi-e1000e.rom | Bin 209408 -> 209920 bytes >> pc-bios/efi-eepro100.rom | Bin 209920 -> 209920 bytes >> pc-bios/efi-ne2k_pci.rom | Bin 208384 -> 208896 bytes >> pc-bios/efi-pcnet.rom| Bin 208384 -> 208896 bytes >> pc-bios/efi-rtl8139.rom | Bin 211456 -> 212480 bytes >> pc-bios/efi-virtio.rom | Bin 211456 -> 212480 bytes >> pc-bios/efi-vmxnet3.rom | Bin 205312 -> 206848 bytes >> roms/ipxe| 2 +- >> 9 files changed, 1 insertion(+), 1 deletion(-) >> > > Thanks, applied to my staging tree: > https://github.com/stefanha/qemu/commits/staging > > Stefan > Thank you, Gerd and Stefan. Stefan, if your staging tree is eligible for rebasing, I propose to add the following pointers to the commit message (on patch #1): Ref: https://bugs.archlinux.org/task/50778 Ref: https://bugs.launchpad.net/qemu/+bug/1623276 Ref: https://bugzilla.proxmox.com/show_bug.cgi?id=1182 Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1356762 If you think that's overkill, then please consider adding just the Launchpad reference. Thanks! Laszlo
Re: [Qemu-devel] [PATCH v2 2/3] vus: Introduce vhost-user-scsi host device
Hi
On Thu, Nov 10, 2016 at 5:50 PM Felipe Franciosi wrote:
> This commit introduces a vhost-user device for SCSI. This is based
> on the existing vhost-scsi implementation, but done over vhost-user
> instead. It also uses a chardev to connect to the backend. Unlike
> vhost-scsi (today), VMs using vhost-user-scsi can be live migrated.
>
> To use it, one must configure Qemu with --enable-vhost-user-scsi and
> start Qemu with a command line equivalent to:
>
> qemu-system-x86_64 \
>-chardev socket,id=vus0,path=/tmp/vus.sock \
>-device vhost-user-scsi-pci,chardev=vus0,bus=pci.0,addr=...
>
>
Instead of adding a new device, have you investigated using vhost-scsi-pci
with a new vhost-user (chardev) option? I managed to do that with
virtio-input/gpu.
fwiw, in vhost-user-gpu RFC series, I went a step further, and created a
"vhost-user-backend" object, which may not be a great idea, but simplify
some setup:
-object vhost-user-backend,id=vug,cmd="./vhost-user-gpu"
-device virtio-vga,virgl=true,vhost-user=vug
https://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg01013.html
Once I get back to this RFC, I'll try to refine this idea, but feedback is
welcome.
> A separate commit presents a sample application linked with libiscsi to
> provide a backend for vhost-user-scsi.
>
> Signed-off-by: Felipe Franciosi
> ---
> configure | 10 ++
> hw/scsi/Makefile.objs | 1 +
> hw/scsi/vhost-user-scsi.c | 198
>
> hw/virtio/virtio-pci.c | 58 +++
> hw/virtio/virtio-pci.h | 15 +++
> include/hw/virtio/vhost-user-scsi.h | 34 +++
> include/hw/virtio/virtio-scsi.h | 5 +
> 7 files changed, 321 insertions(+)
> create mode 100644 hw/scsi/vhost-user-scsi.c
> create mode 100644 include/hw/virtio/vhost-user-scsi.h
>
> diff --git a/configure b/configure
> index fd6f898..8fd8678 100755
> --- a/configure
> +++ b/configure
> @@ -228,6 +228,7 @@ xfs=""
>
> vhost_net="no"
> vhost_scsi="no"
> +vhost_user_scsi="no"
> vhost_vsock="no"
> kvm="no"
> colo="yes"
> @@ -678,6 +679,7 @@ Haiku)
>kvm="yes"
>vhost_net="yes"
>vhost_scsi="yes"
> + vhost_user_scsi="yes"
>vhost_vsock="yes"
>QEMU_INCLUDES="-I\$(SRC_PATH)/linux-headers -I$(pwd)/linux-headers
> $QEMU_INCLUDES"
> ;;
> @@ -1024,6 +1026,10 @@ for opt do
>;;
>--enable-vhost-scsi) vhost_scsi="yes"
>;;
> + --disable-vhost-user-scsi) vhost_user_scsi="no"
> + ;;
> + --enable-vhost-user-scsi) vhost_user_scsi="yes"
> + ;;
>--disable-vhost-vsock) vhost_vsock="no"
>;;
>--enable-vhost-vsock) vhost_vsock="yes"
> @@ -5048,6 +5054,7 @@ echo "posix_madvise $posix_madvise"
> echo "libcap-ng support $cap_ng"
> echo "vhost-net support $vhost_net"
> echo "vhost-scsi support $vhost_scsi"
> +echo "vhost-user-scsi support $vhost_user_scsi"
> echo "vhost-vsock support $vhost_vsock"
> echo "Trace backends$trace_backends"
> if have_backend "simple"; then
> @@ -5433,6 +5440,9 @@ fi
> if test "$vhost_scsi" = "yes" ; then
>echo "CONFIG_VHOST_SCSI=y" >> $config_host_mak
> fi
> +if test "$vhost_user_scsi" = "yes" ; then
> + echo "CONFIG_VHOST_USER_SCSI=y" >> $config_host_mak
> +fi
> if test "$vhost_net" = "yes" ; then
>echo "CONFIG_VHOST_NET_USED=y" >> $config_host_mak
> fi
> diff --git a/hw/scsi/Makefile.objs b/hw/scsi/Makefile.objs
> index 54d8754..b188f72 100644
> --- a/hw/scsi/Makefile.objs
> +++ b/hw/scsi/Makefile.objs
> @@ -11,4 +11,5 @@ obj-$(CONFIG_PSERIES) += spapr_vscsi.o
> ifeq ($(CONFIG_VIRTIO),y)
> obj-y += virtio-scsi.o virtio-scsi-dataplane.o
> obj-$(CONFIG_VHOST_SCSI) += vhost-scsi-common.o vhost-scsi.o
> +obj-$(CONFIG_VHOST_USER_SCSI) += vhost-scsi-common.o vhost-user-scsi.o
> endif
> diff --git a/hw/scsi/vhost-user-scsi.c b/hw/scsi/vhost-user-scsi.c
> new file mode 100644
> index 000..6bb3a9c
> --- /dev/null
> +++ b/hw/scsi/vhost-user-scsi.c
> @@ -0,0 +1,198 @@
> +/*
> + * vhost-user-scsi host device
> + *
> + * Copyright (c) 2016 Nutanix Inc. All rights reserved.
> + *
> + * Author:
> + * Felipe Franciosi
> + *
> + * This work is largely based on the "vhost-scsi" implementation by:
> + * Stefan Hajnoczi
> + * Nicholas Bellinger
> + *
> + * This work is licensed under the terms of the GNU LGPL, version 2 or
> later.
> + * See the COPYING.LIB file in the top-level directory.
> + *
> + */
> +
> +#include "qemu/osdep.h"
> +#include "migration/vmstate.h"
> +#include "qapi/error.h"
> +#include "qemu/error-report.h"
> +#include "qemu/typedefs.h"
> +#include "qom/object.h"
> +#include "hw/fw-path-provider.h"
> +#include "hw/qdev-core.h"
> +#include "hw/virtio/vhost.h"
> +#include "hw/virtio/vhost-backend.h"
> +#include "hw/virtio/vhost-user-scsi.h"
> +#include "hw/virtio/virtio.h"
> +#include "hw/virtio/virtio-access.h"
> +#include "sysemu/char.h"
> +
> +/* Features supported by the host application */
> +static const int user_feature_bits[] = {
> +VI
[Qemu-devel] [Bug?] Guest pause because VMPTRLD failed in KVM
Hello, We encountered a problem that a guest paused because the KMOD report VMPTRLD failed. The related information is as follows: 1) Qemu command: /usr/bin/qemu-kvm -name omu1 -S -machine pc-i440fx-2.3,accel=kvm,usb=off -cpu host -m 15625 -realtime mlock=off -smp 8,sockets=1,cores=8,threads=1 -uuid a2aacfff-6583-48b4-b6a4-e6830e519931 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/omu1.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/home/env/guest1.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0 -drive file=/home/env/guest_300G.img,if=none,id=drive-virtio-disk1,format=raw,cache=none,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1 -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:00:80:05:00:00,bus=pci.0,addr=0x3 -netdev tap,fd=27,id=hostnet1,vhost=on,vhostfd=28 -device virtio-net-pci,netdev=hostnet1,id=net1,mac=00:00:80:05:00:01,bus=pci.0,addr=0x4 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -device cirrus-vga,id=video0,vgamem_mb=16,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on 2) Qemu log: KVM: entry failed, hardware error 0x4 RAX=ffed RBX=8803fa2d7fd8 RCX=0100 RDX= RSI= RDI=0046 RBP=8803fa2d7e90 RSP=8803fa2efe90 R8 = R9 = R10= R11=b69a R12=0001 R13=81a25b40 R14= R15=8803fa2d7fd8 RIP=81053e16 RFL=0286 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = 00c0 CS =0010 00a09b00 DPL=0 CS64 [-RA] SS =0018 00c09300 DPL=0 DS [-WA] DS = 00c0 FS = 00c0 GS = 88040f54 00c0 LDT= 00c0 TR =0040 88040f550a40 2087 8b00 DPL=0 TSS64-busy GDT= 88040f549000 007f IDT= ff529000 0fff CR0=80050033 CR2=7f81ca0c5000 CR3=0003f5081000 CR4=000407e0 DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER=0d01 Code=?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 3) Demsg [347315.028339] kvm: vmptrld 8817ec5f/17ec5f failed klogd 1.4.1, -- state change -- [347315.039506] kvm: vmptrld 8817ec5f/17ec5f failed [347315.051728] kvm: vmptrld 8817ec5f/17ec5f failed [347315.057472] vmwrite error: reg 6c0a value 88307e66e480 (err 2120672384) [347315.064567] Pid: 69523, comm: qemu-kvm Tainted: GF X 3.0.93-0.8-default #1 [347315.064569] Call Trace: [347315.064587] [] dump_trace+0x75/0x300 [347315.064595] [] dump_stack+0x69/0x6f [347315.064617] [] vmx_vcpu_load+0x11e/0x1d0 [kvm_intel] [347315.064647] [] kvm_arch_vcpu_load+0x44/0x1d0 [kvm] [347315.064669] [] finish_task_switch+0x81/0xe0 [347315.064676] [] thread_return+0x3b/0x2a7 [347315.064687] [] kvm_vcpu_block+0x65/0xa0 [kvm] [347315.064703] [] __vcpu_run+0xd1/0x260 [kvm] [347315.064732] [] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 [kvm] [347315.064759] [] kvm_vcpu_ioctl+0x38e/0x580 [kvm] [347315.064771] [] do_vfs_ioctl+0x8b/0x3b0 [347315.064776] [] sys_ioctl+0xa1/0xb0 [347315.064783] [] system_call_fastpath+0x16/0x1b [347315.064797] [<7fee51969ce7>] 0x7fee51969ce6 [347315.064799] vmwrite error: reg 6c0c value 88307e664000 (err 2120630272) [347315.064802] Pid: 69523, comm: qemu-kvm Tainted: GF X 3.0.93-0.8-default #1 [347315.064803] Call Trace: [347315.064807] [] dump_trace+0x75/0x300 [347315.064811] [] dump_stack+0x69/0x6f [347315.064817] [] vmx_vcpu_load+0x12c/0x1d0 [kvm_intel] [347315.064832] [] kvm_arch_vcpu_load+0x44/0x1d0 [kvm] [347315.064851] [] finish_task_switch+0x81/0xe0 [347315.064855] [] thread_return+0x3b/0x2a7 [347315.064865] [] kvm_vcpu_block+0x65/0xa0 [kvm] [347315.064880] [] __vcpu_run+0xd1/0x260 [kvm] [347315.064907] [] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 [kvm] [347315.064933] [] kvm_vcpu_ioctl+0x38e/0x580 [kvm] [347315.064943] [] do_vfs_ioctl+0x8b/0x3b0 [347315.064947] [] sys_ioctl+0xa1/0xb
Re: [Qemu-devel] [PULL 12/47] virtio: remove ioeventfd_disabled altogether
On 10/30/2016 10:23 PM, Michael S. Tsirkin wrote:
> From: Paolo Bonzini
>
> Now that there is not anymore a switch from the generic ioeventfd handler
> to the dataplane handler, virtio_bus_set_host_notifier(assign=true) is
> always called with !bus->ioeventfd_started, hence virtio_bus_stop_ioeventfd
> does nothing in this case. Move the invocation to vhost.c, which is the
> only place that needs it.
>
> Reviewed-by: Cornelia Huck
> Signed-off-by: Paolo Bonzini
> Reviewed-by: Michael S. Tsirkin
> Signed-off-by: Michael S. Tsirkin
> ---
> include/hw/virtio/virtio-bus.h | 6 --
> hw/virtio/vhost.c | 3 +++
> hw/virtio/virtio-bus.c | 23 ---
> 3 files changed, 11 insertions(+), 21 deletions(-)
This breaks vhost-net for s390/kvm after rebooting the guest. (ping fails and
ifconfig shows no packets is TXed)
Any idea?
>
> diff --git a/include/hw/virtio/virtio-bus.h b/include/hw/virtio/virtio-bus.h
> index af6b5c4..cbdf745 100644
> --- a/include/hw/virtio/virtio-bus.h
> +++ b/include/hw/virtio/virtio-bus.h
> @@ -94,12 +94,6 @@ struct VirtioBusState {
> BusState parent_obj;
>
> /*
> - * Set if the default ioeventfd handlers are disabled by vhost
> - * or dataplane.
> - */
> -bool ioeventfd_disabled;
> -
> -/*
> * Set if ioeventfd has been started.
> */
> bool ioeventfd_started;
> diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
> index 501a5f4..131f164 100644
> --- a/hw/virtio/vhost.c
> +++ b/hw/virtio/vhost.c
> @@ -1196,6 +1196,7 @@ int vhost_dev_enable_notifiers(struct vhost_dev *hdev,
> VirtIODevice *vdev)
> goto fail;
> }
>
> +virtio_device_stop_ioeventfd(vdev);
> for (i = 0; i < hdev->nvqs; ++i) {
> r = virtio_bus_set_host_notifier(VIRTIO_BUS(qbus), hdev->vq_index +
> i,
> true);
> @@ -1215,6 +1216,7 @@ fail_vq:
> }
> assert (e >= 0);
> }
> +virtio_device_start_ioeventfd(vdev);
> fail:
> return r;
> }
> @@ -1237,6 +1239,7 @@ void vhost_dev_disable_notifiers(struct vhost_dev
> *hdev, VirtIODevice *vdev)
> }
> assert (r >= 0);
> }
> +virtio_device_start_ioeventfd(vdev);
> }
>
> /* Test and clear event pending status.
> diff --git a/hw/virtio/virtio-bus.c b/hw/virtio/virtio-bus.c
> index a619445..b0e4544 100644
> --- a/hw/virtio/virtio-bus.c
> +++ b/hw/virtio/virtio-bus.c
> @@ -190,7 +190,7 @@ int virtio_bus_start_ioeventfd(VirtioBusState *bus)
> if (!k->ioeventfd_assign || !k->ioeventfd_enabled(proxy)) {
> return -ENOSYS;
> }
> -if (bus->ioeventfd_started || bus->ioeventfd_disabled) {
> +if (bus->ioeventfd_started) {
> return 0;
> }
> r = vdc->start_ioeventfd(vdev);
> @@ -226,8 +226,8 @@ bool virtio_bus_ioeventfd_enabled(VirtioBusState *bus)
> }
>
> /*
> - * This function switches from/to the generic ioeventfd handler.
> - * assign==false means 'use generic ioeventfd handler'.
> + * This function switches ioeventfd on/off in the device.
> + * The caller must set or clear the handlers for the EventNotifier.
> */
> int virtio_bus_set_host_notifier(VirtioBusState *bus, int n, bool assign)
> {
> @@ -237,19 +237,12 @@ int virtio_bus_set_host_notifier(VirtioBusState *bus,
> int n, bool assign)
> if (!k->ioeventfd_assign) {
> return -ENOSYS;
> }
> -bus->ioeventfd_disabled = assign;
> if (assign) {
> -/*
> - * Stop using the generic ioeventfd, we are doing eventfd handling
> - * ourselves below
> - *
> - * FIXME: We should just switch the handler and not deassign the
> - * ioeventfd.
> - * Otherwise, there's a window where we don't have an
> - * ioeventfd and we may end up with a notification where
> - * we don't expect one.
> - */
> -virtio_bus_stop_ioeventfd(bus);
> +assert(!bus->ioeventfd_started);
> +} else {
> +if (!bus->ioeventfd_started) {
> +return 0;
> +}
> }
> return set_host_notifier_internal(proxy, bus, n, assign);
> }
>
Re: [Qemu-devel] [PULL 12/47] virtio: remove ioeventfd_disabled altogether
On 10/11/2016 15:35, Christian Borntraeger wrote:
> On 10/30/2016 10:23 PM, Michael S. Tsirkin wrote:
>> From: Paolo Bonzini
>>
>> Now that there is not anymore a switch from the generic ioeventfd handler
>> to the dataplane handler, virtio_bus_set_host_notifier(assign=true) is
>> always called with !bus->ioeventfd_started, hence virtio_bus_stop_ioeventfd
>> does nothing in this case. Move the invocation to vhost.c, which is the
>> only place that needs it.
>>
>> Reviewed-by: Cornelia Huck
>> Signed-off-by: Paolo Bonzini
>> Reviewed-by: Michael S. Tsirkin
>> Signed-off-by: Michael S. Tsirkin
>> ---
>> include/hw/virtio/virtio-bus.h | 6 --
>> hw/virtio/vhost.c | 3 +++
>> hw/virtio/virtio-bus.c | 23 ---
>> 3 files changed, 11 insertions(+), 21 deletions(-)
>
> This breaks vhost-net for s390/kvm after rebooting the guest. (ping fails and
> ifconfig shows no packets is TXed)
>
> Any idea?
Patch from Felipe:
[PATCH v2] vhost: Update 'ioeventfd_started' with host notifiers
Paolo
>>
>> diff --git a/include/hw/virtio/virtio-bus.h b/include/hw/virtio/virtio-bus.h
>> index af6b5c4..cbdf745 100644
>> --- a/include/hw/virtio/virtio-bus.h
>> +++ b/include/hw/virtio/virtio-bus.h
>> @@ -94,12 +94,6 @@ struct VirtioBusState {
>> BusState parent_obj;
>>
>> /*
>> - * Set if the default ioeventfd handlers are disabled by vhost
>> - * or dataplane.
>> - */
>> -bool ioeventfd_disabled;
>> -
>> -/*
>> * Set if ioeventfd has been started.
>> */
>> bool ioeventfd_started;
>> diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
>> index 501a5f4..131f164 100644
>> --- a/hw/virtio/vhost.c
>> +++ b/hw/virtio/vhost.c
>> @@ -1196,6 +1196,7 @@ int vhost_dev_enable_notifiers(struct vhost_dev *hdev,
>> VirtIODevice *vdev)
>> goto fail;
>> }
>>
>> +virtio_device_stop_ioeventfd(vdev);
>> for (i = 0; i < hdev->nvqs; ++i) {
>> r = virtio_bus_set_host_notifier(VIRTIO_BUS(qbus), hdev->vq_index +
>> i,
>> true);
>> @@ -1215,6 +1216,7 @@ fail_vq:
>> }
>> assert (e >= 0);
>> }
>> +virtio_device_start_ioeventfd(vdev);
>> fail:
>> return r;
>> }
>> @@ -1237,6 +1239,7 @@ void vhost_dev_disable_notifiers(struct vhost_dev
>> *hdev, VirtIODevice *vdev)
>> }
>> assert (r >= 0);
>> }
>> +virtio_device_start_ioeventfd(vdev);
>> }
>>
>> /* Test and clear event pending status.
>> diff --git a/hw/virtio/virtio-bus.c b/hw/virtio/virtio-bus.c
>> index a619445..b0e4544 100644
>> --- a/hw/virtio/virtio-bus.c
>> +++ b/hw/virtio/virtio-bus.c
>> @@ -190,7 +190,7 @@ int virtio_bus_start_ioeventfd(VirtioBusState *bus)
>> if (!k->ioeventfd_assign || !k->ioeventfd_enabled(proxy)) {
>> return -ENOSYS;
>> }
>> -if (bus->ioeventfd_started || bus->ioeventfd_disabled) {
>> +if (bus->ioeventfd_started) {
>> return 0;
>> }
>> r = vdc->start_ioeventfd(vdev);
>> @@ -226,8 +226,8 @@ bool virtio_bus_ioeventfd_enabled(VirtioBusState *bus)
>> }
>>
>> /*
>> - * This function switches from/to the generic ioeventfd handler.
>> - * assign==false means 'use generic ioeventfd handler'.
>> + * This function switches ioeventfd on/off in the device.
>> + * The caller must set or clear the handlers for the EventNotifier.
>> */
>> int virtio_bus_set_host_notifier(VirtioBusState *bus, int n, bool assign)
>> {
>> @@ -237,19 +237,12 @@ int virtio_bus_set_host_notifier(VirtioBusState *bus,
>> int n, bool assign)
>> if (!k->ioeventfd_assign) {
>> return -ENOSYS;
>> }
>> -bus->ioeventfd_disabled = assign;
>> if (assign) {
>> -/*
>> - * Stop using the generic ioeventfd, we are doing eventfd handling
>> - * ourselves below
>> - *
>> - * FIXME: We should just switch the handler and not deassign the
>> - * ioeventfd.
>> - * Otherwise, there's a window where we don't have an
>> - * ioeventfd and we may end up with a notification where
>> - * we don't expect one.
>> - */
>> -virtio_bus_stop_ioeventfd(bus);
>> +assert(!bus->ioeventfd_started);
>> +} else {
>> +if (!bus->ioeventfd_started) {
>> +return 0;
>> +}
>> }
>> return set_host_notifier_internal(proxy, bus, n, assign);
>> }
>>
>
Re: [Qemu-devel] [PATCH] spapr-vty: Fix bad assert() statement
On 10/11/2016 10:06, Thomas Huth wrote:
> When using the serial console in the GTK interface of QEMU (and
> QEMU has been compiled with CONFIG_VTE), it is possible to trigger
> the assert() statement in vty_receive() in spapr_vty.c by pasting
> a chunk of text with length > 16 into the QEMU window.
> Most of the other serial backends seem to simply drop characters
> that they can not handle, so I think we should also do the same in
> spapr-vty to fix this issue. And since it is quite ugly when pasted
> text is chopped after 16 bytes, we also increase the size of the
> input buffer here so that we can at least handle a couple of text
> lines.
>
> Buglink: https://bugs.launchpad.net/qemu/+bug/1639322
> Signed-off-by: Thomas Huth
> ---
> hw/char/spapr_vty.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/hw/char/spapr_vty.c b/hw/char/spapr_vty.c
> index 31822fe..bee6c34 100644
> --- a/hw/char/spapr_vty.c
> +++ b/hw/char/spapr_vty.c
> @@ -1,4 +1,5 @@
> #include "qemu/osdep.h"
> +#include "qemu/error-report.h"
> #include "qapi/error.h"
> #include "qemu-common.h"
> #include "cpu.h"
> @@ -7,7 +8,7 @@
> #include "hw/ppc/spapr.h"
> #include "hw/ppc/spapr_vio.h"
>
> -#define VTERM_BUFSIZE 16
> +#define VTERM_BUFSIZE 2048
This change causes a change in the migration protocol.
Paolo
>
> typedef struct VIOsPAPRVTYDevice {
> VIOsPAPRDevice sdev;
> @@ -37,7 +38,15 @@ static void vty_receive(void *opaque, const uint8_t *buf,
> int size)
> qemu_irq_pulse(spapr_vio_qirq(&dev->sdev));
> }
> for (i = 0; i < size; i++) {
> -assert((dev->in - dev->out) < VTERM_BUFSIZE);
> +if (dev->in - dev->out >= VTERM_BUFSIZE) {
> +static bool reported;
> +if (!reported) {
> +error_report("VTY input buffer exhausted - characters
> dropped."
> + " (input size = %i)", size);
> +reported = true;
> +}
> +break;
> +}
> dev->buf[dev->in++ % VTERM_BUFSIZE] = buf[i];
> }
> }
>
Re: [Qemu-devel] [PULL 12/47] virtio: remove ioeventfd_disabled altogether
On 11/10/2016 03:38 PM, Paolo Bonzini wrote: > > > On 10/11/2016 15:35, Christian Borntraeger wrote: >> On 10/30/2016 10:23 PM, Michael S. Tsirkin wrote: >>> From: Paolo Bonzini >>> >>> Now that there is not anymore a switch from the generic ioeventfd handler >>> to the dataplane handler, virtio_bus_set_host_notifier(assign=true) is >>> always called with !bus->ioeventfd_started, hence virtio_bus_stop_ioeventfd >>> does nothing in this case. Move the invocation to vhost.c, which is the >>> only place that needs it. >>> >>> Reviewed-by: Cornelia Huck >>> Signed-off-by: Paolo Bonzini >>> Reviewed-by: Michael S. Tsirkin >>> Signed-off-by: Michael S. Tsirkin >>> --- >>> include/hw/virtio/virtio-bus.h | 6 -- >>> hw/virtio/vhost.c | 3 +++ >>> hw/virtio/virtio-bus.c | 23 --- >>> 3 files changed, 11 insertions(+), 21 deletions(-) >> >> This breaks vhost-net for s390/kvm after rebooting the guest. (ping fails and >> ifconfig shows no packets is TXed) >> >> Any idea? > > Patch from Felipe: > [PATCH v2] vhost: Update 'ioeventfd_started' with host notifiers > > Paolo Yes, that fixes the issue
Re: [Qemu-devel] [PATCH 0/4] make SMBUS/SATA/PIT configurable and introduce
On Sat, Nov 05, 2016 at 03:19:47AM -0400, Chao Peng wrote: > This patchset makes SMBUS/SATA/PIT configurable and introduces a new > machine type q35-lite with these features disabled by default. This is > useful for creating light weight virtual machine without boot time > penalty when these devices are unused. > > See https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg00422.html > for the background. Reviewed-by: Michael S. Tsirkin As we are in freeze now, please remember to re-test and ping after the release to get this applied. > Chao Peng (4): > pc: make smbus configurable > pc: make sata configurable > pc: make pit configurable > q35: introduce q35-lite > > hw/i386/pc.c | 68 > +++- > hw/i386/pc_piix.c| 2 +- > hw/i386/pc_q35.c | 57 ++- > include/hw/i386/pc.h | 8 +++ > 4 files changed, 112 insertions(+), 23 deletions(-) > > -- > 1.8.3.1
Re: [Qemu-devel] [PATCHv2 3/3] Split ISA and sysbus versions of m48t59 device
On 09/11/2016 13:22, David Gibson wrote:
> The m48t59 device supports both ISA and direct sysbus attached versions of
> the device in the one .c file. This can be awkward for some embedded
> machine types which need the sysbus M48T59, but don't want to pull in the
> ISA bus code and its other dependencies.
>
> Therefore, this patch splits out the code for the ISA attached M48T59 into
> its own C file. It will be built when both CONFIG_M48T59 and
> CONFIG_ISA_BUS are enabled.
>
> Signed-off-by: David Gibson
Who needs the ISA M48T59? Perhaps it should be a separate symbol
altogether. Let's document that SPARC will stop providing it in 2.9,
for example, if it's only a PReP thing.
Paolo
> ---
> hw/timer/Makefile.objs | 3 +
> hw/timer/m48t59-internal.h | 82
> hw/timer/m48t59-isa.c | 181 +++
> hw/timer/m48t59.c | 228
> -
> 4 files changed, 284 insertions(+), 210 deletions(-)
> create mode 100644 hw/timer/m48t59-internal.h
> create mode 100644 hw/timer/m48t59-isa.c
>
> diff --git a/hw/timer/Makefile.objs b/hw/timer/Makefile.objs
> index 7ba8c23..bf3ea3c 100644
> --- a/hw/timer/Makefile.objs
> +++ b/hw/timer/Makefile.objs
> @@ -6,6 +6,9 @@ common-obj-$(CONFIG_DS1338) += ds1338.o
> common-obj-$(CONFIG_HPET) += hpet.o
> common-obj-$(CONFIG_I8254) += i8254_common.o i8254.o
> common-obj-$(CONFIG_M48T59) += m48t59.o
> +ifeq ($(CONFIG_ISA_BUS),y)
> +common-obj-$(CONFIG_M48T59) += m48t59-isa.o
> +endif
> common-obj-$(CONFIG_PL031) += pl031.o
> common-obj-$(CONFIG_PUV3) += puv3_ost.o
> common-obj-$(CONFIG_TWL92230) += twl92230.o
> diff --git a/hw/timer/m48t59-internal.h b/hw/timer/m48t59-internal.h
> new file mode 100644
> index 000..32ae957
> --- /dev/null
> +++ b/hw/timer/m48t59-internal.h
> @@ -0,0 +1,82 @@
> +/*
> + * QEMU M48T59 and M48T08 NVRAM emulation (common header)
> + *
> + * Copyright (c) 2003-2005, 2007 Jocelyn Mayer
> + * Copyright (c) 2013 Hervé Poussineau
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> copy
> + * of this software and associated documentation files (the "Software"), to
> deal
> + * in the Software without restriction, including without limitation the
> rights
> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> + * copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> + * THE SOFTWARE.
> + */
> +#ifndef HW_M48T59_INTERNAL_H
> +#define HW_M48T59_INTERNAL_H 1
> +
> +//#define DEBUG_NVRAM
> +
> +#if defined(DEBUG_NVRAM)
> +#define NVRAM_PRINTF(fmt, ...) do { printf(fmt , ## __VA_ARGS__); } while (0)
> +#else
> +#define NVRAM_PRINTF(fmt, ...) do { } while (0)
> +#endif
> +
> +/*
> + * The M48T02, M48T08 and M48T59 chips are very similar. The newer '59 has
> + * alarm and a watchdog timer and related control registers. In the
> + * PPC platform there is also a nvram lock function.
> + */
> +
> +typedef struct M48txxInfo {
> +const char *bus_name;
> +uint32_t model; /* 2 = m48t02, 8 = m48t08, 59 = m48t59 */
> +uint32_t size;
> +} M48txxInfo;
> +
> +typedef struct M48t59State {
> +/* Hardware parameters */
> +qemu_irq IRQ;
> +MemoryRegion iomem;
> +uint32_t size;
> +int32_t base_year;
> +/* RTC management */
> +time_t time_offset;
> +time_t stop_time;
> +/* Alarm & watchdog */
> +struct tm alarm;
> +QEMUTimer *alrm_timer;
> +QEMUTimer *wd_timer;
> +/* NVRAM storage */
> +uint8_t *buffer;
> +/* Model parameters */
> +uint32_t model; /* 2 = m48t02, 8 = m48t08, 59 = m48t59 */
> +/* NVRAM storage */
> +uint16_t addr;
> +uint8_t lock;
> +} M48t59State;
> +
> +uint32_t m48t59_read(M48t59State *NVRAM, uint32_t addr);
> +void m48t59_write(M48t59State *NVRAM, uint32_t addr, uint32_t val);
> +void m48t59_reset_common(M48t59State *NVRAM);
> +void m48t59_realize_common(M48t59State *s, Error **errp);
> +
> +static inline void m48t59_toggle_lock(M48t59State *NVRAM, int lock)
> +{
> +NVRAM->lock ^= 1 << lock;
> +}
> +
> +extern const MemoryRegionOps m48t59_io_ops;
> +
> +#endif /* HW_M48T59_INTERNAL_H */
> diff --git a/hw/timer/m48t59-isa.c b/hw/timer/m48t59-isa.c
> new file mode 100644
> index 00
Re: [Qemu-devel] [PATCH v6 01/19] docs: new design document multi-thread-tcg.txt
On 11/09/2016 03:57 PM, Alex Bennée wrote: This documents the current design for upgrading TCG emulation to take advantage of modern CPUs by running a thread-per-CPU. The document goes through the various areas of the code affected by such a change and proposes design requirements for each part of the solution. The text marked with (Current solution[s]) to document what the current approaches being used are. Signed-off-by: Alex Bennée Reviewed-by: Richard Henderson +- target-i386 +- target-arm +- target-aarch64 +- target-alpha If you're going to list these, target-mips is also updated. r~
Re: [Qemu-devel] [PATCH v2] vhost: Update 'ioeventfd_started' with host notifiers
On 11/09/2016 01:44 PM, Felipe Franciosi wrote: > Following the recent refactor of virtio notfiers [1], more specifically > the patch that uses virtio_bus_set_host_notifier [2] by default, core > virtio code requires 'ioeventfd_started' to be set to true/false when > the host notifiers are configured. Because not all vhost devices were > update (eg. vhost-scsi) to use the new interface, this value is always > set to false. > > When booting a guest with a vhost-scsi backend controller, SeaBIOS will > initially configure the device which sets all notifiers. The guest will > continue to boot fine until the kernel virtio-scsi driver reinitialises > the device causing a stop followed by another start. Since > ioeventfd_started was never set to true, the 'stop' operation triggered > by virtio_bus_set_host_notifier() will not result in a call to > virtio_pci_ioeventfd_assign(assign=false). This leaves the memory > regions with stale notifiers and results on the next start triggering > the following assertion: > > kvm_mem_ioeventfd_add: error adding ioeventfd: File exists > Aborted > > This patch updates ioeventfd_started whenever the notifiers are set or > cleared, fixing this issue. > > Signed-off-by: Felipe Franciosi This also fixes vhost-net after reboot on s390/kvm for me Tested-by: Christian Borntraeger > > [1] http://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg07748.html > [2] http://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg07760.html > --- > v1->v2: > - Update ioeventfd_started in vhost_dev_enable/disable_notifiers() > instead of vhost_scsi_start/stop(). > - Reword the commit message accordingly. > --- > hw/virtio/vhost.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c > index 131f164..1290963 100644 > --- a/hw/virtio/vhost.c > +++ b/hw/virtio/vhost.c > @@ -1205,6 +1205,7 @@ int vhost_dev_enable_notifiers(struct vhost_dev *hdev, > VirtIODevice *vdev) > goto fail_vq; > } > } > +VIRTIO_BUS(qbus)->ioeventfd_started = true; > > return 0; > fail_vq: > @@ -1239,6 +1240,7 @@ void vhost_dev_disable_notifiers(struct vhost_dev > *hdev, VirtIODevice *vdev) > } > assert (r >= 0); > } > +VIRTIO_BUS(qbus)->ioeventfd_started = false; > virtio_device_start_ioeventfd(vdev); > } >
Re: [Qemu-devel] [PATCH] dma: rc4030: limit interval timer reload value
On 10/11/2016 06:56, Gonglei (Arei) wrote: > Any ideas about this fix? It seems sensible, but perhaps the field is even smaller. Let's CC Hervé and Aurelien as I don't have a datasheet for this device. Also, s->itr is used here: tm_hz = 1000 / (s->itr + 1); timer_mod(s->periodic_timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + NANOSECONDS_PER_SECOND / tm_hz); and this is the same as timer_mod(s->periodic_timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + NANOSECONDS_PER_SECOND / 1000 * (s->itr + 1)); so perhaps it's better to do it like that. Paolo >> -Original Message- >> From: Qemu-devel >> [mailto:qemu-devel-bounces+arei.gonglei=huawei@nongnu.org] On >> Behalf Of P J P >> Sent: Wednesday, October 12, 2016 8:38 PM >> To: Qemu Developers >> Cc: Paolo Bonzini; Huawei PSIRT; Prasad J Pandit; Michael S. Tsirkin >> Subject: [Qemu-devel] [PATCH] dma: rc4030: limit interval timer reload value >> >> From: Prasad J Pandit >> >> The JAZZ RC4030 chipset emulator has a periodic timer and >> associated interval reload register. The reload value is used >> as divider when computing timer's next tick value. If reload >> value is large, it could lead to divide by zero error. Limit >> the interval reload value to avoid it. >> >> Reported-by: Huawei PSIRT >> Signed-off-by: Prasad J Pandit >> --- >> hw/dma/rc4030.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/hw/dma/rc4030.c b/hw/dma/rc4030.c >> index 2f2576f..c1b4997 100644 >> --- a/hw/dma/rc4030.c >> +++ b/hw/dma/rc4030.c >> @@ -460,7 +460,7 @@ static void rc4030_write(void *opaque, hwaddr addr, >> uint64_t data, >> break; >> /* Interval timer reload */ >> case 0x0228: >> -s->itr = val; >> +s->itr = val & 0x01FF; >> qemu_irq_lower(s->timer_irq); >> set_next_tick(s); >> break; >> -- >> 2.5.5 >> > > >
Re: [Qemu-devel] [PATCH v6 3/3] IOMMU: enable intel_iommu map and unmap notifiers
On Tue, Nov 08, 2016 at 01:04:24PM +0200, Aviv B.D wrote:
> From: "Aviv Ben-David"
>
> Adds a list of registered vtd_as's to intel iommu state to save
> iteration over each PCI device in a search of the corrosponding domain.
>
> Signed-off-by: Aviv Ben-David
> ---
> hw/i386/intel_iommu.c | 96
> +++---
> hw/i386/intel_iommu_internal.h | 2 +
> include/hw/i386/intel_iommu.h | 9
> 3 files changed, 100 insertions(+), 7 deletions(-)
>
> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> index 6ba915c..095b56d 100644
> --- a/hw/i386/intel_iommu.c
> +++ b/hw/i386/intel_iommu.c
> @@ -54,6 +54,9 @@ static int vtd_dbgflags = VTD_DBGBIT(GENERAL) |
> VTD_DBGBIT(CSR);
> #define VTD_DPRINTF(what, fmt, ...) do {} while (0)
> #endif
>
> +static int vtd_dev_to_context_entry(IntelIOMMUState *s, uint8_t bus_num,
> +uint8_t devfn, VTDContextEntry *ce);
> +
Please put the whole function here, don't declare static ones.
> static void vtd_define_quad(IntelIOMMUState *s, hwaddr addr, uint64_t val,
> uint64_t wmask, uint64_t w1cmask)
> {
> @@ -145,6 +148,23 @@ static uint64_t vtd_set_clear_mask_quad(IntelIOMMUState
> *s, hwaddr addr,
> return new_val;
> }
>
> +static int vtd_get_did_dev(IntelIOMMUState *s, uint8_t bus_num, uint8_t
> devfn,
> + uint16_t *domain_id)
> +{
> +VTDContextEntry ce;
> +int ret_fr;
> +
> +assert(domain_id);
> +
> +ret_fr = vtd_dev_to_context_entry(s, bus_num, devfn, &ce);
> +if (ret_fr) {
> +return -1;
> +}
> +
> +*domain_id = VTD_CONTEXT_ENTRY_DID(ce.hi);
> +return 0;
> +}
> +
> /* GHashTable functions */
> static gboolean vtd_uint64_equal(gconstpointer v1, gconstpointer v2)
> {
> @@ -679,7 +699,7 @@ static int vtd_gpa_to_slpte(VTDContextEntry *ce, uint64_t
> gpa,
> }
> *reads = (*reads) && (slpte & VTD_SL_R);
> *writes = (*writes) && (slpte & VTD_SL_W);
> -if (!(slpte & access_right_check)) {
> +if (!(slpte & access_right_check) && !(flags & IOMMU_NO_FAIL)) {
> VTD_DPRINTF(GENERAL, "error: lack of %s permission for "
> "gpa 0x%"PRIx64 " slpte 0x%"PRIx64,
> (flags & IOMMU_WO ? "write" : "read"), gpa, slpte);
> @@ -1064,6 +1084,44 @@ static void
> vtd_iotlb_domain_invalidate(IntelIOMMUState *s, uint16_t domain_id)
> &domain_id);
> }
>
> +static void vtd_iotlb_page_invalidate_notify(IntelIOMMUState *s,
> + uint16_t domain_id, hwaddr addr,
> + uint8_t am)
> +{
> +IntelIOMMUNotifierNode *node;
> +
> +QLIST_FOREACH(node, &(s->notifiers_list), next) {
> +VTDAddressSpace *vtd_as = node->vtd_as;
> +uint16_t vfio_domain_id;
> +int ret = vtd_get_did_dev(s, pci_bus_num(vtd_as->bus), vtd_as->devfn,
> + &vfio_domain_id);
Space won't hurt here, after a declaration.
> +if (!ret && domain_id == vfio_domain_id) {
> +hwaddr original_addr = addr;
> +
> +while (addr < original_addr + (1 << am) * VTD_PAGE_SIZE) {
> +IOMMUTLBEntry entry = s->iommu_ops.translate(
> +
> &node->vtd_as->iommu,
> + addr,
> + IOMMU_NO_FAIL);
> +
> +if (entry.perm == IOMMU_NONE &&
> +node->notifier_flag & IOMMU_NOTIFIER_UNMAP) {
> +entry.target_as = &address_space_memory;
> +entry.iova = addr & VTD_PAGE_MASK_4K;
> +entry.translated_addr = 0;
> +entry.addr_mask = ~VTD_PAGE_MASK(VTD_PAGE_SHIFT);
> +memory_region_notify_iommu(&node->vtd_as->iommu, entry);
> +addr += VTD_PAGE_SIZE;
> +} else if (node->notifier_flag & IOMMU_NOTIFIER_MAP) {
> +memory_region_notify_iommu(&node->vtd_as->iommu,
> entry);
> +addr += entry.addr_mask + 1;
> +}
> +}
> +}
> +}
> +}
> +
> +
> static void vtd_iotlb_page_invalidate(IntelIOMMUState *s, uint16_t domain_id,
>hwaddr addr, uint8_t am)
> {
> @@ -1074,6 +1132,8 @@ static void vtd_iotlb_page_invalidate(IntelIOMMUState
> *s, uint16_t domain_id,
> info.addr = addr;
> info.mask = ~((1 << am) - 1);
> g_hash_table_foreach_remove(s->iotlb, vtd_hash_remove_by_page, &info);
> +
> +vtd_iotlb_page_invalidate_notify(s, domain_id, addr, am);
> }
>
> /* Flush IOTLB
> @@ -1999,15 +2059,37 @@ static void
> vtd_iommu_notify_flag_changed(MemoryRegion *iommu,
>
Re: [Qemu-devel] [PATCH v6 0/3] IOMMU: intel_iommu support map and unmap notifications
On Tue, Nov 08, 2016 at 01:04:21PM +0200, Aviv B.D wrote: > From: "Aviv Ben-David" > > * Advertize Cache Mode capability in iommu cap register. > This capability is controlled by "cache-mode" property of intel-iommu > device. > To enable this option call QEMU with "-device intel-iommu,cache-mode=true". > > * On page cache invalidation in intel vIOMMU, check if the domain belong to > registered notifier, and notify accordingly. This looks sane I think. Alex, care to comment? Merging will have to wait until after the release. Pls remember to re-test and re-ping then. > Currently this patch still doesn't enabling VFIO devices support with vIOMMU > present. Current problems: > * vfio_iommu_map_notify is not aware about memory range belong to specific > VFIOGuestIOMMU. > * memory_region_iommu_replay hangs QEMU on start up while it itterate over > 64bit address space. Commenting out the call to this function enables > workable VFIO device while vIOMMU present. > * vfio_iommu_map_notify should check if address space range is suitable for > current notifier. > > Changes from v1 to v2: > * remove assumption that the cache do not clears > * fix lockup on high load. > > Changes from v2 to v3: > * remove debug leftovers > * split to sepearate commits > * change is_write to flags in vtd_do_iommu_translate, add IOMMU_NO_FAIL > to suppress error propagating to guest. > > Changes from v3 to v4: > * Add property to intel_iommu device to control the CM capability, > default to False. > * Use s->iommu_ops.notify_flag_changed to register notifiers. > > Changes from v4 to v4 RESEND: > * Fix codding style pointed by checkpatch.pl script. > > Changes from v4 to v5: > * Reduce the number of changes in patch 2 and make flags real bitfield. > * Revert deleted debug prints. > * Fix memory leak in patch 3. > > Changes from v5 to v6: > * fix prototype of iommu_translate function for more IOMMU types. > * VFIO will be notified only on the difference, without unmap > before change to maps. > > Aviv Ben-David (3): > IOMMU: add option to enable VTD_CAP_CM to vIOMMU capility exposoed to > guest > IOMMU: change iommu_op->translate's is_write to flags, add support to > NO_FAIL flag mode > IOMMU: enable intel_iommu map and unmap notifiers > > exec.c | 3 +- > hw/alpha/typhoon.c | 2 +- > hw/i386/amd_iommu.c| 4 +- > hw/i386/intel_iommu.c | 160 > + > hw/i386/intel_iommu_internal.h | 3 + > hw/pci-host/apb.c | 2 +- > hw/ppc/spapr_iommu.c | 2 +- > hw/s390x/s390-pci-bus.c| 2 +- > include/exec/memory.h | 6 +- > include/hw/i386/intel_iommu.h | 11 +++ > memory.c | 3 +- > 11 files changed, 160 insertions(+), 38 deletions(-) > > -- > 1.9.1
Re: [Qemu-devel] [virtio-dev] Re: [PATCH v12 0/2] virtio-crypto: virtio crypto device specification
On Sat, Nov 05, 2016 at 09:15:58AM +, Gonglei (Arei) wrote: > > > > Subject: [virtio-dev] Re: [PATCH v12 0/2] virtio-crypto: virtio crypto > > device > > specification > > > > On Mon, Oct 24, 2016 at 06:51:52AM +, Gonglei (Arei) wrote: > > > Ping > > > > > > And the corresponding source code v9 on QEMU side had been posted: > > > > > > [PATCH v9 00/12] virtio-crypto: introduce framework and device emulation > > > https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg04755.html > > > > > > Regards, > > > -Gonglei > > > > If there are no comments and this is ready to get votes now, > > pls open the jira issue that you created. > > I can then start the ballot. > > > Hi Michael, > > I just updated and opened the jira issue. > Please address it, thanks :) > > Regards, > -Gonglei Looks like there are still minor comments, pls address, wait a bit then ping me again. Thanks! -- MST
Re: [Qemu-devel] [PATCH] smbios: Add 1 terminator if there is any string field defined in given table.
On Tue, Sep 06, 2016 at 04:28:33PM +0800, Lin Ma wrote:
> If user specifies binary file on command line to load smbios entries, then
> will get error messages while decoding them in guest.
>
> Reproducer:
> 1. dump a smbios table to a binary file from host or guest.(says table 1)
> 2. load the binary file through command line: 'qemu -smbios file=...'.
> 3. perform 'dmidecode' or 'dmidecode -t 1' in guest.
>
> It reports 'Invalid entry length...' because qemu doesn't add terminator(s)
> for
> the table correctly.
> For smbios tables which have string field provided, qemu should add 1
> terminator.
> For smbios tables which dont have string field provided, qemu should add 2.
>
> This patch fixed the issue.
>
> Signed-off-by: Lin Ma
Seems to make sense superficially
Acked-by: Michael S. Tsirkin
Fam, would you like to take this?
> ---
> hw/smbios/smbios.c | 90
> ++
> include/hw/smbios/smbios.h | 44 +++
> 2 files changed, 134 insertions(+)
>
> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
> index 74c7102..6293bc5 100644
> --- a/hw/smbios/smbios.c
> +++ b/hw/smbios/smbios.c
> @@ -885,6 +885,9 @@ void smbios_entry_add(QemuOpts *opts)
> {
> const char *val;
>
> +int i, terminator_count = 2, table_str_field_count = 0;
> +int *tables_str_field_offset = NULL;
> +
> assert(!smbios_immutable);
>
> val = qemu_opt_get(opts, "file");
> @@ -926,7 +929,94 @@ void smbios_entry_add(QemuOpts *opts)
> smbios_type4_count++;
> }
>
> +switch (header->type) {
> +case 0:
> +tables_str_field_offset = g_malloc0(sizeof(int) * \
> +TYPE_0_STR_FIELD_COUNT);
> +tables_str_field_offset = (int []){\
> +TYPE_0_STR_FIELD_OFFSET_VENDOR, \
> +TYPE_0_STR_FIELD_OFFSET_BIOS_VERSION, \
> +
> TYPE_0_STR_FIELD_OFFSET_BIOS_RELEASE_DATE};
> +table_str_field_count = sizeof(tables_str_field_offset) / \
> +sizeof(tables_str_field_offset[0]);
> +break;
> +case 1:
> +tables_str_field_offset = g_malloc0(sizeof(int) * \
> +TYPE_1_STR_FIELD_COUNT);
> +tables_str_field_offset = (int []){
> +TYPE_1_STR_FIELD_OFFSET_MANUFACTURER, \
> +TYPE_1_STR_FIELD_OFFSET_PRODUCT, \
> +TYPE_1_STR_FIELD_OFFSET_VERSION, \
> +TYPE_1_STR_FIELD_OFFSET_SERIAL, \
> +TYPE_1_STR_FIELD_OFFSET_SKU, \
> +TYPE_1_STR_FIELD_OFFSET_FAMILY};
> +table_str_field_count = sizeof(tables_str_field_offset) / \
> +sizeof(tables_str_field_offset[0]);
> +break;
> +case 2:
> +tables_str_field_offset = g_malloc0(sizeof(int) * \
> +TYPE_2_STR_FIELD_COUNT);
> +tables_str_field_offset = (int []){\
> +TYPE_2_STR_FIELD_OFFSET_MANUFACTURER, \
> +TYPE_2_STR_FIELD_OFFSET_PRODUCT, \
> +TYPE_2_STR_FIELD_OFFSET_VERSION, \
> +TYPE_2_STR_FIELD_OFFSET_SERIAL, \
> +TYPE_2_STR_FIELD_OFFSET_ASSET, \
> +TYPE_2_STR_FIELD_OFFSET_LOCATION};
> +table_str_field_count = sizeof(tables_str_field_offset) / \
> +sizeof(tables_str_field_offset[0]);
> +break;
> +case 3:
> +tables_str_field_offset = g_malloc0(sizeof(int) * \
> +TYPE_3_STR_FIELD_COUNT);
> +tables_str_field_offset = (int []){\
> +TYPE_3_STR_FIELD_OFFSET_MANUFACTURER, \
> +TYPE_3_STR_FIELD_OFFSET_VERSION, \
> +TYPE_3_STR_FIELD_OFFSET_SERIAL, \
> +TYPE_3_STR_FIELD_OFFSET_ASSET, \
> +TYPE_3_STR_FIELD_OFFSET_SKU};
> +table_str_field_count = sizeof(tables_str_field_offset) / \
> +sizeof(tables_str_field_offset[0]);
> +break;
> +case 4:
> +tables_str_field_offset = g_malloc0(sizeof(int) * \
> +TYPE_4_STR_FIELD_COUNT);
> +tables_str_field_offset = (int []){\
> +TYPE_4_STR_FIELD_OFFSET_SOCKET, \
> +
> TYPE_4_STR_FIELD_OF
Re: [Qemu-devel] [PATCH v6 03/19] tcg: add kick timer for single-threaded vCPU emulation
On 11/09/2016 03:57 PM, Alex Bennée wrote: Currently we rely on the side effect of the main loop grabbing the iothread_mutex to give any long running basic block chains a kick to ensure the next vCPU is scheduled. As this code is being re-factored and rationalised we now do it explicitly here. Signed-off-by: Alex Bennée Reviewed-by: Richard Henderson r~
Re: [Qemu-devel] [PATCHv2 3/3] Split ISA and sysbus versions of m48t59 device
On 10/11/16 14:57, Paolo Bonzini wrote: > > > On 09/11/2016 13:22, David Gibson wrote: >> The m48t59 device supports both ISA and direct sysbus attached versions of >> the device in the one .c file. This can be awkward for some embedded >> machine types which need the sysbus M48T59, but don't want to pull in the >> ISA bus code and its other dependencies. >> >> Therefore, this patch splits out the code for the ISA attached M48T59 into >> its own C file. It will be built when both CONFIG_M48T59 and >> CONFIG_ISA_BUS are enabled. >> >> Signed-off-by: David Gibson > > Who needs the ISA M48T59? Perhaps it should be a separate symbol > altogether. Let's document that SPARC will stop providing it in 2.9, > for example, if it's only a PReP thing. > > Paolo Hi Paolo, The ISA M48T59 is still actively used by the sun4u machine on qemu-system-sparc64. In real terms it's actually connected to the ebus, but for all intents and purposes it's the same as an ISA bus connected via a PCI bridge. ATB, Mark.
[Qemu-devel] [PATCH v4 07/15] qapi: use one symbol per line
The documentation parser we are going to add only handles a single symbol per line. Signed-off-by: Marc-André Lureau --- qapi/block-core.json | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/qapi/block-core.json b/qapi/block-core.json index c64a48c..e1cc94a 100644 --- a/qapi/block-core.json +++ b/qapi/block-core.json @@ -1712,9 +1712,13 @@ # # Drivers that are supported in block device operations. # -# @host_device, @host_cdrom: Since 2.1 +# @host_device: Since 2.1 +# @host_cdrom: Since 2.1 # @gluster: Since 2.7 -# @nbd, @nfs, @replication, @ssh: Since 2.8 +# @nbd: Since 2.8 +# @nfs: Since 2.8 +# @replication: Since 2.8 +# @ssh: Since 2.8 # # Since: 2.0 ## -- 2.10.0
Re: [Qemu-devel] [PATCH v6 05/19] tcg: drop global lock during TCG code execution
On 11/09/2016 03:57 PM, Alex Bennée wrote: From: Jan Kiszka This finally allows TCG to benefit from the iothread introduction: Drop the global mutex while running pure TCG CPU code. Reacquire the lock when entering MMIO or PIO emulation, or when leaving the TCG loop. We have to revert a few optimization for the current TCG threading model, namely kicking the TCG thread in qemu_mutex_lock_iothread and not kicking it in qemu_cpu_kick. We also need to disable RAM block reordering until we have a more efficient locking mechanism at hand. Still, a Linux x86 UP guest and my Musicpal ARM model boot fine here. These numbers demonstrate where we gain something: 20338 jan 20 0 331m 75m 6904 R 99 0.9 0:50.95 qemu-system-arm 20337 jan 20 0 331m 75m 6904 S 20 0.9 0:26.50 qemu-system-arm The guest CPU was fully loaded, but the iothread could still run mostly independent on a second core. Without the patch we don't get beyond 32206 jan 20 0 330m 73m 7036 R 82 0.9 1:06.00 qemu-system-arm 32204 jan 20 0 330m 73m 7036 S 21 0.9 0:17.03 qemu-system-arm We don't benefit significantly, though, when the guest is not fully loading a host CPU. Signed-off-by: Jan Kiszka Message-Id: <1439220437-23957-10-git-send-email-fred.kon...@greensocs.com> [FK: Rebase, fix qemu_devices_reset deadlock, rm address_space_* mutex] Signed-off-by: KONRAD Frederic [EGC: fixed iothread lock for cpu-exec IRQ handling] Signed-off-by: Emilio G. Cota [AJB: -smp single-threaded fix, rm old info from commit msg, review updates] Signed-off-by: Alex Bennée --- Reviewed-by: Richard Henderson r~
[Qemu-devel] [PATCH v4 03/15] qga/schema: improve guest-set-vcpus Returns: section
The documentation parser we are going to add finishes a section after an empty line. Fix the Returns: section of guest-set-vcpus, and itemize the possible return values. Signed-off-by: Marc-André Lureau --- qga/qapi-schema.json | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/qga/qapi-schema.json b/qga/qapi-schema.json index 758803a..cb68c17 100644 --- a/qga/qapi-schema.json +++ b/qga/qapi-schema.json @@ -696,22 +696,18 @@ # # Returns: The length of the initial sublist that has been successfully # processed. The guest agent maximizes this value. Possible cases: -# -# 0:if the @vcpus list was empty on input. Guest state +# - 0: if the @vcpus list was empty on input. Guest state #has not been changed. Otherwise, -# -# Error:processing the first node of @vcpus failed for the +# - Error: processing the first node of @vcpus failed for the #reason returned. Guest state has not been changed. #Otherwise, -# -# < length(@vcpus): more than zero initial nodes have been processed, +# - < length(@vcpus): more than zero initial nodes have been processed, #but not the entire @vcpus list. Guest state has #changed accordingly. To retrieve the error #(assuming it persists), repeat the call with the #successfully processed initial sublist removed. #Otherwise, -# -# length(@vcpus): call successful. +# - length(@vcpus): call successful. # # Since: 1.5 ## -- 2.10.0
[Qemu-devel] [PATCH v4 05/15] qapi: fix missing symbol @prefix
Signed-off-by: Marc-André Lureau
Reviewed-by: Eric Blake
---
qapi-schema.json | 4 ++--
qapi/block-core.json | 4 ++--
qapi/crypto.json | 36 ++--
3 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index 8ef6635..09dbc88 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -4650,7 +4650,7 @@
{ 'include': 'qapi/rocker.json' }
##
-# ReplayMode:
+# @ReplayMode:
#
# Mode of the replay subsystem.
#
@@ -4718,7 +4718,7 @@
{ 'command': 'query-gic-capabilities', 'returns': ['GICCapability'] }
##
-# CpuInstanceProperties
+# @CpuInstanceProperties
#
# List of properties to be used for hotplugging a CPU instance,
# it should be passed by management with device_add command when
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 5108b42..372889c 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -1144,7 +1144,7 @@
'data': 'DriveMirror' }
##
-# DriveMirror
+# @DriveMirror
#
# A set of parameters describing drive mirror setup.
#
@@ -1368,7 +1368,7 @@
'data': 'BlockIOThrottle' }
##
-# BlockIOThrottle
+# @BlockIOThrottle
#
# A set of parameters describing block throttling.
#
diff --git a/qapi/crypto.json b/qapi/crypto.json
index 5c9d7d4..15d296e 100644
--- a/qapi/crypto.json
+++ b/qapi/crypto.json
@@ -3,7 +3,7 @@
# QAPI crypto definitions
##
-# QCryptoTLSCredsEndpoint:
+# @QCryptoTLSCredsEndpoint:
#
# The type of network endpoint that will be using the credentials.
# Most types of credential require different setup / structures
@@ -22,7 +22,7 @@
##
-# QCryptoSecretFormat:
+# @QCryptoSecretFormat:
#
# The data format that the secret is provided in
#
@@ -36,7 +36,7 @@
##
-# QCryptoHashAlgorithm:
+# @QCryptoHashAlgorithm:
#
# The supported algorithms for computing content digests
#
@@ -55,7 +55,7 @@
##
-# QCryptoCipherAlgorithm:
+# @QCryptoCipherAlgorithm:
#
# The supported algorithms for content encryption ciphers
#
@@ -82,7 +82,7 @@
##
-# QCryptoCipherMode:
+# @QCryptoCipherMode:
#
# The supported modes for content encryption ciphers
#
@@ -98,7 +98,7 @@
##
-# QCryptoIVGenAlgorithm:
+# @QCryptoIVGenAlgorithm:
#
# The supported algorithms for generating initialization
# vectors for full disk encryption. The 'plain' generator
@@ -116,7 +116,7 @@
'data': ['plain', 'plain64', 'essiv']}
##
-# QCryptoBlockFormat:
+# @QCryptoBlockFormat:
#
# The supported full disk encryption formats
#
@@ -131,7 +131,7 @@
'data': ['qcow', 'luks']}
##
-# QCryptoBlockOptionsBase:
+# @QCryptoBlockOptionsBase:
#
# The common options that apply to all full disk
# encryption formats
@@ -144,7 +144,7 @@
'data': { 'format': 'QCryptoBlockFormat' }}
##
-# QCryptoBlockOptionsQCow:
+# @QCryptoBlockOptionsQCow:
#
# The options that apply to QCow/QCow2 AES-CBC encryption format
#
@@ -158,7 +158,7 @@
'data': { '*key-secret': 'str' }}
##
-# QCryptoBlockOptionsLUKS:
+# @QCryptoBlockOptionsLUKS:
#
# The options that apply to LUKS encryption format
#
@@ -172,7 +172,7 @@
##
-# QCryptoBlockCreateOptionsLUKS:
+# @QCryptoBlockCreateOptionsLUKS:
#
# The options that apply to LUKS encryption format initialization
#
@@ -202,7 +202,7 @@
##
-# QCryptoBlockOpenOptions:
+# @QCryptoBlockOpenOptions:
#
# The options that are available for all encryption formats
# when opening an existing volume
@@ -217,7 +217,7 @@
##
-# QCryptoBlockCreateOptions:
+# @QCryptoBlockCreateOptions:
#
# The options that are available for all encryption formats
# when initializing a new volume
@@ -232,7 +232,7 @@
##
-# QCryptoBlockInfoBase:
+# @QCryptoBlockInfoBase:
#
# The common information that applies to all full disk
# encryption formats
@@ -246,7 +246,7 @@
##
-# QCryptoBlockInfoLUKSSlot:
+# @QCryptoBlockInfoLUKSSlot:
#
# Information about the LUKS block encryption key
# slot options
@@ -266,7 +266,7 @@
##
-# QCryptoBlockInfoLUKS:
+# @QCryptoBlockInfoLUKS:
#
# Information about the LUKS block encryption options
#
@@ -294,7 +294,7 @@
'slots': [ 'QCryptoBlockInfoLUKSSlot' ] }}
##
-# QCryptoBlockInfoQCow:
+# @QCryptoBlockInfoQCow:
#
# Information about the QCow block encryption options
#
@@ -305,7 +305,7 @@
##
-# QCryptoBlockInfo:
+# @QCryptoBlockInfo:
#
# Information about the block encryption options
#
--
2.10.0
[Qemu-devel] [PATCH v4 15/15] build-sys: add qapi doc generation targets
Generate and install the man and html version of QAPI documentation. Add it also to optional pdf/dvi/info targets. Also support plain-text targets docs/qemu-ga-ref.txt & docs/qemu-qmp-ref.txt. Signed-off-by: Marc-André Lureau --- Makefile | 56 +++--- .gitignore | 11 ++- docs/qmp-intro.txt | 3 +-- 3 files changed, 60 insertions(+), 10 deletions(-) diff --git a/Makefile b/Makefile index 3617736..cc1c46e 100644 --- a/Makefile +++ b/Makefile @@ -91,6 +91,8 @@ HELPERS-$(CONFIG_LINUX) = qemu-bridge-helper$(EXESUF) ifdef BUILD_DOCS DOCS=qemu-doc.html qemu.1 qemu-img.1 qemu-nbd.8 qemu-ga.8 +DOCS+=docs/qemu-qmp-ref.html docs/qemu-qmp-ref.7 +DOCS+=docs/qemu-ga-ref.html docs/qemu-ga-ref.7 ifdef CONFIG_VIRTFS DOCS+=fsdev/virtfs-proxy-helper.1 endif @@ -266,6 +268,7 @@ qemu-ga$(EXESUF): QEMU_CFLAGS += -I qga/qapi-generated gen-out-type = $(subst .,-,$(suffix $@)) qapi-py = $(SRC_PATH)/scripts/qapi.py $(SRC_PATH)/scripts/ordereddict.py +qapi-py += $(SRC_PATH)/scripts/qapi2texi.py qga/qapi-generated/qga-qapi-types.c qga/qapi-generated/qga-qapi-types.h :\ $(SRC_PATH)/qga/qapi-schema.json $(SRC_PATH)/scripts/qapi-types.py $(qapi-py) @@ -395,6 +398,11 @@ distclean: clean rm -f qemu-doc.vr rm -f config.log rm -f linux-headers/asm + rm -f qemu-ga-qapi.texi qemu-qapi.texi + rm -f docs/qemu-qmp-ref.7 docs/qemu-ga-ref.7 + rm -f docs/qemu-qmp-ref.txt docs/qemu-ga-ref.txt + rm -f docs/qemu-qmp-ref.pdf docs/qemu-ga-ref.pdf + rm -f docs/qemu-qmp-ref.html docs/qemu-ga-ref.html for d in $(TARGET_DIRS); do \ rm -rf $$d || exit 1 ; \ done @@ -431,9 +439,12 @@ endif install-doc: $(DOCS) $(INSTALL_DIR) "$(DESTDIR)$(qemu_docdir)" $(INSTALL_DATA) qemu-doc.html "$(DESTDIR)$(qemu_docdir)" + $(INSTALL_DATA) docs/qemu-qmp-ref.html "$(DESTDIR)$(qemu_docdir)" ifdef CONFIG_POSIX $(INSTALL_DIR) "$(DESTDIR)$(mandir)/man1" $(INSTALL_DATA) qemu.1 "$(DESTDIR)$(mandir)/man1" + $(INSTALL_DIR) "$(DESTDIR)$(mandir)/man7" + $(INSTALL_DATA) docs/qemu-qmp-ref.7 "$(DESTDIR)$(mandir)/man7" ifneq ($(TOOLS),) $(INSTALL_DATA) qemu-img.1 "$(DESTDIR)$(mandir)/man1" $(INSTALL_DIR) "$(DESTDIR)$(mandir)/man8" @@ -441,6 +452,8 @@ ifneq ($(TOOLS),) endif ifneq (,$(findstring qemu-ga,$(TOOLS))) $(INSTALL_DATA) qemu-ga.8 "$(DESTDIR)$(mandir)/man8" + $(INSTALL_DATA) docs/qemu-ga-ref.html "$(DESTDIR)$(qemu_docdir)" + $(INSTALL_DATA) docs/qemu-ga-ref.7 "$(DESTDIR)$(mandir)/man7" endif endif ifdef CONFIG_VIRTFS @@ -528,9 +541,9 @@ ui/console-gl.o: $(SRC_PATH)/ui/console-gl.c \ ui/shader/texture-blit-vert.h ui/shader/texture-blit-frag.h # documentation -MAKEINFO=makeinfo +MAKEINFO=makeinfo -D 'VERSION $(VERSION)' MAKEINFOFLAGS=--no-headers --no-split --number-sections -TEXIFLAG=$(if $(V),,--quiet) +TEXIFLAG=$(if $(V),,--quiet) --command='@set VERSION $(VERSION)' %.dvi: %.texi $(call quiet-command,texi2dvi $(TEXIFLAG) -I . $<,"GEN","$@") @@ -542,7 +555,11 @@ TEXIFLAG=$(if $(V),,--quiet) $(call quiet-command,$(MAKEINFO) $< -o $@,"GEN","$@") %.pdf: %.texi - $(call quiet-command,texi2pdf $(TEXIFLAG) -I . $<,"GEN","$@") + $(call quiet-command,texi2pdf $(TEXIFLAG) -I . $< -o $@,"GEN","$@") + +%.txt: %.texi + $(call quiet-command,LC_ALL=C $(MAKEINFO) $(MAKEINFOFLAGS) --plaintext $< -o $@,\ + " GEN $@") qemu-options.texi: $(SRC_PATH)/qemu-options.hx $(SRC_PATH)/scripts/hxtool $(call quiet-command,sh $(SRC_PATH)/scripts/hxtool -t < $< > $@,"GEN","$@") @@ -556,6 +573,12 @@ qemu-monitor-info.texi: $(SRC_PATH)/hmp-commands-info.hx $(SRC_PATH)/scripts/hxt qemu-img-cmds.texi: $(SRC_PATH)/qemu-img-cmds.hx $(SRC_PATH)/scripts/hxtool $(call quiet-command,sh $(SRC_PATH)/scripts/hxtool -t < $< > $@,"GEN","$@") +qemu-qapi.texi: $(qapi-modules) $(qapi-py) + $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi2texi.py $< > $@,"GEN" "$@") + +qemu-ga-qapi.texi: $(SRC_PATH)/qga/qapi-schema.json $(qapi-py) + $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/qapi2texi.py $< > $@,"GEN","$@") + qemu.1: qemu-doc.texi qemu-options.texi qemu-monitor.texi qemu-monitor-info.texi $(call quiet-command, \ perl -Ww -- $(SRC_PATH)/scripts/texi2pod.pl $< qemu.pod && \ @@ -587,16 +610,35 @@ qemu-ga.8: qemu-ga.texi $(POD2MAN) --section=8 --center=" " --release=" " qemu-ga.pod > $@, \ "GEN","$@") -dvi: qemu-doc.dvi -html: qemu-doc.html -info: qemu-doc.info -pdf: qemu-doc.pdf +docs/qemu-qmp-ref.7: + $(call quiet-command, \ +perl -Ww -- $(SRC_PATH)/scripts/texi2pod.pl $< qemu-qmp-ref.pod && \ +$(POD2MAN) --section=7 --center=" " --release=" " qemu-qmp-ref.pod > $@, \ +"GEN","$@") + +docs/qemu-ga-ref.7: + $(call quiet-command, \ +perl -Ww -- $(SRC_PATH)/scripts/texi2p
[Qemu-devel] [PATCH v4 00/15] qapi doc generation (whole version, squashed)
Add a qapi2texi script to generate the documentation from the qapi
schemas.
The 13th patch in this series is a squashed version of the
documentation move from qmp-commands.txt to the schemas. The whole
version (not sent on the ML to avoid spamming) is in the following git
branch: https://github.com/elmarco/qemu/commits/qapi-doc
v4:
- more device_add schema fixes
- do not merge docs/qmp-intro.txt in qemu-qmp-ref.texi
- remove needless @ifinfo, add GPL copying text
- added qemu logo to pdf
- added some r-b tags
v3:
- many improvements to the doc parser:
- throws an error in various malformated conditions
- allows multiple meta-sections, except for "Since:" and "Return:"
- build a list of docs, instead of attaching docs to expressions
- accept() breaks on new doc block, and get_doc() returns a QAPIDoc
- fix more documentation to fit the new parser
- use a master texi file that includes the generated file, instead of
templated texi file
- texi fixes after Markus review
- only build and install html and man pages by default
- fix .gitignore
v2:
- change licence to be lgpl2+
- fix some comments & commit message
- add more code comments
- improve the doc parsing to treat only "Since" as a special case not
requiring ":" (common notation in the doc)
- include some early schema doc fixes (to fix generated doc)
- include the squashed version of the doc move
- include the man page and installation build changes
Marc-André Lureau (15):
qapi: improve device_add schema
qga/schema: fix double-return in doc
qga/schema: improve guest-set-vcpus Returns: section
qapi: fix schema symbol sections
qapi: fix missing symbol @prefix
qapi: fix various symbols mismatch in documentation
qapi: use one symbol per line
qapi: add missing colon-ending for section name
qapi: add some sections in docs
docs: add master qapi texi files
qapi: add qapi2texi script
texi2pod: learn quotation, deftp and deftypefn
qmp-commands: (SQUASHED) move doc to schema
docs: add qemu logo
build-sys: add qapi doc generation targets
Makefile| 57 +-
scripts/qapi.py | 175 +-
scripts/qapi2texi.py| 316
scripts/texi2pod.pl | 44 +-
.gitignore | 11 +-
docs/qapi-code-gen.txt | 44 +-
docs/qemu-ga-ref.texi | 82 +
docs/qemu-qmp-ref.texi | 82 +
docs/qemu_logo.pdf | Bin 0 -> 9117 bytes
{pc-bios => docs}/qemu_logo.svg |0
docs/qmp-commands.txt | 3824 ---
docs/qmp-events.txt | 731
docs/qmp-intro.txt |3 +-
qapi-schema.json| 1623 +++--
qapi/block-core.json| 894 +++--
qapi/block.json | 82 +-
qapi/common.json| 52 +-
qapi/crypto.json| 41 +-
qapi/event.json | 304 +++-
qapi/introspect.json| 28 +-
qapi/rocker.json| 63 +-
qapi/trace.json | 25 +-
qga/qapi-schema.json| 64 +-
23 files changed, 3527 insertions(+), 5018 deletions(-)
create mode 100755 scripts/qapi2texi.py
create mode 100644 docs/qemu-ga-ref.texi
create mode 100644 docs/qemu-qmp-ref.texi
create mode 100644 docs/qemu_logo.pdf
rename {pc-bios => docs}/qemu_logo.svg (100%)
delete mode 100644 docs/qmp-commands.txt
delete mode 100644 docs/qmp-events.txt
--
2.10.0
[Qemu-devel] [PATCH v4 01/15] qapi: improve device_add schema
'device_add' is still incomplete for now, but we can fix a few
arguments:
- 'bus' is a common argument, regardless of the device
- 'id' is an optionnal argument
Signed-off-by: Marc-André Lureau
---
qapi-schema.json | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index b0b4bf6..9201330 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2287,7 +2287,7 @@
#
# @bus: #optional the device's parent bus (device tree path)
#
-# @id: the device's ID, must be unique
+# @id: #optional the device's ID, must be unique
#
# Additional arguments depend on the type.
#
@@ -2317,7 +2317,7 @@
# Since: 0.13
##
{ 'command': 'device_add',
- 'data': {'driver': 'str', 'id': 'str'},
+ 'data': {'driver': 'str', '*bus': 'str', '*id': 'str'},
'gen': false } # so we can get the additional arguments
##
--
2.10.0
[Qemu-devel] [PATCH v4 09/15] qapi: add some sections in docs
Add some more section titles to organize the produced documents.
Signed-off-by: Marc-André Lureau
---
qapi-schema.json | 4
qapi/block-core.json | 6 --
qapi/block.json | 10 --
qapi/common.json | 6 --
qapi/crypto.json | 5 -
qapi/event.json | 6 ++
qapi/rocker.json | 4
qapi/trace.json | 3 +++
8 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index 67c53a2..30f5492 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -20,6 +20,10 @@
# QAPI introspection
{ 'include': 'qapi/introspect.json' }
+##
+# = QMP commands
+##
+
##
# @qmp_capabilities:
#
diff --git a/qapi/block-core.json b/qapi/block-core.json
index bc78042..91febed 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -1,6 +1,8 @@
# -*- Mode: Python -*-
-#
-# QAPI block core definitions (vm unrelated)
+
+##
+# == QAPI block core definitions (vm unrelated)
+##
# QAPI common definitions
{ 'include': 'common.json' }
diff --git a/qapi/block.json b/qapi/block.json
index 937df05..e4ad74b 100644
--- a/qapi/block.json
+++ b/qapi/block.json
@@ -1,10 +1,16 @@
# -*- Mode: Python -*-
-#
-# QAPI block definitions (vm related)
+
+##
+# = QAPI block definitions
+##
# QAPI block core definitions
{ 'include': 'block-core.json' }
+##
+# == QAPI block definitions (vm unrelated)
+##
+
##
# @BiosAtaTranslation:
#
diff --git a/qapi/common.json b/qapi/common.json
index 624a861..d93f159 100644
--- a/qapi/common.json
+++ b/qapi/common.json
@@ -1,6 +1,8 @@
# -*- Mode: Python -*-
-#
-# QAPI common definitions
+
+##
+# = QAPI common definitions
+##
##
# @QapiErrorClass:
diff --git a/qapi/crypto.json b/qapi/crypto.json
index 15d296e..1e517b0 100644
--- a/qapi/crypto.json
+++ b/qapi/crypto.json
@@ -1,6 +1,9 @@
# -*- Mode: Python -*-
#
-# QAPI crypto definitions
+
+##
+# = QAPI crypto definitions
+##
##
# @QCryptoTLSCredsEndpoint:
diff --git a/qapi/event.json b/qapi/event.json
index 37bf34e..59942b0 100644
--- a/qapi/event.json
+++ b/qapi/event.json
@@ -1,3 +1,9 @@
+# -*- Mode: Python -*-
+
+##
+# = Events
+##
+
##
# @SHUTDOWN:
#
diff --git a/qapi/rocker.json b/qapi/rocker.json
index ace2776..dd72e02 100644
--- a/qapi/rocker.json
+++ b/qapi/rocker.json
@@ -1,4 +1,8 @@
##
+# = Rocker API
+##
+
+##
# @RockerSwitch:
#
# Rocker switch information.
diff --git a/qapi/trace.json b/qapi/trace.json
index 4fd39b7..3ad7df7 100644
--- a/qapi/trace.json
+++ b/qapi/trace.json
@@ -5,6 +5,9 @@
# This work is licensed under the terms of the GNU GPL, version 2 or later.
# See the COPYING file in the top-level directory.
+##
+# = Tracing commands
+##
##
# @TraceEventState:
--
2.10.0
[Qemu-devel] [PATCH v4 11/15] qapi: add qapi2texi script
As the name suggests, the qapi2texi script converts JSON QAPI
description into a texi file suitable for different target
formats (info/man/txt/pdf/html...).
It parses the following kind of blocks:
Free-form:
##
# = Section
# == Subsection
#
# Some text foo with *emphasis*
# 1. with a list
# 2. like that
#
# And some code:
# | $ echo foo
# | -> do this
# | <- get that
#
##
Symbol:
##
# @symbol:
#
# Symbol body ditto ergo sum. Foo bar
# baz ding.
#
# @arg: foo
# @arg: #optional foo
#
# Returns: returns bla bla
# Or bla blah
#
# Since: version
# Notes: notes, comments can have
#- itemized list
#- like this
#
# Example:
#
# -> { "execute": "quit" }
# <- { "return": {} }
#
##
That's roughly following the following BNF grammar:
api_comment = "##\n" comment "##\n"
comment = freeform_comment | symbol_comment
freeform_comment = { "#" text "\n" }
symbol_comment = "#" "@" name ":\n" { freeform | member | meta }
member = "#" '@' name ':' [ text ] freeform_comment
meta = "#" ( "Returns:", "Since:", "Note:", "Notes:", "Example:", "Examples:" )
[ text ] freeform_comment
text = free-text markdown-like, "#optional" for members
Thanks to the following json expressions, the documentation is enhanced
with extra information about the type of arguments and return value
expected.
Signed-off-by: Marc-André Lureau
---
scripts/qapi.py| 175 ++-
scripts/qapi2texi.py | 316 +
docs/qapi-code-gen.txt | 44 +--
3 files changed, 524 insertions(+), 11 deletions(-)
create mode 100755 scripts/qapi2texi.py
diff --git a/scripts/qapi.py b/scripts/qapi.py
index 21bc32f..ed52ee4 100644
--- a/scripts/qapi.py
+++ b/scripts/qapi.py
@@ -122,6 +122,103 @@ class QAPIExprError(Exception):
"%s:%d: %s" % (self.info['file'], self.info['line'], self.msg)
+class QAPIDoc(object):
+def __init__(self, parser):
+self.parser = parser
+self.symbol = None
+self.body = []
+# args is {'arg': 'doc', ...}
+self.args = OrderedDict()
+# meta is [(Since/Notes/Examples/Returns:, 'doc'), ...]
+self.meta = []
+# the current section to populate, array of [dict, key, comment...]
+self.section = None
+self.expr_elem = None
+
+def get_body(self):
+return "\n".join(self.body)
+
+def has_meta(self, name):
+"""Returns True if the doc has a meta section 'name'"""
+return next((True for i in self.meta if i[0] == name), False)
+
+def append(self, line):
+"""Adds a # comment line, to be parsed and added in a section"""
+line = line[1:]
+if len(line) == 0:
+self._append_section(line)
+return
+
+if line[0] != ' ':
+raise QAPISchemaError(self.parser, "missing space after #")
+
+line = line[1:]
+# take the first word out
+name = line.split(' ', 1)[0]
+if name.startswith("@") and name.endswith(":"):
+line = line[len(name):]
+name = name[1:-1]
+if self.symbol is None:
+# the first is the symbol this APIDoc object documents
+if len(self.body):
+raise QAPISchemaError(self.parser, "symbol must come
first")
+self.symbol = name
+else:
+# else an arg
+self._start_args_section(name)
+elif self.symbol and name in (
+"Returns:", "Since:",
+# those are often singular or plural
+"Note:", "Notes:",
+"Example:", "Examples:"):
+# new "meta" section
+line = line[len(name):]
+self._start_meta_section(name[:-1])
+
+self._append_section(line)
+
+def _start_args_section(self, name):
+self.end_section()
+if self.args.has_key(name):
+raise QAPISchemaError(self.parser, "'%s' arg duplicated" % name)
+self.section = [self.args, name]
+
+def _start_meta_section(self, name):
+self.end_section()
+if name in ("Returns", "Since") and self.has_meta(name):
+raise QAPISchemaError(self.parser, "'%s' section duplicated" %
name)
+self.section = [self.meta, name]
+
+def _append_section(self, line):
+"""Add a comment to the current section, or the comment body"""
+if self.section:
+name = self.section[1]
+if not name.startswith("Example"):
+# an empty line ends the section, except with Example
+if len(self.section) > 2 and len(line) == 0:
+self.end_section()
+return
+# Example is verbatim
+line = line.strip()
+if len(line) > 0:
+self.section.append(line)
+else:
+self
[Qemu-devel] [PATCH v4 14/15] docs: add qemu logo
The pdf (needed by texi2pdf for vectorized images) was generated thanks
to inkscape, from the pc-bios/qemu_logo.svg file. Move the original file
in the docs folder too, since it's not being referenced elsewhere.
Signed-off-by: Marc-André Lureau
---
docs/qemu-ga-ref.texi | 4
docs/qemu-qmp-ref.texi | 4
docs/qemu_logo.pdf | Bin 0 -> 9117 bytes
{pc-bios => docs}/qemu_logo.svg | 0
4 files changed, 8 insertions(+)
create mode 100644 docs/qemu_logo.pdf
rename {pc-bios => docs}/qemu_logo.svg (100%)
diff --git a/docs/qemu-ga-ref.texi b/docs/qemu-ga-ref.texi
index 02ecdb7..f7ed73e 100644
--- a/docs/qemu-ga-ref.texi
+++ b/docs/qemu-ga-ref.texi
@@ -6,6 +6,10 @@
@settitle QEMU Guest Agent Protocol Reference
+@iftex
+@center @image{docs/qemu_logo}
+@end iftex
+
@copying
This is the QEMU Guest Agent Protocol reference manual.
diff --git a/docs/qemu-qmp-ref.texi b/docs/qemu-qmp-ref.texi
index ccc03cb..0f7e9e4 100644
--- a/docs/qemu-qmp-ref.texi
+++ b/docs/qemu-qmp-ref.texi
@@ -6,6 +6,10 @@
@settitle QEMU QMP Reference Manual
+@iftex
+@center @image{docs/qemu_logo}
+@end iftex
+
@copying
This is the QEMU QMP reference manual.
diff --git a/docs/qemu_logo.pdf b/docs/qemu_logo.pdf
new file mode 100644
index
..294cb7dec50de73c786925671300fb0abdf9d641
GIT binary patch
literal 9117
zcmd5?2|QF^`%elfQWRNlwoqesGqx7H>`T^?!C)*ini-
zlq^4#U7MYvi2uDarj$PK|9#)j`*}a_T%U38bDnd~^E~G{-*e9Qj*O|64h*S?<(4TL
z&Yk5(0|LewJPiPq*yuGb;qMxXf2Yrrc>;>)5rxe(}mw!_IBZ
zBWn5r%A#k#rGWQNo&)#KDAvR8x0=tc_AK7FZkNj5=6K3XBu`00v0e4uQlqTXa{EK^pC6URTA>12kjw8+SN
zFL;DT>nnVNJ9Uq*i!-qH#ln^D>ACfRJ_j`?HMf@?@jNTxflU55Zj$}?+0HD(+jedv
zsK^#=)qCfsdYUJ$wa)c?4(M-vH?`g0kBxo1J)9j`)_>X;B@~wx>R4K+FqOBp`!xB!
zYKk&q;3}T*uAA-Y$KeWcRpI5+{BuFY&Y#omOBB^5Vs^djKT6SmH9b!`dlmmaNI~J^
zjhaIL<6~y+qD@B~K30`}Of;%hE1bESUHuGxc_QqQg4HY2nclzcN$iJ3-3#cc0hp{c
zy<3R6;a%}Tr^$xj_YZd`?t32RE2i$=QC7C+f&?{Ht6y(`IGs*^kgG1CxPJQO;rX-K
zqbvRQ-n}mIZI9i->s9SXlwd0Z-)STpY7g`9DQu+Vcix|ylVCSlqiqSJKCGLROGORi
z;~vdL4}>0hReysnT{AIsU5Z=eLjIN9LeG(#e>oLhxsg(nPCXa|sBAxwcvHo$7qz`L
zzF`mF+!cqM>Bn3jyHyX}d#uXcUE)Nqdckppx$%
z9tC}RYDDtvV8xkqOBHjhW=1uKc7gM`fjT2i$CVqd1WajXh4ZG~Fo(5ux(Q^;S5-bK
zNn(qtkEuUX-|kNw(tZw%jR}6;;H-4&+FQHLdyx1w=eKl{Gfbac=L;e~?hj
z?(4f_tdx|(I)fX-(!c8lWJpMzX6LS4Qx{$`F=meR!Q1T~eXPqX96>(6f^#T+X4P{x
zJ7+{w-KxEw_B^GEhSDO1JcG6ww|tVHemwOBU*2~3q|GI{2V0JEcDO6K2y1TlS=)bT
zm4ZRAs2E$v+a1DTIf1}U!UcH_r~GQ~*Xhxw2k=?qU%+d
zWyVR<-GG(a%7(!Nx~Jp(R@-a#zSo$qHs&{TUt5Q-Bp-Rj71(Y~|NF3nPiyLJY{r<7
zLJ-VRcOx7A(8*O5oK9QWKAdsVnHSE{W;bnEpo~2feFA&S7roKc#Woy2-otTl%VunR
zabGKE;)441crKUVgF|_yMZ-IdbKUsd>LN#Pv1NbX8!sFwc86>9Wn5eS%?3cQi7=TRk_t$f(16+
zkiH~e|5X?VQW|D_n){%QJ;IzVeIHHxq8p$WRMQTz#w5PAfrQC5`{lSU<
z>6lPkrP2zCAiSbEX2r(67JB%1LK}BpIbpaBqkA^imU^iw?Q9BcqY3`+b9N?O^|$=f
z0{EWBM}|AJjSfbIE0n0e!>XiOJUabGQZ^w)CuRoUSJR+Hl=4^LuJgNosy^7V`Mac~
zYk9rn#C1t1oASf}}pySTiteAizyd9I}=WkLm%Ik*bG3v83fR#y|+MoLdCIf-}Zj{fE?c#$4q#{>7Cm>U~E
z-*tR$a{S%Y_y&_ZC)f;gtWI(h$u5hy3*JG94Z$?@9|US78m|l~K#!;&fX;w$ZGXD1
z1s#NMKurx2fFC#k0X_h5%{>4TfIAbwZxGZM%VW3yJK;
zXoKdC1+Y*#sOgRaaE#kUJsk>}zNA-I7y^a>l$SIH>Ma_LM1W$}GGrOxLj>Ta1UDkX
z15*N(2sVUdRfHQ6T}T8Cia%fviVy$_k5t6qFbE|8udIks#vrgb-~gkhCTIXyl?FhI
z9CJm}rBZx-mKeqCiy>u2zyg3M5}Dx>l4U<)(M1GH
zfc#Bh3?P?w@pJ6KHT$3M;zxgs<`wbEI1E~8vCCh3fQEW8=RlvKBw9=ch9l_3STO=b
z@uE;Id&L8l$
zDEnEm2yzT~V?y1|oy=0^RAt_?@^@KvnmZB=;wqFFKhbeNp_S#J*7*jpCRU^Csfw7Wn=w7)(x^I>7@@0WBWQ%hYh53O#
z5U8`zhiR`7f#%5=4$x3TUvCnbLL<=`ISbbXkjz5>Xuu+TEwBGe=;0PnbKvl?W)fpv
zVKfgdGmM)(`WApI!HdQ?L$FX0S}|C5u_h$LzJH90V0wVpBFsauwN&scW+9>V>)+~P
zN%JfO{M9QRqq-(meT1)<*%6y_34w^
zGXdmB0D|izgEjanS4GSAZ#2iqOz_EFmELzFU4SoIh>uS`L)(xP8KlLfvHEqooSA^T
zQPK^e9ogaj;mPyU;i)-ds!bRDRGL1Fyg4yFD>1t;ds+R#J5+;EldU@Yq;-qs>xa|j
z{Mabcs73PrfN8IVBGtQIQP0YQw^=nC-@LE=pl_XX%YaJ}u|0M2X6UtpV%)L%JFg${
z(5`t&nKrBT%6c(zBckWXTa~aeuZr(CJzZaXdZ6hkS$Zb#UBi~7O;Hi#isUu39twla
zb~?5kd}OJiJE_V=U((L-NNm_?yz{cF@J;jRjJ@P6_uD(}N3TiKIkP#fIJKkS$tW*q
zHiqtod=Wn)_2#14TLB7Cm256!^I}Kkbc$uPRclBA8fG2G(-##OuK4#eNgLP3ZSAlJ
zg?`1aTXJcndy=8$Js&9Pf(n&4%9X*0G)<
zaPfrHkHIS1!?wP?XV-h~{OXgZSuWad>um*#^(^+`tk3NTNXzYDFWJXl5HuVS=O=NL1Nb~nXQf)X4pe%|Zw?Yjlp@x?;w
zmo1)4k;>G2IA;i7Kn3(Y&PiDv1>Y9%MkYYu+2n%k!brulr-$BFwvH89wjR6zw@`n)
ze$JxyM9~<9Fl;ZhU`1JgpRo4d^rC0qRLlvDzO7#D=r}`@lg9GBp|h|+$xpIh1zvga
zMZOoy>BTxpHR(Mxr8f!)zaUt&9l&shN0&wqyKH+_5(H1e)jT73H<|h8PEz5!q$Z03
ztt34v`SOi0;oezDUCRiL7DLQI)g3M2t9yO(PbLLR^*L9-L^(ZsGXoSnUtRLw8aohT
z$Jyary(`i019oEHSA|b5sihY%_ww#vYM7oZ2n66g9W@`-R9_^l8SuD2ho0Y{U3x}L
zC*rj&zkRjTnxcH(GqcjFwXSO}CBYI>?NrJ>9JLiZ8a5MU^sXoMVmRB~gpXT_FB)B|
zqaQNzvkPnyFv~vR_-4+*JHao=SRmR%+T^O&+fZIJ#V?Un(%C~kJj#02J{k8yu`b&v
z8FD2%_66?z5b|l|MAPlzW;^%j2W@NY1Or;h&6^v`Xs0Lxs`5_No5ycwbgF1q7RVYT
z$Pq4w(4O#miY3N6p(WPe<%HP|mFDH4g`U(_4f<5u>>lZfx@MzmFKH_!;azs#s=^0r
z|2R-uz2;))q^}GtStcHPrZ(@KQ)^)fWup3B0WVC#qD{CUw;$#u<4GuZztTnTXt_uH
zsoWLkdZsa+L1tG5yJt2o1ieaR+tPLFcx-c5-I?Un$?veTvML!#hjU7`!LF;k>Luga
zKOd;bW!s`%B{RSI_}B0XgQgfcxb$G~M&Zy6`4PJ^8WTgxlxkOe*Ga<7Zom26K+V8>
z?K%Ieo7W*sByLZQze&PnzZnsqQ#L5R*zvhOv!R;u4et8I%lB~GwRp14%;x~@*LIm3
zKkx$skrxlTK2V+S5#^uqvwU{{
[Qemu-devel] [PATCH v4 04/15] qapi: fix schema symbol sections
According to docs/qapi-code-gen.txt, there needs to be '##' to start a
and end a symbol section, that's also what the documentation parser
expects.
Signed-off-by: Marc-André Lureau
Reviewed-by: Eric Blake
---
qapi-schema.json | 18 +-
qapi/block-core.json | 1 +
qga/qapi-schema.json | 3 +++
3 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index 9201330..8ef6635 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -65,6 +65,7 @@
{ 'enum': 'LostTickPolicy',
'data': ['discard', 'delay', 'merge', 'slew' ] }
+##
# @add_client
#
# Allow client connections for VNC, Spice and socket based
@@ -442,6 +443,7 @@
'cache-miss': 'int', 'cache-miss-rate': 'number',
'overflow': 'int' } }
+##
# @MigrationStatus:
#
# An enumeration of migration status.
@@ -627,6 +629,7 @@
##
{ 'command': 'query-migrate-capabilities', 'returns':
['MigrationCapabilityStatus']}
+##
# @MigrationParameter
#
# Migration parameters enumeration
@@ -685,7 +688,7 @@
'tls-creds', 'tls-hostname', 'max-bandwidth',
'downtime-limit', 'x-checkpoint-delay' ] }
-#
+##
# @migrate-set-parameters
#
# Set various migration parameters. See MigrationParameters for details.
@@ -697,7 +700,7 @@
{ 'command': 'migrate-set-parameters', 'boxed': true,
'data': 'MigrationParameters' }
-#
+##
# @MigrationParameters
#
# Optional members can be omitted on input ('migrate-set-parameters')
@@ -795,6 +798,7 @@
# command.
#
# Since: 2.5
+##
{ 'command': 'migrate-start-postcopy' }
##
@@ -2252,6 +2256,7 @@
##
{ 'command': 'migrate-incoming', 'data': {'uri': 'str' } }
+##
# @xen-save-devices-state:
#
# Save the state of all devices to file. The RAM and the block devices
@@ -3482,6 +3487,7 @@
'modelb': 'CpuModelInfo' },
'returns': 'CpuModelBaselineInfo' }
+##
# @AddfdInfo:
#
# Information about a file descriptor that was added to an fd set.
@@ -4530,14 +4536,16 @@
##
{ 'command': 'query-memory-devices', 'returns': ['MemoryDeviceInfo'] }
-## @ACPISlotType
+##
+# @ACPISlotType
#
# @DIMM: memory slot
# @CPU: logical CPU slot (since 2.7)
-#
+##
{ 'enum': 'ACPISlotType', 'data': [ 'DIMM', 'CPU' ] }
-## @ACPIOSTInfo
+##
+# @ACPIOSTInfo
#
# OSPM Status Indication for a device
# For description of possible values of @source and @status fields
diff --git a/qapi/block-core.json b/qapi/block-core.json
index bcd3b9e..5108b42 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -2810,6 +2810,7 @@
'offset': 'int',
'speed' : 'int' } }
+##
# @PreallocMode
#
# Preallocation mode of QEMU image file
diff --git a/qga/qapi-schema.json b/qga/qapi-schema.json
index cb68c17..5173c4a 100644
--- a/qga/qapi-schema.json
+++ b/qga/qapi-schema.json
@@ -833,6 +833,7 @@
{ 'command': 'guest-set-user-password',
'data': { 'username': 'str', 'password': 'str', 'crypted': 'bool' } }
+##
# @GuestMemoryBlock:
#
# @phys-index: Arbitrary guest-specific unique identifier of the MEMORY BLOCK.
@@ -932,6 +933,7 @@
'data':{'mem-blks': ['GuestMemoryBlock'] },
'returns': ['GuestMemoryBlockResponse'] }
+##
# @GuestMemoryBlockInfo:
#
# @size: the size (in bytes) of the guest memory blocks,
@@ -955,6 +957,7 @@
{ 'command': 'guest-get-memory-block-info',
'returns': 'GuestMemoryBlockInfo' }
+##
# @GuestExecStatus:
#
# @exited: true if process has already terminated.
--
2.10.0
[Qemu-devel] [PATCH v4 02/15] qga/schema: fix double-return in doc
guest-get-memory-block-info documentation should have only one "Returns:". Signed-off-by: Marc-André Lureau Reviewed-by: Eric Blake --- qga/qapi-schema.json | 1 - 1 file changed, 1 deletion(-) diff --git a/qga/qapi-schema.json b/qga/qapi-schema.json index c21f308..758803a 100644 --- a/qga/qapi-schema.json +++ b/qga/qapi-schema.json @@ -952,7 +952,6 @@ # # Get information relating to guest memory blocks. # -# Returns: memory block size in bytes. # Returns: @GuestMemoryBlockInfo # # Since 2.3 -- 2.10.0
[Qemu-devel] [PATCH v4 08/15] qapi: add missing colon-ending for section name
The documentation parser we are going to add expects a section name to
end with ':', otherwise the comment is treated as free-form text body.
Signed-off-by: Marc-André Lureau
---
qapi-schema.json | 300 +--
qapi/block-core.json | 196 -
qapi/block.json | 16 +--
qapi/common.json | 8 +-
qapi/event.json | 58 +-
qapi/introspect.json | 28 ++---
qapi/trace.json | 8 +-
qga/qapi-schema.json | 44
8 files changed, 329 insertions(+), 329 deletions(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index 6ea6e2e..67c53a2 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -66,7 +66,7 @@
'data': ['discard', 'delay', 'merge', 'slew' ] }
##
-# @add_client
+# @add_client:
#
# Allow client connections for VNC, Spice and socket based
# character devices to be passed in to QEMU via SCM_RIGHTS.
@@ -97,7 +97,7 @@
#
# @name: #optional The name of the guest
#
-# Since 0.14.0
+# Since: 0.14.0
##
{ 'struct': 'NameInfo', 'data': {'*name': 'str'} }
@@ -108,7 +108,7 @@
#
# Returns: @NameInfo of the guest
#
-# Since 0.14.0
+# Since: 0.14.0
##
{ 'command': 'query-name', 'returns': 'NameInfo' }
@@ -137,7 +137,7 @@
{ 'command': 'query-kvm', 'returns': 'KvmInfo' }
##
-# @RunState
+# @RunState:
#
# An enumeration of VM run states.
#
@@ -235,7 +235,7 @@
#
# Returns: The @UuidInfo for the guest
#
-# Since 0.14.0
+# Since: 0.14.0
##
{ 'command': 'query-uuid', 'returns': 'UuidInfo' }
@@ -382,7 +382,7 @@
{ 'command': 'query-events', 'returns': ['EventInfo'] }
##
-# @MigrationStats
+# @MigrationStats:
#
# Detailed migration status.
#
@@ -396,7 +396,7 @@
#
# @skipped: number of skipped zero pages (since 1.5)
#
-# @normal : number of normal pages (since 1.2)
+# @normal: number of normal pages (since 1.2)
#
# @normal-bytes: number of normal bytes sent (since 1.2)
#
@@ -420,7 +420,7 @@
'postcopy-requests' : 'int' } }
##
-# @XBZRLECacheStats
+# @XBZRLECacheStats:
#
# Detailed XBZRLE migration cache statistics
#
@@ -474,7 +474,7 @@
'active', 'postcopy-active', 'completed', 'failed', 'colo' ] }
##
-# @MigrationInfo
+# @MigrationInfo:
#
# Information about current migration process.
#
@@ -534,7 +534,7 @@
'*error-desc': 'str'} }
##
-# @query-migrate
+# @query-migrate:
#
# Returns information about current migration process.
#
@@ -545,7 +545,7 @@
{ 'command': 'query-migrate', 'returns': 'MigrationInfo' }
##
-# @MigrationCapability
+# @MigrationCapability:
#
# Migration capabilities enumeration
#
@@ -593,7 +593,7 @@
'compress', 'events', 'postcopy-ram', 'x-colo'] }
##
-# @MigrationCapabilityStatus
+# @MigrationCapabilityStatus:
#
# Migration capability information
#
@@ -607,7 +607,7 @@
'data': { 'capability' : 'MigrationCapability', 'state' : 'bool' } }
##
-# @migrate-set-capabilities
+# @migrate-set-capabilities:
#
# Enable/Disable the following migration capabilities (like xbzrle)
#
@@ -619,7 +619,7 @@
'data': { 'capabilities': ['MigrationCapabilityStatus'] } }
##
-# @query-migrate-capabilities
+# @query-migrate-capabilities:
#
# Returns information about the current migration capabilities status
#
@@ -630,7 +630,7 @@
{ 'command': 'query-migrate-capabilities', 'returns':
['MigrationCapabilityStatus']}
##
-# @MigrationParameter
+# @MigrationParameter:
#
# Migration parameters enumeration
#
@@ -689,7 +689,7 @@
'downtime-limit', 'x-checkpoint-delay' ] }
##
-# @migrate-set-parameters
+# @migrate-set-parameters:
#
# Set various migration parameters. See MigrationParameters for details.
#
@@ -699,7 +699,7 @@
'data': 'MigrationParameters' }
##
-# @MigrationParameters
+# @MigrationParameters:
#
# Optional members can be omitted on input ('migrate-set-parameters')
# but most members will always be present on output
@@ -758,7 +758,7 @@
'*x-checkpoint-delay': 'int'} }
##
-# @query-migrate-parameters
+# @query-migrate-parameters:
#
# Returns information about the current migration parameters
#
@@ -770,7 +770,7 @@
'returns': 'MigrationParameters' }
##
-# @client_migrate_info
+# @client_migrate_info:
#
# Set migration information for remote display. This makes the server
# ask the client to automatically reconnect using the new parameters
@@ -789,7 +789,7 @@
'*tls-port': 'int', '*cert-subject': 'str' } }
##
-# @migrate-start-postcopy
+# @migrate-start-postcopy:
#
# Followup to a migration command to switch the migration to postcopy mode.
# The postcopy-ram capability must be set before the original migration
@@ -800,7 +800,7 @@
{ 'command': 'migrate-start-postcopy' }
##
-# @COLOMessage
+# @COLOMessage:
#
# The message transmission between Primary side and Secondary side.
#
@@ -826,7 +826,7 @@
'vmstate-loaded' ] }
##
-# @COLOMode
+# @COLOMode:
#
# The colo mode
#
@@ -842,7
[Qemu-devel] [PATCH for-2.8] megasas: do not call pci_dma_unmap after having freed the frame once
Commit 8cc4678 ("megasas: remove useless check for cmd->frame", 2016-07-17) was
wrong because I trusted Coverity too much. It turns out that there _is_ a
path through which cmd->frame can become NULL. After megasas_handle_frame's
switch (md->frame->header.frame_cmd), megasas_init_firmware can be called.
>From there, megasas_reset_frames will call megasas_unmap_frame which resets
cmd->frame = NULL.
However, there is another bug to fix in there, because megasas_unmap_frame
is called again after setting the command status. In this case QEMU should
not do anything, instead it calls pci_dma_unmap again. Harmless, but
better fix it.
Signed-off-by: Paolo Bonzini
---
hw/scsi/megasas.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
index 52a4123..ca62952 100644
--- a/hw/scsi/megasas.c
+++ b/hw/scsi/megasas.c
@@ -461,9 +461,12 @@ static void megasas_unmap_frame(MegasasState *s,
MegasasCmd *cmd)
{
PCIDevice *p = PCI_DEVICE(s);
-pci_dma_unmap(p, cmd->frame, cmd->pa_size, 0, 0);
+if (cmd->pa_size) {
+pci_dma_unmap(p, cmd->frame, cmd->pa_size, 0, 0);
+}
cmd->frame = NULL;
cmd->pa = 0;
+cmd->pa_size = 0;
clear_bit(cmd->index, s->frame_map);
}
--
2.9.3
[Qemu-devel] [PATCH v4 06/15] qapi: fix various symbols mismatch in documentation
There are various mismatch:
- invalid symbols
- section and member symbols mismatch
- enum or union values vs 'type'
The documentation parser catches all these cases.
Signed-off-by: Marc-André Lureau
---
qapi-schema.json | 20 +---
qapi/block-core.json | 4
qapi/common.json | 6 +++---
qapi/rocker.json | 2 +-
qga/qapi-schema.json | 6 +++---
5 files changed, 16 insertions(+), 22 deletions(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index 09dbc88..6ea6e2e 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -693,8 +693,6 @@
#
# Set various migration parameters. See MigrationParameters for details.
#
-# @x-checkpoint-delay: the delay time between two checkpoints. (Since 2.8)
-#
# Since: 2.4
##
{ 'command': 'migrate-set-parameters', 'boxed': true,
@@ -1171,7 +1169,7 @@
'*service': 'str', '*auth': 'str', '*clients': ['VncClientInfo']} }
##
-# @VncPriAuth:
+# @VncPrimaryAuth:
#
# vnc primary authentication method.
#
@@ -3174,7 +3172,7 @@
#
# @alias: #optional an alias for the machine name
#
-# @default: #optional whether the machine is default
+# @is-default: #optional whether the machine is default
#
# @cpu-max: maximum number of CPUs supported by the machine type
# (since 1.5.0)
@@ -3727,7 +3725,6 @@
#
# @device: The name of the special file for the device,
# i.e. /dev/ttyS0 on Unix or COM1: on Windows
-# @type: What kind of device this is.
#
# Since: 1.4
##
@@ -3992,7 +3989,7 @@
#
# A union referencing different TPM backend types' configuration options
#
-# @passthrough: The configuration options for the TPM passthrough type
+# @type: 'passthrough' The configuration options for the TPM passthrough type
#
# Since: 1.5
##
@@ -4000,7 +3997,7 @@
'data': { 'passthrough' : 'TPMPassthroughOptions' } }
##
-# @TpmInfo:
+# @TPMInfo:
#
# Information about the TPM
#
@@ -4344,10 +4341,11 @@
#
# Input event union.
#
-# @key: Input event of Keyboard
-# @btn: Input event of pointer buttons
-# @rel: Input event of relative pointer motion
-# @abs: Input event of absolute pointer motion
+# @type: the input type, one of:
+# - 'key': Input event of Keyboard
+# - 'btn': Input event of pointer buttons
+# - 'rel': Input event of relative pointer motion
+# - 'abs': Input event of absolute pointer motion
#
# Since: 2.0
##
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 372889c..c64a48c 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -2160,10 +2160,6 @@
#
# @type: Transport type used for gluster connection
#
-# @unix: socket file
-#
-# @tcp:host address and port number
-#
# This is similar to SocketAddress, only distinction:
#
# 1. GlusterServer is a flat union, SocketAddress is a simple union.
diff --git a/qapi/common.json b/qapi/common.json
index 9353a7b..6987100 100644
--- a/qapi/common.json
+++ b/qapi/common.json
@@ -34,11 +34,11 @@
#
# A three-part version number.
#
-# @qemu.major: The major version number.
+# @major: The major version number.
#
-# @qemu.minor: The minor version number.
+# @minor: The minor version number.
#
-# @qemu.micro: The micro version number.
+# @micro: The micro version number.
#
# Since: 2.4
##
diff --git a/qapi/rocker.json b/qapi/rocker.json
index 2fe7fdf..ace2776 100644
--- a/qapi/rocker.json
+++ b/qapi/rocker.json
@@ -1,5 +1,5 @@
##
-# @Rocker:
+# @RockerSwitch:
#
# Rocker switch information.
#
diff --git a/qga/qapi-schema.json b/qga/qapi-schema.json
index 5173c4a..2e6cc91 100644
--- a/qga/qapi-schema.json
+++ b/qga/qapi-schema.json
@@ -203,7 +203,7 @@
#
# Open a file in the guest and retrieve a file handle for it
#
-# @filepath: Full path to the file in the guest to open.
+# @path: Full path to the file in the guest to open.
#
# @mode: #optional open mode, as per fopen(), "r" is the default.
#
@@ -378,7 +378,7 @@
'data': { 'handle': 'int' } }
##
-# @GuestFsFreezeStatus
+# @GuestFsfreezeStatus
#
# An enumeration of filesystem freeze states
#
@@ -766,7 +766,7 @@
# @GuestDiskAddress:
#
# @pci-controller: controller's PCI address
-# @type: bus type
+# @bus-type: bus type
# @bus: bus id
# @target: target id
# @unit: unit id
--
2.10.0
[Qemu-devel] [PATCH v4 10/15] docs: add master qapi texi files
The qapi2texi script generates a file to be included in a texi file. Add
"QEMU QMP Reference Manual" and "QEMU Guest Agent Protocol Reference"
master texi files.
Signed-off-by: Marc-André Lureau
---
docs/qemu-ga-ref.texi | 78 ++
docs/qemu-qmp-ref.texi | 78 ++
2 files changed, 156 insertions(+)
create mode 100644 docs/qemu-ga-ref.texi
create mode 100644 docs/qemu-qmp-ref.texi
diff --git a/docs/qemu-ga-ref.texi b/docs/qemu-ga-ref.texi
new file mode 100644
index 000..02ecdb7
--- /dev/null
+++ b/docs/qemu-ga-ref.texi
@@ -0,0 +1,78 @@
+\input texinfo
+@setfilename qemu-ga-ref.info
+
+@exampleindent 0
+@paragraphindent 0
+
+@settitle QEMU Guest Agent Protocol Reference
+
+@copying
+This is the QEMU Guest Agent Protocol reference manual.
+
+Copyright @copyright{} 2016 The QEMU Project developers
+
+@quotation
+This manual is free documentation: you can redistribute it and/or
+modify it under the terms of the GNU General Public License as
+published by the Free Software Foundation, either version 2 of the
+License, or (at your option) any later version.
+
+This manual is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this manual. If not, see http://www.gnu.org/licenses/.
+@end quotation
+@end copying
+
+@dircategory QEMU
+@direntry
+* QEMU-GA-Ref: (qemu-ga-ref). QEMU Guest Agent Protocol Reference
+@end direntry
+
+@titlepage
+@title Guest Agent Protocol Reference Manual
+@subtitle QEMU version @value{VERSION}
+@page
+@vskip 0pt plus 1filll
+@insertcopying
+@end titlepage
+
+@contents
+
+@ifnottex
+@node Top
+@top QEMU Guest Agent protocol reference
+@end ifnottex
+
+@menu
+* API Reference::
+* Commands and Events Index::
+* Data Types Index::
+@end menu
+
+@node API Reference
+@chapter API Reference
+
+@c for texi2pod:
+@c man begin DESCRIPTION
+
+@include qemu-ga-qapi.texi
+
+@c man end
+
+@c man begin SEEALSO
+The HTML documentation of QEMU for more information.
+@c man end
+
+@node Commands and Events Index
+@unnumbered Commands and Events Index
+@printindex fn
+
+@node Data Types Index
+@unnumbered Data Types Index
+@printindex tp
+
+@bye
diff --git a/docs/qemu-qmp-ref.texi b/docs/qemu-qmp-ref.texi
new file mode 100644
index 000..ccc03cb
--- /dev/null
+++ b/docs/qemu-qmp-ref.texi
@@ -0,0 +1,78 @@
+\input texinfo
+@setfilename qemu-qmp-ref.info
+
+@exampleindent 0
+@paragraphindent 0
+
+@settitle QEMU QMP Reference Manual
+
+@copying
+This is the QEMU QMP reference manual.
+
+Copyright @copyright{} 2016 The QEMU Project developers
+
+@quotation
+This manual is free documentation: you can redistribute it and/or
+modify it under the terms of the GNU General Public License as
+published by the Free Software Foundation, either version 2 of the
+License, or (at your option) any later version.
+
+This manual is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this manual. If not, see http://www.gnu.org/licenses/.
+@end quotation
+@end copying
+
+@dircategory QEMU
+@direntry
+* QEMU-QMP-Ref: (qemu-qmp-ref). QEMU QMP Reference Manual
+@end direntry
+
+@titlepage
+@title QMP Reference Manual
+@subtitle QEMU version @value{VERSION}
+@page
+@vskip 0pt plus 1filll
+@insertcopying
+@end titlepage
+
+@contents
+
+@ifnottex
+@node Top
+@top QEMU QMP reference
+@end ifnottex
+
+@menu
+* API Reference::
+* Commands and Events Index::
+* Data Types Index::
+@end menu
+
+@node API Reference
+@chapter API Reference
+
+@c for texi2pod:
+@c man begin DESCRIPTION
+
+@include qemu-qapi.texi
+
+@c man end
+
+@c man begin SEEALSO
+The HTML documentation of QEMU for more information.
+@c man end
+
+@node Commands and Events Index
+@unnumbered Commands and Events Index
+@printindex fn
+
+@node Data Types Index
+@unnumbered Data Types Index
+@printindex tp
+
+@bye
--
2.10.0
[Qemu-devel] [PATCH for-2.8] megasas: clean up and fix request completion/cancellation
megasas_command_cancel is a callback; it should report the abort in
the frame, not try another abort! Compare for instance with
mptsas_request_cancelled.
So extract the common bits for request completion in a new function
megasas_complete_command, call it from both the .complete and .cancel
callbacks, and remove duplicate pieces from the DCMD path.
Signed-off-by: Paolo Bonzini
---
hw/scsi/megasas.c | 53 -
1 file changed, 28 insertions(+), 25 deletions(-)
diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
index ca62952..67fc1e7 100644
--- a/hw/scsi/megasas.c
+++ b/hw/scsi/megasas.c
@@ -300,12 +300,6 @@ unmap:
return iov_count - i;
}
-static void megasas_unmap_sgl(MegasasCmd *cmd)
-{
-qemu_sglist_destroy(&cmd->qsg);
-cmd->iov_offset = 0;
-}
-
/*
* passthrough sense and io sense are at the same offset
*/
@@ -580,6 +574,20 @@ static void megasas_complete_frame(MegasasState *s,
uint64_t context)
}
}
+static void megasas_complete_command(MegasasCmd *cmd)
+{
+qemu_sglist_destroy(&cmd->qsg);
+cmd->iov_size = 0;
+cmd->iov_offset = 0;
+
+cmd->req->hba_private = NULL;
+scsi_req_unref(cmd->req);
+cmd->req = NULL;
+
+megasas_unmap_frame(cmd->state, cmd);
+megasas_complete_frame(cmd->state, cmd->context);
+}
+
static void megasas_reset_frames(MegasasState *s)
{
int i;
@@ -596,9 +604,9 @@ static void megasas_reset_frames(MegasasState *s)
static void megasas_abort_command(MegasasCmd *cmd)
{
-if (cmd->req) {
+/* Never abort internal commands. */
+if (cmd->req != NULL) {
scsi_req_cancel(cmd->req);
-cmd->req = NULL;
}
}
@@ -689,9 +697,6 @@ static void megasas_finish_dcmd(MegasasCmd *cmd, uint32_t
iov_size)
{
trace_megasas_finish_dcmd(cmd->index, iov_size);
-if (cmd->frame->header.sge_count) {
-qemu_sglist_destroy(&cmd->qsg);
-}
if (iov_size > cmd->iov_size) {
if (megasas_frame_is_ieee_sgl(cmd)) {
cmd->frame->dcmd.sgl.sg_skinny->len = cpu_to_le32(iov_size);
@@ -701,7 +706,6 @@ static void megasas_finish_dcmd(MegasasCmd *cmd, uint32_t
iov_size)
cmd->frame->dcmd.sgl.sg32->len = cpu_to_le32(iov_size);
}
}
-cmd->iov_size = 0;
}
static int megasas_ctrl_get_info(MegasasState *s, MegasasCmd *cmd)
@@ -1589,7 +1593,6 @@ static int megasas_finish_internal_dcmd(MegasasCmd *cmd,
int lun = req->lun;
opcode = le32_to_cpu(cmd->frame->dcmd.opcode);
-scsi_req_unref(req);
trace_megasas_dcmd_internal_finish(cmd->index, opcode, lun);
switch (opcode) {
case MFI_DCMD_PD_GET_INFO:
@@ -1860,7 +1863,11 @@ static void megasas_command_complete(SCSIRequest *req,
uint32_t status,
trace_megasas_command_complete(cmd->index, status, resid);
-if (cmd->req != req) {
+if (req->io_canceled) {
+return;
+}
+
+if (cmd->req == NULL) {
/*
* Internal command complete
*/
@@ -1879,25 +1886,21 @@ static void megasas_command_complete(SCSIRequest *req,
uint32_t status,
megasas_copy_sense(cmd);
}
-megasas_unmap_sgl(cmd);
cmd->frame->header.scsi_status = req->status;
-scsi_req_unref(cmd->req);
-cmd->req = NULL;
}
cmd->frame->header.cmd_status = cmd_status;
-megasas_unmap_frame(cmd->state, cmd);
-megasas_complete_frame(cmd->state, cmd->context);
+megasas_complete_command(cmd);
}
-static void megasas_command_cancel(SCSIRequest *req)
+static void megasas_command_cancelled(SCSIRequest *req)
{
MegasasCmd *cmd = req->hba_private;
-if (cmd) {
-megasas_abort_command(cmd);
-} else {
-scsi_req_unref(req);
+if (!cmd) {
+return;
}
+cmd->frame->header.cmd_status = MFI_STAT_SCSI_IO_FAILED;
+megasas_complete_command(cmd);
}
static int megasas_handle_abort(MegasasState *s, MegasasCmd *cmd)
@@ -2316,7 +2319,7 @@ static const struct SCSIBusInfo megasas_scsi_info = {
.transfer_data = megasas_xfer_complete,
.get_sg_list = megasas_get_sg_list,
.complete = megasas_command_complete,
-.cancel = megasas_command_cancel,
+.cancel = megasas_command_cancelled,
};
static void megasas_scsi_realize(PCIDevice *dev, Error **errp)
--
2.9.3
Re: [Qemu-devel] [PATCH v4 14/15] docs: add qemu logo
On Thu, Nov 10, 2016 at 07:22:08PM +0400, Marc-André Lureau wrote: > The pdf (needed by texi2pdf for vectorized images) was generated thanks > to inkscape, from the pc-bios/qemu_logo.svg file. Move the original file > in the docs folder too, since it's not being referenced elsewhere. I don't think we should be moving the qemu_logo.svg file. The pc-bios has 3 other logo files qemu_logo_no_text.svg, qemu-icon.bmp and qemu-nsis.ico. Having those three logo files in pc-bios, and the other file in docs/ is unhelpful. IMHO they should all live together, either all in docs/ or all in pc-bios/ I'd probably pick docs/ as its a bit strange to be looking for logos in a bios sub-dir Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o-http://search.cpan.org/~danberr/ :|
Re: [Qemu-devel] [PATCHv2 3/3] Split ISA and sysbus versions of m48t59 device
- Original Message - > From: "Mark Cave-Ayland" > To: "Paolo Bonzini" , "David Gibson" > , "edgar iglesias" > , mich...@walle.cc, pro...@gmail.com, > borntrae...@de.ibm.com, "cornelia huck" > , kbast...@mail.uni-paderborn.de, jcmvb...@gmail.com > Cc: veroniaba...@gmail.com, "peter maydell" , > m...@redhat.com, arm...@redhat.com, > qemu-devel@nongnu.org, ag...@suse.de > Sent: Thursday, November 10, 2016 4:16:36 PM > Subject: Re: [Qemu-devel] [PATCHv2 3/3] Split ISA and sysbus versions of > m48t59 device > > On 10/11/16 14:57, Paolo Bonzini wrote: > > > > > > On 09/11/2016 13:22, David Gibson wrote: > >> The m48t59 device supports both ISA and direct sysbus attached versions of > >> the device in the one .c file. This can be awkward for some embedded > >> machine types which need the sysbus M48T59, but don't want to pull in the > >> ISA bus code and its other dependencies. > >> > >> Therefore, this patch splits out the code for the ISA attached M48T59 into > >> its own C file. It will be built when both CONFIG_M48T59 and > >> CONFIG_ISA_BUS are enabled. > >> > >> Signed-off-by: David Gibson > > > > Who needs the ISA M48T59? Perhaps it should be a separate symbol > > altogether. Let's document that SPARC will stop providing it in 2.9, > > for example, if it's only a PReP thing. > > > > Paolo > > Hi Paolo, > > The ISA M48T59 is still actively used by the sun4u machine on > qemu-system-sparc64. In real terms it's actually connected to the ebus, > but for all intents and purposes it's the same as an ISA bus connected > via a PCI bridge. sun4u is actually using the sysbus M48T59, and mapping it into the ebus space: nvram = m48t59_init(NULL, 0, 0, NVRAM_SIZE, 1968, 59); s = SYS_BUS_DEVICE(nvram); memory_region_add_subregion(get_system_io(), 0x2000, sysbus_mmio_get_region(s, 0)); Paolo
Re: [Qemu-devel] [PULL for-2.8 0/1] ipxe: update to 20161108 snapshot.
On Thu, Nov 10, 2016 at 2:10 PM, Laszlo Ersek wrote: > On 11/10/16 11:48, Stefan Hajnoczi wrote: >> On Wed, Nov 09, 2016 at 10:09:24AM +0100, Gerd Hoffmann wrote: >>> Hi, >>> >>> This rebases ipxe to latest master. ipxe qemu builds will not use >>> fxsave/fxrestore any more, which caused problems on older intel cpus >>> due to kvm not emulating these instructions. >>> >>> Special thanks to Laszlo for pushing these patches to ipxe upstream, >>> they finally landed in ipxe master yesterday. >>> >>> please pull, >>> Gerd >>> >>> The following changes since commit 207faf24c58859f5240f66bf6decc33b87a1776e: >>> >>> Merge remote-tracking branch 'pm215/tags/pull-target-arm-20161107' into >>> staging (2016-11-07 14:02:15 +) >>> >>> are available in the git repository at: >>> >>> >>> git://git.kraxel.org/qemu tags/pull-ipxe-20161109-1 >>> >>> for you to fetch changes up to 129fa54c734f4dbaf8d3bb9ca47283a2add2e4dc: >>> >>> ipxe: update to 20161108 snapshot (2016-11-09 09:49:33 +0100) >>> >>> >>> ipxe: update to 20161108 snapshot. >>> >>> >>> Gerd Hoffmann (1): >>> ipxe: update to 20161108 snapshot >>> >>> pc-bios/efi-e1000.rom| Bin 209408 -> 209920 bytes >>> pc-bios/efi-e1000e.rom | Bin 209408 -> 209920 bytes >>> pc-bios/efi-eepro100.rom | Bin 209920 -> 209920 bytes >>> pc-bios/efi-ne2k_pci.rom | Bin 208384 -> 208896 bytes >>> pc-bios/efi-pcnet.rom| Bin 208384 -> 208896 bytes >>> pc-bios/efi-rtl8139.rom | Bin 211456 -> 212480 bytes >>> pc-bios/efi-virtio.rom | Bin 211456 -> 212480 bytes >>> pc-bios/efi-vmxnet3.rom | Bin 205312 -> 206848 bytes >>> roms/ipxe| 2 +- >>> 9 files changed, 1 insertion(+), 1 deletion(-) >>> >> >> Thanks, applied to my staging tree: >> https://github.com/stefanha/qemu/commits/staging >> >> Stefan >> > > Thank you, Gerd and Stefan. > > Stefan, if your staging tree is eligible for rebasing, I propose to add > the following pointers to the commit message (on patch #1): > > Ref: https://bugs.archlinux.org/task/50778 > Ref: https://bugs.launchpad.net/qemu/+bug/1623276 > Ref: https://bugzilla.proxmox.com/show_bug.cgi?id=1182 > Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1356762 Sorry, it's too late. I've already pushed the staging tree to master. BTW I will not modify commits from pull requests. Gerd would have had to send a v2. That way the merge is bit-for-bit the tree from the pull request. Stefan
Re: [Qemu-devel] [PATCH v6 0/3] IOMMU: intel_iommu support map and unmap notifications
On Thu, 10 Nov 2016 17:14:24 +0200 "Michael S. Tsirkin" wrote: > On Tue, Nov 08, 2016 at 01:04:21PM +0200, Aviv B.D wrote: > > From: "Aviv Ben-David" > > > > * Advertize Cache Mode capability in iommu cap register. > > This capability is controlled by "cache-mode" property of intel-iommu > > device. > > To enable this option call QEMU with "-device > > intel-iommu,cache-mode=true". > > > > * On page cache invalidation in intel vIOMMU, check if the domain belong to > > registered notifier, and notify accordingly. > > This looks sane I think. Alex, care to comment? > Merging will have to wait until after the release. > Pls remember to re-test and re-ping then. I don't think it's suitable for upstream until there's a reasonable replay mechanism and we straighten out whether it's expected to get multiple notifies and the notif-ee is responsible for filtering them or if the notif-er should do filtering. Without those, this is effectively just an RFC. Thanks, Alex > > Currently this patch still doesn't enabling VFIO devices support with > > vIOMMU > > present. Current problems: > > * vfio_iommu_map_notify is not aware about memory range belong to specific > > VFIOGuestIOMMU. > > * memory_region_iommu_replay hangs QEMU on start up while it itterate over > > 64bit address space. Commenting out the call to this function enables > > workable VFIO device while vIOMMU present. > > * vfio_iommu_map_notify should check if address space range is suitable for > > current notifier. > > > > Changes from v1 to v2: > > * remove assumption that the cache do not clears > > * fix lockup on high load. > > > > Changes from v2 to v3: > > * remove debug leftovers > > * split to sepearate commits > > * change is_write to flags in vtd_do_iommu_translate, add IOMMU_NO_FAIL > > to suppress error propagating to guest. > > > > Changes from v3 to v4: > > * Add property to intel_iommu device to control the CM capability, > > default to False. > > * Use s->iommu_ops.notify_flag_changed to register notifiers. > > > > Changes from v4 to v4 RESEND: > > * Fix codding style pointed by checkpatch.pl script. > > > > Changes from v4 to v5: > > * Reduce the number of changes in patch 2 and make flags real bitfield. > > * Revert deleted debug prints. > > * Fix memory leak in patch 3. > > > > Changes from v5 to v6: > > * fix prototype of iommu_translate function for more IOMMU types. > > * VFIO will be notified only on the difference, without unmap > > before change to maps. > > > > Aviv Ben-David (3): > > IOMMU: add option to enable VTD_CAP_CM to vIOMMU capility exposoed to > > guest > > IOMMU: change iommu_op->translate's is_write to flags, add support to > > NO_FAIL flag mode > > IOMMU: enable intel_iommu map and unmap notifiers > > > > exec.c | 3 +- > > hw/alpha/typhoon.c | 2 +- > > hw/i386/amd_iommu.c| 4 +- > > hw/i386/intel_iommu.c | 160 > > + > > hw/i386/intel_iommu_internal.h | 3 + > > hw/pci-host/apb.c | 2 +- > > hw/ppc/spapr_iommu.c | 2 +- > > hw/s390x/s390-pci-bus.c| 2 +- > > include/exec/memory.h | 6 +- > > include/hw/i386/intel_iommu.h | 11 +++ > > memory.c | 3 +- > > 11 files changed, 160 insertions(+), 38 deletions(-) > > > > -- > > 1.9.1 >
Re: [Qemu-devel] [PATCH v6 0/3] IOMMU: intel_iommu support map and unmap notifications
On Thu, Nov 10, 2016 at 08:30:21AM -0700, Alex Williamson wrote: > On Thu, 10 Nov 2016 17:14:24 +0200 > "Michael S. Tsirkin" wrote: > > > On Tue, Nov 08, 2016 at 01:04:21PM +0200, Aviv B.D wrote: > > > From: "Aviv Ben-David" > > > > > > * Advertize Cache Mode capability in iommu cap register. > > > This capability is controlled by "cache-mode" property of intel-iommu > > > device. > > > To enable this option call QEMU with "-device > > > intel-iommu,cache-mode=true". > > > > > > * On page cache invalidation in intel vIOMMU, check if the domain belong > > > to > > > registered notifier, and notify accordingly. > > > > This looks sane I think. Alex, care to comment? > > Merging will have to wait until after the release. > > Pls remember to re-test and re-ping then. > > I don't think it's suitable for upstream until there's a reasonable > replay mechanism Could you pls clarify what do you mean by replay? Is this when you attach a device by hotplug to a running system? If yes this can maybe be addressed by disabling hotplug temporarily. > and we straighten out whether it's expected to get > multiple notifies and the notif-ee is responsible for filtering > them or if the notif-er should do filtering. OK this is a documentation thing. > Without those, this is > effectively just an RFC. It's infrastructure without users so it doesn't break things, I'm more interested in seeing whether it's broken in some way than whether it's complete. The patchset spent out of tree too long and I'd like to see us make progress towards device assignment working with vIOMMU sooner rather than later, so if it's broken I won't merge it but if it's incomplete I will. > Thanks, > > Alex > > > > Currently this patch still doesn't enabling VFIO devices support with > > > vIOMMU > > > present. Current problems: > > > * vfio_iommu_map_notify is not aware about memory range belong to > > > specific > > > VFIOGuestIOMMU. > > > * memory_region_iommu_replay hangs QEMU on start up while it itterate > > > over > > > 64bit address space. Commenting out the call to this function enables > > > workable VFIO device while vIOMMU present. > > > * vfio_iommu_map_notify should check if address space range is suitable > > > for > > > current notifier. > > > > > > Changes from v1 to v2: > > > * remove assumption that the cache do not clears > > > * fix lockup on high load. > > > > > > Changes from v2 to v3: > > > * remove debug leftovers > > > * split to sepearate commits > > > * change is_write to flags in vtd_do_iommu_translate, add IOMMU_NO_FAIL > > > to suppress error propagating to guest. > > > > > > Changes from v3 to v4: > > > * Add property to intel_iommu device to control the CM capability, > > > default to False. > > > * Use s->iommu_ops.notify_flag_changed to register notifiers. > > > > > > Changes from v4 to v4 RESEND: > > > * Fix codding style pointed by checkpatch.pl script. > > > > > > Changes from v4 to v5: > > > * Reduce the number of changes in patch 2 and make flags real bitfield. > > > * Revert deleted debug prints. > > > * Fix memory leak in patch 3. > > > > > > Changes from v5 to v6: > > > * fix prototype of iommu_translate function for more IOMMU types. > > > * VFIO will be notified only on the difference, without unmap > > > before change to maps. > > > > > > Aviv Ben-David (3): > > > IOMMU: add option to enable VTD_CAP_CM to vIOMMU capility exposoed to > > > guest > > > IOMMU: change iommu_op->translate's is_write to flags, add support to > > > NO_FAIL flag mode > > > IOMMU: enable intel_iommu map and unmap notifiers > > > > > > exec.c | 3 +- > > > hw/alpha/typhoon.c | 2 +- > > > hw/i386/amd_iommu.c| 4 +- > > > hw/i386/intel_iommu.c | 160 > > > + > > > hw/i386/intel_iommu_internal.h | 3 + > > > hw/pci-host/apb.c | 2 +- > > > hw/ppc/spapr_iommu.c | 2 +- > > > hw/s390x/s390-pci-bus.c| 2 +- > > > include/exec/memory.h | 6 +- > > > include/hw/i386/intel_iommu.h | 11 +++ > > > memory.c | 3 +- > > > 11 files changed, 160 insertions(+), 38 deletions(-) > > > > > > -- > > > 1.9.1 > >
[Qemu-devel] [PATCH v4 12/15] texi2pod: learn quotation, deftp and deftypefn
Learn a few more markups used for API documentation.
Signed-off-by: Marc-André Lureau
---
scripts/texi2pod.pl | 44 +++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/scripts/texi2pod.pl b/scripts/texi2pod.pl
index 8767662..5df4b5f 100755
--- a/scripts/texi2pod.pl
+++ b/scripts/texi2pod.pl
@@ -37,6 +37,7 @@ $inf = "";
$ibase = "";
@ipath = ();
$encoding = undef;
+@args = ();
while ($_ = shift) {
if (/^-D(.*)$/) {
@@ -162,7 +163,8 @@ while(<$inf>) {
if ($ended =~ /^(?:ifset|ifclear|ignore|menu|iftex)$/) {
$skipping = pop @skstack;
next;
- } elsif ($ended =~ /^(?:example|smallexample|display)$/) {
+ } elsif ($ended =~ /^(?:example|smallexample|display
+|quotation|deftp|deftypefn)$/x) {
$shift = "";
$_ = "";# need a paragraph break
} elsif ($ended =~ /^(?:itemize|enumerate|[fv]?table)$/) {
@@ -323,6 +325,46 @@ while(<$inf>) {
$_ = "\n=item ".join (" : ", @columns)."\n";
};
+/^\@(quotation)\s*(.+)?$/ and do {
+push @endwstack, $endw;
+$endw = $1;
+$_ = "\n$2:"
+};
+
+/^{(.*)}$|^(.*)$/ and $#args > 0 and do {
+$kind = $args[0];
+$arguments = $1 // "";
+if ($endw eq "deftypefn") {
+$ret = $args[1];
+$fname = "B<$args[2]>";
+$_ = $ret ? "$ret " : "";
+$_ .= "$fname $arguments ($kind)";
+} else {
+$_ = "B<$args[1]> ($kind)\n\n$arguments";
+}
+@args = ();
+};
+
+/^\@(deftp)\s*(.+)?$/ and do {
+push @endwstack, $endw;
+$endw = $1;
+$arg = $2;
+$arg =~ s/{([^}]*)}/$1/g;
+$arg =~ s/\@$//;
+@args = split (/ /, $arg);
+$_ = "";
+};
+
+/^\@(deftypefn)\s*(.+)?$/ and do {
+push @endwstack, $endw;
+$endw = $1;
+$arg = $2;
+$arg =~ s/{([^}]*)}/$1/g;
+$arg =~ s/\@$//;
+@args = split (/ /, $arg);
+$_ = "";
+};
+
/^\@itemx?\s*(.+)?$/ and do {
if (defined $1) {
# Entity escapes prevent munging by the <> processing below.
--
2.10.0
