[Qemu-devel] [PATCH 13/16] block: explicitly acquire aiocontext in aio callbacks that need it
Signed-off-by: Paolo Bonzini
---
block/archipelago.c| 3 ---
block/block-backend.c | 7 ---
block/curl.c | 2 +-
block/io.c | 6 +-
block/iscsi.c | 3 ---
block/linux-aio.c | 5 +
block/mirror.c | 12 +---
block/null.c | 8
block/qed-cluster.c| 2 ++
block/qed-table.c | 12 ++--
block/qed.c| 4 ++--
block/rbd.c| 4
block/win32-aio.c | 3 ---
hw/block/virtio-blk.c | 12 +++-
hw/scsi/scsi-disk.c| 15 +++
hw/scsi/scsi-generic.c | 20 +---
thread-pool.c | 4 +++-
17 files changed, 72 insertions(+), 50 deletions(-)
diff --git a/block/archipelago.c b/block/archipelago.c
index a624390..2449cfc 100644
--- a/block/archipelago.c
+++ b/block/archipelago.c
@@ -310,11 +310,8 @@ static void qemu_archipelago_complete_aio(void *opaque)
{
AIORequestData *reqdata = (AIORequestData *) opaque;
ArchipelagoAIOCB *aio_cb = (ArchipelagoAIOCB *) reqdata->aio_cb;
-AioContext *ctx = bdrv_get_aio_context(aio_cb->common.bs);
-aio_context_acquire(ctx);
aio_cb->common.cb(aio_cb->common.opaque, aio_cb->ret);
-aio_context_release(ctx);
aio_cb->status = 0;
qemu_aio_unref(aio_cb);
diff --git a/block/block-backend.c b/block/block-backend.c
index bfc0e6b..819f272 100644
--- a/block/block-backend.c
+++ b/block/block-backend.c
@@ -939,12 +939,9 @@ int blk_make_zero(BlockBackend *blk, BdrvRequestFlags
flags)
static void error_callback_bh(void *opaque)
{
struct BlockBackendAIOCB *acb = opaque;
-AioContext *ctx = bdrv_get_aio_context(acb->common.bs);
bdrv_dec_in_flight(acb->common.bs);
-aio_context_acquire(ctx);
acb->common.cb(acb->common.opaque, acb->ret);
-aio_context_release(ctx);
qemu_aio_unref(acb);
}
@@ -986,12 +983,8 @@ static void blk_aio_complete(BlkAioEmAIOCB *acb)
static void blk_aio_complete_bh(void *opaque)
{
BlkAioEmAIOCB *acb = opaque;
-AioContext *ctx = bdrv_get_aio_context(acb->common.bs);
-
assert(acb->has_returned);
-aio_context_acquire(ctx);
blk_aio_complete(acb);
-aio_context_release(ctx);
}
static BlockAIOCB *blk_aio_prwv(BlockBackend *blk, int64_t offset, int bytes,
diff --git a/block/curl.c b/block/curl.c
index f3f063b..2939cc7 100644
--- a/block/curl.c
+++ b/block/curl.c
@@ -854,11 +854,11 @@ static void curl_readv_bh_cb(void *p)
curl_multi_socket_action(s->multi, CURL_SOCKET_TIMEOUT, 0, &running);
out:
+aio_context_release(ctx);
if (ret != -EINPROGRESS) {
acb->common.cb(acb->common.opaque, ret);
qemu_aio_unref(acb);
}
-aio_context_release(ctx);
}
static BlockAIOCB *curl_aio_readv(BlockDriverState *bs,
diff --git a/block/io.c b/block/io.c
index 800fcf8..3a879cc 100644
--- a/block/io.c
+++ b/block/io.c
@@ -813,7 +813,7 @@ static void bdrv_co_io_em_complete(void *opaque, int ret)
CoroutineIOCompletion *co = opaque;
co->ret = ret;
-qemu_coroutine_enter(co->coroutine);
+aio_co_wake(co->coroutine);
}
static int coroutine_fn bdrv_driver_preadv(BlockDriverState *bs,
@@ -2147,13 +2147,9 @@ static void bdrv_co_complete(BlockAIOCBCoroutine *acb)
static void bdrv_co_em_bh(void *opaque)
{
BlockAIOCBCoroutine *acb = opaque;
-BlockDriverState *bs = acb->common.bs;
-AioContext *ctx = bdrv_get_aio_context(bs);
assert(!acb->need_bh);
-aio_context_acquire(ctx);
bdrv_co_complete(acb);
-aio_context_release(ctx);
}
static void bdrv_co_maybe_schedule_bh(BlockAIOCBCoroutine *acb)
diff --git a/block/iscsi.c b/block/iscsi.c
index 5de5d93..c19c838 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -136,16 +136,13 @@ static void
iscsi_bh_cb(void *p)
{
IscsiAIOCB *acb = p;
-AioContext *ctx = bdrv_get_aio_context(acb->common.bs);
qemu_bh_delete(acb->bh);
g_free(acb->buf);
acb->buf = NULL;
-aio_context_acquire(ctx);
acb->common.cb(acb->common.opaque, acb->status);
-aio_context_release(ctx);
if (acb->task != NULL) {
scsi_free_scsi_task(acb->task);
diff --git a/block/linux-aio.c b/block/linux-aio.c
index f7ae38a..88b8d55 100644
--- a/block/linux-aio.c
+++ b/block/linux-aio.c
@@ -75,7 +75,6 @@ static inline ssize_t io_event_ret(struct io_event *ev)
*/
static void qemu_laio_process_completion(struct qemu_laiocb *laiocb)
{
-LinuxAioState *s = laiocb->ctx;
int ret;
ret = laiocb->ret;
@@ -94,7 +93,6 @@ static void qemu_laio_process_completion(struct qemu_laiocb
*laiocb)
}
laiocb->ret = ret;
-aio_context_acquire(s->aio_context);
if (laiocb->co) {
/* If the coroutine is already entered it must be in ioq_submit() and
* will notice laio->ret has been filled in when it eventually runs
@@ -102,13 +100,12 @@ static void qemu_laio_process_completion(struct
qemu_laiocb *laiocb)
* that!
*/
if (!qemu
[Qemu-devel] [PATCH 15/16] async: remove unnecessary inc/dec pairs
Pull the increment/decrement pair out of aio_bh_poll and into the
callers.
Signed-off-by: Paolo Bonzini
---
aio-posix.c | 8 +++-
aio-win32.c | 8
async.c | 12 ++--
3 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/aio-posix.c b/aio-posix.c
index 51e92b8..2537bcd 100644
--- a/aio-posix.c
+++ b/aio-posix.c
@@ -425,9 +425,8 @@ static bool aio_dispatch_handlers(AioContext *ctx)
void aio_dispatch(AioContext *ctx)
{
-aio_bh_poll(ctx);
-
qemu_lockcnt_inc(&ctx->list_lock);
+aio_bh_poll(ctx);
aio_dispatch_handlers(ctx);
qemu_lockcnt_dec(&ctx->list_lock);
@@ -678,16 +677,15 @@ bool aio_poll(AioContext *ctx, bool blocking)
}
npfd = 0;
-qemu_lockcnt_dec(&ctx->list_lock);
progress |= aio_bh_poll(ctx);
if (ret > 0) {
-qemu_lockcnt_inc(&ctx->list_lock);
progress |= aio_dispatch_handlers(ctx);
-qemu_lockcnt_dec(&ctx->list_lock);
}
+qemu_lockcnt_dec(&ctx->list_lock);
+
progress |= timerlistgroup_run_timers(&ctx->tlg);
return progress;
diff --git a/aio-win32.c b/aio-win32.c
index 442a179..bca496a 100644
--- a/aio-win32.c
+++ b/aio-win32.c
@@ -253,8 +253,6 @@ static bool aio_dispatch_handlers(AioContext *ctx, HANDLE
event)
bool progress = false;
AioHandler *tmp;
-qemu_lockcnt_inc(&ctx->list_lock);
-
/*
* We have to walk very carefully in case aio_set_fd_handler is
* called while we're walking.
@@ -305,14 +303,15 @@ static bool aio_dispatch_handlers(AioContext *ctx, HANDLE
event)
}
}
-qemu_lockcnt_dec(&ctx->list_lock);
return progress;
}
void aio_dispatch(AioContext *ctx)
{
+qemu_lockcnt_inc(&ctx->list_lock);
aio_bh_poll(ctx);
aio_dispatch_handlers(ctx, INVALID_HANDLE_VALUE);
+qemu_lockcnt_dec(&ctx->list_lock);
timerlistgroup_run_timers(&ctx->tlg);
}
@@ -349,7 +348,6 @@ bool aio_poll(AioContext *ctx, bool blocking)
}
}
-qemu_lockcnt_dec(&ctx->list_lock);
first = true;
/* ctx->notifier is always registered. */
@@ -392,6 +390,8 @@ bool aio_poll(AioContext *ctx, bool blocking)
progress |= aio_dispatch_handlers(ctx, event);
} while (count > 0);
+qemu_lockcnt_dec(&ctx->list_lock);
+
progress |= timerlistgroup_run_timers(&ctx->tlg);
return progress;
}
diff --git a/async.c b/async.c
index 1839aa5..c471b1e 100644
--- a/async.c
+++ b/async.c
@@ -89,15 +89,16 @@ void aio_bh_call(QEMUBH *bh)
bh->cb(bh->opaque);
}
-/* Multiple occurrences of aio_bh_poll cannot be called concurrently */
+/* Multiple occurrences of aio_bh_poll cannot be called concurrently.
+ * The count in ctx->list_lock is incremented before the call, and is
+ * not affected by the call.
+ */
int aio_bh_poll(AioContext *ctx)
{
QEMUBH *bh, **bhp, *next;
int ret;
bool deleted = false;
-qemu_lockcnt_inc(&ctx->list_lock);
-
ret = 0;
for (bh = atomic_rcu_read(&ctx->first_bh); bh; bh = next) {
next = atomic_rcu_read(&bh->next);
@@ -122,11 +123,10 @@ int aio_bh_poll(AioContext *ctx)
/* remove deleted bhs */
if (!deleted) {
-qemu_lockcnt_dec(&ctx->list_lock);
return ret;
}
-if (qemu_lockcnt_dec_and_lock(&ctx->list_lock)) {
+if (qemu_lockcnt_dec_if_lock(&ctx->list_lock)) {
bhp = &ctx->first_bh;
while (*bhp) {
bh = *bhp;
@@ -137,7 +137,7 @@ int aio_bh_poll(AioContext *ctx)
bhp = &bh->next;
}
}
-qemu_lockcnt_unlock(&ctx->list_lock);
+qemu_lockcnt_inc_and_unlock(&ctx->list_lock);
}
return ret;
}
--
2.9.3
Re: [Qemu-devel] [PATCH 0/6] ppc: add a IBM 40p machine (RS/6000, PReP)
On Fri, Jan 13, 2017 at 1:23 PM, Mark Cave-Ayland wrote: > On 12/01/17 12:57, Hervé Poussineau wrote: > >> Le 11/01/2017 à 17:58, Artyom Tarasenko a écrit : >>> Hi Hervé, >>> >>> nice work! >>> >>> On Thu, Dec 29, 2016 at 11:12 PM, Hervé Poussineau >>> wrote: Hi, This patchset adds the emulation of the IBM RS/6000 7020 (40p). The real machine is able to run AIX (up to 4.3.3), Windows NT (up to 4.0 SP1), the beta of OS/2 PowerPC, Solaris, Linux, NetBSD/PReP ... I've tested current emulation with Open Hack'Ware, OpenBIOS and official firmware. Linux kernel starts, and freezes during boot (like with 'prep' machine). >> >> I already saw a regression during 2.7.0 cycle with 603 CPU. However, I >> was unable to provide kernel source, so Benjamin was unable to find the >> problem. >> http://lists.gnu.org/archive/html/qemu-devel/2016-08/msg03760.html >> >>> >>> If prep can't do it anymore, it looks like a regression. I definitely >>> remember seen a sitting penguin and a login prompt ~ 2 years ago. At >>> least with OFW. >>> Windows NT starts up to the point where it wants to change endianness. >>> >>> I hit that with Solaris/PPC a few years back as you published your >>> previous attempt. Do you know what is missing? I guess CPU endianness >>> switch emulation is working because it is used in the newer POWER >>> CPUs. Is it just the systemIO which has to be improved, or is it more? >> >> Yes, PReP System I/O has LE flag which is not implemented. >> You may be interested by >> ftp://ftp.software.ibm.com/rs6000/technology/spec/endian.ps >> which deals about endianness switching, with some code from Windows NT/PPC >> >>> Other OSes have not been tested. This machine is a superset of the 'prep' one, because we know exactly what is/should emulated, and that operating system list running on it is quite wide. I hope that 'prep' machine can be deprecated soon and then later removed. >>> >>> Would be nice to keep 'prep' until the 40p can boot Linux and NetBSD >>> 6.1.3 (this version used to work with -M prep last time I checked). >> >> Some Linux kernels seem to work, some other ones seem to not work (hang >> while booting) >> I've not searched why. >> >> I tried NetBSD 6.1.3/PReP. >> cdroms/harddisks don't boot anymore with Open Hack'Ware since some >> changes in IDE core >> Kernel boots better with 40p than with prep >> >> >> prep: >> >> Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, >> 2006, 2007, 2008, 2009, 2010, 2011, 2012 >> The NetBSD Foundation, Inc. All rights reserved. >> Copyright (c) 1982, 1986, 1989, 1991, 1993 >> The Regents of the University of California. All rights reserved. >> >> NetBSD 6.1.3 (INSTALL) >> Model: Qemu >> total memory = 128 MB >> avail memory = 119 MB >> panic: call to null-ptr from 0x0 >> >> The operating system has halted. >> Please press any key to reboot. >> >> >> 40p/Open Hack'Ware: >> >> Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, >> 2006, 2007, 2008, 2009, 2010, 2011, 2012 >> The NetBSD Foundation, Inc. All rights reserved. >> Copyright (c) 1982, 1986, 1989, 1991, 1993 >> The Regents of the University of California. All rights reserved. >> >> NetBSD 6.1.3 (INSTALL) >> Model: Qemu >> total memory = 128 MB >> avail memory = 119 MB >> mainbus0 (root) >> cpu0 at mainbus0: 604 (Revision 1.3), ID 0 (primary) >> cpu0: HID0 0xc084, powersave: 1 >> cpu0: 0.00 MHz >> Couldn't find PNP data for bus 0 devfunc 0x0 >> pnpbus0 at mainbus0 >> pci0 at mainbus0 bus 0: indirect configuration space access >> pchb0 at pci0 dev 0 function 0 >> pchb0: vendor 0x1057 product 0x4801 (rev. 0x00) >> siop0 at pci0 dev 1 function 0: Symbios Logic 53c810 (fast scsi) >> siop0: couldn't map interrupt >> vga0 at pci0 dev 2 function 0: vendor 0x1234 product 0x (rev. 0x02) >> wsdisplay0 at vga0 (kbdmux ignored) >> drm at vga0 not configured >> pcn0 at pci0 dev 3 function 0: AMD PCnet-PCI Ethernet >> pcn0: Am79c970A PCnet-PCI II rev 0, Ethernet address 52:54:00:12:34:56 >> pcn0: unable to map interrupt >> pcib0 at pci0 dev 11 function 0: vendor 0x8086 product 0x0484 (rev. 0x03) >> isa0 at pcib0 >> com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo >> com0: console >> com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo >> pckbc0 at isa0 port 0x60-0x64 >> pckbd0 at pckbc0 (kbd slot) >> pckbc0: using irq 1 for kbd slot >> wskbd0 at pckbd0 (mux ignored) >> vmmask 1000 schedmask 1000 highmask 7000 >> boot device: mainbus0 >> root on md0a dumps on md0b >> root file system type: ffs >> WARNING: no TOD clock present >> WARNING: using filesystem time >> WARNING: CHECK AND RESET THE DATE! >> erase ^H, werase ^W, kill ^U, intr ^C, status ^T >> Terminal type? [vt100] >> >> =
[Qemu-devel] [PATCH 09/16] aio: push aio_context_acquire/release down to dispatching
The AioContext data structures are now protected by list_lock and/or
they are walked with FOREACH_RCU primitives. There is no need anymore
to acquire the AioContext for the entire duration of aio_dispatch.
Instead, just acquire it before and after invoking the callbacks.
The next step is then to push it further down.
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Paolo Bonzini
---
aio-posix.c | 25 +++--
aio-win32.c | 15 +++
async.c | 2 ++
3 files changed, 20 insertions(+), 22 deletions(-)
diff --git a/aio-posix.c b/aio-posix.c
index 9453d83..3fd64fb 100644
--- a/aio-posix.c
+++ b/aio-posix.c
@@ -402,7 +402,9 @@ static bool aio_dispatch_handlers(AioContext *ctx)
(revents & (G_IO_IN | G_IO_HUP | G_IO_ERR)) &&
aio_node_check(ctx, node->is_external) &&
node->io_read) {
+aio_context_acquire(ctx);
node->io_read(node->opaque);
+aio_context_release(ctx);
/* aio_notify() does not count as progress */
if (node->opaque != &ctx->notifier) {
@@ -413,7 +415,9 @@ static bool aio_dispatch_handlers(AioContext *ctx)
(revents & (G_IO_OUT | G_IO_ERR)) &&
aio_node_check(ctx, node->is_external) &&
node->io_write) {
+aio_context_acquire(ctx);
node->io_write(node->opaque);
+aio_context_release(ctx);
progress = true;
}
@@ -450,7 +454,9 @@ bool aio_dispatch(AioContext *ctx, bool dispatch_fds)
}
/* Run our timers */
+aio_context_acquire(ctx);
progress |= timerlistgroup_run_timers(&ctx->tlg);
+aio_context_release(ctx);
return progress;
}
@@ -596,9 +602,6 @@ bool aio_poll(AioContext *ctx, bool blocking)
int64_t timeout;
int64_t start = 0;
-aio_context_acquire(ctx);
-progress = false;
-
/* aio_notify can avoid the expensive event_notifier_set if
* everything (file descriptors, bottom halves, timers) will
* be re-evaluated before the next blocking poll(). This is
@@ -616,9 +619,11 @@ bool aio_poll(AioContext *ctx, bool blocking)
start = qemu_clock_get_ns(QEMU_CLOCK_REALTIME);
}
-if (try_poll_mode(ctx, blocking)) {
-progress = true;
-} else {
+aio_context_acquire(ctx);
+progress = try_poll_mode(ctx, blocking);
+aio_context_release(ctx);
+
+if (!progress) {
assert(npfd == 0);
/* fill pollfds */
@@ -635,9 +640,6 @@ bool aio_poll(AioContext *ctx, bool blocking)
timeout = blocking ? aio_compute_timeout(ctx) : 0;
/* wait until next event */
-if (timeout) {
-aio_context_release(ctx);
-}
if (aio_epoll_check_poll(ctx, pollfds, npfd, timeout)) {
AioHandler epoll_handler;
@@ -649,9 +651,6 @@ bool aio_poll(AioContext *ctx, bool blocking)
} else {
ret = qemu_poll_ns(pollfds, npfd, timeout);
}
-if (timeout) {
-aio_context_acquire(ctx);
-}
}
if (blocking) {
@@ -716,8 +715,6 @@ bool aio_poll(AioContext *ctx, bool blocking)
progress = true;
}
-aio_context_release(ctx);
-
return progress;
}
diff --git a/aio-win32.c b/aio-win32.c
index 900524c..ab6d0e5 100644
--- a/aio-win32.c
+++ b/aio-win32.c
@@ -266,7 +266,9 @@ static bool aio_dispatch_handlers(AioContext *ctx, HANDLE
event)
(revents || event_notifier_get_handle(node->e) == event) &&
node->io_notify) {
node->pfd.revents = 0;
+aio_context_acquire(ctx);
node->io_notify(node->e);
+aio_context_release(ctx);
/* aio_notify() does not count as progress */
if (node->e != &ctx->notifier) {
@@ -278,11 +280,15 @@ static bool aio_dispatch_handlers(AioContext *ctx, HANDLE
event)
(node->io_read || node->io_write)) {
node->pfd.revents = 0;
if ((revents & G_IO_IN) && node->io_read) {
+aio_context_acquire(ctx);
node->io_read(node->opaque);
+aio_context_release(ctx);
progress = true;
}
if ((revents & G_IO_OUT) && node->io_write) {
+aio_context_acquire(ctx);
node->io_write(node->opaque);
+aio_context_release(ctx);
progress = true;
}
@@ -329,7 +335,6 @@ bool aio_poll(AioContext *ctx, bool blocking)
int count;
int timeout;
-aio_context_acquire(ctx);
progress = false;
/* aio_notify can avoid the expensive event_notifier_set if
@@ -371,17 +376,11 @@ bool aio_poll(AioContext *ctx, bool blocking)
timeout = blocking && !have_select_revents
? qemu_timeout_ns_to_ms(aio_compute_timeout(ctx)) : 0;
-if (timeout) {
-aio_context_release(ctx);
-}
ret = WaitForMultipleObjects(count, events,
[Qemu-devel] [PATCH 14/16] aio-posix: partially inline aio_dispatch into aio_poll
This patch prepares for the removal of unnecessary lockcnt inc/dec pairs.
Extract the dispatching loop for file descriptor handlers into a new
function aio_dispatch_handlers, and then inline aio_dispatch into
aio_poll.
aio_dispatch can now become void.
Signed-off-by: Paolo Bonzini
---
aio-posix.c | 44 ++--
aio-win32.c | 13 -
async.c | 2 +-
include/block/aio.h | 6 +-
4 files changed, 20 insertions(+), 45 deletions(-)
diff --git a/aio-posix.c b/aio-posix.c
index 6beebcd..51e92b8 100644
--- a/aio-posix.c
+++ b/aio-posix.c
@@ -386,12 +386,6 @@ static bool aio_dispatch_handlers(AioContext *ctx)
AioHandler *node, *tmp;
bool progress = false;
-/*
- * We have to walk very carefully in case aio_set_fd_handler is
- * called while we're walking.
- */
-qemu_lockcnt_inc(&ctx->list_lock);
-
QLIST_FOREACH_SAFE_RCU(node, &ctx->aio_handlers, node, tmp) {
int revents;
@@ -426,33 +420,18 @@ static bool aio_dispatch_handlers(AioContext *ctx)
}
}
-qemu_lockcnt_dec(&ctx->list_lock);
return progress;
}
-/*
- * Note that dispatch_fds == false has the side-effect of post-poning the
- * freeing of deleted handlers.
- */
-bool aio_dispatch(AioContext *ctx, bool dispatch_fds)
+void aio_dispatch(AioContext *ctx)
{
-bool progress;
-
-/*
- * If there are callbacks left that have been queued, we need to call them.
- * Do not call select in this case, because it is possible that the caller
- * does not need a complete flush (as is the case for aio_poll loops).
- */
-progress = aio_bh_poll(ctx);
+aio_bh_poll(ctx);
-if (dispatch_fds) {
-progress |= aio_dispatch_handlers(ctx);
-}
-
-/* Run our timers */
-progress |= timerlistgroup_run_timers(&ctx->tlg);
+qemu_lockcnt_inc(&ctx->list_lock);
+aio_dispatch_handlers(ctx);
+qemu_lockcnt_dec(&ctx->list_lock);
-return progress;
+timerlistgroup_run_timers(&ctx->tlg);
}
/* These thread-local variables are used only in a small part of aio_poll
@@ -701,11 +680,16 @@ bool aio_poll(AioContext *ctx, bool blocking)
npfd = 0;
qemu_lockcnt_dec(&ctx->list_lock);
-/* Run dispatch even if there were no readable fds to run timers */
-if (aio_dispatch(ctx, ret > 0)) {
-progress = true;
+progress |= aio_bh_poll(ctx);
+
+if (ret > 0) {
+qemu_lockcnt_inc(&ctx->list_lock);
+progress |= aio_dispatch_handlers(ctx);
+qemu_lockcnt_dec(&ctx->list_lock);
}
+progress |= timerlistgroup_run_timers(&ctx->tlg);
+
return progress;
}
diff --git a/aio-win32.c b/aio-win32.c
index 20b63ce..442a179 100644
--- a/aio-win32.c
+++ b/aio-win32.c
@@ -309,16 +309,11 @@ static bool aio_dispatch_handlers(AioContext *ctx, HANDLE
event)
return progress;
}
-bool aio_dispatch(AioContext *ctx, bool dispatch_fds)
+void aio_dispatch(AioContext *ctx)
{
-bool progress;
-
-progress = aio_bh_poll(ctx);
-if (dispatch_fds) {
-progress |= aio_dispatch_handlers(ctx, INVALID_HANDLE_VALUE);
-}
-progress |= timerlistgroup_run_timers(&ctx->tlg);
-return progress;
+aio_bh_poll(ctx);
+aio_dispatch_handlers(ctx, INVALID_HANDLE_VALUE);
+timerlistgroup_run_timers(&ctx->tlg);
}
bool aio_poll(AioContext *ctx, bool blocking)
diff --git a/async.c b/async.c
index 0243ca9..1839aa5 100644
--- a/async.c
+++ b/async.c
@@ -257,7 +257,7 @@ aio_ctx_dispatch(GSource *source,
AioContext *ctx = (AioContext *) source;
assert(callback == NULL);
-aio_dispatch(ctx, true);
+aio_dispatch(ctx);
return true;
}
diff --git a/include/block/aio.h b/include/block/aio.h
index 614cbc6..677b6ff 100644
--- a/include/block/aio.h
+++ b/include/block/aio.h
@@ -310,12 +310,8 @@ bool aio_pending(AioContext *ctx);
/* Dispatch any pending callbacks from the GSource attached to the AioContext.
*
* This is used internally in the implementation of the GSource.
- *
- * @dispatch_fds: true to process fds, false to skip them
- *(can be used as an optimization by callers that know there
- *are no fds ready)
*/
-bool aio_dispatch(AioContext *ctx, bool dispatch_fds);
+void aio_dispatch(AioContext *ctx);
/* Progress in completing AIO work to occur. This can issue new pending
* aio as a result of executing I/O completion or bh callbacks.
--
2.9.3
[Qemu-devel] [PATCH 10/16] block: explicitly acquire aiocontext in timers that need it
Signed-off-by: Paolo Bonzini
---
aio-posix.c | 2 --
aio-win32.c | 2 --
block/curl.c| 2 ++
block/iscsi.c | 8 ++--
block/null.c| 4
block/qed.c | 12
block/qed.h | 3 +++
block/throttle-groups.c | 2 ++
util/qemu-coroutine-sleep.c | 2 +-
9 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/aio-posix.c b/aio-posix.c
index 3fd64fb..8d79cf3 100644
--- a/aio-posix.c
+++ b/aio-posix.c
@@ -454,9 +454,7 @@ bool aio_dispatch(AioContext *ctx, bool dispatch_fds)
}
/* Run our timers */
-aio_context_acquire(ctx);
progress |= timerlistgroup_run_timers(&ctx->tlg);
-aio_context_release(ctx);
return progress;
}
diff --git a/aio-win32.c b/aio-win32.c
index ab6d0e5..810e1c6 100644
--- a/aio-win32.c
+++ b/aio-win32.c
@@ -403,9 +403,7 @@ bool aio_poll(AioContext *ctx, bool blocking)
progress |= aio_dispatch_handlers(ctx, event);
} while (count > 0);
-aio_context_acquire(ctx);
progress |= timerlistgroup_run_timers(&ctx->tlg);
-aio_context_release(ctx);
return progress;
}
diff --git a/block/curl.c b/block/curl.c
index 792fef8..65e6da1 100644
--- a/block/curl.c
+++ b/block/curl.c
@@ -424,9 +424,11 @@ static void curl_multi_timeout_do(void *arg)
return;
}
+aio_context_acquire(s->aio_context);
curl_multi_socket_action(s->multi, CURL_SOCKET_TIMEOUT, 0, &running);
curl_multi_check_completion(s);
+aio_context_release(s->aio_context);
#else
abort();
#endif
diff --git a/block/iscsi.c b/block/iscsi.c
index 6aeeb9e..e1f10d6 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -174,7 +174,7 @@ static void iscsi_retry_timer_expired(void *opaque)
struct IscsiTask *iTask = opaque;
iTask->complete = 1;
if (iTask->co) {
-qemu_coroutine_enter(iTask->co);
+aio_co_wake(iTask->co);
}
}
@@ -1388,16 +1388,20 @@ static void iscsi_nop_timed_event(void *opaque)
{
IscsiLun *iscsilun = opaque;
+aio_context_acquire(iscsilun->aio_context);
if (iscsi_get_nops_in_flight(iscsilun->iscsi) >= MAX_NOP_FAILURES) {
error_report("iSCSI: NOP timeout. Reconnecting...");
iscsilun->request_timed_out = true;
} else if (iscsi_nop_out_async(iscsilun->iscsi, NULL, NULL, 0, NULL) != 0)
{
error_report("iSCSI: failed to sent NOP-Out. Disabling NOP messages.");
-return;
+goto out;
}
timer_mod(iscsilun->nop_timer, qemu_clock_get_ms(QEMU_CLOCK_REALTIME) +
NOP_INTERVAL);
iscsi_set_events(iscsilun);
+
+out:
+aio_context_release(iscsilun->aio_context);
}
static void iscsi_readcapacity_sync(IscsiLun *iscsilun, Error **errp)
diff --git a/block/null.c b/block/null.c
index b300390..356209a 100644
--- a/block/null.c
+++ b/block/null.c
@@ -141,7 +141,11 @@ static void null_bh_cb(void *opaque)
static void null_timer_cb(void *opaque)
{
NullAIOCB *acb = opaque;
+AioContext *ctx = bdrv_get_aio_context(acb->common.bs);
+
+aio_context_acquire(ctx);
acb->common.cb(acb->common.opaque, 0);
+aio_context_release(ctx);
timer_deinit(&acb->timer);
qemu_aio_unref(acb);
}
diff --git a/block/qed.c b/block/qed.c
index 7f1c508..a21d025 100644
--- a/block/qed.c
+++ b/block/qed.c
@@ -345,10 +345,22 @@ static void qed_need_check_timer_cb(void *opaque)
trace_qed_need_check_timer_cb(s);
+qed_acquire(s);
qed_plug_allocating_write_reqs(s);
/* Ensure writes are on disk before clearing flag */
bdrv_aio_flush(s->bs->file->bs, qed_clear_need_check, s);
+qed_release(s);
+}
+
+void qed_acquire(BDRVQEDState *s)
+{
+aio_context_acquire(bdrv_get_aio_context(s->bs));
+}
+
+void qed_release(BDRVQEDState *s)
+{
+aio_context_release(bdrv_get_aio_context(s->bs));
}
static void qed_start_need_check_timer(BDRVQEDState *s)
diff --git a/block/qed.h b/block/qed.h
index 9676ab9..ce8c314 100644
--- a/block/qed.h
+++ b/block/qed.h
@@ -198,6 +198,9 @@ enum {
*/
typedef void QEDFindClusterFunc(void *opaque, int ret, uint64_t offset, size_t
len);
+void qed_acquire(BDRVQEDState *s);
+void qed_release(BDRVQEDState *s);
+
/**
* Generic callback for chaining async callbacks
*/
diff --git a/block/throttle-groups.c b/block/throttle-groups.c
index 17b2efb..aade5de 100644
--- a/block/throttle-groups.c
+++ b/block/throttle-groups.c
@@ -416,7 +416,9 @@ static void timer_cb(BlockBackend *blk, bool is_write)
qemu_mutex_unlock(&tg->lock);
/* Run the request that was waiting for this timer */
+aio_context_acquire(blk_get_aio_context(blk));
empty_queue = !qemu_co_enter_next(&blkp->throttled_reqs[is_write]);
+aio_context_release(blk_get_aio_context(blk));
/* If the request queue was empty then we have to take care of
* scheduling the next one */
diff --git a/util/qemu-coroutine-sleep.c b/util/qemu-coroutine-sleep.c
index 25de3ed..9c
Re: [Qemu-devel] [PATCH] hw/i386: check if nvdimm is enabled before plugging
On 01/13/17 13:17 +, Stefan Hajnoczi wrote:
On Fri, Jan 13, 2017 at 07:56:51PM +0800, Haozhong Zhang wrote:
The missing of 'nvdimm' in the machine type option '-M' means NVDIMM
is disabled. QEMU should refuse to plug any NVDIMM device in this case
and report the misconfiguration.
Reported-by: Stefan Hajnoczi
Signed-off-by: Haozhong Zhang
Message-Id: 20170112110928.GF4621@stefanha-x1.localdomain
Message-Id: 20170111093630.2088-1-stefa...@redhat.com
---
hw/i386/pc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 25e8586..3907609 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1715,6 +1715,11 @@ static void pc_dimm_plug(HotplugHandler *hotplug_dev,
}
if (object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM)) {
+if (!pcms->acpi_nvdimm_state.is_enabled) {
+error_setg(&local_err,
+ "nvdimm is not enabled: missing 'nvdimm' in '-M'");
+goto out;
+}
A warning is definitely useful to notify users of a possible
configuration error.
If NVDIMM is plugged at boot time, QEMU with this patch will stop and report a
message like
qemu-system-x86_64: -device nvdimm,...: nvdimm is not enabled: missing
'nvdimm' in '-M'
If NVDIMM is plugged via 'device_add' command, QEMU with this patch will report
a warning message
nvdimm is not enabled: missing 'nvdimm' in '-M'
and continue to run w/o plugging this device.
I wonder what happens when you plug an NVDIMM into a motherboard where
the firmware lacks support. Does it:
* Refuse to boot?
* Treat the DIMM as regular RAM?
* Boot but the DIMM will not be used by firmware and kernel?
Good question. Guangrong, any idea?
Thanks,
Haozhong
QEMU should act the same way as real hardware.
Stefan
[Qemu-devel] [PATCH 16/16] block: document fields protected by AioContext lock
Signed-off-by: Paolo Bonzini
---
include/block/block_int.h | 64 +-
include/sysemu/block-backend.h | 14 ++---
2 files changed, 49 insertions(+), 29 deletions(-)
diff --git a/include/block/block_int.h b/include/block/block_int.h
index 2d92d7e..1670941 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -430,8 +430,9 @@ struct BdrvChild {
* copied as well.
*/
struct BlockDriverState {
-int64_t total_sectors; /* if we are reading a disk image, give its
- size in sectors */
+/* Protected by big QEMU lock or read-only after opening. No special
+ * locking needed during I/O...
+ */
int open_flags; /* flags used to open the file, re-used for re-open */
bool read_only; /* if true, the media is read only */
bool encrypted; /* if true, the media is encrypted */
@@ -439,14 +440,6 @@ struct BlockDriverState {
bool sg;/* if true, the device is a /dev/sg* */
bool probed;/* if true, format was probed rather than specified */
-int copy_on_read; /* if nonzero, copy read backing sectors into image.
- note this is a reference count */
-
-CoQueue flush_queue;/* Serializing flush queue */
-bool active_flush_req; /* Flush request in flight? */
-unsigned int write_gen; /* Current data generation */
-unsigned int flushed_gen; /* Flushed write generation */
-
BlockDriver *drv; /* NULL means no media */
void *opaque;
@@ -468,18 +461,6 @@ struct BlockDriverState {
BdrvChild *backing;
BdrvChild *file;
-/* Callback before write request is processed */
-NotifierWithReturnList before_write_notifiers;
-
-/* number of in-flight requests; overall and serialising */
-unsigned int in_flight;
-unsigned int serialising_in_flight;
-
-bool wakeup;
-
-/* Offset after the highest byte written to */
-uint64_t wr_highest_offset;
-
/* I/O Limits */
BlockLimits bl;
@@ -497,11 +478,8 @@ struct BlockDriverState {
QTAILQ_ENTRY(BlockDriverState) bs_list;
/* element of the list of monitor-owned BDS */
QTAILQ_ENTRY(BlockDriverState) monitor_list;
-QLIST_HEAD(, BdrvDirtyBitmap) dirty_bitmaps;
int refcnt;
-QLIST_HEAD(, BdrvTrackedRequest) tracked_requests;
-
/* operation blockers */
QLIST_HEAD(, BdrvOpBlocker) op_blockers[BLOCK_OP_TYPE_MAX];
@@ -522,6 +500,31 @@ struct BlockDriverState {
/* The error object in use for blocking operations on backing_hd */
Error *backing_blocker;
+/* Protected by AioContext lock */
+
+/* If true, copy read backing sectors into image. Can be >1 if more
+ * than one client has requested copy-on-read.
+ */
+int copy_on_read;
+
+/* If we are reading a disk image, give its size in sectors.
+ * Generally read-only; it is written to by load_vmstate and save_vmstate,
+ * but the block layer is quiescent during those.
+ */
+int64_t total_sectors;
+
+/* Callback before write request is processed */
+NotifierWithReturnList before_write_notifiers;
+
+/* number of in-flight requests; overall and serialising */
+unsigned int in_flight;
+unsigned int serialising_in_flight;
+
+bool wakeup;
+
+/* Offset after the highest byte written to */
+uint64_t wr_highest_offset;
+
/* threshold limit for writes, in bytes. "High water mark". */
uint64_t write_threshold_offset;
NotifierWithReturn write_threshold_notifier;
@@ -529,6 +532,17 @@ struct BlockDriverState {
/* counter for nested bdrv_io_plug */
unsigned io_plugged;
+QLIST_HEAD(, BdrvTrackedRequest) tracked_requests;
+CoQueue flush_queue; /* Serializing flush queue */
+bool active_flush_req;/* Flush request in flight? */
+unsigned int write_gen; /* Current data generation */
+unsigned int flushed_gen; /* Flushed write generation */
+
+QLIST_HEAD(, BdrvDirtyBitmap) dirty_bitmaps;
+
+/* do we need to tell the quest if we have a volatile write cache? */
+int enable_write_cache;
+
int quiesce_counter;
};
diff --git a/include/sysemu/block-backend.h b/include/sysemu/block-backend.h
index 6444e41..f365a51 100644
--- a/include/sysemu/block-backend.h
+++ b/include/sysemu/block-backend.h
@@ -64,14 +64,20 @@ typedef struct BlockDevOps {
* fields that must be public. This is in particular for QLIST_ENTRY() and
* friends so that BlockBackends can be kept in lists outside block-backend.c
*/
typedef struct BlockBackendPublic {
-/* I/O throttling.
- * throttle_state tells us if this BlockBackend has I/O limits configured.
- * io_limits_disabled tells us if they are currently being enforced */
+/* I/O throttling has its own locking, but also some fields are
+ * protected by the AioContext lock.
+ */
+
+/* Protected by AioContex
Re: [Qemu-devel] [PATCH v6 wave 2 1/3] hw/isa/lpc_ich9: add SMI feature negotiation via fw_cfg
On Thu, 12 Jan 2017 19:24:44 +0100
Laszlo Ersek wrote:
[...]
> +static void smi_features_ok_callback(void *opaque)
> +{
> +ICH9LPCState *lpc = opaque;
> +uint64_t guest_features;
> +
> +if (lpc->smi_features_ok) {
> +/* negotiation already complete, features locked */
> +return;
> +}
> +
> +memcpy(&guest_features, lpc->smi_guest_features_le, sizeof
> guest_features);
> +le64_to_cpus(&guest_features);
> +if (guest_features & ~lpc->smi_host_features) {
> +/* guest requests invalid features, leave @features_ok at zero */
> +return;
> +}
> +
> +/* valid feature subset requested, lock it down, report success */
> +lpc->smi_negotiated_features = guest_features;
> +lpc->smi_features_ok = 1;
> +}
[...]
> +.fields = (VMStateField[]) {
> +VMSTATE_UINT8_ARRAY(smi_guest_features_le, ICH9LPCState,
> +sizeof(uint64_t)),
> +VMSTATE_UINT8(smi_features_ok, ICH9LPCState),
> +VMSTATE_UINT64(smi_negotiated_features, ICH9LPCState),
Couldn't smi_negotiated_features be derived from
smi_guest_features_le on target side?
> +VMSTATE_END_OF_LIST()
> +}
> +};
> +
> static const VMStateDescription vmstate_ich9_lpc = {
> .name = "ICH9LPC",
> .version_id = 1,
> @@ -683,6 +761,7 @@ static const VMStateDescription vmstate_ich9_lpc = {
> },
> .subsections = (const VMStateDescription*[]) {
> &vmstate_ich9_rst_cnt,
> +&vmstate_ich9_smi_feat,
> NULL
> }
> };
Re: [Qemu-devel] [PATCH v5 00/10] aio_context_acquire/release pushdown, part 1
On Thu, Jan 12, 2017 at 07:07:50PM +0100, Paolo Bonzini wrote: > This is the first step of pushing down the AioContext lock. Bottom halves > are already protected by their own lock, use it also for walking_bh > and for the handlers list (including walking_handlers). The (lock, > walking_foo) pair is wrapped into the QemuLockCnt primitive. > > The only difference from v3 is a smattering of tiny nice improvements > to QemuLockCnt. > > Paolo > > v4->v5: > remove stray tabs [patchew] > > v3->v4: > Avoid useless atomic_mb_read in non-futex lockcnt [Stefan] > Use atomic_read in qemu_lockcnt_count [Stefan] > Tweak comment for qemu_lockcnt_cmpxchg_or_wait [Fam] > Use if/else in qemu_lockcnt_dec_and_lock [Fam] > Comment QEMU_LOCKCNT_STATE_* definitions [Fam] > > v2->v3: > fix missing unlock > > v1->v2: > rebased on top of polling patches > moved documentation to include/ > new patch "aio-posix: split aio_dispatch_handlers out of aio_dispatch" > replaced atomic_read with atomic_mb_read in qemu_lockcnt_inc > replaced futex* function and macro names with qemu_futex* > removed atomic access to node->pfd.revents (because there is no > concurrent aio_poll anymore after the BDRV_POLL_WHILE series) > left "aio: push aio_context_acquire/release down to dispatching" > to a later series > > Paolo Bonzini (10): > aio: rename bh_lock to list_lock > qemu-thread: introduce QemuLockCnt > aio: make ctx->list_lock a QemuLockCnt, subsuming ctx->walking_bh > qemu-thread: optimize QemuLockCnt with futexes on Linux > aio-posix: split aio_dispatch_handlers out of aio_dispatch > aio: tweak walking in dispatch phase > aio-posix: remove walking_handlers, protecting AioHandler list with > list_lock > aio-win32: remove walking_handlers, protecting AioHandler list with > list_lock > aio: document locking > async: optimize aio_bh_poll > > aio-posix.c | 116 +++-- > aio-win32.c | 83 + > async.c | 45 ++--- > docs/lockcnt.txt| 277 +++ > docs/multiple-iothreads.txt | 13 +- > include/block/aio.h | 38 ++--- > include/qemu/futex.h| 36 > include/qemu/thread.h | 112 + > util/Makefile.objs | 1 + > util/lockcnt.c | 397 > > util/qemu-thread-posix.c| 35 +--- > util/qemu-thread-win32.c| 2 +- > util/trace-events | 10 ++ > 13 files changed, 1006 insertions(+), 159 deletions(-) > create mode 100644 docs/lockcnt.txt > create mode 100644 include/qemu/futex.h > create mode 100644 util/lockcnt.c > > -- > 2.9.3 > Thanks, applied to my block tree: https://github.com/stefanha/qemu/commits/block Stefan signature.asc Description: PGP signature
Re: [Qemu-devel] [PATCH] sdl2: fix build failure on windows
On 13 January 2017 at 08:27, Stefan Weil wrote:
> Am 13.01.2017 um 09:14 schrieb Gerd Hoffmann:
>> Cc: Stefan Weil
>> Cc: Samuel Thibault
>> Signed-off-by: Gerd Hoffmann
>> ---
>> ui/sdl2.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/ui/sdl2.c b/ui/sdl2.c
>> index 9a79b17..91fb111 100644
>> --- a/ui/sdl2.c
>> +++ b/ui/sdl2.c
>> @@ -817,9 +817,15 @@ void sdl_display_init(DisplayState *ds, int
>> full_screen, int no_frame)
>> sdl2_console[i].dcl.con = con;
>> register_displaychangelistener(&sdl2_console[i].dcl);
>>
>> +#if defined(SDL_VIDEO_DRIVER_WINDOWS) || defined(SDL_VIDEO_DRIVER_X11)
>> if (SDL_GetWindowWMInfo(sdl2_console[i].real_window, &info)) {
>> +#if defined(SDL_VIDEO_DRIVER_WINDOWS)
>> +qemu_console_set_window_id(con,
>> (uintptr_t)info.info.win.window);
>> +#elif defined(SDL_VIDEO_DRIVER_X11)
>> qemu_console_set_window_id(con, info.info.x11.window);
>> +#endif
>> }
>> +#endif
>> }
>>
>> /* Load a 32x32x4 image. White pixels are transparent. */
>
>
> Thanks.
>
> Reviewed-by: Stefan Weil
Thanks; applied to master as a buildfix.
-- PMM
Re: [Qemu-devel] [PATCH v6 wave 2 3/3] hw/isa/lpc_ich9: negotiate SMI broadcast on pc-q35-2.9+ machine types
On Thu, 12 Jan 2017 19:24:46 +0100
Laszlo Ersek wrote:
> Cc: "Michael S. Tsirkin"
> Cc: Eduardo Habkost
> Cc: Gerd Hoffmann
> Cc: Igor Mammedov
> Cc: Paolo Bonzini
> Signed-off-by: Laszlo Ersek
> Reviewed-by: Eduardo Habkost
> Reviewed-by: Michael S. Tsirkin
> ---
>
> Notes:
> v6:
> - rename "smi_broadcast" to "x-smi-broadcast" [Eduardo]
> - pick up Eduardo's R-b
> - pick up Michael's R-b
>
> v5:
> - replace the v4 patch "hw/i386/pc_q35: advertise broadcast SMI if VCPU
> hotplug is turned off" with a simple device property and compat
> setting [Igor]
>
> include/hw/i386/pc.h | 5 +
> hw/isa/lpc_ich9.c| 2 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index 230e9e70c504..9d950733abdf 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -376,6 +376,11 @@ bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t
> *);
>
> #define PC_COMPAT_2_8 \
> HW_COMPAT_2_8 \
> +{\
> +.driver = "ICH9-LPC",\
> +.property = "x-smi-broadcast",\
> +.value= "off",\
> +},\
>
>
> #define PC_COMPAT_2_7 \
> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
> index ced6f803a4f2..59930dd9d09d 100644
> --- a/hw/isa/lpc_ich9.c
> +++ b/hw/isa/lpc_ich9.c
> @@ -776,6 +776,8 @@ static const VMStateDescription vmstate_ich9_lpc = {
>
> static Property ich9_lpc_properties[] = {
> DEFINE_PROP_BOOL("noreboot", ICH9LPCState, pin_strap.spkr_hi, true),
> +DEFINE_PROP_BIT64("x-smi-broadcast", ICH9LPCState, smi_host_features,
> + ICH9_LPC_SMI_F_BROADCAST_BIT, true),
> DEFINE_PROP_END_OF_LIST(),
> };
>
Reviewed-by: Igor Mammedov
Re: [Qemu-devel] [PATCH 0/6] ppc: add a IBM 40p machine (RS/6000, PReP)
On 13.01.2017 13:23, Mark Cave-Ayland wrote: > On 12/01/17 12:57, Hervé Poussineau wrote: > >> Le 11/01/2017 à 17:58, Artyom Tarasenko a écrit : >>> Hi Hervé, >>> >>> nice work! >>> >>> On Thu, Dec 29, 2016 at 11:12 PM, Hervé Poussineau >>> wrote: Hi, This patchset adds the emulation of the IBM RS/6000 7020 (40p). The real machine is able to run AIX (up to 4.3.3), Windows NT (up to 4.0 SP1), the beta of OS/2 PowerPC, Solaris, Linux, NetBSD/PReP ... I've tested current emulation with Open Hack'Ware, OpenBIOS and official firmware. Linux kernel starts, and freezes during boot (like with 'prep' machine). >> >> I already saw a regression during 2.7.0 cycle with 603 CPU. However, I >> was unable to provide kernel source, so Benjamin was unable to find the >> problem. >> http://lists.gnu.org/archive/html/qemu-devel/2016-08/msg03760.html >> >>> >>> If prep can't do it anymore, it looks like a regression. I definitely >>> remember seen a sitting penguin and a login prompt ~ 2 years ago. At >>> least with OFW. >>> Windows NT starts up to the point where it wants to change endianness. >>> >>> I hit that with Solaris/PPC a few years back as you published your >>> previous attempt. Do you know what is missing? I guess CPU endianness >>> switch emulation is working because it is used in the newer POWER >>> CPUs. Is it just the systemIO which has to be improved, or is it more? >> >> Yes, PReP System I/O has LE flag which is not implemented. >> You may be interested by >> ftp://ftp.software.ibm.com/rs6000/technology/spec/endian.ps >> which deals about endianness switching, with some code from Windows NT/PPC >> >>> Other OSes have not been tested. This machine is a superset of the 'prep' one, because we know exactly what is/should emulated, and that operating system list running on it is quite wide. I hope that 'prep' machine can be deprecated soon and then later removed. >>> >>> Would be nice to keep 'prep' until the 40p can boot Linux and NetBSD >>> 6.1.3 (this version used to work with -M prep last time I checked). >> >> Some Linux kernels seem to work, some other ones seem to not work (hang >> while booting) >> I've not searched why. >> >> I tried NetBSD 6.1.3/PReP. >> cdroms/harddisks don't boot anymore with Open Hack'Ware since some >> changes in IDE core >> Kernel boots better with 40p than with prep >> >> >> prep: >> >> Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, >> 2006, 2007, 2008, 2009, 2010, 2011, 2012 >> The NetBSD Foundation, Inc. All rights reserved. >> Copyright (c) 1982, 1986, 1989, 1991, 1993 >> The Regents of the University of California. All rights reserved. >> >> NetBSD 6.1.3 (INSTALL) >> Model: Qemu >> total memory = 128 MB >> avail memory = 119 MB >> panic: call to null-ptr from 0x0 >> >> The operating system has halted. >> Please press any key to reboot. >> >> >> 40p/Open Hack'Ware: >> >> Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, >> 2006, 2007, 2008, 2009, 2010, 2011, 2012 >> The NetBSD Foundation, Inc. All rights reserved. >> Copyright (c) 1982, 1986, 1989, 1991, 1993 >> The Regents of the University of California. All rights reserved. >> >> NetBSD 6.1.3 (INSTALL) >> Model: Qemu >> total memory = 128 MB >> avail memory = 119 MB >> mainbus0 (root) >> cpu0 at mainbus0: 604 (Revision 1.3), ID 0 (primary) >> cpu0: HID0 0xc084, powersave: 1 >> cpu0: 0.00 MHz >> Couldn't find PNP data for bus 0 devfunc 0x0 >> pnpbus0 at mainbus0 >> pci0 at mainbus0 bus 0: indirect configuration space access >> pchb0 at pci0 dev 0 function 0 >> pchb0: vendor 0x1057 product 0x4801 (rev. 0x00) >> siop0 at pci0 dev 1 function 0: Symbios Logic 53c810 (fast scsi) >> siop0: couldn't map interrupt >> vga0 at pci0 dev 2 function 0: vendor 0x1234 product 0x (rev. 0x02) >> wsdisplay0 at vga0 (kbdmux ignored) >> drm at vga0 not configured >> pcn0 at pci0 dev 3 function 0: AMD PCnet-PCI Ethernet >> pcn0: Am79c970A PCnet-PCI II rev 0, Ethernet address 52:54:00:12:34:56 >> pcn0: unable to map interrupt >> pcib0 at pci0 dev 11 function 0: vendor 0x8086 product 0x0484 (rev. 0x03) >> isa0 at pcib0 >> com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo >> com0: console >> com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo >> pckbc0 at isa0 port 0x60-0x64 >> pckbd0 at pckbc0 (kbd slot) >> pckbc0: using irq 1 for kbd slot >> wskbd0 at pckbd0 (mux ignored) >> vmmask 1000 schedmask 1000 highmask 7000 >> boot device: mainbus0 >> root on md0a dumps on md0b >> root file system type: ffs >> WARNING: no TOD clock present >> WARNING: using filesystem time >> WARNING: CHECK AND RESET THE DATE! >> erase ^H, werase ^W, kill ^U, intr ^C, status ^T >> Terminal type? [vt100] >> >> =
Re: [Qemu-devel] [PATCH RFC v2 1/6] docs/block-replication: Add description for shared-disk case
On Mon, Dec 05, 2016 at 04:34:59PM +0800, zhanghailiang wrote:
> +Issue qmp command:
> + { 'execute': 'blockdev-add',
> +'arguments': {
> +'driver': 'replication',
> +'node-name': 'rep',
> +'mode': 'primary',
> +'shared-disk-id': 'primary_disk0',
> +'shared-disk': true,
> +'file': {
> +'driver': 'nbd',
> +'export': 'hidden_disk0',
> +'server': {
> +'type': 'inet',
> +'data': {
> +'host': 'xxx.xxx.xxx.xxx',
> +'port': 'yyy'
> +}
> +}
block/nbd.c does have good error handling and recovery in case there is
a network issue. There are no reconnection attempts or timeouts that
deal with a temporary loss of network connectivity.
This is a general problem with block/nbd.c and not something to solve in
this patch series. I'm just mentioning it because it may affect COLO
replication.
I'm sure these limitations in block/nbd.c can be fixed but it will take
some effort. Maybe block/sheepdog.c, net/socket.c, and other network
code could also benefit from generic network connection recovery.
Reviewed-by: Stefan Hajnoczi
signature.asc
Description: PGP signature
Re: [Qemu-devel] [PULL 00/30] target-sparc sun4v support
On 12 January 2017 at 02:55, Richard Henderson wrote: > Mark Cave-Ayland asked me to handle the merge of this patch set > while he is traveling. > > This is the v2 that Artyom posted today. I had reviewed the majority > of v1 earlier. I re-read through the rebase and saw nothing amiss. > It passes my tests for sparc32, and does run the OpenSolaris image > to which Artyom links. > > > r~ > > > The following changes since commit 41a0e54756a9ae6b60be34bb33302a7e085fdb07: > > Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging > (2017-01-10 10:46:21 +) > > are available in the git repository at: > > git://github.com/rth7680/qemu.git tags/pull-sparc-20170111 > > for you to fetch changes up to 224be7cc93a37ccd38342811a8925de889de1a49: > > target-sparc: fix up niagara machine (2017-01-11 12:23:58 -0800) > > > Sun4v support This hits clang's unused-function error; /home/petmay01/linaro/qemu-for-merges/target/sparc/ldst_helper.c:346:20: error: unused function 'do_check_asi' [-Werror,-Wunused-function] static inline void do_check_asi(CPUSPARCState *env, int asi, uintptr_t ra) ^ 1 error generated. thanks -- PMM
Re: [Qemu-devel] [PATCH for-2.9 v3] qapi: add explicit null to string input and output visitors
Greg Kurz writes: > This may be used for deprecated object properties that are kept for > backwards compatibility. > > Signed-off-by: Greg Kurz Reviewed-by: Markus Armbruster Happy to merge this as soon as we have an actual user.
Re: [Qemu-devel] [PATCH v2] x86: add AVX512_VPOPCNTDQ features
On Fri, Jan 13, 2017 at 09:53:31AM +0800, He Chen wrote: > AVX512_VPOPCNTDQ: Vector POPCNT instructions for word and qwords. > variable precision. > > Signed-off-by: He Chen Reviewed-by: Eduardo Habkost Applied to x86-next. Thanks! -- Eduardo
Re: [Qemu-devel] [PULL 0/2] Travis updates
On 12 January 2017 at 13:16, Alex Bennée wrote: > The following changes since commit b44486dfb9447c88e4b216e730adcc780190852c: > > Merge remote-tracking branch 'remotes/kraxel/tags/pull-ui-20170110-1' into > staging (2017-01-10 14:52:34 +) > > are available in the git repository at: > > https://github.com/stsquad/qemu.git tags/pull-travis-20170112-1 > > for you to fetch changes up to ae1a772c5607f25cbdc80063f0f5a85290434058: > > travis: add Trusty with clang stable build (2017-01-12 10:04:17 +) > > > A couple of fixes to reduce the matrix some more that just missed the > last iteration. > > Applied, thanks. -- PMM
[Qemu-devel] [PATCH v8 13/21] texi2pod: learn quotation, deftp and deftypefn
Learn a few more markups used for API documentation.
Signed-off-by: Marc-André Lureau
---
scripts/texi2pod.pl | 54 ++---
1 file changed, 51 insertions(+), 3 deletions(-)
diff --git a/scripts/texi2pod.pl b/scripts/texi2pod.pl
index 8767662d30..6e8fec41a1 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)$/) {
@@ -303,6 +305,7 @@ while(<$inf>) {
$ic =~ s/\@(?:code|kbd)/C/;
$ic =~ s/\@(?:dfn|var|emph|cite|i)/I/;
$ic =~ s/\@(?:file)/F/;
+ $ic =~ s/\@(?:asis)//;
$_ = "\n=over 4\n";
};
@@ -323,10 +326,54 @@ 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.
- $_ = "\n=item $ic\<$1\>\n";
+if ($ic eq "") {
+$_ = "\n=item $1\n";
+} else {
+# Entity escapes prevent munging by the <> processing below.
+$_ = "\n=item $ic\<$1\>\n";
+}
} else {
$_ = "\n=item $ic\n";
$ic =~ y/A-Ya-y/B-Zb-z/;
@@ -388,6 +435,7 @@ sub postprocess
s/\@sc\{([^\}]*)\}/\U$1/g;
s/\@file\{([^\}]*)\}/F<$1>/g;
s/\@w\{([^\}]*)\}/S<$1>/g;
+s/\@t\{([^\}]*)\}/$1/g;
s/\@(?:dmn|math)\{([^\}]*)\}/$1/g;
# keep references of the form @ref{...}, print them bold
--
2.11.0
[Qemu-devel] [PATCH v8 01/21] qapi: replace 'o' for list items
Replace with '*', the common form for list items.
Signed-off-by: Marc-André Lureau
---
qapi-schema.json | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index eab8d4a9ee..1d4f27f1a3 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1883,11 +1883,11 @@
#
#Known limitations:
#
-#o This command is stateless, this means that commands that depend
+#* This command is stateless, this means that commands that depend
# on state information (such as getfd) might not work
#
-# o Commands that prompt the user for data (eg. 'cont' when the block
-# device is encrypted) don't currently work
+#* Commands that prompt the user for data (eg. 'cont' when the block
+# device is encrypted) don't currently work
##
{ 'command': 'human-monitor-command',
'data': {'command-line': 'str', '*cpu-index': 'int'},
--
2.11.0
[Qemu-devel] [PATCH v8 03/21] qapi: make TODOs named-sections
Have the TODO in the TAG: format, so they will stand out in the
generated documentation.
Signed-off-by: Marc-André Lureau
---
qapi-schema.json | 4 ++--
qapi/introspect.json | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index bcbf72bf59..c18a59fefc 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2314,7 +2314,7 @@
# "mac": "52:54:00:12:34:56" } }
# <- { "return": {} }
#
-# TODO This command effectively bypasses QAPI completely due to its
+# TODO: This command effectively bypasses QAPI completely due to its
# "additional arguments" business. It shouldn't have been added to
# the schema in this form. It should be qapified properly, or
# replaced by a properly qapified command.
@@ -2515,7 +2515,7 @@
#
# Additional arguments depend on the type.
#
-# TODO This command effectively bypasses QAPI completely due to its
+# TODO: This command effectively bypasses QAPI completely due to its
# "additional arguments" business. It shouldn't have been added to
# the schema in this form. It should be qapified properly, or
# replaced by a properly qapified command.
diff --git a/qapi/introspect.json b/qapi/introspect.json
index fd4dc84196..464097a235 100644
--- a/qapi/introspect.json
+++ b/qapi/introspect.json
@@ -258,7 +258,7 @@
#
# @ret-type: the name of the command's result type.
#
-# TODO @success-response (currently irrelevant, because it's QGA, not QMP)
+# TODO: @success-response (currently irrelevant, because it's QGA, not QMP)
#
# Since: 2.5
##
--
2.11.0
[Qemu-devel] [PATCH v8 05/21] qapi: improve TransactionAction doc
TransactionAction is a flat union, document 'type' versions
exhaustively, and sort the members.
Signed-off-by: Marc-André Lureau
Reviewed-by: Markus Armbruster
---
qapi-schema.json | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index 70e32570e8..6c251605ac 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1795,28 +1795,29 @@
# @TransactionAction:
#
# A discriminated record of operations that can be performed with
-# @transaction.
+# @transaction. Action @type can be:
#
-# Since: 1.1
+# - @abort: since 1.6
+# - @block-dirty-bitmap-add: since 2.5
+# - @block-dirty-bitmap-clear: since 2.5
+# - @blockdev-backup: since 2.3
+# - @blockdev-snapshot: since 2.5
+# - @blockdev-snapshot-internal-sync: since 1.7
+# - @blockdev-snapshot-sync: since 1.1
+# - @drive-backup: since 1.6
#
-# drive-backup since 1.6
-# abort since 1.6
-# blockdev-snapshot-internal-sync since 1.7
-# blockdev-backup since 2.3
-# blockdev-snapshot since 2.5
-# block-dirty-bitmap-add since 2.5
-# block-dirty-bitmap-clear since 2.5
+# Since: 1.1
##
{ 'union': 'TransactionAction',
'data': {
- 'blockdev-snapshot': 'BlockdevSnapshot',
- 'blockdev-snapshot-sync': 'BlockdevSnapshotSync',
- 'drive-backup': 'DriveBackup',
- 'blockdev-backup': 'BlockdevBackup',
'abort': 'Abort',
- 'blockdev-snapshot-internal-sync': 'BlockdevSnapshotInternal',
'block-dirty-bitmap-add': 'BlockDirtyBitmapAdd',
- 'block-dirty-bitmap-clear': 'BlockDirtyBitmap'
+ 'block-dirty-bitmap-clear': 'BlockDirtyBitmap',
+ 'blockdev-backup': 'BlockdevBackup',
+ 'blockdev-snapshot': 'BlockdevSnapshot',
+ 'blockdev-snapshot-internal-sync': 'BlockdevSnapshotInternal',
+ 'blockdev-snapshot-sync': 'BlockdevSnapshotSync',
+ 'drive-backup': 'DriveBackup'
} }
##
--
2.11.0
[Qemu-devel] [PATCH v8 04/21] 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 optional argument
Signed-off-by: Marc-André Lureau
Reviewed-by: Markus Armbruster
Reviewed-by: Eric Blake
---
qapi-schema.json | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index c18a59fefc..70e32570e8 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2292,7 +2292,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.
#
@@ -2322,7 +2322,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.11.0
[Qemu-devel] [PATCH v8 07/21] qapi: avoid interleaving sections and parameters
Follow documentation guideline, body, parameters then additional
sections.
Signed-off-by: Marc-André Lureau
---
qapi-schema.json | 10 +-
qapi/event.json | 4 ++--
qapi/introspect.json | 3 +--
3 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index 6c251605ac..c1af70057d 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -4733,17 +4733,17 @@
# it should be passed by management with device_add command when
# a CPU is being hotplugged.
#
+# @node-id: #optional NUMA node ID the CPU belongs to
+# @socket-id: #optional socket number within node/board the CPU belongs to
+# @core-id: #optional core number within socket the CPU belongs to
+# @thread-id: #optional thread number within core the CPU belongs to
+#
# Note: currently there are 4 properties that could be present
# but management should be prepared to pass through other
# properties with device_add command to allow for future
# interface extension. This also requires the filed names to be kept in
# sync with the properties passed to -device/device_add.
#
-# @node-id: #optional NUMA node ID the CPU belongs to
-# @socket-id: #optional socket number within node/board the CPU belongs to
-# @core-id: #optional core number within socket the CPU belongs to
-# @thread-id: #optional thread number within core the CPU belongs to
-#
# Since: 2.7
##
{ 'struct': 'CpuInstanceProperties',
diff --git a/qapi/event.json b/qapi/event.json
index 37bf34ed6d..c7689b211d 100644
--- a/qapi/event.json
+++ b/qapi/event.json
@@ -272,9 +272,9 @@
#
# Emitted when guest executes ACPI _OST method.
#
-# Since: 2.1
-#
# @info: ACPIOSTInfo type as described in qapi-schema.json
+#
+# Since: 2.1
##
{ 'event': 'ACPI_DEVICE_OST',
'data': { 'info': 'ACPIOSTInfo' } }
diff --git a/qapi/introspect.json b/qapi/introspect.json
index 464097a235..f6adc439bb 100644
--- a/qapi/introspect.json
+++ b/qapi/introspect.json
@@ -78,14 +78,13 @@
# @SchemaInfo:
#
# @name: the entity's name, inherited from @base.
+#The SchemaInfo is always referenced by this name.
#Commands and events have the name defined in the QAPI schema.
#Unlike command and event names, type names are not part of
#the wire ABI. Consequently, type names are meaningless
#strings here, although they are still guaranteed unique
#regardless of @meta-type.
#
-# All references to other SchemaInfo are by name.
-#
# @meta-type: the entity's meta type, inherited from @base.
#
# Additional members depend on the value of @meta-type.
--
2.11.0
[Qemu-devel] [PATCH v8 06/21] qga/schema: improve guest-set-vcpus Returns: section
Itemize the possible return values of guest-set-vcpus. Drop the blank lines for consistency with itemized lists elsewhere. Signed-off-by: Marc-André Lureau Reviewed-by: Markus Armbruster --- qga/qapi-schema.json | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/qga/qapi-schema.json b/qga/qapi-schema.json index 94c03128fd..d421609dcb 100644 --- a/qga/qapi-schema.json +++ b/qga/qapi-schema.json @@ -697,21 +697,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.11.0
[Qemu-devel] [PATCH v8 09/21] qapi: add some sections in docs
Add some more section titles to organize the documentation we're going
to generate.
Signed-off-by: Marc-André Lureau
Reviewed-by: Markus Armbruster
---
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 c1af70057d..54c3e48ba9 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 fb5034c3a9..7f7f10bb49 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 8e9f59019a..693e234779 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 624a8619c8..d93f159946 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 f4fd93b813..93a04743ea 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 c7689b211d..0cd4b79ad8 100644
--- a/qapi/event.json
+++ b/qapi/event.json
@@ -1,3 +1,9 @@
+# -*- Mode: Python -*-
+
+##
+# = Other events
+##
+
##
# @SHUTDOWN:
#
diff --git a/qapi/rocker.json b/qapi/rocker.json
index ace27760f1..1e511cd37a 100644
--- a/qapi/rocker.json
+++ b/qapi/rocker.json
@@ -1,3 +1,7 @@
+##
+# = Rocker switch device
+##
+
##
# @RockerSwitch:
#
diff --git a/qapi/trace.json b/qapi/trace.json
index 4fd39b7792..3ad7df7fdb 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.11.0
[Qemu-devel] [PATCH v8 00/21] qapi doc generation (whole version, squashed)
Add a qapi2texi script to generate the documentation from the qapi
schemas.
The SQUASHED 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
PDF preview:
https://fedorapeople.org/~elmarco/qemu-qmp-ref.pdf (v7 without type info)
v8: after Markus review of v7
- error messages improvements
- python code style change (despite bad W503 pep8 warnings)
- build-sys GEN message fix
- doc improvements from Markus
- more TODOs
v7: after Markus review of v6
- removed type information, doc and syntax (post-poned)
- keep original documentation order (consequently,
tests/qapi-schema/doc-bad-section.json is now accepted)
- removed "qapi: use a QAPIParseError in parser" patch
- removed "reorder documentation body" patch
- removed 'o' support for list items
- added several TODOs
- added a few preliminary patches for the new changes
- improved some error messages
- updated tests corresponding to the changes above
- added r-b tags
v6:
- rebased on top of armbru/qapi-next branch
- add a few patches to improve Exception subclasses and usage in
qapi.py as suggested during review
- parser and generator fixes and improvements after v5 review:
- various union improvements, hopefully with a better syntax
- improve error messages
- improve docs/qapi-code-gen.txt documentation section
- do not allow interleaved body documentation between sections
- more tests for new cases
- make expression documentation mandatory, fix the tests
- replace bad usage of @var{} with @t{} in texi, fix texi2pod to
handle it
- renaming, reordering etc..
- add docs/qapi-syntax.texi to describe the API syntax used in the
texi documentation
- fix interleaved body and section documentation
- improve documentation sections name
- many build-sys improvements after review
- fix and improve commit messages, update R-b tags
v5:
- many parser and generator fixes and improvements after v4 review:
- simplified current section handling by using a Section object
- adding a line is more stateful: either freeform or symbol comment
- always check_docs() when parsing with QAPISchema
- simplified some code and comments
- do not break current section on empty line, but break after a non
indented paragraph in an argument section. This seems to reflects
the way documentation is written:
##
# @foo:
# @arg: fluctuat nec mergitur
# - continues here
#
# Since: 1853
#
# Body
#
##
Other sections (Note/Examples etc) are not indented (it seems), but
could use a similar rule. I prefer to keep this only for args, for
styling reasons (bikeshedding?).
- better handling of flat-union in generator
- list all enum values (even when not documented)
- added qapi-doc parsing tests and more error checking
- pep8/pylint fixes
- some more schema doc fixes
- do not move logo to docs/
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 (21):
qapi: replace 'o' for list items
qapi: move QKeyCode doc body at the top
qapi: make TODOs named-sections
qapi: improve device_add schema
qapi: improve TransactionAction doc
qga/schema: improve guest-set-vcpus Returns: section
qapi: avoid interleaving sections and parameters
qapi: move experimental note down
qapi: add some sections in docs
docs: add master qapi texi files
qapi: rework qapi Exception
qapi.py: fix line break before binary operator pep8
texi2pod: learn quotation, deftp and deftypefn
(SQUASHED) move doc to schema
qapi: add qapi2texi script
docs: add qemu logo to pdf
build-sys: use --no-split for info
build-sys: remove dvi doc generation
build-sys: use a generic TEXI2MAN rule
build-sys: add txt documentation rules
build-sys: add qapi doc generation targets
qapi-schema.jso
[Qemu-devel] [PATCH v8 08/21] qapi: move experimental note down
Use a better 'Note:' section, move it below parameters following
guidelines.
Signed-off-by: Marc-André Lureau
---
qapi/block-core.json | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 6b42216960..fb5034c3a9 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -2441,12 +2441,12 @@
# BlockBackend will be created; otherwise, @node-name is mandatory at the top
# level and no BlockBackend will be created.
#
-# This command is still a work in progress. It doesn't support all
+# For the arguments, see the documentation of BlockdevOptions.
+#
+# Note: This command is still a work in progress. It doesn't support all
# block drivers among other things. Stay away from it unless you want
# to help with its development.
#
-# For the arguments, see the documentation of BlockdevOptions.
-#
# Since: 1.7
##
{ 'command': 'blockdev-add', 'data': 'BlockdevOptions', 'boxed': true }
@@ -2458,12 +2458,12 @@
# The command will fail if the node is attached to a device or is
# otherwise being used.
#
-# This command is still a work in progress and is considered
+# @node-name: Name of the graph node to delete.
+#
+# Note: This command is still a work in progress and is considered
# experimental. Stay away from it unless you want to help with its
# development.
#
-# @node-name: Name of the graph node to delete.
-#
# Since: 2.5
##
{ 'command': 'x-blockdev-del', 'data': { 'node-name': 'str' } }
@@ -2530,13 +2530,13 @@
#
# If the tray is open and there is no medium inserted, this will be a no-op.
#
-# This command is still a work in progress and is considered experimental.
-# Stay away from it unless you want to help with its development.
-#
# @device: #optional Block device name (deprecated, use @id instead)
#
# @id: #optional The name or QOM path of the guest device (since: 2.8)
#
+# Note: This command is still a work in progress and is considered
experimental.
+# Stay away from it unless you want to help with its development.
+#
# Since: 2.5
##
{ 'command': 'x-blockdev-remove-medium',
@@ -2550,15 +2550,15 @@
# device's tray must currently be open (unless there is no attached guest
# device) and there must be no medium inserted already.
#
-# This command is still a work in progress and is considered experimental.
-# Stay away from it unless you want to help with its development.
-#
# @device:#optional Block device name (deprecated, use @id instead)
#
# @id:#optional The name or QOM path of the guest device (since: 2.8)
#
# @node-name: name of a node in the block driver state graph
#
+# Note: This command is still a work in progress and is considered
experimental.
+# Stay away from it unless you want to help with its development.
+#
# Since: 2.5
##
{ 'command': 'x-blockdev-insert-medium',
--
2.11.0
[Qemu-devel] [PATCH v8 12/21] qapi.py: fix line break before binary operator pep8
Python code style accepts both form, but pep8 complains. Better to clean up the single warning for now, so new errors stand out more easily. Fix scripts/qapi.py:1539:21: W503 line break before binary operator Signed-off-by: Marc-André Lureau --- scripts/qapi.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/qapi.py b/scripts/qapi.py index 1483ec09f5..3d5f9e1eaf 100644 --- a/scripts/qapi.py +++ b/scripts/qapi.py @@ -1535,8 +1535,8 @@ def c_name(name, protect=True): # namespace pollution: polluted_words = set(['unix', 'errno', 'mips', 'sparc']) name = name.translate(c_name_trans) -if protect and (name in c89_words | c99_words | c11_words | gcc_words -| cpp_words | polluted_words): +if protect and (name in c89_words | c99_words | c11_words | gcc_words | +cpp_words | polluted_words): return "q_" + name return name -- 2.11.0
[Qemu-devel] [PATCH v8 02/21] qapi: move QKeyCode doc body at the top
Following documentation guidelines. Signed-off-by: Marc-André Lureau --- qapi-schema.json | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/qapi-schema.json b/qapi-schema.json index 1d4f27f1a3..bcbf72bf59 100644 --- a/qapi-schema.json +++ b/qapi-schema.json @@ -3612,6 +3612,10 @@ ## # @QKeyCode: # +# An enumeration of key name. +# +# This is used by the @send-key command. +# # @unmapped: since 2.0 # @pause: since 2.0 # @ro: since 2.4 @@ -3622,10 +3626,6 @@ # @henkan: since 2.9 # @yen: since 2.9 # -# An enumeration of key name. -# -# This is used by the send-key command. -# # Since: 1.3.0 # ## -- 2.11.0
[Qemu-devel] [PULL 2/3] cpu_common_reset: wrap TCG specific code in tcg_enabled()
Both the cpu->tb_jmp_cache and SoftMMU TLB structures are only used
when running TCG code so we might as well skip them for anything else.
Signed-off-by: Alex Bennée
Reviewed-by: Eduardo Habkost
---
qom/cpu.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/qom/cpu.c b/qom/cpu.c
index cc51de2a8c..61ee0cb88c 100644
--- a/qom/cpu.c
+++ b/qom/cpu.c
@@ -270,13 +270,15 @@ static void cpu_common_reset(CPUState *cpu)
cpu->exception_index = -1;
cpu->crash_occurred = false;
-for (i = 0; i < TB_JMP_CACHE_SIZE; ++i) {
-atomic_set(&cpu->tb_jmp_cache[i], NULL);
-}
+if (tcg_enabled()) {
+for (i = 0; i < TB_JMP_CACHE_SIZE; ++i) {
+atomic_set(&cpu->tb_jmp_cache[i], NULL);
+}
#ifdef CONFIG_SOFTMMU
-tlb_flush(cpu, 0);
+tlb_flush(cpu, 0);
#endif
+}
}
static bool cpu_common_has_work(CPUState *cs)
--
2.11.0
[Qemu-devel] [PATCH v8 10/21] 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
Reviewed-by: Markus Armbruster
---
docs/qemu-ga-ref.texi | 74 ++
docs/qemu-qmp-ref.texi | 74 ++
2 files changed, 148 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 00..b8898027dc
--- /dev/null
+++ b/docs/qemu-ga-ref.texi
@@ -0,0 +1,74 @@
+\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
+
+@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 00..efb3370a24
--- /dev/null
+++ b/docs/qemu-qmp-ref.texi
@@ -0,0 +1,74 @@
+\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
+
+@node Commands and Events Index
+@unnumbered Commands and Events Index
+@printindex fn
+
+@node Data Types Index
+@unnumbered Data Types Index
+@printindex tp
+
+@bye
--
2.11.0
[Qemu-devel] [PATCH v8 17/21] build-sys: use --no-split for info
Splitting the info files doesn't bring much benefits these days. This fixes also untracked generated info files from git ignore. Let's use MAKEINFOFLAGS for common flags, --number-sections is already the default anyway, so adding it doesn't change the info output. Signed-off-by: Marc-André Lureau Reviewed-by: Markus Armbruster --- Makefile | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index 360a6a24a2..82ee20150a 100644 --- a/Makefile +++ b/Makefile @@ -527,17 +527,17 @@ ui/console-gl.o: $(SRC_PATH)/ui/console-gl.c \ # documentation MAKEINFO=makeinfo -MAKEINFOFLAGS=--no-headers --no-split --number-sections +MAKEINFOFLAGS=--no-split --number-sections TEXIFLAG=$(if $(V),,--quiet) %.dvi: %.texi $(call quiet-command,texi2dvi $(TEXIFLAG) -I . $<,"GEN","$@") %.html: %.texi - $(call quiet-command,LC_ALL=C $(MAKEINFO) $(MAKEINFOFLAGS) --html $< -o $@, \ - "GEN","$@") + $(call quiet-command,LC_ALL=C $(MAKEINFO) $(MAKEINFOFLAGS) --no-headers \ + --html $< -o $@,"GEN","$@") %.info: %.texi - $(call quiet-command,$(MAKEINFO) $< -o $@,"GEN","$@") + $(call quiet-command,$(MAKEINFO) $(MAKEINFOFLAGS) $< -o $@,"GEN","$@") %.pdf: %.texi $(call quiet-command,texi2pdf $(TEXIFLAG) -I . $<,"GEN","$@") -- 2.11.0
[Qemu-devel] [PATCH v8 18/21] build-sys: remove dvi doc generation
There is no clear reason to have rules to generate dvi format documentation, pdf is generally better supported nowadays. Signed-off-by: Marc-André Lureau Reviewed-by: Markus Armbruster --- .gitignore | 1 - Makefile | 12 2 files changed, 4 insertions(+), 9 deletions(-) diff --git a/.gitignore b/.gitignore index e43c3044dc..3338bdc876 100644 --- a/.gitignore +++ b/.gitignore @@ -60,7 +60,6 @@ *.a *.aux *.cp -*.dvi *.exe *.msi *.dll diff --git a/Makefile b/Makefile index 82ee20150a..1d6a31deb3 100644 --- a/Makefile +++ b/Makefile @@ -80,7 +80,7 @@ GENERATED_HEADERS += module_block.h Makefile: ; configure: ; -.PHONY: all clean cscope distclean dvi html info install install-doc \ +.PHONY: all clean cscope distclean html info install install-doc \ pdf recurse-all speed test dist msi FORCE $(call set-vpath, $(SRC_PATH)) @@ -387,7 +387,7 @@ distclean: clean rm -f config-all-devices.mak config-all-disas.mak config.status rm -f po/*.mo tests/qemu-iotests/common.env rm -f roms/seabios/config.mak roms/vgabios/config.mak - rm -f qemu-doc.info qemu-doc.aux qemu-doc.cp qemu-doc.cps qemu-doc.dvi + rm -f qemu-doc.info qemu-doc.aux qemu-doc.cp qemu-doc.cps rm -f qemu-doc.fn qemu-doc.fns qemu-doc.info qemu-doc.ky qemu-doc.kys rm -f qemu-doc.log qemu-doc.pdf qemu-doc.pg qemu-doc.toc qemu-doc.tp rm -f qemu-doc.vr @@ -529,9 +529,6 @@ ui/console-gl.o: $(SRC_PATH)/ui/console-gl.c \ MAKEINFO=makeinfo MAKEINFOFLAGS=--no-split --number-sections TEXIFLAG=$(if $(V),,--quiet) -%.dvi: %.texi - $(call quiet-command,texi2dvi $(TEXIFLAG) -I . $<,"GEN","$@") - %.html: %.texi $(call quiet-command,LC_ALL=C $(MAKEINFO) $(MAKEINFOFLAGS) --no-headers \ --html $< -o $@,"GEN","$@") @@ -585,12 +582,11 @@ 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 -qemu-doc.dvi qemu-doc.html qemu-doc.info qemu-doc.pdf: \ +qemu-doc.html qemu-doc.info qemu-doc.pdf: \ qemu-img.texi qemu-nbd.texi qemu-options.texi qemu-option-trace.texi \ qemu-monitor.texi qemu-img-cmds.texi qemu-ga.texi \ qemu-monitor-info.texi @@ -687,7 +683,7 @@ help: @echo ' docker - Help about targets running tests inside Docker containers' @echo '' @echo 'Documentation targets:' - @echo ' dvi html info pdf' + @echo ' html info pdf' @echo ' - Build documentation in specified format' @echo '' ifdef CONFIG_WIN32 -- 2.11.0
[Qemu-devel] [PATCH v8 11/21] qapi: rework qapi Exception
Use a base class QAPIError, and QAPIParseError for parser errors and
QAPISemError for semantic errors, suggested by Markus Armbruster.
Signed-off-by: Marc-André Lureau
Reviewed-by: Markus Armbruster
---
scripts/qapi.py | 334 ++--
1 file changed, 156 insertions(+), 178 deletions(-)
diff --git a/scripts/qapi.py b/scripts/qapi.py
index 21bc32fda3..1483ec09f5 100644
--- a/scripts/qapi.py
+++ b/scripts/qapi.py
@@ -91,35 +91,38 @@ def error_path(parent):
return res
-class QAPISchemaError(Exception):
-def __init__(self, schema, msg):
+class QAPIError(Exception):
+def __init__(self, fname, line, col, incl_info, msg):
Exception.__init__(self)
-self.fname = schema.fname
+self.fname = fname
+self.line = line
+self.col = col
+self.info = incl_info
self.msg = msg
-self.col = 1
-self.line = schema.line
-for ch in schema.src[schema.line_pos:schema.pos]:
-if ch == '\t':
-self.col = (self.col + 7) % 8 + 1
-else:
-self.col += 1
-self.info = schema.incl_info
def __str__(self):
-return error_path(self.info) + \
-"%s:%d:%d: %s" % (self.fname, self.line, self.col, self.msg)
+loc = "%s:%d" % (self.fname, self.line)
+if self.col is not None:
+loc += ":%s" % self.col
+return error_path(self.info) + "%s: %s" % (loc, self.msg)
-class QAPIExprError(Exception):
-def __init__(self, expr_info, msg):
-Exception.__init__(self)
-assert expr_info
-self.info = expr_info
-self.msg = msg
+class QAPIParseError(QAPIError):
+def __init__(self, parser, msg):
+col = 1
+for ch in parser.src[parser.line_pos:parser.pos]:
+if ch == '\t':
+col = (col + 7) % 8 + 1
+else:
+col += 1
+QAPIError.__init__(self, parser.fname, parser.line, col,
+ parser.incl_info, msg)
-def __str__(self):
-return error_path(self.info['parent']) + \
-"%s:%d: %s" % (self.info['file'], self.info['line'], self.msg)
+
+class QAPISemError(QAPIError):
+def __init__(self, info, msg):
+QAPIError.__init__(self, info['file'], info['line'], None,
+ info['parent'], msg)
class QAPISchemaParser(object):
@@ -140,25 +143,24 @@ class QAPISchemaParser(object):
self.accept()
while self.tok is not None:
-expr_info = {'file': fname, 'line': self.line,
- 'parent': self.incl_info}
+info = {'file': fname, 'line': self.line,
+'parent': self.incl_info}
expr = self.get_expr(False)
if isinstance(expr, dict) and "include" in expr:
if len(expr) != 1:
-raise QAPIExprError(expr_info,
-"Invalid 'include' directive")
+raise QAPISemError(info, "Invalid 'include' directive")
include = expr["include"]
if not isinstance(include, str):
-raise QAPIExprError(expr_info,
-"Value of 'include' must be a string")
+raise QAPISemError(info,
+ "Value of 'include' must be a string")
incl_abs_fname = os.path.join(os.path.dirname(abs_fname),
include)
# catch inclusion cycle
-inf = expr_info
+inf = info
while inf:
if incl_abs_fname == os.path.abspath(inf['file']):
-raise QAPIExprError(expr_info, "Inclusion loop for %s"
-% include)
+raise QAPISemError(info, "Inclusion loop for %s"
+ % include)
inf = inf['parent']
# skip multiple include of the same file
if incl_abs_fname in previously_included:
@@ -166,14 +168,13 @@ class QAPISchemaParser(object):
try:
fobj = open(incl_abs_fname, 'r')
except IOError as e:
-raise QAPIExprError(expr_info,
-'%s: %s' % (e.strerror, include))
+raise QAPISemError(info, '%s: %s' % (e.strerror, include))
exprs_include = QAPISchemaParser(fobj, previously_included,
- expr_info)
+ info)
self.exprs.extend(exprs_include.exprs)
else:
expr_elem = {'expr': expr,
- 'info': expr_info}
+ 'i
[Qemu-devel] [PATCH v8 16/21] docs: add qemu logo to pdf
Add a logo to texi2pdf output. Other formats (info/html) are left as
future improvements.
The PDF (needed by texi2pdf for vectorized images) was generated from
pc-bios/qemu_logo.svg like this:
inkscape --export-pdf=docs/qemu_logo.pdf pc-bios/qemu_logo.svg
Signed-off-by: Marc-André Lureau
Reviewed-by: Markus Armbruster
---
docs/qemu-ga-ref.texi | 4
docs/qemu-qmp-ref.texi | 4
docs/qemu_logo.pdf | Bin 0 -> 9117 bytes
3 files changed, 8 insertions(+)
create mode 100644 docs/qemu_logo.pdf
diff --git a/docs/qemu-ga-ref.texi b/docs/qemu-ga-ref.texi
index b8898027dc..87cc8d01a5 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 efb3370a24..818e52573b 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{{R{fE*BHPWOqhq}AC)
z$ma9
[Qemu-devel] [PATCH v8 19/21] build-sys: use a generic TEXI2MAN rule
The recipe for making a man page from .texi is duplicated several times over. Capture it in suitable pattern rules instead. Signed-off-by: Marc-André Lureau Reviewed-by: Markus Armbruster --- Makefile | 24 rules.mak | 10 ++ 2 files changed, 10 insertions(+), 24 deletions(-) diff --git a/Makefile b/Makefile index 1d6a31deb3..4a4a34ed8b 100644 --- a/Makefile +++ b/Makefile @@ -552,35 +552,11 @@ 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.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 && \ - $(POD2MAN) --section=1 --center=" " --release=" " qemu.pod > $@, \ - "GEN","$@") qemu.1: qemu-option-trace.texi - qemu-img.1: qemu-img.texi qemu-option-trace.texi qemu-img-cmds.texi - $(call quiet-command, \ - perl -Ww -- $(SRC_PATH)/scripts/texi2pod.pl $< qemu-img.pod && \ - $(POD2MAN) --section=1 --center=" " --release=" " qemu-img.pod > $@, \ - "GEN","$@") - fsdev/virtfs-proxy-helper.1: fsdev/virtfs-proxy-helper.texi - $(call quiet-command, \ - perl -Ww -- $(SRC_PATH)/scripts/texi2pod.pl $< fsdev/virtfs-proxy-helper.pod && \ - $(POD2MAN) --section=1 --center=" " --release=" " fsdev/virtfs-proxy-helper.pod > $@, \ - "GEN","$@") - qemu-nbd.8: qemu-nbd.texi qemu-option-trace.texi - $(call quiet-command, \ - perl -Ww -- $(SRC_PATH)/scripts/texi2pod.pl $< qemu-nbd.pod && \ - $(POD2MAN) --section=8 --center=" " --release=" " qemu-nbd.pod > $@, \ - "GEN","$@") - qemu-ga.8: qemu-ga.texi - $(call quiet-command, \ - perl -Ww -- $(SRC_PATH)/scripts/texi2pod.pl $< qemu-ga.pod && \ - $(POD2MAN) --section=8 --center=" " --release=" " qemu-ga.pod > $@, \ - "GEN","$@") html: qemu-doc.html info: qemu-doc.info diff --git a/rules.mak b/rules.mak index ce9e7e6ffe..a7b6c0b020 100644 --- a/rules.mak +++ b/rules.mak @@ -363,3 +363,13 @@ define unnest-vars $(eval -include $(patsubst %.o,%.d,$(patsubst %.mo,%.d,$($v $(eval $v := $(filter-out %/,$($v endef + +TEXI2MAN = $(call quiet-command, \ + perl -Ww -- $(SRC_PATH)/scripts/texi2pod.pl $< $@.pod && \ + $(POD2MAN) --section=$(subst .,,$(suffix $@)) --center=" " --release=" " $@.pod > $@, \ + "GEN","$@") + +%.1: + $(call TEXI2MAN) +%.8: + $(call TEXI2MAN) -- 2.11.0
[Qemu-devel] [PULL 0/3] Common TLB reset changes
The following changes since commit b6c08970bc989bfddcf830684ea7a96b7a4d62a7: Merge remote-tracking branch 'remotes/bkoppelmann/tags/pull-tricore-2017-01-11-2' into staging (2017-01-12 18:29:49 +) are available in the git repository at: https://github.com/stsquad/qemu.git tags/pull-tcg-common-tlb-reset-20170113-r1 for you to fetch changes up to d10eb08f5d8389c814b554d01aa2882ac58221bf: cputlb: drop flush_global flag from tlb_flush (2017-01-13 14:24:37 +) This is the same as the v3 posted except a re-base and a few extra signoffs Alex Bennée (3): qom/cpu: move tlb_flush to cpu_common_reset cpu_common_reset: wrap TCG specific code in tcg_enabled() cputlb: drop flush_global flag from tlb_flush cputlb.c | 21 ++--- exec.c | 4 ++-- hw/sh4/sh7750.c| 2 +- include/exec/exec-all.h| 14 ++ qom/cpu.c | 10 -- target/alpha/cpu.c | 2 +- target/alpha/sys_helper.c | 2 +- target/arm/cpu.c | 5 ++--- target/arm/cpu.h | 5 - target/arm/helper.c| 26 +- target/cris/cpu.c | 3 +-- target/cris/cpu.h | 9 ++--- target/i386/cpu.c | 2 -- target/i386/cpu.h | 6 -- target/i386/fpu_helper.c | 2 +- target/i386/helper.c | 8 target/i386/machine.c | 2 +- target/i386/misc_helper.c | 2 +- target/i386/svm_helper.c | 2 +- target/lm32/cpu.c | 3 +-- target/lm32/cpu.h | 3 +++ target/m68k/cpu.c | 3 +-- target/m68k/cpu.h | 3 +++ target/microblaze/cpu.c| 3 +-- target/microblaze/cpu.h| 3 +++ target/microblaze/mmu.c| 2 +- target/mips/cpu.c | 3 +-- target/mips/cpu.h | 5 - target/mips/helper.c | 6 +++--- target/mips/op_helper.c| 8 target/moxie/cpu.c | 4 +--- target/moxie/cpu.h | 3 +++ target/openrisc/cpu.c | 9 + target/openrisc/cpu.h | 3 +++ target/openrisc/interrupt.c| 2 +- target/openrisc/interrupt_helper.c | 2 +- target/openrisc/sys_helper.c | 2 +- target/ppc/helper_regs.h | 4 ++-- target/ppc/misc_helper.c | 4 ++-- target/ppc/mmu_helper.c| 32 target/ppc/translate_init.c| 3 --- target/s390x/cpu.c | 7 ++- target/s390x/cpu.h | 5 +++-- target/s390x/gdbstub.c | 2 +- target/s390x/mem_helper.c | 8 target/sh4/cpu.c | 3 +-- target/sh4/cpu.h | 3 +++ target/sh4/helper.c| 2 +- target/sparc/cpu.c | 3 +-- target/sparc/cpu.h | 3 +++ target/sparc/ldst_helper.c | 12 ++-- target/tilegx/cpu.c| 3 +-- target/tilegx/cpu.h| 3 +++ target/tricore/cpu.c | 2 -- target/unicore32/cpu.c | 2 +- target/unicore32/helper.c | 2 +- target/xtensa/op_helper.c | 2 +- 57 files changed, 151 insertions(+), 148 deletions(-) -- 2.11.0
Re: [Qemu-devel] [PATCH] libvhost-user: Start VQs on SET_VRING_CALL
Hi
- Original Message -
> Currently, VQs are started as soon as a SET_VRING_KICK is received. That
> is too early in the VQ setup process, as the backend might not yet have
I think we may want to reconsider queue_set_started(), move it elsewhere, since
kick/call fds aren't mandatory to process the rings.
> a callfd to notify in case it received a kick and fully processed the
> request/command. This patch only starts a VQ when a SET_VRING_CALL is
> received.
I don't like that much, as soon as the kick fd is received, it should start
polling it imho. callfd is optional, it may have one and not the other.
Perhaps it's best for now to delay the callfd notification with a flag until it
is received?
> Signed-off-by: Felipe Franciosi
> ---
> contrib/libvhost-user/libvhost-user.c | 26 +-
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/contrib/libvhost-user/libvhost-user.c
> b/contrib/libvhost-user/libvhost-user.c
> index af4faad..a46ef90 100644
> --- a/contrib/libvhost-user/libvhost-user.c
> +++ b/contrib/libvhost-user/libvhost-user.c
> @@ -607,19 +607,6 @@ vu_set_vring_kick_exec(VuDev *dev, VhostUserMsg *vmsg)
> DPRINT("Got kick_fd: %d for vq: %d\n", vmsg->fds[0], index);
> }
>
> -dev->vq[index].started = true;
> -if (dev->iface->queue_set_started) {
> -dev->iface->queue_set_started(dev, index, true);
> -}
> -
> -if (dev->vq[index].kick_fd != -1 && dev->vq[index].handler) {
> -dev->set_watch(dev, dev->vq[index].kick_fd, VU_WATCH_IN,
> - vu_kick_cb, (void *)(long)index);
> -
> -DPRINT("Waiting for kicks on fd: %d for vq: %d\n",
> - dev->vq[index].kick_fd, index);
> -}
> -
> return false;
> }
>
> @@ -661,6 +648,19 @@ vu_set_vring_call_exec(VuDev *dev, VhostUserMsg *vmsg)
>
> DPRINT("Got call_fd: %d for vq: %d\n", vmsg->fds[0], index);
>
> +dev->vq[index].started = true;
> +if (dev->iface->queue_set_started) {
> +dev->iface->queue_set_started(dev, index, true);
> +}
> +
> +if (dev->vq[index].kick_fd != -1 && dev->vq[index].handler) {
> +dev->set_watch(dev, dev->vq[index].kick_fd, VU_WATCH_IN,
> + vu_kick_cb, (void *)(long)index);
> +
> +DPRINT("Waiting for kicks on fd: %d for vq: %d\n",
> + dev->vq[index].kick_fd, index);
> +}
> +
> return false;
> }
>
> --
> 1.9.4
>
>
[Qemu-devel] [PATCH v8 20/21] build-sys: add txt documentation rules
Build plain text documentation, and install it. Signed-off-by: Marc-André Lureau Reviewed-by: Markus Armbruster --- .gitignore | 1 + Makefile | 12 +--- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/.gitignore b/.gitignore index 3338bdc876..568c4bf9d3 100644 --- a/.gitignore +++ b/.gitignore @@ -40,6 +40,7 @@ /qmp-marshal.c /qemu-doc.html /qemu-doc.info +/qemu-doc.txt /qemu-img /qemu-nbd /qemu-options.def diff --git a/Makefile b/Makefile index 4a4a34ed8b..3280da201b 100644 --- a/Makefile +++ b/Makefile @@ -81,7 +81,7 @@ Makefile: ; configure: ; .PHONY: all clean cscope distclean html info install install-doc \ - pdf recurse-all speed test dist msi FORCE + pdf txt recurse-all speed test dist msi FORCE $(call set-vpath, $(SRC_PATH)) @@ -90,7 +90,7 @@ LIBS+=-lz $(LIBS_TOOLS) 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=qemu-doc.html qemu-doc.txt qemu.1 qemu-img.1 qemu-nbd.8 qemu-ga.8 ifdef CONFIG_VIRTFS DOCS+=fsdev/virtfs-proxy-helper.1 endif @@ -429,6 +429,7 @@ endif install-doc: $(DOCS) $(INSTALL_DIR) "$(DESTDIR)$(qemu_docdir)" $(INSTALL_DATA) qemu-doc.html "$(DESTDIR)$(qemu_docdir)" + $(INSTALL_DATA) qemu-doc.txt "$(DESTDIR)$(qemu_docdir)" ifdef CONFIG_POSIX $(INSTALL_DIR) "$(DESTDIR)$(mandir)/man1" $(INSTALL_DATA) qemu.1 "$(DESTDIR)$(mandir)/man1" @@ -536,6 +537,10 @@ TEXIFLAG=$(if $(V),,--quiet) %.info: %.texi $(call quiet-command,$(MAKEINFO) $(MAKEINFOFLAGS) $< -o $@,"GEN","$@") +%.txt: %.texi + $(call quiet-command,LC_ALL=C $(MAKEINFO) $(MAKEINFOFLAGS) --no-headers \ + --plaintext $< -o $@,"GEN","$@") + %.pdf: %.texi $(call quiet-command,texi2pdf $(TEXIFLAG) -I . $<,"GEN","$@") @@ -561,6 +566,7 @@ qemu-ga.8: qemu-ga.texi html: qemu-doc.html info: qemu-doc.info pdf: qemu-doc.pdf +txt: qemu-doc.txt qemu-doc.html qemu-doc.info qemu-doc.pdf: \ qemu-img.texi qemu-nbd.texi qemu-options.texi qemu-option-trace.texi \ @@ -659,7 +665,7 @@ help: @echo ' docker - Help about targets running tests inside Docker containers' @echo '' @echo 'Documentation targets:' - @echo ' html info pdf' + @echo ' html info pdf txt' @echo ' - Build documentation in specified format' @echo '' ifdef CONFIG_WIN32 -- 2.11.0
[Qemu-devel] [PATCH v8 21/21] build-sys: add qapi doc generation targets
Generate and install the man, txt and html versions of QAPI documentation (generate and install qemu-doc.txt too). Add it also to optional pdf/info targets. Signed-off-by: Marc-André Lureau --- .gitignore | 9 + Makefile | 43 --- configure | 2 +- docs/qmp-intro.txt | 3 +-- rules.mak | 2 ++ 5 files changed, 49 insertions(+), 10 deletions(-) diff --git a/.gitignore b/.gitignore index 568c4bf9d3..78f180a020 100644 --- a/.gitignore +++ b/.gitignore @@ -105,6 +105,15 @@ /pc-bios/optionrom/kvmvapic.img /pc-bios/s390-ccw/s390-ccw.elf /pc-bios/s390-ccw/s390-ccw.img +/docs/qemu-ga-ref.html +/docs/qemu-ga-ref.txt +/docs/qemu-qmp-ref.html +/docs/qemu-qmp-ref.txt +docs/qemu-ga-ref.info* +docs/qemu-qmp-ref.info* +/qemu-ga-qapi.texi +/qemu-qapi.texi +*.tps .stgit-* cscope.* tags diff --git a/Makefile b/Makefile index 3280da201b..9f8968d047 100644 --- a/Makefile +++ b/Makefile @@ -91,6 +91,8 @@ HELPERS-$(CONFIG_LINUX) = qemu-bridge-helper$(EXESUF) ifdef BUILD_DOCS DOCS=qemu-doc.html qemu-doc.txt qemu.1 qemu-img.1 qemu-nbd.8 qemu-ga.8 +DOCS+=docs/qemu-qmp-ref.html docs/qemu-qmp-ref.txt docs/qemu-qmp-ref.7 +DOCS+=docs/qemu-ga-ref.html docs/qemu-ga-ref.txt docs/qemu-ga-ref.7 ifdef CONFIG_VIRTFS DOCS+=fsdev/virtfs-proxy-helper.1 endif @@ -265,6 +267,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) @@ -393,6 +396,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 @@ -430,9 +438,13 @@ install-doc: $(DOCS) $(INSTALL_DIR) "$(DESTDIR)$(qemu_docdir)" $(INSTALL_DATA) qemu-doc.html "$(DESTDIR)$(qemu_docdir)" $(INSTALL_DATA) qemu-doc.txt "$(DESTDIR)$(qemu_docdir)" + $(INSTALL_DATA) docs/qemu-qmp-ref.html "$(DESTDIR)$(qemu_docdir)" + $(INSTALL_DATA) docs/qemu-qmp-ref.txt "$(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" @@ -440,6 +452,9 @@ 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.txt "$(DESTDIR)$(qemu_docdir)" + $(INSTALL_DATA) docs/qemu-ga-ref.7 "$(DESTDIR)$(mandir)/man7" endif endif ifdef CONFIG_VIRTFS @@ -527,9 +542,10 @@ 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-split --number-sections -TEXIFLAG=$(if $(V),,--quiet) +TEXIFLAG=$(if $(V),,--quiet) --command='@set VERSION $(VERSION)' + %.html: %.texi $(call quiet-command,LC_ALL=C $(MAKEINFO) $(MAKEINFOFLAGS) --no-headers \ --html $< -o $@,"GEN","$@") @@ -542,7 +558,7 @@ TEXIFLAG=$(if $(V),,--quiet) --plaintext $< -o $@,"GEN","$@") %.pdf: %.texi - $(call quiet-command,texi2pdf $(TEXIFLAG) -I . $<,"GEN","$@") + $(call quiet-command,texi2pdf $(TEXIFLAG) -I $(SRC_PATH) -I . $< -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 +572,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 qemu.1: qemu-option-trace.texi qemu-img.1: qemu-img.texi qe
[Qemu-devel] [PULL 3/3] cputlb: drop flush_global flag from tlb_flush
We have never has the concept of global TLB entries which would avoid
the flush so we never actually use this flag. Drop it and make clear
that tlb_flush is the sledge-hammer it has always been.
Signed-off-by: Alex Bennée
Reviewed-by: Richard Henderson
[DG: ppc portions]
Acked-by: David Gibson
---
cputlb.c | 21 ++---
exec.c | 4 ++--
hw/sh4/sh7750.c| 2 +-
include/exec/exec-all.h| 14 ++
target/alpha/cpu.c | 2 +-
target/alpha/sys_helper.c | 2 +-
target/arm/helper.c| 26 +-
target/i386/fpu_helper.c | 2 +-
target/i386/helper.c | 8
target/i386/machine.c | 2 +-
target/i386/misc_helper.c | 2 +-
target/i386/svm_helper.c | 2 +-
target/microblaze/mmu.c| 2 +-
target/mips/cpu.h | 2 +-
target/mips/helper.c | 6 +++---
target/mips/op_helper.c| 8
target/openrisc/interrupt.c| 2 +-
target/openrisc/interrupt_helper.c | 2 +-
target/openrisc/sys_helper.c | 2 +-
target/ppc/helper_regs.h | 4 ++--
target/ppc/misc_helper.c | 4 ++--
target/ppc/mmu_helper.c| 32
target/s390x/gdbstub.c | 2 +-
target/s390x/mem_helper.c | 8
target/sh4/helper.c| 2 +-
target/sparc/ldst_helper.c | 12 ++--
target/unicore32/cpu.c | 2 +-
target/unicore32/helper.c | 2 +-
target/xtensa/op_helper.c | 2 +-
29 files changed, 85 insertions(+), 96 deletions(-)
diff --git a/cputlb.c b/cputlb.c
index 813279f3bc..6c39927455 100644
--- a/cputlb.c
+++ b/cputlb.c
@@ -60,24 +60,15 @@
/* statistics */
int tlb_flush_count;
-/* NOTE:
- * If flush_global is true (the usual case), flush all tlb entries.
- * If flush_global is false, flush (at least) all tlb entries not
- * marked global.
- *
- * Since QEMU doesn't currently implement a global/not-global flag
- * for tlb entries, at the moment tlb_flush() will also flush all
- * tlb entries in the flush_global == false case. This is OK because
- * CPU architectures generally permit an implementation to drop
- * entries from the TLB at any time, so flushing more entries than
- * required is only an efficiency issue, not a correctness issue.
+/* This is OK because CPU architectures generally permit an
+ * implementation to drop entries from the TLB at any time, so
+ * flushing more entries than required is only an efficiency issue,
+ * not a correctness issue.
*/
-void tlb_flush(CPUState *cpu, int flush_global)
+void tlb_flush(CPUState *cpu)
{
CPUArchState *env = cpu->env_ptr;
-tlb_debug("(%d)\n", flush_global);
-
memset(env->tlb_table, -1, sizeof(env->tlb_table));
memset(env->tlb_v_table, -1, sizeof(env->tlb_v_table));
memset(cpu->tb_jmp_cache, 0, sizeof(cpu->tb_jmp_cache));
@@ -144,7 +135,7 @@ void tlb_flush_page(CPUState *cpu, target_ulong addr)
TARGET_FMT_lx "/" TARGET_FMT_lx ")\n",
env->tlb_flush_addr, env->tlb_flush_mask);
-tlb_flush(cpu, 1);
+tlb_flush(cpu);
return;
}
diff --git a/exec.c b/exec.c
index 47835c1dc1..401a9127c2 100644
--- a/exec.c
+++ b/exec.c
@@ -544,7 +544,7 @@ static int cpu_common_post_load(void *opaque, int
version_id)
/* 0x01 was CPU_INTERRUPT_EXIT. This line can be removed when the
version_id is increased. */
cpu->interrupt_request &= ~0x01;
-tlb_flush(cpu, 1);
+tlb_flush(cpu);
return 0;
}
@@ -2426,7 +2426,7 @@ static void tcg_commit(MemoryListener *listener)
*/
d = atomic_rcu_read(&cpuas->as->dispatch);
atomic_rcu_set(&cpuas->memory_dispatch, d);
-tlb_flush(cpuas->cpu, 1);
+tlb_flush(cpuas->cpu);
}
void address_space_init_dispatch(AddressSpace *as)
diff --git a/hw/sh4/sh7750.c b/hw/sh4/sh7750.c
index 3132d559d7..166e4bd947 100644
--- a/hw/sh4/sh7750.c
+++ b/hw/sh4/sh7750.c
@@ -417,7 +417,7 @@ static void sh7750_mem_writel(void *opaque, hwaddr addr,
case SH7750_PTEH_A7:
/* If asid changes, clear all registered tlb entries. */
if ((s->cpu->env.pteh & 0xff) != (mem_value & 0xff)) {
-tlb_flush(CPU(s->cpu), 1);
+tlb_flush(CPU(s->cpu));
}
s->cpu->env.pteh = mem_value;
return;
diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h
index a8c13cee66..bbc9478a50 100644
--- a/include/exec/exec-all.h
+++ b/include/exec/exec-all.h
@@ -95,15 +95,13 @@ void tlb_flush_page(CPUState *cpu, target_ulong addr);
/**
* tlb_flush:
* @cpu: CPU whose TLB should be flushed
- * @flush_global: ignored
*
- * Flush the entire TLB for the specified CPU.
- * The flush_global flag is in theory an indicator of whether the whole
- * TLB should be flushed, or
Re: [Qemu-devel] [PATCH 0/2] virtio: revert virtio_queue_set_notification() nesting
On 1/12/17 2:05 PM, Michael S. Tsirkin wrote: > On Thu, Jan 12, 2017 at 10:57:53AM -0600, Doug Goldstein wrote: >> On 1/12/17 5:46 AM, Stefan Hajnoczi wrote: >>> The virtio_queue_set_notification() nesting introduced for AioContext >>> polling >>> raised an assertion with virtio-net (even in non-polling mode). Converting >>> virtio-net and virtio-crypto to use virtio_queue_set_notification() in a >>> nesting fashion would be invasive and isn't worth it. >>> >>> Patch 1 contains the revert to resolve the bug that Doug noticed. >>> >>> Patch 2 is a less efficient but safe alternative. >>> >>> Stefan Hajnoczi (2): >>> Revert "virtio: turn vq->notification into a nested counter" >>> virtio: disable notifications again after poll succeeded >>> >>> hw/virtio/virtio.c | 21 + >>> 1 file changed, 9 insertions(+), 12 deletions(-) >>> >> >> So I just gave this series a whirl and it fixes the assert but causes >> another issue for me. While iPXE is getting a DHCP address the screen >> immediately flashes over to the UEFI shell. Its like a timeout is >> getting hit and just dropping me to the shell. >> >> -- >> Doug Goldstein >> > > Is this just with UEFI or with seabios as well? > Sorry for the delay on responding. I've now tested seabios and UEFI (using OVMF). The issue is only happening via UEFI and it works fine with seabios. -- Doug Goldstein signature.asc Description: OpenPGP digital signature
[Qemu-devel] [PULL 1/3] qom/cpu: move tlb_flush to cpu_common_reset
It is a common thing amongst the various cpu reset functions want to
flush the SoftMMU's TLB entries. This is done either by calling
tlb_flush directly or by way of a general memset of the CPU
structure (sometimes both).
This moves the tlb_flush call to the common reset function and
additionally ensures it is only done for the CONFIG_SOFTMMU case and
when tcg is enabled.
In some target cases we add an empty end_of_reset_fields structure to the
target vCPU structure so have a clear end point for any memset which
is resetting value in the structure before CPU_COMMON (where the TLB
structures are).
While this is a nice clean-up in general it is also a precursor for
changes coming to cputlb for MTTCG where the clearing of entries
can't be done arbitrarily across vCPUs. Currently the cpu_reset
function is usually called from the context of another vCPU as the
architectural power up sequence is run. By using the cputlb API
functions we can ensure the right behaviour in the future.
Signed-off-by: Alex Bennée
Reviewed-by: Richard Henderson
Reviewed-by: David Gibson
---
qom/cpu.c | 4
target/arm/cpu.c| 5 ++---
target/arm/cpu.h| 5 -
target/cris/cpu.c | 3 +--
target/cris/cpu.h | 9 ++---
target/i386/cpu.c | 2 --
target/i386/cpu.h | 6 --
target/lm32/cpu.c | 3 +--
target/lm32/cpu.h | 3 +++
target/m68k/cpu.c | 3 +--
target/m68k/cpu.h | 3 +++
target/microblaze/cpu.c | 3 +--
target/microblaze/cpu.h | 3 +++
target/mips/cpu.c | 3 +--
target/mips/cpu.h | 3 +++
target/moxie/cpu.c | 4 +---
target/moxie/cpu.h | 3 +++
target/openrisc/cpu.c | 9 +
target/openrisc/cpu.h | 3 +++
target/ppc/translate_init.c | 3 ---
target/s390x/cpu.c | 7 ++-
target/s390x/cpu.h | 5 +++--
target/sh4/cpu.c| 3 +--
target/sh4/cpu.h| 3 +++
target/sparc/cpu.c | 3 +--
target/sparc/cpu.h | 3 +++
target/tilegx/cpu.c | 3 +--
target/tilegx/cpu.h | 3 +++
target/tricore/cpu.c| 2 --
29 files changed, 62 insertions(+), 50 deletions(-)
diff --git a/qom/cpu.c b/qom/cpu.c
index 03d9190f8c..cc51de2a8c 100644
--- a/qom/cpu.c
+++ b/qom/cpu.c
@@ -273,6 +273,10 @@ static void cpu_common_reset(CPUState *cpu)
for (i = 0; i < TB_JMP_CACHE_SIZE; ++i) {
atomic_set(&cpu->tb_jmp_cache[i], NULL);
}
+
+#ifdef CONFIG_SOFTMMU
+tlb_flush(cpu, 0);
+#endif
}
static bool cpu_common_has_work(CPUState *cs)
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index f5cb30af6c..91046111d9 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -122,7 +122,8 @@ static void arm_cpu_reset(CPUState *s)
acc->parent_reset(s);
-memset(env, 0, offsetof(CPUARMState, features));
+memset(env, 0, offsetof(CPUARMState, end_reset_fields));
+
g_hash_table_foreach(cpu->cp_regs, cp_reg_reset, cpu);
g_hash_table_foreach(cpu->cp_regs, cp_reg_check_reset, cpu);
@@ -226,8 +227,6 @@ static void arm_cpu_reset(CPUState *s)
&env->vfp.fp_status);
set_float_detect_tininess(float_tininess_before_rounding,
&env->vfp.standard_fp_status);
-tlb_flush(s, 1);
-
#ifndef CONFIG_USER_ONLY
if (kvm_enabled()) {
kvm_arm_reset_vcpu(cpu);
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index ab119e62ab..7bd16eec18 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -491,9 +491,12 @@ typedef struct CPUARMState {
struct CPUBreakpoint *cpu_breakpoint[16];
struct CPUWatchpoint *cpu_watchpoint[16];
+/* Fields up to this point are cleared by a CPU reset */
+struct {} end_reset_fields;
+
CPU_COMMON
-/* These fields after the common ones so they are preserved on reset. */
+/* Fields after CPU_COMMON are preserved across CPU reset. */
/* Internal CPU feature flags. */
uint64_t features;
diff --git a/target/cris/cpu.c b/target/cris/cpu.c
index 2e9ab9700e..5f766f09d6 100644
--- a/target/cris/cpu.c
+++ b/target/cris/cpu.c
@@ -52,9 +52,8 @@ static void cris_cpu_reset(CPUState *s)
ccc->parent_reset(s);
vr = env->pregs[PR_VR];
-memset(env, 0, offsetof(CPUCRISState, load_info));
+memset(env, 0, offsetof(CPUCRISState, end_reset_fields));
env->pregs[PR_VR] = vr;
-tlb_flush(s, 1);
#if defined(CONFIG_USER_ONLY)
/* start in user mode with interrupts enabled. */
diff --git a/target/cris/cpu.h b/target/cris/cpu.h
index 43d5f9d1da..920e1c33ba 100644
--- a/target/cris/cpu.h
+++ b/target/cris/cpu.h
@@ -167,10 +167,13 @@ typedef struct CPUCRISState {
*/
TLBSet tlbsets[2][4][16];
- CPU_COMMON
+/* Fields up to this point are cleared by a CPU reset */
+struct {} end_reset_fields;
-/* Members from load_info on are preserved across resets. */
-void *load_info;
+
Re: [Qemu-devel] [PATCH] libvhost-user: Start VQs on SET_VRING_CALL
Hi Marc-Andre,
> On 13 Jan 2017, at 07:03, Marc-André Lureau wrote:
>
> Hi
>
> - Original Message -
>> Currently, VQs are started as soon as a SET_VRING_KICK is received. That
>> is too early in the VQ setup process, as the backend might not yet have
>
> I think we may want to reconsider queue_set_started(), move it elsewhere,
> since kick/call fds aren't mandatory to process the rings.
Hmm. The fds aren't mandatory, but I imagine in that case we should still
receive SET_VRING_KICK/CALL messages without an fd (ie. with the
VHOST_MSG_VQ_NOFD_MASK flag set). Wouldn't that be the case?
>
>> a callfd to notify in case it received a kick and fully processed the
>> request/command. This patch only starts a VQ when a SET_VRING_CALL is
>> received.
>
> I don't like that much, as soon as the kick fd is received, it should start
> polling it imho. callfd is optional, it may have one and not the other.
So the question is whether we should be receiving a SET_VRING_CALL anyway or
not, regardless of an fd being sent. (I think we do, but I haven't done
extensive testing with other device types.)
>
> Perhaps it's best for now to delay the callfd notification with a flag until
> it is received?
The other idea is to always kick when we receive the callfd. I remember
discussing that alternative with you before libvhost-user went in. The protocol
says both the driver and the backend must handle spurious kicks. This approach
also fixes the bug.
I'm happy with whatever alternative you want, as long it makes libvhost-user
usable for storage devices.
Thanks,
Felipe
>
>
>> Signed-off-by: Felipe Franciosi
>> ---
>> contrib/libvhost-user/libvhost-user.c | 26 +-
>> 1 file changed, 13 insertions(+), 13 deletions(-)
>>
>> diff --git a/contrib/libvhost-user/libvhost-user.c
>> b/contrib/libvhost-user/libvhost-user.c
>> index af4faad..a46ef90 100644
>> --- a/contrib/libvhost-user/libvhost-user.c
>> +++ b/contrib/libvhost-user/libvhost-user.c
>> @@ -607,19 +607,6 @@ vu_set_vring_kick_exec(VuDev *dev, VhostUserMsg *vmsg)
>> DPRINT("Got kick_fd: %d for vq: %d\n", vmsg->fds[0], index);
>> }
>>
>> -dev->vq[index].started = true;
>> -if (dev->iface->queue_set_started) {
>> -dev->iface->queue_set_started(dev, index, true);
>> -}
>> -
>> -if (dev->vq[index].kick_fd != -1 && dev->vq[index].handler) {
>> -dev->set_watch(dev, dev->vq[index].kick_fd, VU_WATCH_IN,
>> - vu_kick_cb, (void *)(long)index);
>> -
>> -DPRINT("Waiting for kicks on fd: %d for vq: %d\n",
>> - dev->vq[index].kick_fd, index);
>> -}
>> -
>> return false;
>> }
>>
>> @@ -661,6 +648,19 @@ vu_set_vring_call_exec(VuDev *dev, VhostUserMsg *vmsg)
>>
>> DPRINT("Got call_fd: %d for vq: %d\n", vmsg->fds[0], index);
>>
>> +dev->vq[index].started = true;
>> +if (dev->iface->queue_set_started) {
>> +dev->iface->queue_set_started(dev, index, true);
>> +}
>> +
>> +if (dev->vq[index].kick_fd != -1 && dev->vq[index].handler) {
>> +dev->set_watch(dev, dev->vq[index].kick_fd, VU_WATCH_IN,
>> + vu_kick_cb, (void *)(long)index);
>> +
>> +DPRINT("Waiting for kicks on fd: %d for vq: %d\n",
>> + dev->vq[index].kick_fd, index);
>> +}
>> +
>> return false;
>> }
>>
>> --
>> 1.9.4
>>
>>
Re: [Qemu-devel] [PATCH 0/2] virtio: revert virtio_queue_set_notification() nesting
On 1/13/17 6:02 AM, Stefan Hajnoczi wrote: > On Thu, Jan 12, 2017 at 10:57:53AM -0600, Doug Goldstein wrote: >> On 1/12/17 5:46 AM, Stefan Hajnoczi wrote: >>> The virtio_queue_set_notification() nesting introduced for AioContext >>> polling >>> raised an assertion with virtio-net (even in non-polling mode). Converting >>> virtio-net and virtio-crypto to use virtio_queue_set_notification() in a >>> nesting fashion would be invasive and isn't worth it. >>> >>> Patch 1 contains the revert to resolve the bug that Doug noticed. >>> >>> Patch 2 is a less efficient but safe alternative. >>> >>> Stefan Hajnoczi (2): >>> Revert "virtio: turn vq->notification into a nested counter" >>> virtio: disable notifications again after poll succeeded >>> >>> hw/virtio/virtio.c | 21 + >>> 1 file changed, 9 insertions(+), 12 deletions(-) >>> >> >> So I just gave this series a whirl and it fixes the assert but causes >> another issue for me. While iPXE is getting a DHCP address the screen >> immediately flashes over to the UEFI shell. Its like a timeout is >> getting hit and just dropping me to the shell. > > Sounds like an separate problem. > > Stefan > Is there any debug output that I can provide to help troubleshoot it? I've built 23425cc and UEFI via OVMF is able to get an IP address via DHCP inside of iPXE. I've also taken master and only applied the first patch in this series (the revert) and it too works. Its only when I add the 2nd patch into the mix or don't revert out the "virtio: turn vq->notification into a nested counter" patch that it fails. -- Doug Goldstein signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH RFC v3 1/2] block/qapi: reduce the coupling between the bdrv_query_stats and bdrv_query_bds_stats
On 01/04/2017 12:58 AM, Dou Liyang wrote:
> the bdrv_query_stats and bdrv_query_bds_stats functions need to call
> each other, that increases the coupling. it also makes the program
> complicated and makes some unnecessary judgements.
s/judgements/judgments/ - although I wonder if 'tests' would be a
simpler word.
>
> remove the call from bdrv_query_bds_stats to bdrv_query_stats, just
> take some recursion to make it clearly.
>
> avoid judging whether the blk is NULL during querying the bds stats.
Again, 'testing' might read nicer than 'judging'.
> it is unnecessary.
>
> Signed-off-by: Dou Liyang
> ---
> block/qapi.c | 26 ++
> 1 file changed, 14 insertions(+), 12 deletions(-)
>
> -static void bdrv_query_bds_stats(BlockStats *s, const BlockDriverState *bs,
> +static BlockStats *bdrv_query_bds_stats(const BlockDriverState *bs,
> bool query_backing)
> {
> +BlockStats *s = NULL;
> +
> +s = g_malloc0(sizeof(*s));
Dead initialization to NULL since the very next statement overwrites it.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 18/40] char: remove class kind field
Hi
- Original Message -
> On 01/11/2017 11:29 AM, Marc-André Lureau wrote:
> > The class kind is necessary to lookup the chardev name in
> > qmp_chardev_add() after calling qemu_chr_new_from_opts() and to set
> > the appropriate ChardevBackend (mainly to free the right
> > fields).
> >
> > qemu_chr_new_from_opts() can be changed to use a non-qmp function
> > using the chardev class typename. Introduce qemu_chardev_add() to be
> > called from qemu_chr_new_from_opts() and remove the class chardev kind
> > field. Set the backend->type in the parse callback (when non-common
> > fields are added).
> >
> > Signed-off-by: Marc-André Lureau
> > ---
>
> >
> > +static Chardev *qemu_chardev_add(const char *id, const char *typename,
> > + ChardevBackend *backend, Error **errp)
> > +{
> > +Chardev *chr;
> > +
> > +chr = qemu_chr_find(id);
> > +if (chr) {
> > +error_setg(errp, "Chardev '%s' already exists", id);
> > +return NULL;
> > +}
> > +
> > +chr = qemu_chardev_new(id, typename, backend, errp);
> > +if (!chr) {
> > +return NULL;
> > +}
> > +
> > +QTAILQ_INSERT_TAIL(&chardevs, chr, next);
> > +return chr;
> > +}
> > +
>
> This part seems okay.
>
> > @@ -4222,22 +4235,22 @@ Chardev *qemu_chr_new_from_opts(QemuOpts *opts,
> >
> > cc = char_get_class(name, errp);
> > if (cc == NULL) {
> > -goto err;
> > +return NULL;
> > }
> >
> > backend = g_new0(ChardevBackend, 1);
> > +backend->type = CHARDEV_BACKEND_KIND_NULL;
> >
> > if (qemu_opt_get_bool(opts, "mux", 0)) {
> > bid = g_strdup_printf("%s-base", id);
> > }
> >
> > chr = NULL;
> > -backend->type = cc->kind;
>
> I'm not sure I follow this hunk - we used to set backend->type
> dynamically and now it is forced to KIND_NULL. Is the point that we
> don't need to set backend->type here because the later call to
> qemu_chardev_add()...
I tried to explain some of the reasons in the commit message.
We need backend->type to be set correctly for the qapi_free_ChardevBackend() to
work. The kind field used to be on a class member, but we try to get rid of it.
So we move that information to _parse(), and change the backend type
appropriately there.
KIND_NULL is the common backend (sharing ChardevCommon).
>
> > @@ -4245,37 +4258,33 @@ Chardev *qemu_chr_new_from_opts(QemuOpts *opts,
> > backend->u.null.data = ccom; /* Any ChardevCommon member would
> > work */
> > }
> >
> > -ret = qmp_chardev_add(bid ? bid : id, backend, errp);
> > -if (!ret) {
> > -goto qapi_out;
> > +chr = qemu_chardev_add(bid ? bid : id,
> > + object_class_get_name(OBJECT_CLASS(cc)),
> > + backend, errp);
>
> ...now passes the Object type which can be used to derive the same same
> information? In that case, was the assignment to backend->type =
> KIND_NULL dead?
0 is KIND_FILE, which would lead to invalid free.
> > +if (chr == NULL) {
> > +goto out;
> > }
> >
> > if (bid) {
> > +Chardev *mux;
> > qapi_free_ChardevBackend(backend);
> > -qapi_free_ChardevReturn(ret);
> > backend = g_new0(ChardevBackend, 1);
> > -backend->u.mux.data = g_new0(ChardevMux, 1);
> > backend->type = CHARDEV_BACKEND_KIND_MUX;
> > +backend->u.mux.data = g_new0(ChardevMux, 1);
>
> Why the churn on the assignment to backend->u.mux.data?
fixed
>
> > backend->u.mux.data->chardev = g_strdup(bid);
> > -ret = qmp_chardev_add(id, backend, errp);
> > -if (!ret) {
> > -chr = qemu_chr_find(bid);
> > +mux = qemu_chardev_add(id, TYPE_CHARDEV_MUX, backend, errp);
> > +if (mux == NULL) {
> > qemu_chr_delete(chr);
> > chr = NULL;
> > -goto qapi_out;
> > +goto out;
> > }
> > +chr = mux;
> > }
> >
> > -chr = qemu_chr_find(id);
> > -
> > -qapi_out:
> > +out:
> > qapi_free_ChardevBackend(backend);
> > -qapi_free_ChardevReturn(ret);
> > g_free(bid);
> > return chr;
> > -
> > -err:
> > -return NULL;
> > }
> >
>
> > @@ -5010,24 +5014,18 @@ Chardev *qemu_chardev_new(const char *id, const
> > char *typename,
> > ChardevReturn *qmp_chardev_add(const char *id, ChardevBackend *backend,
> > Error **errp)
> > {
> > -const ChardevClass *cc;
> > ChardevReturn *ret;
> > +const ChardevClass *cc;
>
> Why the churn on this declaration?
sorry, too many rebases, conflicts.. fixed
>
> > Chardev *chr;
> >
> > -chr = qemu_chr_find(id);
> > -if (chr) {
> > -error_setg(errp, "Chardev '%s' already exists", id);
> > -return NULL;
> > -}
> > -
> > cc = char_get_class(ChardevBackendKind_lookup[backend->type], errp);
> > -if (!cc) {
> > +if (cc == NULL) {
>
Re: [Qemu-devel] [PATCH 2/2] virtio: disable notifications again after poll succeeded
On Thu, Jan 12, 2017 at 11:46:11AM +, Stefan Hajnoczi wrote: > While AioContext is in polling mode virtqueue notifications are not > necessary. Some device virtqueue handlers enable notifications. Make > sure they stay disabled to avoid unnecessary vmexits. > > Signed-off-by: Stefan Hajnoczi So I'll put just the revert in today's pull request, let's make sure this one is not causing regressions. > --- > hw/virtio/virtio.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c > index f04ab7a..34065c7 100644 > --- a/hw/virtio/virtio.c > +++ b/hw/virtio/virtio.c > @@ -2126,6 +2126,9 @@ static bool virtio_queue_host_notifier_aio_poll(void > *opaque) > } > > virtio_queue_notify_aio_vq(vq); > + > +/* In case the handler function re-enabled notifications */ > +virtio_queue_set_notification(vq, 0); > return true; > } > > -- > 2.9.3
Re: [Qemu-devel] [PATCH RFC v3 00/14] VT-d: vfio enablement and misc enhances
On Fri, Jan 13, 2017 at 11:06:26AM +0800, Peter Xu wrote: > v3: > - fix style error reported by patchew > - fix comment in domain switch patch: use "IOMMU address space" rather > than "IOMMU region" [Kevin] > - add ack-by for Paolo in patch: > "memory: add section range info for IOMMU notifier" > (this is seperately collected besides this thread) > - remove 3 patches which are merged already (from Jason) > - rebase to master b6c0897 So 1-6 look like nice cleanups to me. Should I merge them now? > v2: > - change comment for "end" parameter in vtd_page_walk() [Tianyu] > - change comment for "a iova" to "an iova" [Yi] > - fix fault printed val for GPA address in vtd_page_walk_level (debug > only) > - rebased to master (rather than Aviv's v6 series) and merged Aviv's > series v6: picked patch 1 (as patch 1 in this series), dropped patch > 2, re-wrote patch 3 (as patch 17 of this series). > - picked up two more bugfix patches from Jason's DMAR series > - picked up the following patch as well: > "[PATCH v3] intel_iommu: allow dynamic switch of IOMMU region" > > This RFC series is a re-work for Aviv B.D.'s vfio enablement series > with vt-d: > > https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg01452.html > > Aviv has done a great job there, and what we still lack there are > mostly the following: > > (1) VFIO got duplicated IOTLB notifications due to splitted VT-d IOMMU > memory region. > > (2) VT-d still haven't provide a correct replay() mechanism (e.g., > when IOMMU domain switches, things will broke). > > This series should have solved the above two issues. > > Online repo: > > https://github.com/xzpeter/qemu/tree/vtd-vfio-enablement-v2 > > I would be glad to hear about any review comments for above patches. > > = > Test Done > = > > Build test passed for x86_64/arm/ppc64. > > Simply tested with x86_64, assigning two PCI devices to a single VM, > boot the VM using: > > bin=x86_64-softmmu/qemu-system-x86_64 > $bin -M q35,accel=kvm,kernel-irqchip=split -m 1G \ > -device intel-iommu,intremap=on,eim=off,cache-mode=on \ > -netdev user,id=net0,hostfwd=tcp::-:22 \ > -device virtio-net-pci,netdev=net0 \ > -device vfio-pci,host=03:00.0 \ > -device vfio-pci,host=02:00.0 \ > -trace events=".trace.vfio" \ > /var/lib/libvirt/images/vm1.qcow2 > > pxdev:bin [vtd-vfio-enablement]# cat .trace.vfio > vtd_page_walk* > vtd_replay* > vtd_inv_desc* > > Then, in the guest, run the following tool: > > > https://github.com/xzpeter/clibs/blob/master/gpl/userspace/vfio-bind-group/vfio-bind-group.c > > With parameter: > > ./vfio-bind-group 00:03.0 00:04.0 > > Check host side trace log, I can see pages are replayed and mapped in > 00:04.0 device address space, like: > > ... > vtd_replay_ce_valid replay valid context device 00:04.00 hi 0x401 lo > 0x38fe1001 > vtd_page_walk Page walk for ce (0x401, 0x38fe1001) iova range 0x0 - > 0x80 > vtd_page_walk_level Page walk (base=0x38fe1000, level=3) iova range 0x0 - > 0x80 > vtd_page_walk_level Page walk (base=0x35d31000, level=2) iova range 0x0 - > 0x4000 > vtd_page_walk_level Page walk (base=0x34979000, level=1) iova range 0x0 - > 0x20 > vtd_page_walk_one Page walk detected map level 0x1 iova 0x0 -> gpa 0x22dc3000 > mask 0xfff perm 3 > vtd_page_walk_one Page walk detected map level 0x1 iova 0x1000 -> gpa > 0x22e25000 mask 0xfff perm 3 > vtd_page_walk_one Page walk detected map level 0x1 iova 0x2000 -> gpa > 0x22e12000 mask 0xfff perm 3 > vtd_page_walk_one Page walk detected map level 0x1 iova 0x3000 -> gpa > 0x22e2d000 mask 0xfff perm 3 > vtd_page_walk_one Page walk detected map level 0x1 iova 0x4000 -> gpa > 0x12a49000 mask 0xfff perm 3 > vtd_page_walk_one Page walk detected map level 0x1 iova 0x5000 -> gpa > 0x129bb000 mask 0xfff perm 3 > vtd_page_walk_one Page walk detected map level 0x1 iova 0x6000 -> gpa > 0x128db000 mask 0xfff perm 3 > vtd_page_walk_one Page walk detected map level 0x1 iova 0x7000 -> gpa > 0x12a8 mask 0xfff perm 3 > vtd_page_walk_one Page walk detected map level 0x1 iova 0x8000 -> gpa > 0x12a7e000 mask 0xfff perm 3 > vtd_page_walk_one Page walk detected map level 0x1 iova 0x9000 -> gpa > 0x12b22000 mask 0xfff perm 3 > vtd_page_walk_one Page walk detected map level 0x1 iova 0xa000 -> gpa > 0x12b41000 mask 0xfff perm 3 > ... > > = > Todo List > = > > - error reporting for the assigned devices (as Tianyu has mentioned) > > - per-domain address-space: A better solution in the future may be - > we maintain one address space per IOMMU domain in the guest (so > multiple devices can share a same address space if they are sharing > the same IOMMU domains in the guest), rather than one address space > per device (which is current implementation of vt-d). However that's > a step further than this series, and let's see whether we can first > provide a workable version of device assignment with vt-
Re: [Qemu-devel] [virtio-dev] Re: [PATCH v15 0/2] virtio-crypto: virtio crypto device specification
On Fri, Jan 13, 2017 at 02:54:29AM +, Gonglei (Arei) wrote:
>
> >
> > On Thu, Jan 12, 2017 at 12:26:24PM +, Gonglei (Arei) wrote:
> > > Hi,
> > >
> > >
> > > >
> > > > On 01/04/2017 11:10 AM, Gonglei (Arei) wrote:
> > > > > Hi all,
> > > > >
> > > > > I attach the diff files between v14 and v15 for better review.
> > > > >
> > > > Hi,
> > > >
> > > > only had a quick look. Will try to come back to this later.
> > > >
> > > That's cool.
> > >
> > > > > diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> > > > > index 9f7faf0..884ee95 100644
> > > > > --- a/virtio-crypto.tex
> > > > > +++ b/virtio-crypto.tex
> > > > > @@ -2,8 +2,8 @@
> > > > >
> > > > > The virtio crypto device is a virtual cryptography device as well as
> > > > > a kind
> > of
> > > > > virtual hardware accelerator for virtual machines. The encryption and
> > > > > -decryption requests are placed in the data queue and are ultimately
> > handled
> > > > by the
> > > > > -backend crypto accelerators. The second queue is the control queue
> > > > > used
> > to
> > > > create
> > > > > +decryption requests are placed in any of the data active queues and
> > > > > are
> > > > ultimately handled by the
> > > > s/data active/active data/
> > > > > +backend crypto accelerators. The second kind of 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.
> > > >
> > > > [..]
> > > >
> > > > > ===The below diff shows the changes of add non-session
> > mode
> > > > support:
> > > > >
> > > > > diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> > > > > index 884ee95..44819f9 100644
> > > > > --- a/virtio-crypto.tex
> > > > > +++ b/virtio-crypto.tex
> > > > > @@ -26,7 +26,10 @@ N is set by \field{max_dataqueues}.
> > > > >
> > > > > \subsection{Feature bits}\label{sec:Device Types / Crypto Device /
> > Feature
> > > > bits}
> > > > >
> > > > > -None currently defined.
> > > > > +VIRTIO_CRYPTO_F_CIPHER_SESSION_MODE (1) Session mode is
> > available
> > > > for CIPHER service.
> > > > > +VIRTIO_CRYPTO_F_HASH_SESSION_MODE (2) Session mode is available
> > for
> > > > HASH service.
> > > > > +VIRTIO_CRYPTO_F_MAC_SESSION_MODE (3) Session mode is available
> > for
> > > > MAC service.
> > > > > +VIRTIO_CRYPTO_F_AEAD_SESSION_MODE (4) Session mode is available
> > for
> > > > AEAD service.
> > > > >
> > > > > \subsection{Device configuration layout}\label{sec:Device Types /
> > Crypto
> > > > Device / Device configuration layout}
> > > > >
> > > > > @@ -208,6 +211,9 @@ Operation parameters are algorithm-specific
> > > > parameters, output data is the
> > > > > data that should be utilized in operations, and input data is equal
> > > > > to
> > > > > "operation result + result data".
> > > > >
> > > > > +The device can support both session mode (See \ref{sec:Device Types /
> > > > Crypto Device / Device Operation / Control Virtqueue / Session
> > > > operation})
> > and
> > > > non-session mode, for example,
> > > > > +As VIRTIO_CRYPTO_F_CIPHER_SESSION feature bit is negotiated, the
> > driver
> > > > can use session mode for CIPHER service, otherwise it can only use
> > non-session
> > > > mode.
> > > > > +
> > > >
> > > > As far as I understand you are adding non-session mode to the mix but
> > > > providing feature bits for session mode. Would this render the the
> > > > current
> > > > implementation non-compliant?
> > > >
> > > You are right, shall we use feature bits for non-session mode for
> > > compliancy?
> > > Or because the spec is on the fly, and some structures in the
> > > virtio_crypto.h
> > need to
> > > be modified, can we keep the compliancy completely?
> > >
> > > Thanks,
> > > -Gonglei
> >
> > Since there's a linux driver upstream you must at least
> > keep compatibility with that.
> >
> Sure. We use feature bits for non-session mode then.
> For structures modification, do we need to do some specific
> actions for compatibility? Take CIPHER service as an example:
>
> The present structure:
>
> struct virtio_crypto_cipher_para {
> /*
> * Byte Length of valid IV/Counter data pointed to by the below iv data.
> *
> * For block ciphers in CBC or F8 mode, or for Kasumi in F8 mode, or for
> * SNOW3G in UEA2 mode, this is the length of the IV (which
> * must be the same as the block length of the cipher).
> * For block ciphers in CTR mode, this is the length of the counter
> * (which must be the same as the block length of the cipher).
> */
> le32 iv_len;
> /* length of source data */
> le32 src_data_len;
> /* length of destination data */
> le32 dst_data_len;
> };
>
> The future structure if supporting non-session based operations:
>
> struct virtio_crypto_cipher_para {
> struct {
>
Re: [Qemu-devel] [PATCH v8 03/21] qapi: make TODOs named-sections
Marc-André Lureau writes: > Have the TODO in the TAG: format, so they will stand out in the > generated documentation. > > Signed-off-by: Marc-André Lureau As proposed in review of v7, I'm replacing commit message by qapi: Format TODO comments more consistently Consistently put a colon after TODO. This will make the TODOs stand out in the documentation we're going to generate. if that's okay with you.
Re: [Qemu-devel] [PATCH v8 03/21] qapi: make TODOs named-sections
Hi - Original Message - > Marc-André Lureau writes: > > > Have the TODO in the TAG: format, so they will stand out in the > > generated documentation. > > > > Signed-off-by: Marc-André Lureau > > As proposed in review of v7, I'm replacing commit message by > > qapi: Format TODO comments more consistently > > Consistently put a colon after TODO. This will make the TODOs stand > out in the documentation we're going to generate. > > if that's okay with you. > sure, sorry I forgot to update it.
Re: [Qemu-devel] [PATCH v5 0/3] Add litmus tests for MTTCG consistency tests
Hi, Your series seems to have some coding style problems. See output below for more information: Type: series Message-id: 20161201052844.31819-1-bobby.pr...@gmail.com Subject: [Qemu-devel] [PATCH v5 0/3] Add litmus tests for MTTCG consistency tests === TEST SCRIPT BEGIN === #!/bin/bash BASE=base n=1 total=$(git log --oneline $BASE.. | wc -l) failed=0 # Useful git options git config --local diff.renamelimit 0 git config --local diff.renames True commits="$(git log --format=%H --reverse $BASE..)" for c in $commits; do echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..." if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then failed=1 echo fi n=$((n+1)) done exit $failed === TEST SCRIPT END === Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384 fatal: unable to access 'https://github.com/patchew-project/qemu/': The requested URL returned error: 504 error: Could not fetch 3c8cf5a9c21ff8782164d1def7f44bd888713384 Traceback (most recent call last): File "/usr/bin/patchew", line 406, in test_one git_clone_repo(clone, r["repo"], r["head"], logf) File "/usr/bin/patchew", line 47, in git_clone_repo stdout=logf, stderr=logf) File "/usr/lib64/python3.4/subprocess.py", line 561, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['git', 'remote', 'add', '-f', '--mirror=fetch', '3c8cf5a9c21ff8782164d1def7f44bd888713384', 'https://github.com/patchew-project/qemu']' returned non-zero exit status 1 --- Email generated automatically by Patchew [http://patchew.org/]. Please send your feedback to patchew-de...@freelists.org
Re: [Qemu-devel] [PATCH v8 07/21] qapi: avoid interleaving sections and parameters
Marc-André Lureau writes: > Follow documentation guideline, body, parameters then additional > sections. > > Signed-off-by: Marc-André Lureau As proposed in review of v7, I'm replacing commit message by qapi: Reorder doc comments for future doc generator The doc generator we're going to add expects a fairly rigid doc comment structure. Reorder / rephrase some doc comments to please it. if that's okay with you.
Re: [Qemu-devel] [PATCH v8 08/21] qapi: move experimental note down
Marc-André Lureau writes: > Use a better 'Note:' section, move it below parameters following > guidelines. > > Signed-off-by: Marc-André Lureau As proposed in review of v7, I'm replacing commit message by qapi: Move "command is experimental" notes down Move these notes down and prefix with "Note:", to please the doc generator we're going to add. if that's okay with you.
[Qemu-devel] [PATCH] virtio_crypto: header update
Update header from latest linux driver. Session creation structs gain
padding to make them same size. Formatting cleanups.
Signed-off-by: Michael S. Tsirkin
---
include/standard-headers/linux/virtio_crypto.h | 481 +
1 file changed, 251 insertions(+), 230 deletions(-)
diff --git a/include/standard-headers/linux/virtio_crypto.h
b/include/standard-headers/linux/virtio_crypto.h
index 82275a8..5ff0b4e 100644
--- a/include/standard-headers/linux/virtio_crypto.h
+++ b/include/standard-headers/linux/virtio_crypto.h
@@ -1,5 +1,5 @@
-#ifndef _LINUX_VIRTIO_CRYPTO_H
-#define _LINUX_VIRTIO_CRYPTO_H
+#ifndef _VIRTIO_CRYPTO_H
+#define _VIRTIO_CRYPTO_H
/* This header is BSD licensed so anyone can use the definitions to implement
* compatible drivers/servers.
*
@@ -14,52 +14,54 @@
* 3. Neither the name of IBM nor the names of its contributors
*may be used to endorse or promote products derived from this software
*without specific prior written permission.
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS
IS''
- * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED. IN NO EVENT SHALL IBM OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE. */
-
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL IBM OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+ * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
+ * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
#include "standard-headers/linux/types.h"
-#include "standard-headers/linux/virtio_config.h"
#include "standard-headers/linux/virtio_types.h"
+#include "standard-headers/linux/virtio_ids.h"
+#include "standard-headers/linux/virtio_config.h"
#define VIRTIO_CRYPTO_SERVICE_CIPHER 0
-#define VIRTIO_CRYPTO_SERVICE_HASH 1
-#define VIRTIO_CRYPTO_SERVICE_MAC 2
-#define VIRTIO_CRYPTO_SERVICE_AEAD 3
+#define VIRTIO_CRYPTO_SERVICE_HASH 1
+#define VIRTIO_CRYPTO_SERVICE_MAC2
+#define VIRTIO_CRYPTO_SERVICE_AEAD 3
#define VIRTIO_CRYPTO_OPCODE(service, op) (((service) << 8) | (op))
struct virtio_crypto_ctrl_header {
#define VIRTIO_CRYPTO_CIPHER_CREATE_SESSION \
- VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_CIPHER, 0x02)
+ VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_CIPHER, 0x02)
#define VIRTIO_CRYPTO_CIPHER_DESTROY_SESSION \
- VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_CIPHER, 0x03)
+ VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_CIPHER, 0x03)
#define VIRTIO_CRYPTO_HASH_CREATE_SESSION \
- VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_HASH, 0x02)
+ VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_HASH, 0x02)
#define VIRTIO_CRYPTO_HASH_DESTROY_SESSION \
- VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_HASH, 0x03)
+ VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_HASH, 0x03)
#define VIRTIO_CRYPTO_MAC_CREATE_SESSION \
- VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_MAC, 0x02)
+ VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_MAC, 0x02)
#define VIRTIO_CRYPTO_MAC_DESTROY_SESSION \
- VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_MAC, 0x03)
+ VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_MAC, 0x03)
#define VIRTIO_CRYPTO_AEAD_CREATE_SESSION \
- VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x02)
+ VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x02)
#define VIRTIO_CRYPTO_AEAD_DESTROY_SESSION \
- VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x03)
-__virtio32 opcode;
-__virtio32 algo;
-__virtio32 flag;
-/* data virtqueue id */
-__virtio32 queue_id;
+ VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x03)
+ uint32_t opcode;
+ uint32_t algo;
+ uint32_t flag;
+ /* data virtqueue id */
+ uint32_t queue_id;
};
struct virtio_crypto_cipher_session_para {
@@ -78,26 +80,27 @@ struct virtio_crypto_cipher_session_para {
#define
Re: [Qemu-devel] [PATCH v8 12/21] qapi.py: fix line break before binary operator pep8
Marc-André Lureau writes: > Python code style accepts both form, but pep8 complains. Better to clean > up the single warning for now, so new errors stand out more easily. > > Fix scripts/qapi.py:1539:21: W503 line break before binary operator > > Signed-off-by: Marc-André Lureau I'm dropping this patch, as per review of v7.
[Qemu-devel] [PATCH] update-linux-headers.sh: support __bitwise
In 4.10, Linux is switching from __bitwise__ to use __bitwise
exclusively. Update our script accordingly.
Signed-off-by: Michael S. Tsirkin
---
scripts/update-linux-headers.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/update-linux-headers.sh b/scripts/update-linux-headers.sh
index 08c4c4a..72cf1fb 100755
--- a/scripts/update-linux-headers.sh
+++ b/scripts/update-linux-headers.sh
@@ -51,7 +51,7 @@ cp_portable() {
-e 's/__be\([0-9][0-9]*\)/uint\1_t/g' \
-e 's/"\(input-event-codes\.h\)"/"standard-headers\/linux\/\1"/' \
-e 's/]*\)>/"standard-headers\/linux\/\1"/' \
--e 's/__bitwise__//' \
+-e 's/__bitwise//' \
-e 's/__attribute__((packed))/QEMU_PACKED/' \
-e 's/__inline__/inline/' \
-e '/sys\/ioctl.h/d' \
--
MST
Re: [Qemu-devel] [PATCH v8 12/21] qapi.py: fix line break before binary operator pep8
Hi - Original Message - > Marc-André Lureau writes: > > > Python code style accepts both form, but pep8 complains. Better to clean > > up the single warning for now, so new errors stand out more easily. > > > > Fix scripts/qapi.py:1539:21: W503 line break before binary operator > > > > Signed-off-by: Marc-André Lureau > > I'm dropping this patch, as per review of v7. Sorry, I thought I dropped it. I think I screwed up with my two branches (maintaining both split/squash series was quite a pain, I am relieved we are nearing the end)
Re: [Qemu-devel] Proposal PCI/PCIe device placement on PAPR guests
On Fri, 13 Jan 2017 09:57:36 +1100 David Gibson wrote: > On Thu, Jan 12, 2017 at 11:31:35AM +0100, Andrea Bolognani wrote: > > On Mon, 2017-01-09 at 10:46 +1100, David Gibson wrote: > > > > >* To allow for hotplugged devices, libvirt should also add a number > > > > > of additional, empty vPHBs (the PAPR spec allows for hotplug of > > > > > PHBs, but this is not yet implemented in qemu). > > > > > > > > "A number" here will have to mean "one", same number of > > > > empty PCIe Root Ports libvirt will add to a newly-defined > > > > q35 guest. > > > > > > Umm.. why? > > > > Because some applications using libvirt would inevitably > > start relying on the fact that such spare PHBs are > > available, locking us into providing at least the same > > number forever. In other words, increasing the amount at > > a later time is always possible, but decreasing it isn't. > > We did the same when we started automatically adding PCIe > > Root Ports to q35 machines. > > > > The rationale is that having a single spare hotpluggable > > slot is extremely convenient for basic usage, eg. a simple > > guest created by someone who's not necessarily very > > familiar with virtualization; on the other hand, if you > > are actually deploying in production you ought to conduct > > proper capacity planning and figure out in advance how > > many devices you're likely to need to hotplug throughout > > the guest's life. > > Hm, ok. Well I guess the limitation is the same as on x86, so it > shouldn't surprise people. > > > Of course this all will be moot once we can hotplug PHBs :) > > Yes. Unfortunately, nobody's actually working on that at present. > Well, there might be someone now :) Michael Roth had posted a RFC patchset back in 2015: https://lists.gnu.org/archive/html/qemu-ppc/2015-04/msg00275.html I'll start from here. Cheers. -- Greg pgpp3OcuV9NgA.pgp Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH V4 net-next] vhost_net: device IOTLB support
On Fri, Jan 13, 2017 at 10:45:09AM +0800, Jason Wang wrote: > > > On 2017年01月12日 22:17, Michael S. Tsirkin wrote: > > On Wed, Jan 11, 2017 at 12:32:12PM +0800, Jason Wang wrote: > > > This patches implements Device IOTLB support for vhost kernel. This is > > > done through: > > > > > > 1) switch to use dma helpers when map/unmap vrings from vhost codes > > > 2) introduce a set of VhostOps to: > > > - setting up device IOTLB request callback > > > - processing device IOTLB request > > > - processing device IOTLB invalidation > > > 2) kernel support for Device IOTLB API: > > > > > > - allow vhost-net to query the IOMMU IOTLB entry through eventfd > > > - enable the ability for qemu to update a specified mapping of vhost > > > - through ioctl. > > > - enable the ability to invalidate a specified range of iova for the > > >device IOTLB of vhost through ioctl. In x86/intel_iommu case this is > > >triggered through iommu memory region notifier from device IOTLB > > >invalidation descriptor processing routine. > > > > > > With all the above, kernel vhost_net can co-operate with userspace > > > IOMMU. For vhost-user, the support could be easily done on top by > > > implementing the VhostOps. > > > > > > Cc: Michael S. Tsirkin > > > Signed-off-by: Jason Wang > > Applied, thanks! > > > > > --- > > > Changes from V4: > > > - set iotlb callback only when IOMMU_PLATFORM is negotiated (fix > > >vhost-user qtest failure) > > In fact this only checks virtio_host_has_feature - which is > > the right thing to do, we can't trust the guest. > > > > > - whitelist VIRTIO_F_IOMMU_PLATFORM instead of manually add it > > > - keep cpu_physical_memory_map() in vhost_memory_map() > > One further enhancement might be to detect that guest disabled > > iommu (e.g. globally, or using iommu=pt) and disable > > the iotlb to avoid overhead for guests which use DPDK > > for assigned devices but not for vhost. > > > > > > Yes, it's in my todo list. > > Thanks Something that I just noticed is that when user requests iommu_platform but vhost can not provide it, this patches will just let vhost continue without. I think that's wrong, since iommu_platform is a security feature, when it's not supported I think we should fail init. -- MST
[Qemu-devel] [PATCH] hw/arm/virt-acpi - reserve ECAM space as PNP0C02 device
Linux for arm64 v4.10 and later will complain if the ECAM config space is
not reserved in the ACPI namespace:
acpi PNP0A08:00: [Firmware Bug]: ECAM area [mem 0x3f00-0x3fff] not
reserved in ACPI namespace
The rationale is that OSes that don't consume the MCFG table should still
be able to infer that the PCI config space MMIO region is occupied.
So update the ACPI table generation routine to add this reservation.
Signed-off-by: Ard Biesheuvel
---
hw/arm/virt-acpi-build.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index 085a61117378..e8769dc6288f 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -310,6 +310,12 @@ static void acpi_dsdt_add_pci(Aml *scope, const
MemMapEntry *memmap,
Aml *dev_rp0 = aml_device("%s", "RP0");
aml_append(dev_rp0, aml_name_decl("_ADR", aml_int(0)));
aml_append(dev, dev_rp0);
+
+Aml *dev_res0 = aml_device("%s", "RES0");
+crs = aml_resource_template();
+aml_append(crs, aml_memory32_fixed(base_ecam, size_ecam, AML_READ_WRITE));
+aml_append(dev_res0, aml_name_decl("_CRS", crs));
+aml_append(dev, dev_res0);
aml_append(scope, dev);
}
--
2.7.4
Re: [Qemu-devel] [PATCH 27/40] char: move QIOChannel-related in char-io.h
Hi
- Original Message -
> On 01/11/2017 11:29 AM, Marc-André Lureau wrote:
>
> Grammar in subject is a bit terse; maybe:
>
> char: move QIOChannel-related stuff to char-io.h
>
> > Signed-off-by: Marc-André Lureau
> > ---
> > chardev/char-io.h | 24 +++
> > chardev/char-io.c | 168
> >
> > chardev/char.c| 174
> > +-
> > chardev/Makefile.objs | 1 +
> > 4 files changed, 194 insertions(+), 173 deletions(-)
> > create mode 100644 chardev/char-io.h
> > create mode 100644 chardev/char-io.c
> >
> > diff --git a/chardev/char-io.h b/chardev/char-io.h
> > new file mode 100644
> > index 00..ea559fd124
> > --- /dev/null
> > +++ b/chardev/char-io.h
> > @@ -0,0 +1,24 @@
> > +#ifndef CHAR_IO_H
> > +#define CHAR_IO_H
>
> Must... resist... the temptation to repeat myself!
Ok, I'll just copy the original copyright from qemu-char.c in all the files I
created in the series.
>
> > +
> > +#include "qemu/osdep.h"
>
> .h files should NOT include osdep.h; since all .c files included it
> before any other .h file, then all things in osdep.h are already in
> scope at the point the .h file starts.
ok
>
>
> > +static gboolean io_watch_poll_prepare(GSource *source,
> > + gint *timeout_)
> > +{
>
> Why the weird spelling of timeout_ ? Maybe timeout_unused is better?
>
>
> > +++ b/chardev/char.c
>
> > -static gboolean io_watch_poll_prepare(GSource *source,
> > - gint *timeout_)
>
> Then again, it's code motion. Again, up to you if you want to tweak
> style things during code motion, or split them into a general cleanup
> patch separately.
yeah, weird style, any idea why Anthony wrote it that way in commit 96c638477?
I guess I may just drop the _ during the move
[Qemu-devel] [PULL 000/180] QAPI patches for 2017-01-13
This is Marc-André's "[PATCH v8 00/21] qapi doc generation (whole version, squashed)" with a few commit messages tweaked, and "[PATCH v8 14/21] (SQUASHED) move doc to schema" unsquashed into 161 patches. We did all the respins with in this squashed form to reduce noise. However, since the unsquashed form is better suited for review, and probably nicer if we have to revisit this part of the work down the road, I'm proposing to merge this unsquashed. If you want me to post the unsquashed patches, I'm happy to redo this pull request. If you'd rather pull the squashed version, likewise. I'm afraid this is a bit of a doc conflict magnet. The sooner we can get it in, the easier for Marc-André and me. The following changes since commit fdbd92f738693abfda60d2d1fc075cd796f33f80: Merge remote-tracking branch 'remotes/stsquad/tags/pull-travis-20170112-1' into staging (2017-01-13 14:02:30 +) are available in the git repository at: git://repo.or.cz/qemu/armbru.git tags/pull-qapi-2017-01-13 for you to fetch changes up to 3b4ce60a8bb5f48d87c925a4a783d005914605d1: build-sys: add qapi doc generation targets (2017-01-13 17:32:16 +0100) QAPI patches for 2017-01-13 Marc-André Lureau (180): qapi: replace 'o' for list items qapi: move QKeyCode doc body at the top qapi: Format TODO comments more consistently qapi: improve device_add schema qapi: improve TransactionAction doc qga/schema: improve guest-set-vcpus Returns: section qapi: Reorder doc comments for future doc generator qapi: Move "command is experimental" notes down qapi: add some sections in docs docs: add master qapi texi files qapi: rework qapi Exception texi2pod: learn quotation, deftp and deftypefn qmp-commands: move 'add_client' doc to schema qmp-commands: move 'query-name' doc to schema qmp-commands: move 'query-kvm' doc to schema qmp-commands: move 'query-status' doc to schema qmp-commands: move 'query-uuid' doc to schema qmp-commands: move 'query-chardev' doc to schema qmp-commands: move 'query-chardev-backends' doc to schema qmp-commands: move 'ringbuf-write' doc to schema qmp-commands: move 'ringbuf-read' doc to schema qmp-commands: move 'query-events' doc to schema qmp-commands: move 'query-migrate' doc to schema qmp-commands: move 'migrate-set-capabilities' doc to schema qmp-commands: move 'query-migrate-capabilities' doc to schema qmp-commands: move 'migrate-set-parameters' doc to schema qmp-commands: move 'query-migrate-parameters' doc to schema qmp-commands: move 'client_migrate_info' doc to schema qmp-commands: move 'migrate-start-postcopy' doc to schema qmp-commands: move 'query-mice' doc to schema qmp-commands: move 'query-cpus' doc to schema qmp-commands: move 'query-iothreads' doc to schema qmp-commands: move 'query-vnc' doc to schema qmp-commands: move 'query-spice' doc to schema qmp-commands: move 'query-balloon' doc to schema qmp-commands: move 'query-pci' doc to schema qmp-commands: move 'quit' doc to schema qmp-commands: move 'stop' doc to schema qmp-commands: move 'system_reset' doc to schema qmp-commands: move 'system_powerdown' doc to schema qmp-commands: move 'cpu-add' doc to schema qmp-commands: move 'memsave' doc to schema qmp-commands: move 'pmemsave' doc to schema qmp-commands: move 'cont' doc to schema qmp-commands: move 'system_wakeup' doc to schema qmp-commands: move 'inject-nmi' doc to schema qmp-commands: move 'set_link' doc to schema qmp-commands: move 'balloon' doc to schema qmp-commands: move 'transaction' doc to schema qmp-commands: move 'human-monitor-command' doc to schema qmp-commands: move 'migrate_cancel' doc to schema qmp-commands: move 'migrate_set_downtime' doc to schema qmp-commands: move 'migrate_set_speed' doc to schema qmp-commands: move 'query-migrate-cache-size' doc to schema qmp-commands: move 'set_password' doc to schema qmp-commands: move 'expire_password' doc to schema qmp-commands: move 'change' doc to schema qmp-commands: move 'migrate' doc to schema qmp-commands: move 'migrate-incoming' doc to schema qmp-commands: move 'xen-save-devices-state' doc to schema qmp-commands: move 'xen-set-global-dirty-log' doc to schema qmp-commands: move 'device_del' doc to schema qmp-commands: move 'dump-guest-memory' doc to schema qmp-commands: move 'query-dump-guest-memory-capability' doc to schema qmp-commands: move 'dump-skeys' doc to schema qmp-commands: move 'netdev_add' doc to schema qmp-commands: move 'netdev_del' doc to schema qmp-commands: move 'object-add' doc to
Re: [Qemu-devel] [PATCH v8 12/21] qapi.py: fix line break before binary operator pep8
Marc-André Lureau writes: > Hi > > - Original Message - >> Marc-André Lureau writes: >> >> > Python code style accepts both form, but pep8 complains. Better to clean >> > up the single warning for now, so new errors stand out more easily. >> > >> > Fix scripts/qapi.py:1539:21: W503 line break before binary operator >> > >> > Signed-off-by: Marc-André Lureau >> >> I'm dropping this patch, as per review of v7. > > Sorry, I thought I dropped it. I think I screwed up with my two branches > (maintaining both split/squash series was quite a pain, I am relieved we are > nearing the end) Don't worry, you did all the non-trivial changes correctly, so I'm happy to do a few trivial ones :)
Re: [Qemu-devel] [PATCH] hw/arm/virt-acpi - reserve ECAM space as PNP0C02 device
On 13 January 2017 at 16:36, Ard Biesheuvel wrote:
> Linux for arm64 v4.10 and later will complain if the ECAM config space is
> not reserved in the ACPI namespace:
>
> acpi PNP0A08:00: [Firmware Bug]: ECAM area [mem 0x3f00-0x3fff] not
> reserved in ACPI namespace
>
> The rationale is that OSes that don't consume the MCFG table should still
> be able to infer that the PCI config space MMIO region is occupied.
>
> So update the ACPI table generation routine to add this reservation.
>
> Signed-off-by: Ard Biesheuvel
Please disregard -- I failed to add the PNP0C02 HID
> ---
> hw/arm/virt-acpi-build.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 085a61117378..e8769dc6288f 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -310,6 +310,12 @@ static void acpi_dsdt_add_pci(Aml *scope, const
> MemMapEntry *memmap,
> Aml *dev_rp0 = aml_device("%s", "RP0");
> aml_append(dev_rp0, aml_name_decl("_ADR", aml_int(0)));
> aml_append(dev, dev_rp0);
> +
> +Aml *dev_res0 = aml_device("%s", "RES0");
> +crs = aml_resource_template();
> +aml_append(crs, aml_memory32_fixed(base_ecam, size_ecam,
> AML_READ_WRITE));
> +aml_append(dev_res0, aml_name_decl("_CRS", crs));
> +aml_append(dev, dev_res0);
> aml_append(scope, dev);
> }
>
> --
> 2.7.4
>
Re: [Qemu-devel] [PATCH] libvhost-user: Start VQs on SET_VRING_CALL
On Fri, Jan 13, 2017 at 03:09:46PM +, Felipe Franciosi wrote:
> Hi Marc-Andre,
>
> > On 13 Jan 2017, at 07:03, Marc-André Lureau wrote:
> >
> > Hi
> >
> > - Original Message -
> >> Currently, VQs are started as soon as a SET_VRING_KICK is received. That
> >> is too early in the VQ setup process, as the backend might not yet have
> >
> > I think we may want to reconsider queue_set_started(), move it elsewhere,
> > since kick/call fds aren't mandatory to process the rings.
>
> Hmm. The fds aren't mandatory, but I imagine in that case we should still
> receive SET_VRING_KICK/CALL messages without an fd (ie. with the
> VHOST_MSG_VQ_NOFD_MASK flag set). Wouldn't that be the case?
Please look at docs/specs/vhost-user.txt, Starting and stopping rings
The spec says:
Client must start ring upon receiving a kick (that is, detecting that
file descriptor is readable) on the descriptor specified by
VHOST_USER_SET_VRING_KICK, and stop ring upon receiving
VHOST_USER_GET_VRING_BASE.
> >
> >> a callfd to notify in case it received a kick and fully processed the
> >> request/command. This patch only starts a VQ when a SET_VRING_CALL is
> >> received.
> >
> > I don't like that much, as soon as the kick fd is received, it should start
> > polling it imho. callfd is optional, it may have one and not the other.
>
> So the question is whether we should be receiving a SET_VRING_CALL anyway or
> not, regardless of an fd being sent. (I think we do, but I haven't done
> extensive testing with other device types.)
I would say not, only KICK is mandatory and that is also not enough
to process ring. You must wait for it to be readable.
> >
> > Perhaps it's best for now to delay the callfd notification with a flag
> > until it is received?
>
> The other idea is to always kick when we receive the callfd. I remember
> discussing that alternative with you before libvhost-user went in. The
> protocol says both the driver and the backend must handle spurious kicks.
> This approach also fixes the bug.
>
> I'm happy with whatever alternative you want, as long it makes libvhost-user
> usable for storage devices.
>
> Thanks,
> Felipe
>
>
> >
> >
> >> Signed-off-by: Felipe Franciosi
> >> ---
> >> contrib/libvhost-user/libvhost-user.c | 26 +-
> >> 1 file changed, 13 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/contrib/libvhost-user/libvhost-user.c
> >> b/contrib/libvhost-user/libvhost-user.c
> >> index af4faad..a46ef90 100644
> >> --- a/contrib/libvhost-user/libvhost-user.c
> >> +++ b/contrib/libvhost-user/libvhost-user.c
> >> @@ -607,19 +607,6 @@ vu_set_vring_kick_exec(VuDev *dev, VhostUserMsg *vmsg)
> >> DPRINT("Got kick_fd: %d for vq: %d\n", vmsg->fds[0], index);
> >> }
> >>
> >> -dev->vq[index].started = true;
> >> -if (dev->iface->queue_set_started) {
> >> -dev->iface->queue_set_started(dev, index, true);
> >> -}
> >> -
> >> -if (dev->vq[index].kick_fd != -1 && dev->vq[index].handler) {
> >> -dev->set_watch(dev, dev->vq[index].kick_fd, VU_WATCH_IN,
> >> - vu_kick_cb, (void *)(long)index);
> >> -
> >> -DPRINT("Waiting for kicks on fd: %d for vq: %d\n",
> >> - dev->vq[index].kick_fd, index);
> >> -}
> >> -
> >> return false;
> >> }
> >>
> >> @@ -661,6 +648,19 @@ vu_set_vring_call_exec(VuDev *dev, VhostUserMsg *vmsg)
> >>
> >> DPRINT("Got call_fd: %d for vq: %d\n", vmsg->fds[0], index);
> >>
> >> +dev->vq[index].started = true;
> >> +if (dev->iface->queue_set_started) {
> >> +dev->iface->queue_set_started(dev, index, true);
> >> +}
> >> +
> >> +if (dev->vq[index].kick_fd != -1 && dev->vq[index].handler) {
> >> +dev->set_watch(dev, dev->vq[index].kick_fd, VU_WATCH_IN,
> >> + vu_kick_cb, (void *)(long)index);
> >> +
> >> +DPRINT("Waiting for kicks on fd: %d for vq: %d\n",
> >> + dev->vq[index].kick_fd, index);
> >> +}
> >> +
> >> return false;
> >> }
> >>
> >> --
> >> 1.9.4
> >>
> >>
>
Re: [Qemu-devel] [PULL 0/6] x86 and machine queue, 2017-01-17
On 12 January 2017 at 17:53, Eduardo Habkost wrote: > The following changes since commit 204febd17f9ebb9e94b1980b42c7f2c2307851c1: > > libqtest: handle zero length memwrite/memread (2017-01-12 10:45:59 +) > > are available in the git repository at: > > git://github.com/ehabkost/qemu.git tags/x86-and-machine-pull-request > > for you to fetch changes up to 8ed877b78498c89aa7ce5c76aa20841ff5072796: > > qmp: Report QOM type name on query-cpu-definitions (2017-01-12 15:51:36 > -0200) > > > x86 and machine queue, 2017-01-17 > > Includes i386, CPU, NUMA, and memory backends changes. > > i386: > target/i386: Fix bad patch application to translate.c > > CPU: > qmp: Report QOM type name on query-cpu-definitions > > NUMA: > numa: make -numa parser dynamically allocate CPUs masks > > Memory backends: > qom: remove unused header > monitor: reuse user_creatable_add_opts() instead of user_creatable_add() > monitor: fix qmp/hmp query-memdev not reporting IDs of memory backends > > Applied, thanks. -- PMM
[Qemu-devel] [PATCH] 9pfs: fix off-by-one error in PDU free list
The server can handle MAX_REQ - 1 PDUs at a time and the virtio-9p
device has a MAX_REQ sized virtqueue. If the client manages to fill
up the virtqueue, pdu_alloc() will fail and the request won't be
processed without any notice to the client (it actually causes the
linux 9p client to hang).
This has been there since the beginning (commit 9f10751365b2 "virtio-9p:
Add a virtio 9p device to qemu"), but it needs an agressive workload to
run in the guest to show up.
We actually allocate MAX_REQ PDUs and I see no reason not to link them
all into the free list, so let's fix the init loop.
Reported-by: Tuomas Tynkkynen
Suggested-by: Al Viro
Signed-off-by: Greg Kurz
---
hw/9pfs/9p.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index fa58877570f6..965c8edc8030 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -3454,7 +3454,7 @@ int v9fs_device_realize_common(V9fsState *s, Error **errp)
/* initialize pdu allocator */
QLIST_INIT(&s->free_list);
QLIST_INIT(&s->active_list);
-for (i = 0; i < (MAX_REQ - 1); i++) {
+for (i = 0; i < MAX_REQ; i++) {
QLIST_INSERT_HEAD(&s->free_list, &s->pdus[i], next);
s->pdus[i].s = s;
s->pdus[i].idx = i;
Re: [Qemu-devel] [PATCH] ahci: advertise HOST_CAP_64
On 01/13/2017 06:02 AM, Ladi Prosek wrote: > The AHCI emulation code supports 64-bit addressing and should advertise this > fact in the Host Capabilities register. Both Linux and Windows drivers test > this bit to decide if the upper 32 bits of various registers may be written > to, and at least some versions of Windows have a bug where DMA is attempted > with an address above 4GB but, in the absence of HOST_CAP_64, the upper 32 > bits are left unititialized which leads to a memory corruption. > > Signed-off-by: Ladi Prosek > --- > hw/ide/ahci.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c > index 3c19bda..6a17acf 100644 > --- a/hw/ide/ahci.c > +++ b/hw/ide/ahci.c > @@ -488,7 +488,7 @@ static void ahci_reg_init(AHCIState *s) > s->control_regs.cap = (s->ports - 1) | >(AHCI_NUM_COMMAND_SLOTS << 8) | >(AHCI_SUPPORTED_SPEED_GEN1 << > AHCI_SUPPORTED_SPEED) | > - HOST_CAP_NCQ | HOST_CAP_AHCI; > + HOST_CAP_NCQ | HOST_CAP_AHCI | HOST_CAP_64; > > s->control_regs.impl = (1 << s->ports) - 1; > > Was this tested? What was the use case that prompted this patch, and do you have a public bugzilla to point to? It looks correct via the spec, thank you for finding this oversight. It looks like everywhere this bit would make a difference we already do the correct thing for having this bit set. >From what I can gather from the spec, it looks as if even 32bit guests must ensure that the upper 32bit registers are cleared, so I think we're all set here. Reviewed-by: John Snow
Re: [Qemu-devel] [PATCH] qemu-capabilities: Fix query-cpu-model-expansion on s390 with older kernel
On Fri, Jan 13, 2017 at 09:06:52AM -0500, Jason J. Herne wrote: > On 01/13/2017 05:04 AM, Jiri Denemark wrote: > > On Thu, Jan 12, 2017 at 11:18:11 -0500, Collin L. Walling wrote: > > > When running on s390 with a kernel that does not support cpu model > > > checking and > > > with a Qemu new enough to support query-cpu-model-expansion, the > > > gathering of qemu > > > capabilities will fail. Qemu responds to the query-cpu-model-expansion qmp > > > command with an error because the needed kernel ioct does not exist. When > > > this > > > happens a guest cannot even be defined due to missing qemu capabilities > > > data. > > > > > > This patch fixes the problem by silently ignoring generic errors stemming > > > from > > > calls to query-cpu-model-expansion. > > > > > > Reported-by: Farhan Ali > > > Signed-off-by: Collin L. Walling > > > Signed-off-by: Jason J. Herne > > > --- > > > src/qemu/qemu_monitor_json.c | 9 + > > > 1 file changed, 9 insertions(+) > > > > > > diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c > > > index e767437..1662749 100644 > > > --- a/src/qemu/qemu_monitor_json.c > > > +++ b/src/qemu/qemu_monitor_json.c > > > @@ -5041,6 +5041,15 @@ qemuMonitorJSONGetCPUModelExpansion(qemuMonitorPtr > > > mon, > > > if (qemuMonitorJSONCommand(mon, cmd, &reply) < 0) > > > goto cleanup; > > > > > > +/* Some QEMU architectures have the query-cpu-model-expansion > > > + * command, but return 'GenericError' instead of simply omitting > > > + * the command entirely. > > > + */ > > > > Hmm, this comment says something a bit different than the commit > > message. I hope the issue described by this comment was fixed in QEMU > > within the same release the query-cpu-model-expansion command was > > introduced. But we need to fix this nevertheless to address what the > > commit message describes. > > > > The issue still exists in Qemu. I can work up a patch to handle it. My first > idea is to simply test that the ioctl exists and functions at Qemu > initialization and deregister the query-cpu-model-expansion command in the > event that the ioctl does not exist or fails. Thoughts? I'm not sure, probably unregistering the command after KVM is initialized is too late. Even if today QMP is available only after the accelerator is already initialized, we might want to delay accelerator initialization in the future (so the accelerator could be configured using QMP commands). Also, I'm not sure when/how exactly the query-cpu-model-expansion call fails. If the ioctl isn't available, shouldn't query-cpu-model-expansion fail only when querying "host", but let the other CPU models to be queried? In this case, unregistering the command doesn't seem to be the right solution. Probably omitting "host" (or flagging it as unavailable?) on query-cpu-model-definitions would be better. -- Eduardo
[Qemu-devel] bug in new ubfx code
Hi all, I tracked down a boot issue I was having with running the kernel under AArch64 system emulation to commit It appears that ubfx is executing incorrectly: the following code .global _start _start: mov x1, #0x1124 ubfx x2, x1, #28, #4 built with aarch64-linux-gnu-gcc -o /tmp/ubfx /tmp/ubfx.s -nostartfiles aarch64-linux-gnu-objcopy -O binary /tmp/ubfx.bin /tmp/ubfx and executed with qemu-system-aarch64 -M virt -cpu cortex-a53 -kernel /tmp/ubfx -s -S -nographic produces the value 0x11240 in x2 (as can be observed via GDB), while the expected value is 0 Regards, Ard.
Re: [Qemu-devel] bug in new ubfx code
On 13 January 2017 at 17:27, Ard Biesheuvel wrote: > Hi all, > > I tracked down a boot issue I was having with running the kernel under > AArch64 system emulation to commit > 59a71b4c5b4e target-arm: Use new deposit and extract ops > It appears that ubfx is executing incorrectly: the following code > > .global _start > _start: > mov x1, #0x1124 > ubfx x2, x1, #28, #4 > > built with > > aarch64-linux-gnu-gcc -o /tmp/ubfx /tmp/ubfx.s -nostartfiles > aarch64-linux-gnu-objcopy -O binary /tmp/ubfx.bin /tmp/ubfx > > and executed with > > qemu-system-aarch64 -M virt -cpu cortex-a53 -kernel /tmp/ubfx -s -S -nographic > > produces the value 0x11240 in x2 (as can be observed via GDB), > while the expected value is 0 > > Regards, > Ard.
Re: [Qemu-devel] [PATCH] libvhost-user: Start VQs on SET_VRING_CALL
> On 13 Jan 2017, at 09:04, Michael S. Tsirkin wrote:
>
> On Fri, Jan 13, 2017 at 03:09:46PM +, Felipe Franciosi wrote:
>> Hi Marc-Andre,
>>
>>> On 13 Jan 2017, at 07:03, Marc-André Lureau wrote:
>>>
>>> Hi
>>>
>>> - Original Message -
Currently, VQs are started as soon as a SET_VRING_KICK is received. That
is too early in the VQ setup process, as the backend might not yet have
>>>
>>> I think we may want to reconsider queue_set_started(), move it elsewhere,
>>> since kick/call fds aren't mandatory to process the rings.
>>
>> Hmm. The fds aren't mandatory, but I imagine in that case we should still
>> receive SET_VRING_KICK/CALL messages without an fd (ie. with the
>> VHOST_MSG_VQ_NOFD_MASK flag set). Wouldn't that be the case?
>
> Please look at docs/specs/vhost-user.txt, Starting and stopping rings
>
> The spec says:
> Client must start ring upon receiving a kick (that is, detecting that
> file descriptor is readable) on the descriptor specified by
> VHOST_USER_SET_VRING_KICK, and stop ring upon receiving
> VHOST_USER_GET_VRING_BASE.
Yes I have seen the spec, but there is a race with the current libvhost-user
code which needs attention. My initial proposal (which got turned down) was to
send a spurious notification upon seeing a callfd. Then I came up with this
proposal. See below.
>
>
>>>
a callfd to notify in case it received a kick and fully processed the
request/command. This patch only starts a VQ when a SET_VRING_CALL is
received.
>>>
>>> I don't like that much, as soon as the kick fd is received, it should start
>>> polling it imho. callfd is optional, it may have one and not the other.
>>
>> So the question is whether we should be receiving a SET_VRING_CALL anyway or
>> not, regardless of an fd being sent. (I think we do, but I haven't done
>> extensive testing with other device types.)
>
> I would say not, only KICK is mandatory and that is also not enough
> to process ring. You must wait for it to be readable.
The problem is that Qemu takes time between sending the kickfd and the callfd.
Hence the race. Consider this scenario:
1) Guest configures the device
2) Guest put a request on a virtq
3) Guest kicks
4) Qemu starts configuring the backend
4.a) Qemu sends the masked callfds
4.b) Qemu sends the virtq sizes and addresses
4.c) Qemu sends the kickfds
(When using MQ, Qemu will only send the callfd once all VQs are configured)
5) The backend starts listening on the kickfd upon receiving it
6) The backend picks up the guest's request
7) The backend processes the request
8) The backend puts the response on the used ring
9) The backend notifies the masked callfd
4.d) Qemu sends the callfds
At which point the guest missed the notification and gets stuck.
Perhaps you prefer my initial proposal of sending a spurious notification when
the backend sees a callfd?
Felipe
>
>>>
>>> Perhaps it's best for now to delay the callfd notification with a flag
>>> until it is received?
>>
>> The other idea is to always kick when we receive the callfd. I remember
>> discussing that alternative with you before libvhost-user went in. The
>> protocol says both the driver and the backend must handle spurious kicks.
>> This approach also fixes the bug.
>>
>> I'm happy with whatever alternative you want, as long it makes libvhost-user
>> usable for storage devices.
>>
>> Thanks,
>> Felipe
>>
>>
>>>
>>>
Signed-off-by: Felipe Franciosi
---
contrib/libvhost-user/libvhost-user.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/contrib/libvhost-user/libvhost-user.c
b/contrib/libvhost-user/libvhost-user.c
index af4faad..a46ef90 100644
--- a/contrib/libvhost-user/libvhost-user.c
+++ b/contrib/libvhost-user/libvhost-user.c
@@ -607,19 +607,6 @@ vu_set_vring_kick_exec(VuDev *dev, VhostUserMsg *vmsg)
DPRINT("Got kick_fd: %d for vq: %d\n", vmsg->fds[0], index);
}
-dev->vq[index].started = true;
-if (dev->iface->queue_set_started) {
-dev->iface->queue_set_started(dev, index, true);
-}
-
-if (dev->vq[index].kick_fd != -1 && dev->vq[index].handler) {
-dev->set_watch(dev, dev->vq[index].kick_fd, VU_WATCH_IN,
- vu_kick_cb, (void *)(long)index);
-
-DPRINT("Waiting for kicks on fd: %d for vq: %d\n",
- dev->vq[index].kick_fd, index);
-}
-
return false;
}
@@ -661,6 +648,19 @@ vu_set_vring_call_exec(VuDev *dev, VhostUserMsg *vmsg)
DPRINT("Got call_fd: %d for vq: %d\n", vmsg->fds[0], index);
+dev->vq[index].started = true;
+if (dev->iface->queue_set_started) {
+dev->iface->queue_set_started(dev, index, true);
+}
+
+if (dev->vq[index].kick_fd != -1 && dev->vq[index].ha
[Qemu-devel] [PATCH v2] hw/arm/virt-acpi - reserve ECAM space as PNP0C02 device
Linux for arm64 v4.10 and later will complain if the ECAM config space is
not reserved in the ACPI namespace:
acpi PNP0A08:00: [Firmware Bug]: ECAM area [mem 0x3f00-0x3fff] not
reserved in ACPI namespace
The rationale is that OSes that don't consume the MCFG table should still
be able to infer that the PCI config space MMIO region is occupied.
So update the ACPI table generation routine to add this reservation.
Signed-off-by: Ard Biesheuvel
---
hw/arm/virt-acpi-build.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index 085a61117378..50d52f685f68 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -310,6 +310,13 @@ static void acpi_dsdt_add_pci(Aml *scope, const
MemMapEntry *memmap,
Aml *dev_rp0 = aml_device("%s", "RP0");
aml_append(dev_rp0, aml_name_decl("_ADR", aml_int(0)));
aml_append(dev, dev_rp0);
+
+Aml *dev_res0 = aml_device("%s", "RES0");
+aml_append(dev_res0, aml_name_decl("_HID", aml_string("PNP0C02")));
+crs = aml_resource_template();
+aml_append(crs, aml_memory32_fixed(base_ecam, size_ecam, AML_READ_WRITE));
+aml_append(dev_res0, aml_name_decl("_CRS", crs));
+aml_append(dev, dev_res0);
aml_append(scope, dev);
}
--
2.7.4
Re: [Qemu-devel] bug in new ubfx code
On 01/13/2017 09:27 AM, Ard Biesheuvel wrote: > Hi all, > > I tracked down a boot issue I was having with running the kernel under > AArch64 system emulation to commit > > It appears that ubfx is executing incorrectly: the following code > > .global _start > _start: > mov x1, #0x1124 > ubfx x2, x1, #28, #4 > > built with > > aarch64-linux-gnu-gcc -o /tmp/ubfx /tmp/ubfx.s -nostartfiles > aarch64-linux-gnu-objcopy -O binary /tmp/ubfx.bin /tmp/ubfx > > and executed with > > qemu-system-aarch64 -M virt -cpu cortex-a53 -kernel /tmp/ubfx -s -S -nographic > > produces the value 0x11240 in x2 (as can be observed via GDB), > while the expected value is 0 Ho hum. Somehow the relevant patch was corrupted. It has half of Alex's fix in http://lists.nongnu.org/archive/html/qemu-devel/2016-12/msg00137.html but is also missing half. I'll fix it up asap. r~
Re: [Qemu-devel] [PATCH v2 1/5] target-m68k: fix bit operation with immediate value
On 01/13/2017 04:51 AM, Laurent Vivier wrote: > M680x0 bit operations with an immediate value use 9 bits of the 16bit > value, while coldfire ones use only 8 bits. I don't see that in the reference manual. Where do you get this from? r~
Re: [Qemu-devel] [PATCH v2 2/5] target-m68k: fix gen_flush_flags()
On 01/13/2017 04:52 AM, Laurent Vivier wrote: > gen_flush_flags() is setting unconditionally cc_op_synced to 1 > and s->cc_op to CC_OP_FLAGS, whereas env->cc_op can be set > to something else by a previous tcg fragment. > > We fix that by not setting cc_op_synced to 1 > (except for gen_helper_flush_flags() that updates env->cc_op) > > FIX: https://github.com/vivier/qemu-m68k/issues/19 > > Signed-off-by: Laurent Vivier > --- > target/m68k/translate.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Reviewed-by: Richard Henderson r~
Re: [Qemu-devel] [PATCH v2 3/5] target-m68k: manage pre-dec et post-inc in CAS
On 01/13/2017 04:52 AM, Laurent Vivier wrote: > In these cases we must update the address register after > the operation. > > Signed-off-by: Laurent Vivier > --- > target/m68k/translate.c | 9 + > 1 file changed, 9 insertions(+) Reviewed-by: Richard Henderson r~
Re: [Qemu-devel] [PATCH v2 4/5] target-m68k: CAS doesn't need aligned access
On 01/13/2017 04:52 AM, Laurent Vivier wrote: > Signed-off-by: Laurent Vivier > --- > target/m68k/translate.c | 1 - > 1 file changed, 1 deletion(-) Huh. Wow. Ok. Reviewed-by: Richard Henderson r~
Re: [Qemu-devel] [PATCH v2 5/5] target-m68k: increment/decrement with SP
On 01/13/2017 04:52 AM, Laurent Vivier wrote:
> +if (reg0 == 7 && opsize == OS_BYTE &&
> +m68k_feature(s->env, M68K_FEATURE_M68000)) {
> +tcg_gen_subi_i32(tmp, reg, 2);
> +} else {
> +tcg_gen_addi_i32(tmp, reg, opsize_bytes(opsize));
> +}
post-increment add.
r~
Re: [Qemu-devel] [PATCH] hw/i386: check if nvdimm is enabled before plugging
On Fri, Jan 13, 2017 at 01:17:27PM +, Stefan Hajnoczi wrote:
> On Fri, Jan 13, 2017 at 07:56:51PM +0800, Haozhong Zhang wrote:
> > The missing of 'nvdimm' in the machine type option '-M' means NVDIMM
> > is disabled. QEMU should refuse to plug any NVDIMM device in this case
> > and report the misconfiguration.
> >
> > Reported-by: Stefan Hajnoczi
> > Signed-off-by: Haozhong Zhang
> > Message-Id: 20170112110928.GF4621@stefanha-x1.localdomain
> > Message-Id: 20170111093630.2088-1-stefa...@redhat.com
> > ---
> > hw/i386/pc.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> > index 25e8586..3907609 100644
> > --- a/hw/i386/pc.c
> > +++ b/hw/i386/pc.c
> > @@ -1715,6 +1715,11 @@ static void pc_dimm_plug(HotplugHandler *hotplug_dev,
> > }
> >
> > if (object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM)) {
> > +if (!pcms->acpi_nvdimm_state.is_enabled) {
> > +error_setg(&local_err,
> > + "nvdimm is not enabled: missing 'nvdimm' in '-M'");
> > +goto out;
> > +}
>
> A warning is definitely useful to notify users of a possible
> configuration error.
>
> I wonder what happens when you plug an NVDIMM into a motherboard where
> the firmware lacks support. Does it:
> * Refuse to boot?
> * Treat the DIMM as regular RAM?
> * Boot but the DIMM will not be used by firmware and kernel?
>
> QEMU should act the same way as real hardware.
If real hardware behavior is not useful in any way (e.g. first
and third options above), is there a good reason for QEMU to not
implement an additional safety mechanism preventing NVDIMM from
being connected to a machine that doesn't support it?
--
Eduardo
Re: [Qemu-devel] [PATCH] ahci: advertise HOST_CAP_64
On Fri, Jan 13, 2017 at 6:23 PM, John Snow wrote: > On 01/13/2017 06:02 AM, Ladi Prosek wrote: >> The AHCI emulation code supports 64-bit addressing and should advertise this >> fact in the Host Capabilities register. Both Linux and Windows drivers test >> this bit to decide if the upper 32 bits of various registers may be written >> to, and at least some versions of Windows have a bug where DMA is attempted >> with an address above 4GB but, in the absence of HOST_CAP_64, the upper 32 >> bits are left unititialized which leads to a memory corruption. >> >> Signed-off-by: Ladi Prosek >> --- >> hw/ide/ahci.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c >> index 3c19bda..6a17acf 100644 >> --- a/hw/ide/ahci.c >> +++ b/hw/ide/ahci.c >> @@ -488,7 +488,7 @@ static void ahci_reg_init(AHCIState *s) >> s->control_regs.cap = (s->ports - 1) | >>(AHCI_NUM_COMMAND_SLOTS << 8) | >>(AHCI_SUPPORTED_SPEED_GEN1 << >> AHCI_SUPPORTED_SPEED) | >> - HOST_CAP_NCQ | HOST_CAP_AHCI; >> + HOST_CAP_NCQ | HOST_CAP_AHCI | HOST_CAP_64; >> >> s->control_regs.impl = (1 << s->ports) - 1; >> >> > > Was this tested? What was the use case that prompted this patch, and do > you have a public bugzilla to point to? Sorry, I thought you were aware. Here's the BZ with details: https://bugzilla.redhat.com/show_bug.cgi?id=1411105 In short, Windows guests run into issues in certain virtual HW configurations if the bit is not set. I have tested the patch and verified that it fixes the failing cases. > It looks correct via the spec, thank you for finding this oversight. It > looks like everywhere this bit would make a difference we already do the > correct thing for having this bit set. > > From what I can gather from the spec, it looks as if even 32bit guests > must ensure that the upper 32bit registers are cleared, so I think we're > all set here. > > Reviewed-by: John Snow
Re: [Qemu-devel] [PATCH] libvhost-user: Start VQs on SET_VRING_CALL
On Fri, Jan 13, 2017 at 05:15:22PM +, Felipe Franciosi wrote:
>
> > On 13 Jan 2017, at 09:04, Michael S. Tsirkin wrote:
> >
> > On Fri, Jan 13, 2017 at 03:09:46PM +, Felipe Franciosi wrote:
> >> Hi Marc-Andre,
> >>
> >>> On 13 Jan 2017, at 07:03, Marc-André Lureau wrote:
> >>>
> >>> Hi
> >>>
> >>> - Original Message -
> Currently, VQs are started as soon as a SET_VRING_KICK is received. That
> is too early in the VQ setup process, as the backend might not yet have
> >>>
> >>> I think we may want to reconsider queue_set_started(), move it elsewhere,
> >>> since kick/call fds aren't mandatory to process the rings.
> >>
> >> Hmm. The fds aren't mandatory, but I imagine in that case we should still
> >> receive SET_VRING_KICK/CALL messages without an fd (ie. with the
> >> VHOST_MSG_VQ_NOFD_MASK flag set). Wouldn't that be the case?
> >
> > Please look at docs/specs/vhost-user.txt, Starting and stopping rings
> >
> > The spec says:
> > Client must start ring upon receiving a kick (that is, detecting that
> > file descriptor is readable) on the descriptor specified by
> > VHOST_USER_SET_VRING_KICK, and stop ring upon receiving
> > VHOST_USER_GET_VRING_BASE.
>
> Yes I have seen the spec, but there is a race with the current libvhost-user
> code which needs attention. My initial proposal (which got turned down) was
> to send a spurious notification upon seeing a callfd. Then I came up with
> this proposal. See below.
>
> >
> >
> >>>
> a callfd to notify in case it received a kick and fully processed the
> request/command. This patch only starts a VQ when a SET_VRING_CALL is
> received.
> >>>
> >>> I don't like that much, as soon as the kick fd is received, it should
> >>> start polling it imho. callfd is optional, it may have one and not the
> >>> other.
> >>
> >> So the question is whether we should be receiving a SET_VRING_CALL anyway
> >> or not, regardless of an fd being sent. (I think we do, but I haven't done
> >> extensive testing with other device types.)
> >
> > I would say not, only KICK is mandatory and that is also not enough
> > to process ring. You must wait for it to be readable.
>
> The problem is that Qemu takes time between sending the kickfd and the
> callfd. Hence the race. Consider this scenario:
>
> 1) Guest configures the device
> 2) Guest put a request on a virtq
> 3) Guest kicks
> 4) Qemu starts configuring the backend
> 4.a) Qemu sends the masked callfds
> 4.b) Qemu sends the virtq sizes and addresses
> 4.c) Qemu sends the kickfds
>
> (When using MQ, Qemu will only send the callfd once all VQs are configured)
>
> 5) The backend starts listening on the kickfd upon receiving it
> 6) The backend picks up the guest's request
> 7) The backend processes the request
> 8) The backend puts the response on the used ring
> 9) The backend notifies the masked callfd
>
> 4.d) Qemu sends the callfds
>
> At which point the guest missed the notification and gets stuck.
>
> Perhaps you prefer my initial proposal of sending a spurious notification
> when the backend sees a callfd?
>
> Felipe
I thought we read the masked callfd when we unmask it,
and forward the interrupt. See kvm_irqfd_assign:
/*
* Check if there was an event already pending on the eventfd
* before we registered, and trigger it as if we didn't miss it.
*/
events = f.file->f_op->poll(f.file, &irqfd->pt);
if (events & POLLIN)
schedule_work(&irqfd->inject);
Is this a problem you observe in practice?
>
> >
> >>>
> >>> Perhaps it's best for now to delay the callfd notification with a flag
> >>> until it is received?
> >>
> >> The other idea is to always kick when we receive the callfd. I remember
> >> discussing that alternative with you before libvhost-user went in. The
> >> protocol says both the driver and the backend must handle spurious kicks.
> >> This approach also fixes the bug.
> >>
> >> I'm happy with whatever alternative you want, as long it makes
> >> libvhost-user usable for storage devices.
> >>
> >> Thanks,
> >> Felipe
> >>
> >>
> >>>
> >>>
> Signed-off-by: Felipe Franciosi
> ---
> contrib/libvhost-user/libvhost-user.c | 26 +-
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/contrib/libvhost-user/libvhost-user.c
> b/contrib/libvhost-user/libvhost-user.c
> index af4faad..a46ef90 100644
> --- a/contrib/libvhost-user/libvhost-user.c
> +++ b/contrib/libvhost-user/libvhost-user.c
> @@ -607,19 +607,6 @@ vu_set_vring_kick_exec(VuDev *dev, VhostUserMsg
> *vmsg)
> DPRINT("Got kick_fd: %d for vq: %d\n", vmsg->fds[0], index);
> }
>
> -dev->vq[index].started = true;
> -if (dev->iface->queue_set_started) {
> -dev->iface->queue_set_started(dev, index, true);
> -}
> -
> -if (dev->
Re: [Qemu-devel] [PATCH v3 2/2] memory: hmp: add "-f" for "info mtree"
* Peter Xu (pet...@redhat.com) wrote:
> Adding one more option "-f" for "info mtree" to dump the flat views of
> all the address spaces.
>
> This will be useful to debug the memory rendering logic, also it'll be
> much easier with it to know what memory region is handling what address
> range.
>
> Signed-off-by: Peter Xu
> ---
> hmp-commands-info.hx | 6 +++---
> include/exec/memory.h | 2 +-
> memory.c | 40 +++-
> monitor.c | 4 +++-
> 4 files changed, 46 insertions(+), 6 deletions(-)
>
> diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
> index 55d50c4..b0f35e6 100644
> --- a/hmp-commands-info.hx
> +++ b/hmp-commands-info.hx
> @@ -249,9 +249,9 @@ ETEXI
>
> {
> .name = "mtree",
> -.args_type = "",
> -.params = "",
> -.help = "show memory tree",
> +.args_type = "flatview:-f",
> +.params = "[-f]",
> +.help = "show memory tree (-f: dump flat view for address
> spaces)",
> .cmd= hmp_info_mtree,
> },
>
> diff --git a/include/exec/memory.h b/include/exec/memory.h
> index bec9756..71db380 100644
> --- a/include/exec/memory.h
> +++ b/include/exec/memory.h
> @@ -1254,7 +1254,7 @@ void memory_global_dirty_log_start(void);
> */
> void memory_global_dirty_log_stop(void);
>
> -void mtree_info(fprintf_function mon_printf, void *f);
> +void mtree_info(fprintf_function mon_printf, void *f, bool flatview);
>
> /**
> * memory_region_dispatch_read: perform a read directly to the specified
> diff --git a/memory.c b/memory.c
> index c42bde4..25f1c25 100644
> --- a/memory.c
> +++ b/memory.c
> @@ -2564,12 +2564,50 @@ static void mtree_print_mr(fprintf_function
> mon_printf, void *f,
> }
> }
>
> -void mtree_info(fprintf_function mon_printf, void *f)
> +static void mtree_print_flatview(fprintf_function p, void *f,
> + AddressSpace *as)
> +{
> +FlatView *view = address_space_get_flatview(as);
> +FlatRange *range = &view->ranges[0];
> +MemoryRegion *mr;
> +int n = view->nr;
> +
> +if (n <= 0) {
> +p(f, MTREE_INDENT "No rendered FlatView for "
> + "address space '%s'\n", as->name);
Do you need an unref there?
Dave
> +return;
> +}
> +
> +while (n--) {
> +mr = range->mr;
> +p(f, MTREE_INDENT TARGET_FMT_plx "-"
> + TARGET_FMT_plx " (prio %d, %s): %s\n",
> + int128_get64(range->addr.start),
> + int128_get64(range->addr.start) + MR_SIZE(range->addr.size),
> + mr->priority,
> + memory_region_type(mr),
> + memory_region_name(mr));
> +range++;
> +}
> +
> +flatview_unref(view);
> +}
> +
> +void mtree_info(fprintf_function mon_printf, void *f, bool flatview)
> {
> MemoryRegionListHead ml_head;
> MemoryRegionList *ml, *ml2;
> AddressSpace *as;
>
> +if (flatview) {
> +QTAILQ_FOREACH(as, &address_spaces, address_spaces_link) {
> +mon_printf(f, "address-space (flat view): %s\n", as->name);
> +mtree_print_flatview(mon_printf, f, as);
> +mon_printf(f, "\n");
> +}
> +return;
> +}
> +
> QTAILQ_INIT(&ml_head);
>
> QTAILQ_FOREACH(as, &address_spaces, address_spaces_link) {
> diff --git a/monitor.c b/monitor.c
> index 0841d43..679cd52 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -1529,7 +1529,9 @@ static void hmp_boot_set(Monitor *mon, const QDict
> *qdict)
>
> static void hmp_info_mtree(Monitor *mon, const QDict *qdict)
> {
> -mtree_info((fprintf_function)monitor_printf, mon);
> +bool flatview = qdict_get_try_bool(qdict, "flatview", false);
> +
> +mtree_info((fprintf_function)monitor_printf, mon, flatview);
> }
>
> static void hmp_info_numa(Monitor *mon, const QDict *qdict)
> --
> 2.7.4
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [Qemu-devel] [PATCH v2 1/5] target-m68k: fix bit operation with immediate value
Le 13/01/2017 à 18:55, Richard Henderson a écrit : > On 01/13/2017 04:51 AM, Laurent Vivier wrote: >> M680x0 bit operations with an immediate value use 9 bits of the 16bit >> value, while coldfire ones use only 8 bits. > > I don't see that in the reference manual. Where do you get this from? See "BSET Instruction Format:BIT NUMBER STATIC, SPECIFIED AS IMMEDIATE DATA", p. 4.58 of "M68000 FAMILY PROGRAMMER’S REFERENCE MANUAL", "BIT NUMBER" is bits 0 to 8 of extended word. See "Test a Bit and Set", p. 4-22 of "ColdFire Family Programmer’s Reference Manual, Rev. 3" (link given by Thomas), "Bit Number" is bits 0 to 7 of extended word. I've found the problem with RISU. Thanks, Laurent
Re: [Qemu-devel] [PATCH v2 1/5] target-m68k: fix bit operation with immediate value
On 01/13/2017 10:23 AM, Laurent Vivier wrote: > See "BSET Instruction Format:BIT NUMBER STATIC, SPECIFIED AS IMMEDIATE > DATA", p. 4.58 of "M68000 FAMILY PROGRAMMER’S REFERENCE MANUAL", "BIT > NUMBER" is bits 0 to 8 of extended word. Oops, yep. I misread that. Reviewed-by: Richard Henderson r~
Re: [Qemu-devel] [PATCH] ahci: advertise HOST_CAP_64
On 01/13/2017 01:12 PM, Ladi Prosek wrote: > On Fri, Jan 13, 2017 at 6:23 PM, John Snow wrote: >> On 01/13/2017 06:02 AM, Ladi Prosek wrote: >>> The AHCI emulation code supports 64-bit addressing and should advertise this >>> fact in the Host Capabilities register. Both Linux and Windows drivers test >>> this bit to decide if the upper 32 bits of various registers may be written >>> to, and at least some versions of Windows have a bug where DMA is attempted >>> with an address above 4GB but, in the absence of HOST_CAP_64, the upper 32 >>> bits are left unititialized which leads to a memory corruption. >>> >>> Signed-off-by: Ladi Prosek >>> --- >>> hw/ide/ahci.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c >>> index 3c19bda..6a17acf 100644 >>> --- a/hw/ide/ahci.c >>> +++ b/hw/ide/ahci.c >>> @@ -488,7 +488,7 @@ static void ahci_reg_init(AHCIState *s) >>> s->control_regs.cap = (s->ports - 1) | >>>(AHCI_NUM_COMMAND_SLOTS << 8) | >>>(AHCI_SUPPORTED_SPEED_GEN1 << >>> AHCI_SUPPORTED_SPEED) | >>> - HOST_CAP_NCQ | HOST_CAP_AHCI; >>> + HOST_CAP_NCQ | HOST_CAP_AHCI | HOST_CAP_64; >>> >>> s->control_regs.impl = (1 << s->ports) - 1; >>> >>> >> >> Was this tested? What was the use case that prompted this patch, and do >> you have a public bugzilla to point to? > > Sorry, I thought you were aware. Here's the BZ with details: > https://bugzilla.redhat.com/show_bug.cgi?id=1411105 > It's for the public record :) I'm going to amend your commit message, OK? https://github.com/jnsnow/qemu/commit/f037be92fc0c4580b846134e0355a69d0eccd0d9 > In short, Windows guests run into issues in certain virtual HW > configurations if the bit is not set. I have tested the patch and > verified that it fixes the failing cases. > Great. I'm CCing qemu-stable as this should probably be included in 2.7.2 / 2.8.1 / etc. >> It looks correct via the spec, thank you for finding this oversight. It >> looks like everywhere this bit would make a difference we already do the >> correct thing for having this bit set. >> >> From what I can gather from the spec, it looks as if even 32bit guests >> must ensure that the upper 32bit registers are cleared, so I think we're >> all set here. >> >> Reviewed-by: John Snow Thanks, applied to my IDE tree: https://github.com/jnsnow/qemu/commits/ide https://github.com/jnsnow/qemu.git --js
[Qemu-devel] [PATCH v3 3/5] target-m68k: manage pre-dec et post-inc in CAS
In these cases we must update the address register after
the operation.
Signed-off-by: Laurent Vivier
Reviewed-by: Richard Henderson
---
target/m68k/translate.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/target/m68k/translate.c b/target/m68k/translate.c
index 0e97900..23e2b06 100644
--- a/target/m68k/translate.c
+++ b/target/m68k/translate.c
@@ -1963,6 +1963,15 @@ DISAS_INSN(cas)
gen_partset_reg(opsize, DREG(ext, 0), load);
tcg_temp_free(load);
+
+switch (extract32(insn, 3, 3)) {
+case 3: /* Indirect postincrement. */
+tcg_gen_addi_i32(AREG(insn, 0), addr, opsize_bytes(opsize));
+break;
+case 4: /* Indirect predecrememnt. */
+tcg_gen_mov_i32(AREG(insn, 0), addr);
+break;
+}
}
DISAS_INSN(cas2w)
--
2.7.4
[Qemu-devel] [PATCH v3 0/5] Fixes for target/m68k
This is a series of fixes for target/m68k found: - with RISU (bit operation with immediate) - while debugging package build under chroot (gen_flush_flags() and CAS address modes) - while I was working on the softmmu mode (CAS alignment and SP address modes) v2: - Don't align stack access on coldfire. v3: - Fix v2 :( that has introduced a subi instead of an addi Laurent Vivier (5): target-m68k: fix bit operation with immediate value target-m68k: fix gen_flush_flags() target-m68k: manage pre-dec et post-inc in CAS target-m68k: CAS doesn't need aligned access target-m68k: increment/decrement with SP target/m68k/translate.c | 40 +--- 1 file changed, 33 insertions(+), 7 deletions(-) -- 2.7.4
[Qemu-devel] [PATCH v3 4/5] target-m68k: CAS doesn't need aligned access
Signed-off-by: Laurent Vivier Reviewed-by: Richard Henderson --- target/m68k/translate.c | 1 - 1 file changed, 1 deletion(-) diff --git a/target/m68k/translate.c b/target/m68k/translate.c index 23e2b06..cf5d8dd 100644 --- a/target/m68k/translate.c +++ b/target/m68k/translate.c @@ -1934,7 +1934,6 @@ DISAS_INSN(cas) default: g_assert_not_reached(); } -opc |= MO_ALIGN; ext = read_im16(env, s); -- 2.7.4
[Qemu-devel] [PATCH v3 5/5] target-m68k: increment/decrement with SP
On 680x0 family only.
Address Register indirect With postincrement:
When using the stack pointer (A7) with byte size data, the register
is incremented by two.
Address Register indirect With predecrement:
When using the stack pointer (A7) with byte size data, the register
is decremented by two.
Signed-off-by: Laurent Vivier
Reviewed-by: Thomas Huth
---
target/m68k/translate.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/target/m68k/translate.c b/target/m68k/translate.c
index cf5d8dd..9f60fbc 100644
--- a/target/m68k/translate.c
+++ b/target/m68k/translate.c
@@ -725,7 +725,12 @@ static TCGv gen_lea_mode(CPUM68KState *env, DisasContext
*s,
}
reg = get_areg(s, reg0);
tmp = tcg_temp_new();
-tcg_gen_subi_i32(tmp, reg, opsize_bytes(opsize));
+if (reg0 == 7 && opsize == OS_BYTE &&
+m68k_feature(s->env, M68K_FEATURE_M68000)) {
+tcg_gen_subi_i32(tmp, reg, 2);
+} else {
+tcg_gen_subi_i32(tmp, reg, opsize_bytes(opsize));
+}
return tmp;
case 5: /* Indirect displacement. */
reg = get_areg(s, reg0);
@@ -801,7 +806,12 @@ static TCGv gen_ea_mode(CPUM68KState *env, DisasContext
*s, int mode, int reg0,
result = gen_ldst(s, opsize, reg, val, what);
if (what == EA_STORE || !addrp) {
TCGv tmp = tcg_temp_new();
-tcg_gen_addi_i32(tmp, reg, opsize_bytes(opsize));
+if (reg0 == 7 && opsize == OS_BYTE &&
+m68k_feature(s->env, M68K_FEATURE_M68000)) {
+tcg_gen_addi_i32(tmp, reg, 2);
+} else {
+tcg_gen_addi_i32(tmp, reg, opsize_bytes(opsize));
+}
delay_set_areg(s, reg0, tmp, true);
}
return result;
--
2.7.4
[Qemu-devel] [PATCH v3 1/5] target-m68k: fix bit operation with immediate value
M680x0 bit operations with an immediate value use 9 bits of the 16bit
value, while coldfire ones use only 8 bits.
Signed-off-by: Laurent Vivier
Reviewed-by: Richard Henderson
---
target/m68k/translate.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/target/m68k/translate.c b/target/m68k/translate.c
index 5f7357e..410f56a 100644
--- a/target/m68k/translate.c
+++ b/target/m68k/translate.c
@@ -1801,9 +1801,16 @@ DISAS_INSN(bitop_im)
op = (insn >> 6) & 3;
bitnum = read_im16(env, s);
-if (bitnum & 0xff00) {
-disas_undef(env, s, insn);
-return;
+if (m68k_feature(s->env, M68K_FEATURE_M68000)) {
+if (bitnum & 0xfe00) {
+disas_undef(env, s, insn);
+return;
+}
+} else {
+if (bitnum & 0xff00) {
+disas_undef(env, s, insn);
+return;
+}
}
SRC_EA(env, src1, opsize, 0, op ? &addr: NULL);
--
2.7.4
[Qemu-devel] [PATCH v3 2/5] target-m68k: fix gen_flush_flags()
gen_flush_flags() is setting unconditionally cc_op_synced to 1 and s->cc_op to CC_OP_FLAGS, whereas env->cc_op can be set to something else by a previous tcg fragment. We fix that by not setting cc_op_synced to 1 (except for gen_helper_flush_flags() that updates env->cc_op) FIX: https://github.com/vivier/qemu-m68k/issues/19 Signed-off-by: Laurent Vivier Reviewed-by: Richard Henderson --- target/m68k/translate.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/target/m68k/translate.c b/target/m68k/translate.c index 410f56a..0e97900 100644 --- a/target/m68k/translate.c +++ b/target/m68k/translate.c @@ -595,18 +595,19 @@ static void gen_flush_flags(DisasContext *s) case CC_OP_DYNAMIC: gen_helper_flush_flags(cpu_env, QREG_CC_OP); +s->cc_op_synced = 1; break; default: t0 = tcg_const_i32(s->cc_op); gen_helper_flush_flags(cpu_env, t0); tcg_temp_free(t0); +s->cc_op_synced = 1; break; } /* Note that flush_flags also assigned to env->cc_op. */ s->cc_op = CC_OP_FLAGS; -s->cc_op_synced = 1; } static inline TCGv gen_extend(TCGv val, int opsize, int sign) -- 2.7.4
[Qemu-devel] [PATCH] target-i386: Remove AMD feature flag aliases from Opteron models
When CPU vendor is set to AMD, the AMD feature alias bits on
CPUID[0x8001].EDX are already automatically copied from CPUID[1].EDX
on x86_cpu_realizefn(). When CPU vendor is Intel, those bits are
reserved and should be zero. On either case, those bits shouldn't be set
in the CPU model table.
Commit 726a8ff68677d8d5fba17eb0ffb85076bfb598dc removed those
bits from most CPU models, but the Opteron_* entries still have
them. Remove the alias bits from Opteron_* too.
Add an assert() to x86_register_cpudef_type() to ensure we don't
make the same mistake again.
Signed-off-by: Eduardo Habkost
---
target/i386/cpu.c | 46 --
1 file changed, 12 insertions(+), 34 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index a149c8dc42..af726a8fd0 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -1339,12 +1339,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
.features[FEAT_1_ECX] =
CPUID_EXT_SSE3,
.features[FEAT_8000_0001_EDX] =
-CPUID_EXT2_LM | CPUID_EXT2_FXSR | CPUID_EXT2_MMX |
-CPUID_EXT2_NX | CPUID_EXT2_PSE36 | CPUID_EXT2_PAT |
-CPUID_EXT2_CMOV | CPUID_EXT2_MCA | CPUID_EXT2_PGE |
-CPUID_EXT2_MTRR | CPUID_EXT2_SYSCALL | CPUID_EXT2_APIC |
-CPUID_EXT2_CX8 | CPUID_EXT2_MCE | CPUID_EXT2_PAE | CPUID_EXT2_MSR |
-CPUID_EXT2_TSC | CPUID_EXT2_PSE | CPUID_EXT2_DE | CPUID_EXT2_FPU,
+CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
.xlevel = 0x8008,
.model_id = "AMD Opteron 240 (Gen 1 Class Opteron)",
},
@@ -1365,13 +1360,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
CPUID_EXT_CX16 | CPUID_EXT_SSE3,
/* Missing: CPUID_EXT2_RDTSCP */
.features[FEAT_8000_0001_EDX] =
-CPUID_EXT2_LM | CPUID_EXT2_FXSR |
-CPUID_EXT2_MMX | CPUID_EXT2_NX | CPUID_EXT2_PSE36 |
-CPUID_EXT2_PAT | CPUID_EXT2_CMOV | CPUID_EXT2_MCA |
-CPUID_EXT2_PGE | CPUID_EXT2_MTRR | CPUID_EXT2_SYSCALL |
-CPUID_EXT2_APIC | CPUID_EXT2_CX8 | CPUID_EXT2_MCE |
-CPUID_EXT2_PAE | CPUID_EXT2_MSR | CPUID_EXT2_TSC | CPUID_EXT2_PSE |
-CPUID_EXT2_DE | CPUID_EXT2_FPU,
+CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
.features[FEAT_8000_0001_ECX] =
CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM,
.xlevel = 0x8008,
@@ -1395,13 +1384,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
CPUID_EXT_SSE3,
/* Missing: CPUID_EXT2_RDTSCP */
.features[FEAT_8000_0001_EDX] =
-CPUID_EXT2_LM | CPUID_EXT2_FXSR |
-CPUID_EXT2_MMX | CPUID_EXT2_NX | CPUID_EXT2_PSE36 |
-CPUID_EXT2_PAT | CPUID_EXT2_CMOV | CPUID_EXT2_MCA |
-CPUID_EXT2_PGE | CPUID_EXT2_MTRR | CPUID_EXT2_SYSCALL |
-CPUID_EXT2_APIC | CPUID_EXT2_CX8 | CPUID_EXT2_MCE |
-CPUID_EXT2_PAE | CPUID_EXT2_MSR | CPUID_EXT2_TSC | CPUID_EXT2_PSE |
-CPUID_EXT2_DE | CPUID_EXT2_FPU,
+CPUID_EXT2_LM | CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
.features[FEAT_8000_0001_ECX] =
CPUID_EXT3_MISALIGNSSE | CPUID_EXT3_SSE4A |
CPUID_EXT3_ABM | CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM,
@@ -1428,13 +1411,8 @@ static X86CPUDefinition builtin_x86_defs[] = {
CPUID_EXT_SSE3,
/* Missing: CPUID_EXT2_RDTSCP */
.features[FEAT_8000_0001_EDX] =
-CPUID_EXT2_LM |
-CPUID_EXT2_PDPE1GB | CPUID_EXT2_FXSR | CPUID_EXT2_MMX |
-CPUID_EXT2_NX | CPUID_EXT2_PSE36 | CPUID_EXT2_PAT |
-CPUID_EXT2_CMOV | CPUID_EXT2_MCA | CPUID_EXT2_PGE |
-CPUID_EXT2_MTRR | CPUID_EXT2_SYSCALL | CPUID_EXT2_APIC |
-CPUID_EXT2_CX8 | CPUID_EXT2_MCE | CPUID_EXT2_PAE | CPUID_EXT2_MSR |
-CPUID_EXT2_TSC | CPUID_EXT2_PSE | CPUID_EXT2_DE | CPUID_EXT2_FPU,
+CPUID_EXT2_LM | CPUID_EXT2_PDPE1GB | CPUID_EXT2_NX |
+CPUID_EXT2_SYSCALL,
.features[FEAT_8000_0001_ECX] =
CPUID_EXT3_FMA4 | CPUID_EXT3_XOP |
CPUID_EXT3_3DNOWPREFETCH | CPUID_EXT3_MISALIGNSSE |
@@ -1464,13 +1442,8 @@ static X86CPUDefinition builtin_x86_defs[] = {
CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3,
/* Missing: CPUID_EXT2_RDTSCP */
.features[FEAT_8000_0001_EDX] =
-CPUID_EXT2_LM |
-CPUID_EXT2_PDPE1GB | CPUID_EXT2_FXSR | CPUID_EXT2_MMX |
-CPUID_EXT2_NX | CPUID_EXT2_PSE36 | CPUID_EXT2_PAT |
-CPUID_EXT2_CMOV | CPUID_EXT2_MCA | CPUID_EXT2_PGE |
-CPUID_EXT2_MTRR | CPUID_EXT2_SYSCALL | CPUID_EXT2_APIC |
-CPUID_EXT2_CX8 | CPUID_EXT2_MCE | CPUID_EXT2_PAE | CPUID_EXT2_MSR |
-CPUID_EXT2_TSC | CPUID_EXT2_PSE | CPUID_EXT2_DE | CPUID_EXT2_FPU,
+CPUID_EXT2_LM | CPUID_EXT2_PDPE1GB | CPUID_EXT2_NX |
+CPUID_EXT2_SYSCALL,
.features[FEAT_8000_00
Re: [Qemu-devel] [PATCH] ahci: advertise HOST_CAP_64
On Fri, Jan 13, 2017 at 7:31 PM, John Snow wrote: > > > On 01/13/2017 01:12 PM, Ladi Prosek wrote: >> On Fri, Jan 13, 2017 at 6:23 PM, John Snow wrote: >>> On 01/13/2017 06:02 AM, Ladi Prosek wrote: The AHCI emulation code supports 64-bit addressing and should advertise this fact in the Host Capabilities register. Both Linux and Windows drivers test this bit to decide if the upper 32 bits of various registers may be written to, and at least some versions of Windows have a bug where DMA is attempted with an address above 4GB but, in the absence of HOST_CAP_64, the upper 32 bits are left unititialized which leads to a memory corruption. Signed-off-by: Ladi Prosek --- hw/ide/ahci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c index 3c19bda..6a17acf 100644 --- a/hw/ide/ahci.c +++ b/hw/ide/ahci.c @@ -488,7 +488,7 @@ static void ahci_reg_init(AHCIState *s) s->control_regs.cap = (s->ports - 1) | (AHCI_NUM_COMMAND_SLOTS << 8) | (AHCI_SUPPORTED_SPEED_GEN1 << AHCI_SUPPORTED_SPEED) | - HOST_CAP_NCQ | HOST_CAP_AHCI; + HOST_CAP_NCQ | HOST_CAP_AHCI | HOST_CAP_64; s->control_regs.impl = (1 << s->ports) - 1; >>> >>> Was this tested? What was the use case that prompted this patch, and do >>> you have a public bugzilla to point to? >> >> Sorry, I thought you were aware. Here's the BZ with details: >> https://bugzilla.redhat.com/show_bug.cgi?id=1411105 >> > > It's for the public record :) > > I'm going to amend your commit message, OK? > > https://github.com/jnsnow/qemu/commit/f037be92fc0c4580b846134e0355a69d0eccd0d9 Minor nit: the OS we know for sure is affected is Windows Server 2008, without the "R2". Thanks! >> In short, Windows guests run into issues in certain virtual HW >> configurations if the bit is not set. I have tested the patch and >> verified that it fixes the failing cases. >> > > Great. I'm CCing qemu-stable as this should probably be included in > 2.7.2 / 2.8.1 / etc. > >>> It looks correct via the spec, thank you for finding this oversight. It >>> looks like everywhere this bit would make a difference we already do the >>> correct thing for having this bit set. >>> >>> From what I can gather from the spec, it looks as if even 32bit guests >>> must ensure that the upper 32bit registers are cleared, so I think we're >>> all set here. >>> >>> Reviewed-by: John Snow > > Thanks, applied to my IDE tree: > > https://github.com/jnsnow/qemu/commits/ide > https://github.com/jnsnow/qemu.git > > --js
Re: [Qemu-devel] [PATCH] ahci: advertise HOST_CAP_64
On 01/13/2017 02:01 PM, Ladi Prosek wrote: > On Fri, Jan 13, 2017 at 7:31 PM, John Snow wrote: >> >> >> On 01/13/2017 01:12 PM, Ladi Prosek wrote: >>> On Fri, Jan 13, 2017 at 6:23 PM, John Snow wrote: On 01/13/2017 06:02 AM, Ladi Prosek wrote: > The AHCI emulation code supports 64-bit addressing and should advertise > this > fact in the Host Capabilities register. Both Linux and Windows drivers > test > this bit to decide if the upper 32 bits of various registers may be > written > to, and at least some versions of Windows have a bug where DMA is > attempted > with an address above 4GB but, in the absence of HOST_CAP_64, the upper 32 > bits are left unititialized which leads to a memory corruption. > > Signed-off-by: Ladi Prosek > --- > hw/ide/ahci.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c > index 3c19bda..6a17acf 100644 > --- a/hw/ide/ahci.c > +++ b/hw/ide/ahci.c > @@ -488,7 +488,7 @@ static void ahci_reg_init(AHCIState *s) > s->control_regs.cap = (s->ports - 1) | >(AHCI_NUM_COMMAND_SLOTS << 8) | >(AHCI_SUPPORTED_SPEED_GEN1 << > AHCI_SUPPORTED_SPEED) | > - HOST_CAP_NCQ | HOST_CAP_AHCI; > + HOST_CAP_NCQ | HOST_CAP_AHCI | HOST_CAP_64; > > s->control_regs.impl = (1 << s->ports) - 1; > > Was this tested? What was the use case that prompted this patch, and do you have a public bugzilla to point to? >>> >>> Sorry, I thought you were aware. Here's the BZ with details: >>> https://bugzilla.redhat.com/show_bug.cgi?id=1411105 >>> >> >> It's for the public record :) >> >> I'm going to amend your commit message, OK? >> >> https://github.com/jnsnow/qemu/commit/f037be92fc0c4580b846134e0355a69d0eccd0d9 > > Minor nit: the OS we know for sure is affected is Windows Server 2008, > without the "R2". Thanks! > I misunderstood. It looked like the initial report was for "SP2," though I see you saying that the R2 version actually worked okay, but by coincidence. I didn't think there *was* an "SP2," for Windows Server, so I interpreted that to mean R2. So this only manifests with vanilla 2008? >>> In short, Windows guests run into issues in certain virtual HW >>> configurations if the bit is not set. I have tested the patch and >>> verified that it fixes the failing cases. >>> >> >> Great. I'm CCing qemu-stable as this should probably be included in >> 2.7.2 / 2.8.1 / etc. >> It looks correct via the spec, thank you for finding this oversight. It looks like everywhere this bit would make a difference we already do the correct thing for having this bit set. From what I can gather from the spec, it looks as if even 32bit guests must ensure that the upper 32bit registers are cleared, so I think we're all set here. Reviewed-by: John Snow >> >> Thanks, applied to my IDE tree: >> >> https://github.com/jnsnow/qemu/commits/ide >> https://github.com/jnsnow/qemu.git >> >> --js
Re: [Qemu-devel] [PULL 000/180] QAPI patches for 2017-01-13
On 01/13/2017 10:44 AM, Markus Armbruster wrote: > This is Marc-André's "[PATCH v8 00/21] qapi doc generation (whole > version, squashed)" with a few commit messages tweaked, and "[PATCH v8 > 14/21] (SQUASHED) move doc to schema" unsquashed into 161 patches. > > We did all the respins with in this squashed form to reduce noise. > However, since the unsquashed form is better suited for review, and > probably nicer if we have to revisit this part of the work down the > road, I'm proposing to merge this unsquashed. > > If you want me to post the unsquashed patches, I'm happy to redo this > pull request. > > If you'd rather pull the squashed version, likewise. > > I'm afraid this is a bit of a doc conflict magnet. The sooner we can > get it in, the easier for Marc-André and me. Indeed - there's already a merge conflict with commit e1ff3c6, which landed between the time you created the pull request and now. Also, in trying to merge your branch locally, I get a rejection message from my git hooks: $ git commit tests/qapi-schema/comments.out:7: new blank line at EOF. tests/qapi-schema/event-case.out:8: new blank line at EOF. tests/qapi-schema/ident-with-escape.out:10: new blank line at EOF. tests/qapi-schema/include-relpath.out:7: new blank line at EOF. tests/qapi-schema/include-repetition.out:7: new blank line at EOF. tests/qapi-schema/include-simple.out:7: new blank line at EOF. tests/qapi-schema/indented-expr.out:13: new blank line at EOF. tests/qapi-schema/qapi-schema-test.out:446: new blank line at EOF. Worth respinning to fix those issues? > qmp-commands: move 'query-memdev' doc to schema This one is the conflict with current master. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 29/40] char: move win chardev base class in its own file
On 01/11/2017 11:29 AM, Marc-André Lureau wrote: > Signed-off-by: Marc-André Lureau > --- > chardev/char-win.h| 30 ++ > chardev/char-win.c| 242 +++ > chardev/char.c| 253 > +- > chardev/Makefile.objs | 1 + > 4 files changed, 276 insertions(+), 250 deletions(-) > create mode 100644 chardev/char-win.h > create mode 100644 chardev/char-win.c > > +++ b/chardev/Makefile.objs > @@ -4,3 +4,4 @@ chardev-obj-y += char-io.o > chardev-obj-y += char-mux.o > chardev-obj-y += char-null.o > chardev-obj-y += char-ringbuf.o > +chardev-obj-$(CONFIG_WIN32) += char-win.o This part is the neatest - trading #ifdefs in the code for conditionally compiling an entire .c file. I have not closely read 28-39, so I don't know if R-b is appropriate, but they are all mechanical and the fact that it still compiles is good. So maybe we go with the weaker: Acked-by: Eric Blake -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
