[Qemu-devel] qemu feedback

[dave]

hy,

i'm glad of qemu and i found a real valid project.


i would comunicate my difficulties in understanding virtual 
networking features.

you should provide some example about:

  - how configure qemu with a guest os that has an ssh server.
  (i tried using user-net and redirect without success)
  
  - a step to step configuration using tap/tun.


thank you.


-- 
>here are more things in heaven and earth,
horatio, than are dreamt of in your philosophy.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[PATCH] block: Remove unused aio_task_pool_empty

[dave]

From: "Dr. David Alan Gilbert" 

aio_task_pool_empty has been unused since it was added in
  6e9b225f73 ("block: introduce aio task pool")

Remove it.

Signed-off-by: Dr. David Alan Gilbert 
---
 block/aio_task.c | 5 -
 include/block/aio_task.h | 2 --
 2 files changed, 7 deletions(-)

diff --git a/block/aio_task.c b/block/aio_task.c
index 9bd17ea2c1..bb5c05f455 100644
--- a/block/aio_task.c
+++ b/block/aio_task.c
@@ -119,8 +119,3 @@ int aio_task_pool_status(AioTaskPool *pool)
 
 return pool->status;
 }
-
-bool aio_task_pool_empty(AioTaskPool *pool)
-{
-return pool->busy_tasks == 0;
-}
diff --git a/include/block/aio_task.h b/include/block/aio_task.h
index 18a9c41f4e..c81d637617 100644
--- a/include/block/aio_task.h
+++ b/include/block/aio_task.h
@@ -40,8 +40,6 @@ void aio_task_pool_free(AioTaskPool *);
 /* error code of failed task or 0 if all is OK */
 int aio_task_pool_status(AioTaskPool *pool);
 
-bool aio_task_pool_empty(AioTaskPool *pool);
-
 /* User provides filled @task, however task->pool will be set automatically */
 void coroutine_fn aio_task_pool_start_task(AioTaskPool *pool, AioTask *task);
 
-- 
2.46.0

[PATCH] block-backend: Remove deadcode

[dave]

From: "Dr. David Alan Gilbert" 

blk_by_public last use was removed in 2017 by
  c61791fc23 ("block: add aio_context field in ThrottleGroupMember")

blk_activate last use was removed earlier this year by
  eef0bae3a7 ("migration: Remove block migration")

blk_add_insert_bs_notifier, blk_op_block_all, blk_op_unblock_all
last uses were removed in 2016 by
  ef8875b549 ("virtio-scsi: Remove op blocker for dataplane")

blk_iostatus_disable last use was removed in 2016 by
  66a0fae438 ("blockjob: Don't touch BDS iostatus")

Remove them.

Signed-off-by: Dr. David Alan Gilbert 
---
 block/block-backend.c   | 73 -
 include/sysemu/block-backend-global-state.h |  8 ---
 2 files changed, 81 deletions(-)

diff --git a/block/block-backend.c b/block/block-backend.c
index db6f9b92a3..7bea43bf72 100644
--- a/block/block-backend.c
+++ b/block/block-backend.c
@@ -853,15 +853,6 @@ BlockBackendPublic *blk_get_public(BlockBackend *blk)
 return &blk->public;
 }
 
-/*
- * Returns a BlockBackend given the associated @public fields.
- */
-BlockBackend *blk_by_public(BlockBackendPublic *public)
-{
-GLOBAL_STATE_CODE();
-return container_of(public, BlockBackend, public);
-}
-
 /*
  * Disassociates the currently associated BlockDriverState from @blk.
  */
@@ -1214,12 +1205,6 @@ BlockDeviceIoStatus blk_iostatus(const BlockBackend *blk)
 return blk->iostatus;
 }
 
-void blk_iostatus_disable(BlockBackend *blk)
-{
-GLOBAL_STATE_CODE();
-blk->iostatus_enabled = false;
-}
-
 void blk_iostatus_reset(BlockBackend *blk)
 {
 GLOBAL_STATE_CODE();
@@ -2228,28 +2213,6 @@ void blk_set_enable_write_cache(BlockBackend *blk, bool 
wce)
 blk->enable_write_cache = wce;
 }
 
-void blk_activate(BlockBackend *blk, Error **errp)
-{
-BlockDriverState *bs = blk_bs(blk);
-GLOBAL_STATE_CODE();
-
-if (!bs) {
-error_setg(errp, "Device '%s' has no medium", blk->name);
-return;
-}
-
-/*
- * Migration code can call this function in coroutine context, so leave
- * coroutine context if necessary.
- */
-if (qemu_in_coroutine()) {
-bdrv_co_activate(bs, errp);
-} else {
-GRAPH_RDLOCK_GUARD_MAINLOOP();
-bdrv_activate(bs, errp);
-}
-}
-
 bool coroutine_fn blk_co_is_inserted(BlockBackend *blk)
 {
 BlockDriverState *bs = blk_bs(blk);
@@ -2380,36 +2343,6 @@ bool blk_op_is_blocked(BlockBackend *blk, BlockOpType 
op, Error **errp)
 return bdrv_op_is_blocked(bs, op, errp);
 }
 
-void blk_op_unblock(BlockBackend *blk, BlockOpType op, Error *reason)
-{
-BlockDriverState *bs = blk_bs(blk);
-GLOBAL_STATE_CODE();
-
-if (bs) {
-bdrv_op_unblock(bs, op, reason);
-}
-}
-
-void blk_op_block_all(BlockBackend *blk, Error *reason)
-{
-BlockDriverState *bs = blk_bs(blk);
-GLOBAL_STATE_CODE();
-
-if (bs) {
-bdrv_op_block_all(bs, reason);
-}
-}
-
-void blk_op_unblock_all(BlockBackend *blk, Error *reason)
-{
-BlockDriverState *bs = blk_bs(blk);
-GLOBAL_STATE_CODE();
-
-if (bs) {
-bdrv_op_unblock_all(bs, reason);
-}
-}
-
 /**
  * Return BB's current AioContext.  Note that this context may change
  * concurrently at any time, with one exception: If the BB has a root node
@@ -2564,12 +2497,6 @@ void blk_add_remove_bs_notifier(BlockBackend *blk, 
Notifier *notify)
 notifier_list_add(&blk->remove_bs_notifiers, notify);
 }
 
-void blk_add_insert_bs_notifier(BlockBackend *blk, Notifier *notify)
-{
-GLOBAL_STATE_CODE();
-notifier_list_add(&blk->insert_bs_notifiers, notify);
-}
-
 BlockAcctStats *blk_get_stats(BlockBackend *blk)
 {
 IO_CODE();
diff --git a/include/sysemu/block-backend-global-state.h 
b/include/sysemu/block-backend-global-state.h
index 49c12b0fa9..9cc9b008ec 100644
--- a/include/sysemu/block-backend-global-state.h
+++ b/include/sysemu/block-backend-global-state.h
@@ -54,7 +54,6 @@ bool monitor_add_blk(BlockBackend *blk, const char *name, 
Error **errp);
 void monitor_remove_blk(BlockBackend *blk);
 
 BlockBackendPublic *blk_get_public(BlockBackend *blk);
-BlockBackend *blk_by_public(BlockBackendPublic *public);
 
 void blk_remove_bs(BlockBackend *blk);
 int blk_insert_bs(BlockBackend *blk, BlockDriverState *bs, Error **errp);
@@ -67,7 +66,6 @@ void blk_get_perm(BlockBackend *blk, uint64_t *perm, uint64_t 
*shared_perm);
 
 void blk_iostatus_enable(BlockBackend *blk);
 BlockDeviceIoStatus blk_iostatus(const BlockBackend *blk);
-void blk_iostatus_disable(BlockBackend *blk);
 void blk_iostatus_reset(BlockBackend *blk);
 int blk_attach_dev(BlockBackend *blk, DeviceState *dev);
 void blk_detach_dev(BlockBackend *blk, DeviceState *dev);
@@ -76,8 +74,6 @@ BlockBackend *blk_by_dev(void *dev);
 BlockBackend *blk_by_qdev_id(const char *id, Error **errp);
 void blk_set_dev_ops(BlockBackend *blk, const BlockDevOps *ops, void *opaque);
 
-void blk_activate(BlockBackend *blk, Error **errp);
-
 int blk_make_zero(BlockBackend *blk, BdrvRequestFlags flags);

[PATCH] hw/xen: Remove deadcode

[dave]

From: "Dr. David Alan Gilbert" 

xen_be_copy_grant_refs is unused since 2019's
  19f87870ba ("xen: remove the legacy 'xen_disk' backend")

xen_config_dev_console is unused since 2018's
  6d7c06c213 ("Remove broken Xen PV domain builder")

Remove them.

Signed-off-by: Dr. David Alan Gilbert 
---
 hw/xen/xen-legacy-backend.c | 18 --
 hw/xen/xen_devconfig.c  |  8 
 include/hw/xen/xen-legacy-backend.h |  5 -
 3 files changed, 31 deletions(-)

diff --git a/hw/xen/xen-legacy-backend.c b/hw/xen/xen-legacy-backend.c
index 5514184f9c..e8e1ee4f7d 100644
--- a/hw/xen/xen-legacy-backend.c
+++ b/hw/xen/xen-legacy-backend.c
@@ -147,24 +147,6 @@ void xen_be_unmap_grant_refs(struct XenLegacyDevice 
*xendev, void *ptr,
 }
 }
 
-int xen_be_copy_grant_refs(struct XenLegacyDevice *xendev,
-   bool to_domain,
-   XenGrantCopySegment segs[],
-   unsigned int nr_segs)
-{
-int rc;
-
-assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV);
-
-rc = qemu_xen_gnttab_grant_copy(xendev->gnttabdev, to_domain, xen_domid,
-segs, nr_segs, NULL);
-if (rc) {
-xen_pv_printf(xendev, 0, "xengnttab_grant_copy failed: %s\n",
-  strerror(-rc));
-}
-return rc;
-}
-
 /*
  * get xen backend device, allocate a new one if it doesn't exist.
  */
diff --git a/hw/xen/xen_devconfig.c b/hw/xen/xen_devconfig.c
index 2150869f60..45ae134b84 100644
--- a/hw/xen/xen_devconfig.c
+++ b/hw/xen/xen_devconfig.c
@@ -66,11 +66,3 @@ int xen_config_dev_vkbd(int vdev)
 xen_config_dev_dirs("vkbd", "vkbd", vdev, fe, be, sizeof(fe));
 return xen_config_dev_all(fe, be);
 }
-
-int xen_config_dev_console(int vdev)
-{
-char fe[256], be[256];
-
-xen_config_dev_dirs("console", "console", vdev, fe, be, sizeof(fe));
-return xen_config_dev_all(fe, be);
-}
diff --git a/include/hw/xen/xen-legacy-backend.h 
b/include/hw/xen/xen-legacy-backend.h
index 943732b8d1..e198b120c5 100644
--- a/include/hw/xen/xen-legacy-backend.h
+++ b/include/hw/xen/xen-legacy-backend.h
@@ -50,10 +50,6 @@ void *xen_be_map_grant_refs(struct XenLegacyDevice *xendev, 
uint32_t *refs,
 void xen_be_unmap_grant_refs(struct XenLegacyDevice *xendev, void *ptr,
  uint32_t *refs, unsigned int nr_refs);
 
-int xen_be_copy_grant_refs(struct XenLegacyDevice *xendev,
-   bool to_domain, XenGrantCopySegment segs[],
-   unsigned int nr_segs);
-
 static inline void *xen_be_map_grant_ref(struct XenLegacyDevice *xendev,
  uint32_t ref, int prot)
 {
@@ -70,6 +66,5 @@ static inline void xen_be_unmap_grant_ref(struct 
XenLegacyDevice *xendev,
 void xen_config_cleanup(void);
 int xen_config_dev_vfb(int vdev, const char *type);
 int xen_config_dev_vkbd(int vdev);
-int xen_config_dev_console(int vdev);
 
 #endif /* HW_XEN_LEGACY_BACKEND_H */
-- 
2.46.0

[PATCH] ui/cursor: remove cursor_get_mono_image

[dave]

From: "Dr. David Alan Gilbert" 

cursor_get_mono_image has been unused since 2018's
  0015ca5cba ("ui: remove support for SDL1.2 in favour of SDL2")

Remove it.

Signed-off-by: Dr. David Alan Gilbert 
---
 include/ui/console.h |  1 -
 ui/cursor.c  | 24 
 2 files changed, 25 deletions(-)

diff --git a/include/ui/console.h b/include/ui/console.h
index fa986ab97e..5832d52a8a 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -175,7 +175,6 @@ int cursor_get_mono_bpl(QEMUCursor *c);
 void cursor_set_mono(QEMUCursor *c,
  uint32_t foreground, uint32_t background, uint8_t *image,
  int transparent, uint8_t *mask);
-void cursor_get_mono_image(QEMUCursor *c, int foreground, uint8_t *mask);
 void cursor_get_mono_mask(QEMUCursor *c, int transparent, uint8_t *mask);
 
 typedef void *QEMUGLContext;
diff --git a/ui/cursor.c b/ui/cursor.c
index dd3853320d..6e23244fbe 100644
--- a/ui/cursor.c
+++ b/ui/cursor.c
@@ -197,30 +197,6 @@ void cursor_set_mono(QEMUCursor *c,
 }
 }
 
-void cursor_get_mono_image(QEMUCursor *c, int foreground, uint8_t *image)
-{
-uint32_t *data = c->data;
-uint8_t bit;
-int x,y,bpl;
-
-bpl = cursor_get_mono_bpl(c);
-memset(image, 0, bpl * c->height);
-for (y = 0; y < c->height; y++) {
-bit = 0x80;
-for (x = 0; x < c->width; x++, data++) {
-if (((*data & 0xff00) == 0xff00) &&
-((*data & 0x00ff) == foreground)) {
-image[x/8] |= bit;
-}
-bit >>= 1;
-if (bit == 0) {
-bit = 0x80;
-}
-}
-image += bpl;
-}
-}
-
 void cursor_get_mono_mask(QEMUCursor *c, int transparent, uint8_t *mask)
 {
 uint32_t *data = c->data;
-- 
2.46.0

Re: absolute firmware path made relocatable in qemu 5.2.0

[Dave]

This is my qemu binary compiled with --prefix=/nonexistent


bash-5.1# ./qemu-system-x86_64 -L help
/usr/share/qemu
/usr/share/qemu-firmware
/usr/src/sources/qemu-5.2.0/build/pc-bios

bash-5.1# ./qemu-system-x86_64 --help|grep helper

[,br=bridge][,helper=helper][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off]
use network helper 'helper' 
(default=/nonexistent/libexec/qemu-bridge-helper) to

-netdev bridge,id=str[,br=bridge][,helper=helper]
using the program 'helper 
(default=/nonexistent/libexec/qemu-bridge-helper)


See that it will call /nonexistent/libexec/qemu-bridge-helper by default.

Dave

On 12/01/2021 23:53, Paolo Bonzini wrote:

On 12/01/21 18:04, Dave wrote:

Thanks Paola,

We are still in testing and that's the only thing we've uncovered so 
far with the new 5.2.0. I will post if the ops guys find anything else.


Hmm, that's weird though.  The path to the default bridge helper is 
relocated:


net/tap.c:    helper = default_helper = 
get_relocated_path(DEFAULT_BRIDGE_HELPER);


Paolo

absolute firmware path made relocatable in qemu 5.2.0

[Dave]

Hi,

Is seem that absolute firmwarepath compilation option is converted  to 
relocatable in 5.2.0 qemu.


# QEMU configure log Tue 12 Jan 14:46:41 GST 2021
# Configured with: '../configure' '--prefix=/usr' 
'--sysconfdir=/etc/qemu' '--disable-bochs'  
'*--firmwarepath=/usr/share/qemu:/usr/share/qemu-firmware*'

#

And trying to run the executable

   bash-5.1# ./qemu-system-x86_64
   qemu: could not load PC BIOS 'bios-256k.bin'

If i print out the resultant binary paths

   bash-5.1# ./qemu-system-x86_64 -L help
   /root/qemu/../share/qemu
   /root/qemu/../share/qemu-firmware

So there is no way to have a absolute path for firmware /bios and all 
qemu's that we test need to be at the right directory nesting to find 
firmware, bios etc or else they all need their own duplicate firmware 
files. Firmware path needs to honor the absolute paths i believe.


Comments ?

Dave

Re: absolute firmware path made relocatable in qemu 5.2.0

[Dave]

Hi Paolo,

While this (option 2) partially works, it will still search for 
/nonexistent/libexec/qemu-bridge-helper for example so seems that some 
paths are still absolute and some relative.


To explain, what we are expecting that we compile one binary with the 
relevant options, test that and then it goes into production. If we 
compile with --prefix=/usr (it's final resting place will be /usr/bin) 
then everything works as expected once it is in production (since 
/usr/share/qemu, /usr/libexec, /etc/qemu exists as expected).  However 
when we are testing the binary in a directory /root/qemu/5.2.0 with 
--prefix=/usr it breaks since it converts the firmware and bios paths to 
/root/qemu/5.2.0/../share/qemu. This means we need to recompile twice 
with relevant prefixes since if i use --prefix=/nonexistent then we 
can't find the qemu-bridge-helper when the binary goes into production.


It would be nicer with the relocatable binary took some fixed paths from 
/etc/qemu.conf for the bridge-helper, firmware, bios, qemu-ifup/down.


thanks
Dave


On 12/01/2021 18:48, Paolo Bonzini wrote:

On 12/01/21 15:05, Dave wrote:
Is seem that absolute firmwarepath compilation option is converted  to 
relocatable in 5.2.0 qemu.


# QEMU configure log Tue 12 Jan 14:46:41 GST 2021
# Configured with: '../configure' '--prefix=/usr' 
'--sysconfdir=/etc/qemu' '--disable-bochs' 
'*--firmwarepath=/usr/share/qemu:/usr/share/qemu-firmware*'

#


Yes, all paths within the prefix are relocated.  The workaround is 
simply to configure the intended prefix with configure:


./configure --prefix=/root/qemu ...

or if you don't know the prefix:

./configure --prefix=/nonexistent ...

Because /usr/share/qemu and /usr/share/qemu-firmware are outside /usr, 
they will be treated as absolute just like /etc/qemu.


Thanks,

Paolo


And trying to run the executable

    bash-5.1# ./qemu-system-x86_64
    qemu: could not load PC BIOS 'bios-256k.bin'

If i print out the resultant binary paths

    bash-5.1# ./qemu-system-x86_64 -L help
    /root/qemu/../share/qemu
    /root/qemu/../share/qemu-firmware

So there is no way to have a absolute path for firmware /bios and all 
qemu's that we test need to be at the right directory nesting to find 
firmware, bios etc or else they all need their own duplicate firmware 
files. Firmware path needs to honor the absolute paths i believe.

Re: absolute firmware path made relocatable in qemu 5.2.0

[Dave]

Thanks Paola,

We are still in testing and that's the only thing we've uncovered so far 
with the new 5.2.0. I will post if the ops guys find anything else.


Dave

On 12/01/2021 20:53, Paolo Bonzini wrote:



Il mar 12 gen 2021, 17:48 Dave mailto:d...@0bits.com>> 
ha scritto:


Hi Paolo,

While this (option 2) partially works, it will still search for
/nonexistent/libexec/qemu-bridge-helper for example so seems that some
paths are still absolute and some relative.


Ok, that's a bug that can be fixed in 5.2.1. Are there other instances?


To explain, what we are expecting that we compile one binary with the
relevant options, test that and then it goes into production. If we
compile with --prefix=/usr (it's final resting place will be /usr/bin)
then everything works as expected once it is in production (since
/usr/share/qemu, /usr/libexec, /etc/qemu exists as expected).  However
when we are testing the binary in a directory /root/qemu/5.2.0 with
--prefix=/usr it breaks since it converts the firmware and bios
paths to
/root/qemu/5.2.0/../share/qemu. This means we need to recompile twice
with relevant prefixes since if i use --prefix=/nonexistent then we
can't find the qemu-bridge-helper when the binary goes into production.

It would be nicer with the relocatable binary took some fixed paths
from
/etc/qemu.conf for the bridge-helper, firmware, bios, qemu-ifup/down.

thanks
Dave


On 12/01/2021 18:48, Paolo Bonzini wrote:
 > On 12/01/21 15:05, Dave wrote:
 >> Is seem that absolute firmwarepath compilation option is
converted  to
 >> relocatable in 5.2.0 qemu.
 >>
 >> # QEMU configure log Tue 12 Jan 14:46:41 GST 2021
 >> # Configured with: '../configure' '--prefix=/usr'
 >> '--sysconfdir=/etc/qemu' '--disable-bochs'
 >> '*--firmwarepath=/usr/share/qemu:/usr/share/qemu-firmware*'
 >> #
 >
 > Yes, all paths within the prefix are relocated.  The workaround is
 > simply to configure the intended prefix with configure:
 >
 > ./configure --prefix=/root/qemu ...
 >
 > or if you don't know the prefix:
 >
 > ./configure --prefix=/nonexistent ...
 >
 > Because /usr/share/qemu and /usr/share/qemu-firmware are outside
/usr,
 > they will be treated as absolute just like /etc/qemu.
 >
 > Thanks,
 >
 > Paolo
 >
 >> And trying to run the executable
 >>
 >>     bash-5.1# ./qemu-system-x86_64
 >>     qemu: could not load PC BIOS 'bios-256k.bin'
 >>
 >> If i print out the resultant binary paths
 >>
 >>     bash-5.1# ./qemu-system-x86_64 -L help
 >>     /root/qemu/../share/qemu
 >>     /root/qemu/../share/qemu-firmware
 >>
 >> So there is no way to have a absolute path for firmware /bios
and all
 >> qemu's that we test need to be at the right directory nesting to
find
 >> firmware, bios etc or else they all need their own duplicate
firmware
 >> files. Firmware path needs to honor the absolute paths i believe.
 >>
 >

[PATCH] sockets: Remove deadcode

[dave]

From: "Dr. David Alan Gilbert" 

socket_remote_address hasn't been used since it was added in
  17c55decec ("sockets: add helpers for creating SocketAddress from a socket")

inet_connect hasn't been used since 2017's
  8ecc2f9eab ("sheepdog: Use SocketAddress and socket_connect()")

Remove them.

Signed-off-by: Dr. David Alan Gilbert 
---
 include/qemu/sockets.h | 16 
 util/qemu-sockets.c| 35 ---
 2 files changed, 51 deletions(-)

diff --git a/include/qemu/sockets.h b/include/qemu/sockets.h
index d935fd80da..c562690d89 100644
--- a/include/qemu/sockets.h
+++ b/include/qemu/sockets.h
@@ -61,7 +61,6 @@ int socket_set_fast_reuse(int fd);
 int inet_ai_family_from_address(InetSocketAddress *addr,
 Error **errp);
 int inet_parse(InetSocketAddress *addr, const char *str, Error **errp);
-int inet_connect(const char *str, Error **errp);
 int inet_connect_saddr(InetSocketAddress *saddr, Error **errp);
 
 NetworkAddressFamily inet_netfamily(int family);
@@ -117,21 +116,6 @@ socket_sockaddr_to_address(struct sockaddr_storage *sa,
  */
 SocketAddress *socket_local_address(int fd, Error **errp);
 
-/**
- * socket_remote_address:
- * @fd: the socket file handle
- * @errp: pointer to uninitialized error object
- *
- * Get the string representation of the remote socket
- * address. A pointer to the allocated address information
- * struct will be returned, which the caller is required to
- * release with a call qapi_free_SocketAddress() when no
- * longer required.
- *
- * Returns: the socket address struct, or NULL on error
- */
-SocketAddress *socket_remote_address(int fd, Error **errp);
-
 /**
  * socket_address_flatten:
  * @addr: the socket address to flatten
diff --git a/util/qemu-sockets.c b/util/qemu-sockets.c
index 60c44b2b56..c1b162b056 100644
--- a/util/qemu-sockets.c
+++ b/util/qemu-sockets.c
@@ -707,26 +707,6 @@ int inet_parse(InetSocketAddress *addr, const char *str, 
Error **errp)
 }
 
 
-/**
- * Create a blocking socket and connect it to an address.
- *
- * @str: address string
- * @errp: set in case of an error
- *
- * Returns -1 in case of error, file descriptor on success
- **/
-int inet_connect(const char *str, Error **errp)
-{
-int sock = -1;
-InetSocketAddress *addr = g_new(InetSocketAddress, 1);
-
-if (!inet_parse(addr, str, errp)) {
-sock = inet_connect_saddr(addr, errp);
-}
-qapi_free_InetSocketAddress(addr);
-return sock;
-}
-
 #ifdef CONFIG_AF_VSOCK
 static bool vsock_parse_vaddr_to_sockaddr(const VsockSocketAddress *vaddr,
   struct sockaddr_vm *svm,
@@ -1421,21 +1401,6 @@ SocketAddress *socket_local_address(int fd, Error **errp)
 }
 
 
-SocketAddress *socket_remote_address(int fd, Error **errp)
-{
-struct sockaddr_storage ss;
-socklen_t sslen = sizeof(ss);
-
-if (getpeername(fd, (struct sockaddr *)&ss, &sslen) < 0) {
-error_setg_errno(errp, errno, "%s",
- "Unable to query remote socket address");
-return NULL;
-}
-
-return socket_sockaddr_to_address(&ss, sslen, errp);
-}
-
-
 SocketAddress *socket_address_flatten(SocketAddressLegacy *addr_legacy)
 {
 SocketAddress *addr;
-- 
2.46.0

[PATCH] replay: Remove unused replay_disable_events

[dave]

From: "Dr. David Alan Gilbert" 

replay_disable_events has been unused since 2019's
  c8aa7895eb ("replay: don't drain/flush bdrv queue while RR is working")

Remove it.

Signed-off-by: Dr. David Alan Gilbert 
---
 include/sysemu/replay.h | 2 --
 replay/replay-events.c  | 9 -
 2 files changed, 11 deletions(-)

diff --git a/include/sysemu/replay.h b/include/sysemu/replay.h
index 8102fa54f0..cba74fa9bc 100644
--- a/include/sysemu/replay.h
+++ b/include/sysemu/replay.h
@@ -117,8 +117,6 @@ void replay_async_events(void);
 
 /* Asynchronous events queue */
 
-/*! Disables storing events in the queue */
-void replay_disable_events(void);
 /*! Enables storing events in the queue */
 void replay_enable_events(void);
 /*! Returns true when saving events is enabled */
diff --git a/replay/replay-events.c b/replay/replay-events.c
index af0721cc1a..2e46eda6bf 100644
--- a/replay/replay-events.c
+++ b/replay/replay-events.c
@@ -92,15 +92,6 @@ void replay_flush_events(void)
 }
 }
 
-void replay_disable_events(void)
-{
-if (replay_mode != REPLAY_MODE_NONE) {
-events_enabled = false;
-/* Flush events queue before waiting of completion */
-replay_flush_events();
-}
-}
-
 /*! Adds specified async event to the queue */
 void replay_add_event(ReplayAsyncEventKind event_kind,
   void *opaque,
-- 
2.46.0

[PATCH] hw/pci: Remove unused pcie_chassis_find_slot

[dave]

From: "Dr. David Alan Gilbert" 

pcie_chassis_find_slot has been unused since it was added.

Remove it.

Signed-off-by: Dr. David Alan Gilbert 
---
 hw/pci/pcie_port.c | 10 --
 include/hw/pci/pcie_port.h |  1 -
 2 files changed, 11 deletions(-)

diff --git a/hw/pci/pcie_port.c b/hw/pci/pcie_port.c
index 20ff2b39e8..9f978ba164 100644
--- a/hw/pci/pcie_port.c
+++ b/hw/pci/pcie_port.c
@@ -92,16 +92,6 @@ static PCIESlot *pcie_chassis_find_slot_with_chassis(struct 
PCIEChassis *c,
 return s;
 }
 
-PCIESlot *pcie_chassis_find_slot(uint8_t chassis_number, uint16_t slot)
-{
-struct PCIEChassis *c;
-c = pcie_chassis_find(chassis_number);
-if (!c) {
-return NULL;
-}
-return pcie_chassis_find_slot_with_chassis(c, slot);
-}
-
 int pcie_chassis_add_slot(struct PCIESlot *slot)
 {
 struct PCIEChassis *c;
diff --git a/include/hw/pci/pcie_port.h b/include/hw/pci/pcie_port.h
index 90e6cf45b8..7cd7af8cfa 100644
--- a/include/hw/pci/pcie_port.h
+++ b/include/hw/pci/pcie_port.h
@@ -72,7 +72,6 @@ struct PCIESlot {
 };
 
 void pcie_chassis_create(uint8_t chassis_number);
-PCIESlot *pcie_chassis_find_slot(uint8_t chassis, uint16_t slot);
 int pcie_chassis_add_slot(struct PCIESlot *slot);
 void pcie_chassis_del_slot(PCIESlot *s);
 
-- 
2.46.0

[PATCH] io/channel-socket: Remove unused qio_channel_socket_dgram_async

[dave]

From: "Dr. David Alan Gilbert" 

qio_channel_socket_dgram_async has been unused since it was originally
added in 2015.

Remove it.

Signed-off-by: Dr. David Alan Gilbert 
---
 include/io/channel-socket.h | 29 
 io/channel-socket.c | 54 -
 io/trace-events |  1 -
 3 files changed, 84 deletions(-)

diff --git a/include/io/channel-socket.h b/include/io/channel-socket.h
index ab15577d38..6c858cc6b5 100644
--- a/include/io/channel-socket.h
+++ b/include/io/channel-socket.h
@@ -182,35 +182,6 @@ int qio_channel_socket_dgram_sync(QIOChannelSocket *ioc,
   SocketAddress *remoteAddr,
   Error **errp);
 
-/**
- * qio_channel_socket_dgram_async:
- * @ioc: the socket channel object
- * @localAddr: the address to local bind address
- * @remoteAddr: the address to remote peer address
- * @callback: the function to invoke on completion
- * @opaque: user data to pass to @callback
- * @destroy: the function to free @opaque
- * @context: the context to run the async task. If %NULL, the default
- *   context will be used.
- *
- * Attempt to initialize a datagram socket bound to
- * @localAddr and communicating with peer @remoteAddr.
- * This method will run in the background so the caller
- * will regain execution control immediately. The function
- * @callback will be invoked on completion or failure.
- * The @localAddr and @remoteAddr parameters will be copied,
- * so may be freed as soon as this function returns without
- * waiting for completion.
- */
-void qio_channel_socket_dgram_async(QIOChannelSocket *ioc,
-SocketAddress *localAddr,
-SocketAddress *remoteAddr,
-QIOTaskFunc callback,
-gpointer opaque,
-GDestroyNotify destroy,
-GMainContext *context);
-
-
 /**
  * qio_channel_socket_get_local_address:
  * @ioc: the socket channel object
diff --git a/io/channel-socket.c b/io/channel-socket.c
index 608bcf066e..2282e7a549 100644
--- a/io/channel-socket.c
+++ b/io/channel-socket.c
@@ -319,60 +319,6 @@ int qio_channel_socket_dgram_sync(QIOChannelSocket *ioc,
 }
 
 
-struct QIOChannelSocketDGramWorkerData {
-SocketAddress *localAddr;
-SocketAddress *remoteAddr;
-};
-
-
-static void qio_channel_socket_dgram_worker_free(gpointer opaque)
-{
-struct QIOChannelSocketDGramWorkerData *data = opaque;
-qapi_free_SocketAddress(data->localAddr);
-qapi_free_SocketAddress(data->remoteAddr);
-g_free(data);
-}
-
-static void qio_channel_socket_dgram_worker(QIOTask *task,
-gpointer opaque)
-{
-QIOChannelSocket *ioc = QIO_CHANNEL_SOCKET(qio_task_get_source(task));
-struct QIOChannelSocketDGramWorkerData *data = opaque;
-Error *err = NULL;
-
-/* socket_dgram() blocks in DNS lookups, so we must use a thread */
-qio_channel_socket_dgram_sync(ioc, data->localAddr,
-  data->remoteAddr, &err);
-
-qio_task_set_error(task, err);
-}
-
-
-void qio_channel_socket_dgram_async(QIOChannelSocket *ioc,
-SocketAddress *localAddr,
-SocketAddress *remoteAddr,
-QIOTaskFunc callback,
-gpointer opaque,
-GDestroyNotify destroy,
-GMainContext *context)
-{
-QIOTask *task = qio_task_new(
-OBJECT(ioc), callback, opaque, destroy);
-struct QIOChannelSocketDGramWorkerData *data = g_new0(
-struct QIOChannelSocketDGramWorkerData, 1);
-
-data->localAddr = QAPI_CLONE(SocketAddress, localAddr);
-data->remoteAddr = QAPI_CLONE(SocketAddress, remoteAddr);
-
-trace_qio_channel_socket_dgram_async(ioc, localAddr, remoteAddr);
-qio_task_run_in_thread(task,
-   qio_channel_socket_dgram_worker,
-   data,
-   qio_channel_socket_dgram_worker_free,
-   context);
-}
-
-
 QIOChannelSocket *
 qio_channel_socket_accept(QIOChannelSocket *ioc,
   Error **errp)
diff --git a/io/trace-events b/io/trace-events
index d4c0f84a9a..5d0d4358db 100644
--- a/io/trace-events
+++ b/io/trace-events
@@ -25,7 +25,6 @@ qio_channel_socket_listen_async(void *ioc, void *addr, int 
num) "Socket listen a
 qio_channel_socket_listen_fail(void *ioc) "Socket listen fail ioc=%p"
 qio_channel_socket_listen_complete(void *ioc, int fd) "Socket listen complete 
ioc=%p fd=%d"
 qio_channel_socket_dgram_sync(void *ioc, void *localAddr, void *remoteAddr) 
"Socket dgram sync ioc=%p localAddr=%p remoteAddr=%p"
-qio_channel_socket_dgram_async(void *ioc, void *localAddr, void *remoteAdd

[PATCH] hw/net/net_rx_pkt: Remove deadcode

[dave]

From: "Dr. David Alan Gilbert" 

net_rx_pkt_get_l3_hdr_offset and net_rx_pkt_get_iovec_len haven't
been used since they were added.

Remove them.

Signed-off-by: Dr. David Alan Gilbert 
---
 hw/net/net_rx_pkt.c | 13 -
 hw/net/net_rx_pkt.h |  9 -
 2 files changed, 22 deletions(-)

diff --git a/hw/net/net_rx_pkt.c b/hw/net/net_rx_pkt.c
index 32e5f3f9cf..cec1d0523d 100644
--- a/hw/net/net_rx_pkt.c
+++ b/hw/net/net_rx_pkt.c
@@ -209,12 +209,6 @@ void net_rx_pkt_get_protocols(struct NetRxPkt *pkt,
 *l4hdr_proto = pkt->l4hdr_info.proto;
 }
 
-size_t net_rx_pkt_get_l3_hdr_offset(struct NetRxPkt *pkt)
-{
-assert(pkt);
-return pkt->l3hdr_off;
-}
-
 size_t net_rx_pkt_get_l4_hdr_offset(struct NetRxPkt *pkt)
 {
 assert(pkt);
@@ -427,13 +421,6 @@ struct iovec *net_rx_pkt_get_iovec(struct NetRxPkt *pkt)
 return pkt->vec;
 }
 
-uint16_t net_rx_pkt_get_iovec_len(struct NetRxPkt *pkt)
-{
-assert(pkt);
-
-return pkt->vec_len;
-}
-
 void net_rx_pkt_set_vhdr(struct NetRxPkt *pkt,
 struct virtio_net_hdr *vhdr)
 {
diff --git a/hw/net/net_rx_pkt.h b/hw/net/net_rx_pkt.h
index 55ec67a1a7..e8df9cfd52 100644
--- a/hw/net/net_rx_pkt.h
+++ b/hw/net/net_rx_pkt.h
@@ -267,15 +267,6 @@ net_rx_pkt_attach_data(struct NetRxPkt *pkt, const void 
*data,
  */
 struct iovec *net_rx_pkt_get_iovec(struct NetRxPkt *pkt);
 
-/**
-* returns io vector length that holds the attached data
-*
-* @pkt:packet
-* @ret:IOVec length
-*
-*/
-uint16_t net_rx_pkt_get_iovec_len(struct NetRxPkt *pkt);
-
 /**
  * prints rx packet data if debug is enabled
  *
-- 
2.46.0

[PATCH] hw/net/rocker: Remove unused rocker_fp_ports

[dave]

From: "Dr. David Alan Gilbert" 

rocker_fp_ports hasn't been used since it was added back in 2015.
Remove it.

Signed-off-by: Dr. David Alan Gilbert 
---
 hw/net/rocker/rocker.c | 5 -
 hw/net/rocker/rocker.h | 1 -
 2 files changed, 6 deletions(-)

diff --git a/hw/net/rocker/rocker.c b/hw/net/rocker/rocker.c
index 1ab5852113..5e74acc969 100644
--- a/hw/net/rocker/rocker.c
+++ b/hw/net/rocker/rocker.c
@@ -134,11 +134,6 @@ RockerPortList *qmp_query_rocker_ports(const char *name, 
Error **errp)
 return list;
 }
 
-uint32_t rocker_fp_ports(Rocker *r)
-{
-return r->fp_ports;
-}
-
 static uint32_t rocker_get_pport_by_tx_ring(Rocker *r,
 DescRing *ring)
 {
diff --git a/hw/net/rocker/rocker.h b/hw/net/rocker/rocker.h
index f85354d9d1..6e0962f47a 100644
--- a/hw/net/rocker/rocker.h
+++ b/hw/net/rocker/rocker.h
@@ -72,7 +72,6 @@ DECLARE_INSTANCE_CHECKER(Rocker, ROCKER,
  TYPE_ROCKER)
 
 Rocker *rocker_find(const char *name);
-uint32_t rocker_fp_ports(Rocker *r);
 int rocker_event_link_changed(Rocker *r, uint32_t pport, bool link_up);
 int rocker_event_mac_vlan_seen(Rocker *r, uint32_t pport, uint8_t *addr,
uint16_t vlan_id);
-- 
2.46.0

[PATCH] util/iova-tree: Remove deadcode

[dave]

From: "Dr. David Alan Gilbert" 

iova_tree_find_address, and iova_tree_foreach have never been
used since the code was originally added by:
  eecf5eedbd ("util: implement simple iova tree")

Remove them.

Signed-off-by: Dr. David Alan Gilbert 
---
 include/qemu/iova-tree.h | 25 -
 util/iova-tree.c | 23 ---
 2 files changed, 48 deletions(-)

diff --git a/include/qemu/iova-tree.h b/include/qemu/iova-tree.h
index 2a10a7052e..44a45931d5 100644
--- a/include/qemu/iova-tree.h
+++ b/include/qemu/iova-tree.h
@@ -111,31 +111,6 @@ const DMAMap *iova_tree_find(const IOVATree *tree, const 
DMAMap *map);
  */
 const DMAMap *iova_tree_find_iova(const IOVATree *tree, const DMAMap *map);
 
-/**
- * iova_tree_find_address:
- *
- * @tree: the iova tree to search from
- * @iova: the iova address to find
- *
- * Similar to iova_tree_find(), but it tries to find mapping with
- * range iova=iova & size=0.
- *
- * Return: same as iova_tree_find().
- */
-const DMAMap *iova_tree_find_address(const IOVATree *tree, hwaddr iova);
-
-/**
- * iova_tree_foreach:
- *
- * @tree: the iova tree to iterate on
- * @iterator: the iterator for the mappings, return true to stop
- *
- * Iterate over the iova tree.
- *
- * Return: 1 if found any overlap, 0 if not, <0 if error.
- */
-void iova_tree_foreach(IOVATree *tree, iova_tree_iterator iterator);
-
 /**
  * iova_tree_alloc_map:
  *
diff --git a/util/iova-tree.c b/util/iova-tree.c
index 536789797e..06295e2755 100644
--- a/util/iova-tree.c
+++ b/util/iova-tree.c
@@ -115,13 +115,6 @@ const DMAMap *iova_tree_find_iova(const IOVATree *tree, 
const DMAMap *map)
 return args.result;
 }
 
-const DMAMap *iova_tree_find_address(const IOVATree *tree, hwaddr iova)
-{
-const DMAMap map = { .iova = iova, .size = 0 };
-
-return iova_tree_find(tree, &map);
-}
-
 static inline void iova_tree_insert_internal(GTree *gtree, DMAMap *range)
 {
 /* Key and value are sharing the same range data */
@@ -148,22 +141,6 @@ int iova_tree_insert(IOVATree *tree, const DMAMap *map)
 return IOVA_OK;
 }
 
-static gboolean iova_tree_traverse(gpointer key, gpointer value,
-gpointer data)
-{
-iova_tree_iterator iterator = data;
-DMAMap *map = key;
-
-g_assert(key == value);
-
-return iterator(map);
-}
-
-void iova_tree_foreach(IOVATree *tree, iova_tree_iterator iterator)
-{
-g_tree_foreach(tree->tree, iova_tree_traverse, iterator);
-}
-
 void iova_tree_remove(IOVATree *tree, DMAMap map)
 {
 const DMAMap *overlap;
-- 
2.46.0

[PATCH] hw/char: Remove unused serial_set_frequency

[dave]

From: "Dr. David Alan Gilbert" 

serial_set_frequnecy has been unused since it was added in 2009:
  038eaf82c8 ("serial: Add interface to set reference oscillator frequency")

It looks like the 'baudbase' is now a property anyway so the wrapper
isn't needed.

Remove it.

Signed-off-by: Dr. David Alan Gilbert 
---
 hw/char/serial.c | 7 ---
 include/hw/char/serial.h | 2 --
 2 files changed, 9 deletions(-)

diff --git a/hw/char/serial.c b/hw/char/serial.c
index d8b2db5082..6c5c4a23c7 100644
--- a/hw/char/serial.c
+++ b/hw/char/serial.c
@@ -951,13 +951,6 @@ static void serial_unrealize(DeviceState *dev)
 qemu_unregister_reset(serial_reset, s);
 }
 
-/* Change the main reference oscillator frequency. */
-void serial_set_frequency(SerialState *s, uint32_t frequency)
-{
-s->baudbase = frequency;
-serial_update_parameters(s);
-}
-
 const MemoryRegionOps serial_io_ops = {
 .read = serial_ioport_read,
 .write = serial_ioport_write,
diff --git a/include/hw/char/serial.h b/include/hw/char/serial.h
index 6e14099ee7..40aad21df3 100644
--- a/include/hw/char/serial.h
+++ b/include/hw/char/serial.h
@@ -93,8 +93,6 @@ struct SerialMM {
 extern const VMStateDescription vmstate_serial;
 extern const MemoryRegionOps serial_io_ops;
 
-void serial_set_frequency(SerialState *s, uint32_t frequency);
-
 #define TYPE_SERIAL "serial"
 OBJECT_DECLARE_SIMPLE_TYPE(SerialState, SERIAL)
 
-- 
2.46.0

[PATCH] linux-user: Remove unused handle_vm86_fault

[dave]

From: "Dr. David Alan Gilbert" 

handle_vm86_fault has been unused since:
  1ade5b2fed ("linux-user/i386: Split out maybe_handle_vm86_trap")

Remove it, and it's local macros.

Signed-off-by: Dr. David Alan Gilbert 
---
 linux-user/user-internals.h |   1 -
 linux-user/vm86.c   | 136 
 2 files changed, 137 deletions(-)

diff --git a/linux-user/user-internals.h b/linux-user/user-internals.h
index 5c7f173ceb..46ffc093f4 100644
--- a/linux-user/user-internals.h
+++ b/linux-user/user-internals.h
@@ -102,7 +102,6 @@ int host_to_target_waitstatus(int status);
 /* vm86.c */
 void save_v86_state(CPUX86State *env);
 void handle_vm86_trap(CPUX86State *env, int trapno);
-void handle_vm86_fault(CPUX86State *env);
 int do_vm86(CPUX86State *env, long subfunction, abi_ulong v86_addr);
 #elif defined(TARGET_SPARC64)
 void sparc64_set_context(CPUSPARCState *env);
diff --git a/linux-user/vm86.c b/linux-user/vm86.c
index 9f512a2242..31a2d707cf 100644
--- a/linux-user/vm86.c
+++ b/linux-user/vm86.c
@@ -255,142 +255,6 @@ void handle_vm86_trap(CPUX86State *env, int trapno)
 }
 }
 
-#define CHECK_IF_IN_TRAP() \
-  if ((ts->vm86plus.vm86plus.flags & TARGET_vm86dbg_active) && \
-  (ts->vm86plus.vm86plus.flags & TARGET_vm86dbg_TFpendig)) \
-newflags |= TF_MASK
-
-#define VM86_FAULT_RETURN \
-if ((ts->vm86plus.vm86plus.flags & TARGET_force_return_for_pic) && \
-(ts->v86flags & (IF_MASK | VIF_MASK))) \
-return_to_32bit(env, TARGET_VM86_PICRETURN); \
-return
-
-void handle_vm86_fault(CPUX86State *env)
-{
-CPUState *cs = env_cpu(env);
-TaskState *ts = get_task_state(cs);
-uint32_t csp, ssp;
-unsigned int ip, sp, newflags, newip, newcs, opcode, intno;
-int data32, pref_done;
-
-csp = env->segs[R_CS].selector << 4;
-ip = env->eip & 0x;
-
-ssp = env->segs[R_SS].selector << 4;
-sp = env->regs[R_ESP] & 0x;
-
-LOG_VM86("VM86 exception %04x:%08x\n",
- env->segs[R_CS].selector, env->eip);
-
-data32 = 0;
-pref_done = 0;
-do {
-opcode = vm_getb(env, csp, ip);
-ADD16(ip, 1);
-switch (opcode) {
-case 0x66:  /* 32-bit data */ data32=1; break;
-case 0x67:  /* 32-bit address */  break;
-case 0x2e:  /* CS */  break;
-case 0x3e:  /* DS */  break;
-case 0x26:  /* ES */  break;
-case 0x36:  /* SS */  break;
-case 0x65:  /* GS */  break;
-case 0x64:  /* FS */  break;
-case 0xf2:  /* repnz */  break;
-case 0xf3:  /* rep */ break;
-default: pref_done = 1;
-}
-} while (!pref_done);
-
-/* VM86 mode */
-switch(opcode) {
-case 0x9c: /* pushf */
-if (data32) {
-vm_putl(env, ssp, sp - 4, get_vflags(env));
-ADD16(env->regs[R_ESP], -4);
-} else {
-vm_putw(env, ssp, sp - 2, get_vflags(env));
-ADD16(env->regs[R_ESP], -2);
-}
-env->eip = ip;
-VM86_FAULT_RETURN;
-
-case 0x9d: /* popf */
-if (data32) {
-newflags = vm_getl(env, ssp, sp);
-ADD16(env->regs[R_ESP], 4);
-} else {
-newflags = vm_getw(env, ssp, sp);
-ADD16(env->regs[R_ESP], 2);
-}
-env->eip = ip;
-CHECK_IF_IN_TRAP();
-if (data32) {
-if (set_vflags_long(newflags, env))
-return;
-} else {
-if (set_vflags_short(newflags, env))
-return;
-}
-VM86_FAULT_RETURN;
-
-case 0xcd: /* int */
-intno = vm_getb(env, csp, ip);
-ADD16(ip, 1);
-env->eip = ip;
-if (ts->vm86plus.vm86plus.flags & TARGET_vm86dbg_active) {
-if ( (ts->vm86plus.vm86plus.vm86dbg_intxxtab[intno >> 3] >>
-  (intno &7)) & 1) {
-return_to_32bit(env, TARGET_VM86_INTx + (intno << 8));
-return;
-}
-}
-do_int(env, intno);
-break;
-
-case 0xcf: /* iret */
-if (data32) {
-newip = vm_getl(env, ssp, sp) & 0x;
-newcs = vm_getl(env, ssp, sp + 4) & 0x;
-newflags = vm_getl(env, ssp, sp + 8);
-ADD16(env->regs[R_ESP], 12);
-} else {
-newip = vm_getw(env, ssp, sp);
-newcs = vm_getw(env, ssp, sp + 2);
-newflags = vm_getw(env, ssp, sp + 4);
-ADD16(env->regs[R_ESP], 6);
-}
-env->eip = newip;
-cpu_x86_load_seg(env, R_CS, newcs);
-CHECK_IF_IN_TRAP();
-if (data32) {
-if (set_vflags_long(newflags, env))
-return;
-} else {
-if (set_vflags_short(newflags, env))
-return;
-}
-VM86_FAULT_RETURN;
-
-   

[PATCH] crypto: Remove unused DER string functions

[dave]

From: "Dr. David Alan Gilbert" 

qcrypto_der_encode_octet_str_begin and _end have been unused
since they were added in
  3b34ccad66 ("crypto: Support DER encodings")

Remove them.

Signed-off-by: Dr. David Alan Gilbert 
---
 crypto/der.c | 13 -
 crypto/der.h | 22 --
 2 files changed, 35 deletions(-)

diff --git a/crypto/der.c b/crypto/der.c
index ebbecfc3fe..81367524c3 100644
--- a/crypto/der.c
+++ b/crypto/der.c
@@ -408,19 +408,6 @@ void qcrypto_der_encode_octet_str(QCryptoEncodeContext 
*ctx,
 qcrypto_der_encode_prim(ctx, tag, src, src_len);
 }
 
-void qcrypto_der_encode_octet_str_begin(QCryptoEncodeContext *ctx)
-{
-uint8_t tag = QCRYPTO_DER_TAG(QCRYPTO_DER_TAG_CLASS_UNIV,
-  QCRYPTO_DER_TAG_ENC_PRIM,
-  QCRYPTO_DER_TYPE_TAG_OCT_STR);
-qcrypto_der_encode_cons_begin(ctx, tag);
-}
-
-void qcrypto_der_encode_octet_str_end(QCryptoEncodeContext *ctx)
-{
-qcrypto_der_encode_cons_end(ctx);
-}
-
 size_t qcrypto_der_encode_ctx_buffer_len(QCryptoEncodeContext *ctx)
 {
 return ctx->root.dlen;
diff --git a/crypto/der.h b/crypto/der.h
index f4ba6da28a..bcfa4a2495 100644
--- a/crypto/der.h
+++ b/crypto/der.h
@@ -242,28 +242,6 @@ void qcrypto_der_encode_null(QCryptoEncodeContext *ctx);
 void qcrypto_der_encode_octet_str(QCryptoEncodeContext *ctx,
   const uint8_t *src, size_t src_len);
 
-/**
- * qcrypto_der_encode_octet_str_begin:
- * @ctx: the encode context.
- *
- * Start encoding a octet string, All fields between
- * qcrypto_der_encode_octet_str_begin and qcrypto_der_encode_octet_str_end
- * are encoded as an octet string. This is useful when we need to encode a
- * encoded SEQUENCE as OCTET STRING.
- */
-void qcrypto_der_encode_octet_str_begin(QCryptoEncodeContext *ctx);
-
-/**
- * qcrypto_der_encode_octet_str_end:
- * @ctx: the encode context.
- *
- * Finish encoding a octet string, All fields between
- * qcrypto_der_encode_octet_str_begin and qcrypto_der_encode_octet_str_end
- * are encoded as an octet string. This is useful when we need to encode a
- * encoded SEQUENCE as OCTET STRING.
- */
-void qcrypto_der_encode_octet_str_end(QCryptoEncodeContext *ctx);
-
 /**
  * qcrypto_der_encode_ctx_buffer_len:
  * @ctx: the encode context.
-- 
2.46.0

[PATCH] util/cutils: Remove unused qemu_get_exec_dir

[dave]

From: "Dr. David Alan Gilbert" 

qemu_get_exec_dir has been unused since commit:
  5bebe03f51 ("util/cutils: Clean up global variable shadowing in 
get_relocated_path()")

Remove it, and fix up a comment that pointed to it.

Signed-off-by: Dr. David Alan Gilbert 
---
 include/qemu/cutils.h | 5 +
 util/cutils.c | 5 -
 2 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/include/qemu/cutils.h b/include/qemu/cutils.h
index da15547bfb..34a9b9b220 100644
--- a/include/qemu/cutils.h
+++ b/include/qemu/cutils.h
@@ -241,13 +241,10 @@ int uleb128_decode_small(const uint8_t *in, uint32_t *n);
 int qemu_pstrcmp0(const char **str1, const char **str2);
 
 /* Find program directory, and save it for later usage with
- * qemu_get_exec_dir().
+ * get_relocated_path().
  * Try OS specific API first, if not working, parse from argv0. */
 void qemu_init_exec_dir(const char *argv0);
 
-/* Get the saved exec dir.  */
-const char *qemu_get_exec_dir(void);
-
 /**
  * get_relocated_path:
  * @dir: the directory (typically a `CONFIG_*DIR` variable) to be relocated.
diff --git a/util/cutils.c b/util/cutils.c
index 42364039a5..9803f11a59 100644
--- a/util/cutils.c
+++ b/util/cutils.c
@@ -1144,11 +1144,6 @@ void qemu_init_exec_dir(const char *argv0)
 #endif
 }
 
-const char *qemu_get_exec_dir(void)
-{
-return exec_dir;
-}
-
 char *get_relocated_path(const char *dir)
 {
 size_t prefix_len = strlen(CONFIG_PREFIX);
-- 
2.46.0

[PATCH] hw/sysbus: Remove unused sysbus_mmio_unmap

[dave]

From: "Dr. David Alan Gilbert" 

The last use of sysbus_mmio_unmap was removed by
  981b1c6266 ("spapr/xive: rework the mapping the KVM memory regions")

Remove it.

Signed-off-by: Dr. David Alan Gilbert 
---
 hw/core/sysbus.c| 10 --
 include/hw/sysbus.h |  1 -
 2 files changed, 11 deletions(-)

diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index ad34fb7344..e64d99c8ed 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -154,16 +154,6 @@ static void sysbus_mmio_map_common(SysBusDevice *dev, int 
n, hwaddr addr,
 }
 }
 
-void sysbus_mmio_unmap(SysBusDevice *dev, int n)
-{
-assert(n >= 0 && n < dev->num_mmio);
-
-if (dev->mmio[n].addr != (hwaddr)-1) {
-memory_region_del_subregion(get_system_memory(), dev->mmio[n].memory);
-dev->mmio[n].addr = (hwaddr)-1;
-}
-}
-
 void sysbus_mmio_map(SysBusDevice *dev, int n, hwaddr addr)
 {
 sysbus_mmio_map_common(dev, n, addr, false, 0);
diff --git a/include/hw/sysbus.h b/include/hw/sysbus.h
index 3cb29a480e..c9b1e0e90e 100644
--- a/include/hw/sysbus.h
+++ b/include/hw/sysbus.h
@@ -82,7 +82,6 @@ qemu_irq sysbus_get_connected_irq(SysBusDevice *dev, int n);
 void sysbus_mmio_map(SysBusDevice *dev, int n, hwaddr addr);
 void sysbus_mmio_map_overlap(SysBusDevice *dev, int n, hwaddr addr,
  int priority);
-void sysbus_mmio_unmap(SysBusDevice *dev, int n);
 
 bool sysbus_realize(SysBusDevice *dev, Error **errp);
 bool sysbus_realize_and_unref(SysBusDevice *dev, Error **errp);
-- 
2.46.0

[PATCH] hw: Remove unused fw_cfg_init_io

[dave]

From: "Dr. David Alan Gilbert" 

fw_cfg_init_io has been unused since
  918a7f706b ("i386: load kernel on xen using DMA")

Remove it.

Signed-off-by: Dr. David Alan Gilbert 
---
 hw/nvram/fw_cfg.c | 5 -
 include/hw/nvram/fw_cfg.h | 1 -
 2 files changed, 6 deletions(-)

diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index 2dadfd6e1f..b644577734 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -1171,11 +1171,6 @@ FWCfgState *fw_cfg_init_io_dma(uint32_t iobase, uint32_t 
dma_iobase,
 return s;
 }
 
-FWCfgState *fw_cfg_init_io(uint32_t iobase)
-{
-return fw_cfg_init_io_dma(iobase, 0, NULL);
-}
-
 FWCfgState *fw_cfg_init_mem_wide(hwaddr ctl_addr,
  hwaddr data_addr, uint32_t data_width,
  hwaddr dma_addr, AddressSpace *dma_as)
diff --git a/include/hw/nvram/fw_cfg.h b/include/hw/nvram/fw_cfg.h
index d173998803..fa42677619 100644
--- a/include/hw/nvram/fw_cfg.h
+++ b/include/hw/nvram/fw_cfg.h
@@ -321,7 +321,6 @@ void fw_cfg_add_extra_pci_roots(PCIBus *bus, FWCfgState *s);
 
 FWCfgState *fw_cfg_init_io_dma(uint32_t iobase, uint32_t dma_iobase,
 AddressSpace *dma_as);
-FWCfgState *fw_cfg_init_io(uint32_t iobase);
 FWCfgState *fw_cfg_init_mem(hwaddr ctl_addr, hwaddr data_addr);
 FWCfgState *fw_cfg_init_mem_wide(hwaddr ctl_addr,
  hwaddr data_addr, uint32_t data_width,
-- 
2.46.0

[PATCH v2 1/7] migration: Remove migrate_cap_set

[dave]

From: "Dr. David Alan Gilbert" 

migrate_cap_set has been unused since
  18d154f575 ("migration: Remove 'blk/-b' option from migrate commands")

Remove it.

Signed-off-by: Dr. David Alan Gilbert 
Reviewed-by: Fabiano Rosas 
---
 migration/options.c | 20 
 migration/options.h |  1 -
 2 files changed, 21 deletions(-)

diff --git a/migration/options.c b/migration/options.c
index 147cd2b8fd..9460c5dee9 100644
--- a/migration/options.c
+++ b/migration/options.c
@@ -605,26 +605,6 @@ bool migrate_caps_check(bool *old_caps, bool *new_caps, 
Error **errp)
 return true;
 }
 
-bool migrate_cap_set(int cap, bool value, Error **errp)
-{
-MigrationState *s = migrate_get_current();
-bool new_caps[MIGRATION_CAPABILITY__MAX];
-
-if (migration_is_running()) {
-error_setg(errp, "There's a migration process in progress");
-return false;
-}
-
-memcpy(new_caps, s->capabilities, sizeof(new_caps));
-new_caps[cap] = value;
-
-if (!migrate_caps_check(s->capabilities, new_caps, errp)) {
-return false;
-}
-s->capabilities[cap] = value;
-return true;
-}
-
 MigrationCapabilityStatusList *qmp_query_migrate_capabilities(Error **errp)
 {
 MigrationCapabilityStatusList *head = NULL, **tail = &head;
diff --git a/migration/options.h b/migration/options.h
index a0bd6edc06..36e7b3723f 100644
--- a/migration/options.h
+++ b/migration/options.h
@@ -58,7 +58,6 @@ bool migrate_tls(void);
 /* capabilities helpers */
 
 bool migrate_caps_check(bool *old_caps, bool *new_caps, Error **errp);
-bool migrate_cap_set(int cap, bool value, Error **errp);
 
 /* parameters */
 
-- 
2.46.1

[PATCH v2 7/7] util/userfaultfd: Remove unused uffd_poll_events

[dave]

From: "Dr. David Alan Gilbert" 

uffd_poll_events has been unused since it was added; it's also
just a wrapper around a plain old poll call, so doesn't add anything.

Signed-off-by: Dr. David Alan Gilbert 
---
 include/qemu/userfaultfd.h |  1 -
 util/userfaultfd.c | 28 
 2 files changed, 29 deletions(-)

diff --git a/include/qemu/userfaultfd.h b/include/qemu/userfaultfd.h
index 18a4314212..a1979308d7 100644
--- a/include/qemu/userfaultfd.h
+++ b/include/qemu/userfaultfd.h
@@ -39,7 +39,6 @@ int uffd_copy_page(int uffd_fd, void *dst_addr, void 
*src_addr,
 int uffd_zero_page(int uffd_fd, void *addr, uint64_t length, bool dont_wake);
 int uffd_wakeup(int uffd_fd, void *addr, uint64_t length);
 int uffd_read_events(int uffd_fd, struct uffd_msg *msgs, int count);
-bool uffd_poll_events(int uffd_fd, int tmo);
 
 #endif /* CONFIG_LINUX */
 
diff --git a/util/userfaultfd.c b/util/userfaultfd.c
index 518d5c3586..2396104f23 100644
--- a/util/userfaultfd.c
+++ b/util/userfaultfd.c
@@ -358,31 +358,3 @@ int uffd_read_events(int uffd_fd, struct uffd_msg *msgs, 
int count)
 
 return (int) (res / sizeof(struct uffd_msg));
 }
-
-/**
- * uffd_poll_events: poll UFFD file descriptor for read
- *
- * Returns true if events are available for read, false otherwise
- *
- * @uffd_fd: UFFD file descriptor
- * @tmo: timeout value
- */
-bool uffd_poll_events(int uffd_fd, int tmo)
-{
-int res;
-struct pollfd poll_fd = { .fd = uffd_fd, .events = POLLIN, .revents = 0 };
-
-do {
-res = poll(&poll_fd, 1, tmo);
-} while (res < 0 && errno == EINTR);
-
-if (res == 0) {
-return false;
-}
-if (res < 0) {
-error_report("uffd_poll_events() failed: errno=%i", errno);
-return false;
-}
-
-return (poll_fd.revents & POLLIN) != 0;
-}
-- 
2.46.1

[PATCH v2 6/7] migration/postcopy: Use uffd helpers

[dave]

From: "Dr. David Alan Gilbert" 

Use the uffd_copy_page, uffd_zero_page and uffd_wakeup helpers
rather than calling ioctl ourselves.

They return -errno on error, and print an error_report themselves.
I think this actually makes postcopy_place_page actually more
consistent in it's callers.

Signed-off-by: Dr. David Alan Gilbert 
---
 migration/postcopy-ram.c | 47 +++-
 1 file changed, 13 insertions(+), 34 deletions(-)

diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
index 1c374b7ea1..e2b318d3da 100644
--- a/migration/postcopy-ram.c
+++ b/migration/postcopy-ram.c
@@ -746,18 +746,9 @@ int postcopy_wake_shared(struct PostCopyFD *pcfd,
  RAMBlock *rb)
 {
 size_t pagesize = qemu_ram_pagesize(rb);
-struct uffdio_range range;
-int ret;
 trace_postcopy_wake_shared(client_addr, qemu_ram_get_idstr(rb));
-range.start = ROUND_DOWN(client_addr, pagesize);
-range.len = pagesize;
-ret = ioctl(pcfd->fd, UFFDIO_WAKE, &range);
-if (ret) {
-error_report("%s: Failed to wake: %zx in %s (%s)",
- __func__, (size_t)client_addr, qemu_ram_get_idstr(rb),
- strerror(errno));
-}
-return ret;
+return uffd_wakeup(pcfd->fd, (void *)ROUND_DOWN(client_addr, pagesize),
+   pagesize);
 }
 
 static int postcopy_request_page(MigrationIncomingState *mis, RAMBlock *rb,
@@ -1275,18 +1266,10 @@ static int qemu_ufd_copy_ioctl(MigrationIncomingState 
*mis, void *host_addr,
 int ret;
 
 if (from_addr) {
-struct uffdio_copy copy_struct;
-copy_struct.dst = (uint64_t)(uintptr_t)host_addr;
-copy_struct.src = (uint64_t)(uintptr_t)from_addr;
-copy_struct.len = pagesize;
-copy_struct.mode = 0;
-ret = ioctl(userfault_fd, UFFDIO_COPY, ©_struct);
+ret = uffd_copy_page(userfault_fd, host_addr, from_addr, pagesize,
+ false);
 } else {
-struct uffdio_zeropage zero_struct;
-zero_struct.range.start = (uint64_t)(uintptr_t)host_addr;
-zero_struct.range.len = pagesize;
-zero_struct.mode = 0;
-ret = ioctl(userfault_fd, UFFDIO_ZEROPAGE, &zero_struct);
+ret = uffd_zero_page(userfault_fd, host_addr, pagesize, false);
 }
 if (!ret) {
 qemu_mutex_lock(&mis->page_request_mutex);
@@ -1343,18 +1326,16 @@ int postcopy_place_page(MigrationIncomingState *mis, 
void *host, void *from,
 RAMBlock *rb)
 {
 size_t pagesize = qemu_ram_pagesize(rb);
+int e;
 
 /* copy also acks to the kernel waking the stalled thread up
  * TODO: We can inhibit that ack and only do it if it was requested
  * which would be slightly cheaper, but we'd have to be careful
  * of the order of updating our page state.
  */
-if (qemu_ufd_copy_ioctl(mis, host, from, pagesize, rb)) {
-int e = errno;
-error_report("%s: %s copy host: %p from: %p (size: %zd)",
- __func__, strerror(e), host, from, pagesize);
-
-return -e;
+e = qemu_ufd_copy_ioctl(mis, host, from, pagesize, rb);
+if (e) {
+return e;
 }
 
 trace_postcopy_place_page(host);
@@ -1376,12 +1357,10 @@ int postcopy_place_page_zero(MigrationIncomingState 
*mis, void *host,
  * but it's not available for everything (e.g. hugetlbpages)
  */
 if (qemu_ram_is_uf_zeroable(rb)) {
-if (qemu_ufd_copy_ioctl(mis, host, NULL, pagesize, rb)) {
-int e = errno;
-error_report("%s: %s zero host: %p",
- __func__, strerror(e), host);
-
-return -e;
+int e;
+e = qemu_ufd_copy_ioctl(mis, host, NULL, pagesize, rb);
+if (e) {
+return e;
 }
 return postcopy_notify_shared_wake(rb,
qemu_ram_block_host_offset(rb,
-- 
2.46.1

[PATCH] util/co-shared-resource: Remove unused co_try_get_from_shres

[dave]

From: "Dr. David Alan Gilbert" 

co_try_get_from_shres hasn't been used since it was added in
  55fa54a789 ("co-shared-resource: protect with a mutex")

(Everyone uses the _locked version)
Remove it.

Signed-off-by: Dr. David Alan Gilbert 
---
 include/qemu/co-shared-resource.h | 7 ---
 util/qemu-co-shared-resource.c| 6 --
 2 files changed, 13 deletions(-)

diff --git a/include/qemu/co-shared-resource.h 
b/include/qemu/co-shared-resource.h
index 78ca5850f8..41be1a8131 100644
--- a/include/qemu/co-shared-resource.h
+++ b/include/qemu/co-shared-resource.h
@@ -44,13 +44,6 @@ SharedResource *shres_create(uint64_t total);
  */
 void shres_destroy(SharedResource *s);
 
-/*
- * Try to allocate an amount of @n.  Return true on success, and false
- * if there is too little left of the collective resource to fulfill
- * the request.
- */
-bool co_try_get_from_shres(SharedResource *s, uint64_t n);
-
 /*
  * Allocate an amount of @n, and, if necessary, yield until
  * that becomes possible.
diff --git a/util/qemu-co-shared-resource.c b/util/qemu-co-shared-resource.c
index a66cc07e75..752eb5a1c5 100644
--- a/util/qemu-co-shared-resource.c
+++ b/util/qemu-co-shared-resource.c
@@ -66,12 +66,6 @@ static bool co_try_get_from_shres_locked(SharedResource *s, 
uint64_t n)
 return false;
 }
 
-bool co_try_get_from_shres(SharedResource *s, uint64_t n)
-{
-QEMU_LOCK_GUARD(&s->lock);
-return co_try_get_from_shres_locked(s, n);
-}
-
 void coroutine_fn co_get_from_shres(SharedResource *s, uint64_t n)
 {
 assert(n <= s->total);
-- 
2.46.0

[PATCH] vhost: Remove unused vhost_dev_{load|save}_inflight

[dave]

From: "Dr. David Alan Gilbert" 

vhost_dev_load_inflight and vhost_dev_save_inflight have been
unused since they were added in 2019 by:

5ad204bf2a ("vhost-user: Support transferring inflight buffer between qemu and 
backend")

Remove them, and their helper vhost_dev_resize_inflight.

Signed-off-by: Dr. David Alan Gilbert 
---
 hw/virtio/vhost.c | 56 ---
 include/hw/virtio/vhost.h |  2 --
 2 files changed, 58 deletions(-)

diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index 7c5ef81b55..76f9b2aaad 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -1930,62 +1930,6 @@ void vhost_dev_free_inflight(struct vhost_inflight 
*inflight)
 }
 }
 
-static int vhost_dev_resize_inflight(struct vhost_inflight *inflight,
- uint64_t new_size)
-{
-Error *err = NULL;
-int fd = -1;
-void *addr = qemu_memfd_alloc("vhost-inflight", new_size,
-  F_SEAL_GROW | F_SEAL_SHRINK | F_SEAL_SEAL,
-  &fd, &err);
-
-if (err) {
-error_report_err(err);
-return -ENOMEM;
-}
-
-vhost_dev_free_inflight(inflight);
-inflight->offset = 0;
-inflight->addr = addr;
-inflight->fd = fd;
-inflight->size = new_size;
-
-return 0;
-}
-
-void vhost_dev_save_inflight(struct vhost_inflight *inflight, QEMUFile *f)
-{
-if (inflight->addr) {
-qemu_put_be64(f, inflight->size);
-qemu_put_be16(f, inflight->queue_size);
-qemu_put_buffer(f, inflight->addr, inflight->size);
-} else {
-qemu_put_be64(f, 0);
-}
-}
-
-int vhost_dev_load_inflight(struct vhost_inflight *inflight, QEMUFile *f)
-{
-uint64_t size;
-
-size = qemu_get_be64(f);
-if (!size) {
-return 0;
-}
-
-if (inflight->size != size) {
-int ret = vhost_dev_resize_inflight(inflight, size);
-if (ret < 0) {
-return ret;
-}
-}
-inflight->queue_size = qemu_get_be16(f);
-
-qemu_get_buffer(f, inflight->addr, size);
-
-return 0;
-}
-
 int vhost_dev_prepare_inflight(struct vhost_dev *hdev, VirtIODevice *vdev)
 {
 int r;
diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h
index c75be46c06..461c168c37 100644
--- a/include/hw/virtio/vhost.h
+++ b/include/hw/virtio/vhost.h
@@ -338,8 +338,6 @@ void vhost_virtqueue_stop(struct vhost_dev *dev, struct 
VirtIODevice *vdev,
 
 void vhost_dev_reset_inflight(struct vhost_inflight *inflight);
 void vhost_dev_free_inflight(struct vhost_inflight *inflight);
-void vhost_dev_save_inflight(struct vhost_inflight *inflight, QEMUFile *f);
-int vhost_dev_load_inflight(struct vhost_inflight *inflight, QEMUFile *f);
 int vhost_dev_prepare_inflight(struct vhost_dev *hdev, VirtIODevice *vdev);
 int vhost_dev_set_inflight(struct vhost_dev *dev,
struct vhost_inflight *inflight);
-- 
2.46.0

[PATCH] qemu-timer: Remove unused qemu_clock_get_main_loop_timerlist

[dave]

From: "Dr. David Alan Gilbert" 

qemu_clock_get_main_loop_timerlist has been unused since it was
originally added in
  ff83c66ecc ("aio / timers: Split QEMUClock into QEMUClock and QEMUTimerList")

Remove it.

Signed-off-by: Dr. David Alan Gilbert 
---
 include/qemu/timer.h | 10 --
 util/qemu-timer.c|  5 -
 2 files changed, 15 deletions(-)

diff --git a/include/qemu/timer.h b/include/qemu/timer.h
index fa56ec9481..ccd8578ae3 100644
--- a/include/qemu/timer.h
+++ b/include/qemu/timer.h
@@ -190,16 +190,6 @@ bool qemu_clock_use_for_deadline(QEMUClockType type);
  */
 int64_t qemu_clock_deadline_ns_all(QEMUClockType type, int attr_mask);
 
-/**
- * qemu_clock_get_main_loop_timerlist:
- * @type: the clock type
- *
- * Return the default timer list associated with a clock.
- *
- * Returns: the default timer list
- */
-QEMUTimerList *qemu_clock_get_main_loop_timerlist(QEMUClockType type);
-
 /**
  * qemu_clock_nofify:
  * @type: the clock type
diff --git a/util/qemu-timer.c b/util/qemu-timer.c
index 213114be68..e5b5452e4e 100644
--- a/util/qemu-timer.c
+++ b/util/qemu-timer.c
@@ -291,11 +291,6 @@ QEMUClockType timerlist_get_clock(QEMUTimerList 
*timer_list)
 return timer_list->clock->type;
 }
 
-QEMUTimerList *qemu_clock_get_main_loop_timerlist(QEMUClockType type)
-{
-return main_loop_tlg.tl[type];
-}
-
 void timerlist_notify(QEMUTimerList *timer_list)
 {
 if (timer_list->notify_cb) {
-- 
2.46.0

[PATCH] remote: Remove unused remote_iohub_finalize

[dave]

From: "Dr. David Alan Gilbert" 

remote_iohub_finalize has never been used.

Remove it.

Signed-off-by: Dr. David Alan Gilbert 
---
 hw/remote/iohub.c | 13 -
 include/hw/remote/iohub.h |  1 -
 2 files changed, 14 deletions(-)

diff --git a/hw/remote/iohub.c b/hw/remote/iohub.c
index 40dfee4bad..988d3285cc 100644
--- a/hw/remote/iohub.c
+++ b/hw/remote/iohub.c
@@ -33,19 +33,6 @@ void remote_iohub_init(RemoteIOHubState *iohub)
 }
 }
 
-void remote_iohub_finalize(RemoteIOHubState *iohub)
-{
-int pirq;
-
-for (pirq = 0; pirq < REMOTE_IOHUB_NB_PIRQS; pirq++) {
-qemu_set_fd_handler(event_notifier_get_fd(&iohub->resamplefds[pirq]),
-NULL, NULL, NULL);
-event_notifier_cleanup(&iohub->irqfds[pirq]);
-event_notifier_cleanup(&iohub->resamplefds[pirq]);
-qemu_mutex_destroy(&iohub->irq_level_lock[pirq]);
-}
-}
-
 int remote_iohub_map_irq(PCIDevice *pci_dev, int intx)
 {
 return pci_dev->devfn;
diff --git a/include/hw/remote/iohub.h b/include/hw/remote/iohub.h
index 6a8444f9a9..09ee6c77b6 100644
--- a/include/hw/remote/iohub.h
+++ b/include/hw/remote/iohub.h
@@ -37,6 +37,5 @@ void remote_iohub_set_irq(void *opaque, int pirq, int level);
 void process_set_irqfd_msg(PCIDevice *pci_dev, MPQemuMsg *msg);
 
 void remote_iohub_init(RemoteIOHubState *iohub);
-void remote_iohub_finalize(RemoteIOHubState *iohub);
 
 #endif
-- 
2.46.1

[PATCH v2] qemu-timer: Remove unused timer functions

[dave]

From: "Dr. David Alan Gilbert" 

qemu_clock_get_main_loop_timerlist and timerlist_get_clock have been
unused since they were originally added in
  ff83c66ecc ("aio / timers: Split QEMUClock into QEMUClock and QEMUTimerList")

Remove them.

Signed-off-by: Dr. David Alan Gilbert 
---
 include/qemu/timer.h | 21 -
 util/qemu-timer.c| 10 --
 2 files changed, 31 deletions(-)

diff --git a/include/qemu/timer.h b/include/qemu/timer.h
index fa56ec9481..cc167bd825 100644
--- a/include/qemu/timer.h
+++ b/include/qemu/timer.h
@@ -190,16 +190,6 @@ bool qemu_clock_use_for_deadline(QEMUClockType type);
  */
 int64_t qemu_clock_deadline_ns_all(QEMUClockType type, int attr_mask);
 
-/**
- * qemu_clock_get_main_loop_timerlist:
- * @type: the clock type
- *
- * Return the default timer list associated with a clock.
- *
- * Returns: the default timer list
- */
-QEMUTimerList *qemu_clock_get_main_loop_timerlist(QEMUClockType type);
-
 /**
  * qemu_clock_nofify:
  * @type: the clock type
@@ -326,17 +316,6 @@ bool timerlist_expired(QEMUTimerList *timer_list);
  */
 int64_t timerlist_deadline_ns(QEMUTimerList *timer_list);
 
-/**
- * timerlist_get_clock:
- * @timer_list: the timer list to operate on
- *
- * Determine the clock type associated with a timer list.
- *
- * Returns: the clock type associated with the
- * timer list.
- */
-QEMUClockType timerlist_get_clock(QEMUTimerList *timer_list);
-
 /**
  * timerlist_run_timers:
  * @timer_list: the timer list to use
diff --git a/util/qemu-timer.c b/util/qemu-timer.c
index 213114be68..df9327657a 100644
--- a/util/qemu-timer.c
+++ b/util/qemu-timer.c
@@ -286,16 +286,6 @@ int64_t qemu_clock_deadline_ns_all(QEMUClockType type, int 
attr_mask)
 return deadline;
 }
 
-QEMUClockType timerlist_get_clock(QEMUTimerList *timer_list)
-{
-return timer_list->clock->type;
-}
-
-QEMUTimerList *qemu_clock_get_main_loop_timerlist(QEMUClockType type)
-{
-return main_loop_tlg.tl[type];
-}
-
 void timerlist_notify(QEMUTimerList *timer_list)
 {
 if (timer_list->notify_cb) {
-- 
2.46.1

[PATCH] net: Remove deadcode

[dave]

From: "Dr. David Alan Gilbert" 

net_hub_port_find is unused since 2018's commit
  af1a5c3eb4 ("net: Remove the deprecated "vlan" parameter")

qemu_receive_packet_iov is unused since commit
  ffbd2dbd8e ("e1000e: Perform software segmentation for loopback")

in turn it was the last user of qemu_net_queue_receive_iov.

Remove them.

Signed-off-by: Dr. David Alan Gilbert 
---
 include/net/net.h   |  4 
 include/net/queue.h |  4 
 net/hub.c   | 25 -
 net/net.c   | 10 --
 net/queue.c | 11 ---
 5 files changed, 54 deletions(-)

diff --git a/include/net/net.h b/include/net/net.h
index c8f679761b..cdd5b109b0 100644
--- a/include/net/net.h
+++ b/include/net/net.h
@@ -172,9 +172,6 @@ ssize_t qemu_sendv_packet_async(NetClientState *nc, const 
struct iovec *iov,
 int iovcnt, NetPacketSent *sent_cb);
 ssize_t qemu_send_packet(NetClientState *nc, const uint8_t *buf, int size);
 ssize_t qemu_receive_packet(NetClientState *nc, const uint8_t *buf, int size);
-ssize_t qemu_receive_packet_iov(NetClientState *nc,
-const struct iovec *iov,
-int iovcnt);
 ssize_t qemu_send_packet_raw(NetClientState *nc, const uint8_t *buf, int size);
 ssize_t qemu_send_packet_async(NetClientState *nc, const uint8_t *buf,
int size, NetPacketSent *sent_cb);
@@ -307,7 +304,6 @@ void hmp_host_net_remove(Monitor *mon, const QDict *qdict);
 void netdev_add(QemuOpts *opts, Error **errp);
 
 int net_hub_id_for_client(NetClientState *nc, int *id);
-NetClientState *net_hub_port_find(int hub_id);
 
 #define DEFAULT_NETWORK_SCRIPT CONFIG_SYSCONFDIR "/qemu-ifup"
 #define DEFAULT_NETWORK_DOWN_SCRIPT CONFIG_SYSCONFDIR "/qemu-ifdown"
diff --git a/include/net/queue.h b/include/net/queue.h
index 9f2f289d77..2e686b1b61 100644
--- a/include/net/queue.h
+++ b/include/net/queue.h
@@ -59,10 +59,6 @@ ssize_t qemu_net_queue_receive(NetQueue *queue,
const uint8_t *data,
size_t size);
 
-ssize_t qemu_net_queue_receive_iov(NetQueue *queue,
-   const struct iovec *iov,
-   int iovcnt);
-
 ssize_t qemu_net_queue_send(NetQueue *queue,
 NetClientState *sender,
 unsigned flags,
diff --git a/net/hub.c b/net/hub.c
index 4c8a469a50..496a3d3b4b 100644
--- a/net/hub.c
+++ b/net/hub.c
@@ -193,31 +193,6 @@ NetClientState *net_hub_add_port(int hub_id, const char 
*name,
 return &port->nc;
 }
 
-/**
- * Find a available port on a hub; otherwise create one new port
- */
-NetClientState *net_hub_port_find(int hub_id)
-{
-NetHub *hub;
-NetHubPort *port;
-NetClientState *nc;
-
-QLIST_FOREACH(hub, &hubs, next) {
-if (hub->id == hub_id) {
-QLIST_FOREACH(port, &hub->ports, next) {
-nc = port->nc.peer;
-if (!nc) {
-return &(port->nc);
-}
-}
-break;
-}
-}
-
-nc = net_hub_add_port(hub_id, NULL, NULL);
-return nc;
-}
-
 /**
  * Print hub configuration
  */
diff --git a/net/net.c b/net/net.c
index fc1125111c..d9b23a8f8c 100644
--- a/net/net.c
+++ b/net/net.c
@@ -750,16 +750,6 @@ ssize_t qemu_receive_packet(NetClientState *nc, const 
uint8_t *buf, int size)
 return qemu_net_queue_receive(nc->incoming_queue, buf, size);
 }
 
-ssize_t qemu_receive_packet_iov(NetClientState *nc, const struct iovec *iov,
-int iovcnt)
-{
-if (!qemu_can_receive_packet(nc)) {
-return 0;
-}
-
-return qemu_net_queue_receive_iov(nc->incoming_queue, iov, iovcnt);
-}
-
 ssize_t qemu_send_packet_raw(NetClientState *nc, const uint8_t *buf, int size)
 {
 return qemu_send_packet_async_with_flags(nc, QEMU_NET_PACKET_FLAG_RAW,
diff --git a/net/queue.c b/net/queue.c
index c872d51df8..fb33856c18 100644
--- a/net/queue.c
+++ b/net/queue.c
@@ -193,17 +193,6 @@ ssize_t qemu_net_queue_receive(NetQueue *queue,
 return qemu_net_queue_deliver(queue, NULL, 0, data, size);
 }
 
-ssize_t qemu_net_queue_receive_iov(NetQueue *queue,
-   const struct iovec *iov,
-   int iovcnt)
-{
-if (queue->delivering) {
-return 0;
-}
-
-return qemu_net_queue_deliver_iov(queue, NULL, 0, iov, iovcnt);
-}
-
 ssize_t qemu_net_queue_send(NetQueue *queue,
 NetClientState *sender,
 unsigned flags,
-- 
2.46.0

[PATCH v2 0/7] Migration deadcode removal

[dave]

From: "Dr. David Alan Gilbert" 

  This is a set of deadcode removal around migration
found by looking for unused symbols.

v2
   Don't remove the zero-blocks capability yet
   add Fabiano's deprecation text patch.
   Use the uffd helpers in postcopy rather than
 removing most of them.
   Remove one.

Dave

Dr. David Alan Gilbert (6):
  migration: Remove migrate_cap_set
  migration: Remove unused migrate_zero_blocks
  migration: Remove unused socket_send_channel_create_sync
  util/userfaultfd: Return -errno on error
  migration/postcopy: Use uffd helpers
  util/userfaultfd: Remove unused uffd_poll_events

Fabiano Rosas (1):
  migration: Deprecate zero-blocks capability

 docs/about/deprecated.rst  |  6 +
 include/qemu/userfaultfd.h |  1 -
 migration/options.c| 31 
 migration/options.h|  2 --
 migration/postcopy-ram.c   | 47 ++--
 migration/socket.c | 18 --
 migration/socket.h |  1 -
 qapi/migration.json|  5 +++-
 util/userfaultfd.c | 49 ++
 9 files changed, 39 insertions(+), 121 deletions(-)

-- 
2.46.1

[PATCH v2 3/7] migration: Deprecate zero-blocks capability

[dave]

From: Fabiano Rosas 

The zero-blocks capability was meant to be used along with the block
migration, which has been removed already in commit eef0bae3a7
("migration: Remove block migration").

Setting zero-blocks is currently a noop, but the outright removal of
the capability would cause and error in case some users are still
setting it. Put the capability through the deprecation process.

Signed-off-by: Fabiano Rosas 
---
 docs/about/deprecated.rst | 6 ++
 migration/options.c   | 4 
 qapi/migration.json   | 5 -
 3 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index ed31d4b0b2..47cabb6fcc 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -476,3 +476,9 @@ usage of providing a file descriptor to a plain file has 
been
 deprecated in favor of explicitly using the ``file:`` URI with the
 file descriptor being passed as an ``fdset``. Refer to the ``add-fd``
 command documentation for details on the ``fdset`` usage.
+
+``zero-blocks`` capability (since 9.2)
+''
+
+The ``zero-blocks`` capability was part of the block migration which
+doesn't exist anymore since it was removed in QEMU v9.1.
diff --git a/migration/options.c b/migration/options.c
index 6f549984cb..ad8d6989a8 100644
--- a/migration/options.c
+++ b/migration/options.c
@@ -450,6 +450,10 @@ bool migrate_caps_check(bool *old_caps, bool *new_caps, 
Error **errp)
 ERRP_GUARD();
 MigrationIncomingState *mis = migration_incoming_get_current();
 
+if (new_caps[MIGRATION_CAPABILITY_ZERO_BLOCKS]) {
+warn_report("zero-blocks capability is deprecated");
+}
+
 #ifndef CONFIG_REPLICATION
 if (new_caps[MIGRATION_CAPABILITY_X_COLO]) {
 error_setg(errp, "QEMU compiled without replication module"
diff --git a/qapi/migration.json b/qapi/migration.json
index b66cccf107..3af6aa1740 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -479,11 +479,14 @@
 # Features:
 #
 # @unstable: Members @x-colo and @x-ignore-shared are experimental.
+# @deprecated: Member @zero-blocks is deprecated as being part of
+# block migration which was already removed.
 #
 # Since: 1.2
 ##
 { 'enum': 'MigrationCapability',
-  'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
+  'data': ['xbzrle', 'rdma-pin-all', 'auto-converge',
+   { 'name': 'zero-blocks', 'features': [ 'deprecated' ] },
'events', 'postcopy-ram',
{ 'name': 'x-colo', 'features': [ 'unstable' ] },
'release-ram',
-- 
2.46.1

[PATCH v2 4/7] migration: Remove unused socket_send_channel_create_sync

[dave]

From: "Dr. David Alan Gilbert" 

socket_send_channel_create_sync only use was removed by
  d0edb8a173 ("migration: Create the postcopy preempt channel asynchronously")

Remove it.

Signed-off-by: Dr. David Alan Gilbert 
Reviewed-by: Fabiano Rosas 
---
 migration/socket.c | 18 --
 migration/socket.h |  1 -
 2 files changed, 19 deletions(-)

diff --git a/migration/socket.c b/migration/socket.c
index 9ab89b1e08..5ec65b8c03 100644
--- a/migration/socket.c
+++ b/migration/socket.c
@@ -42,24 +42,6 @@ void socket_send_channel_create(QIOTaskFunc f, void *data)
  f, data, NULL, NULL);
 }
 
-QIOChannel *socket_send_channel_create_sync(Error **errp)
-{
-QIOChannelSocket *sioc = qio_channel_socket_new();
-
-if (!outgoing_args.saddr) {
-object_unref(OBJECT(sioc));
-error_setg(errp, "Initial sock address not set!");
-return NULL;
-}
-
-if (qio_channel_socket_connect_sync(sioc, outgoing_args.saddr, errp) < 0) {
-object_unref(OBJECT(sioc));
-return NULL;
-}
-
-return QIO_CHANNEL(sioc);
-}
-
 struct SocketConnectData {
 MigrationState *s;
 char *hostname;
diff --git a/migration/socket.h b/migration/socket.h
index 46c233ecd2..04ebbe95a1 100644
--- a/migration/socket.h
+++ b/migration/socket.h
@@ -22,7 +22,6 @@
 #include "qemu/sockets.h"
 
 void socket_send_channel_create(QIOTaskFunc f, void *data);
-QIOChannel *socket_send_channel_create_sync(Error **errp);
 
 void socket_start_incoming_migration(SocketAddress *saddr, Error **errp);
 
-- 
2.46.1

[PATCH v2 5/7] util/userfaultfd: Return -errno on error

[dave]

From: "Dr. David Alan Gilbert" 

Convert (the currently unused) uffd_wakeup, uffd_copy_page and
uffd_zero_page to return -errno on error rather than -1.

That will make it easier to reuse in postcopy.

Signed-off-by: Dr. David Alan Gilbert 
---
 util/userfaultfd.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/util/userfaultfd.c b/util/userfaultfd.c
index 1b2fa949d4..518d5c3586 100644
--- a/util/userfaultfd.c
+++ b/util/userfaultfd.c
@@ -240,7 +240,7 @@ int uffd_change_protection(int uffd_fd, void *addr, 
uint64_t length,
  * Copy range of source pages to the destination to resolve
  * missing page fault somewhere in the destination range.
  *
- * Returns 0 on success, negative value in case of an error
+ * Returns 0 on success, -errno in case of an error
  *
  * @uffd_fd: UFFD file descriptor
  * @dst_addr: destination base address
@@ -259,10 +259,11 @@ int uffd_copy_page(int uffd_fd, void *dst_addr, void 
*src_addr,
 uffd_copy.mode = dont_wake ? UFFDIO_COPY_MODE_DONTWAKE : 0;
 
 if (ioctl(uffd_fd, UFFDIO_COPY, &uffd_copy)) {
+int e = errno;
 error_report("uffd_copy_page() failed: dst_addr=%p src_addr=%p 
length=%" PRIu64
 " mode=%" PRIx64 " errno=%i", dst_addr, src_addr,
-length, (uint64_t) uffd_copy.mode, errno);
-return -1;
+length, (uint64_t) uffd_copy.mode, e);
+return -e;
 }
 
 return 0;
@@ -273,7 +274,7 @@ int uffd_copy_page(int uffd_fd, void *dst_addr, void 
*src_addr,
  *
  * Fill range pages with zeroes to resolve missing page fault within the range.
  *
- * Returns 0 on success, negative value in case of an error
+ * Returns 0 on success, -errno in case of an error
  *
  * @uffd_fd: UFFD file descriptor
  * @addr: base address
@@ -289,10 +290,11 @@ int uffd_zero_page(int uffd_fd, void *addr, uint64_t 
length, bool dont_wake)
 uffd_zeropage.mode = dont_wake ? UFFDIO_ZEROPAGE_MODE_DONTWAKE : 0;
 
 if (ioctl(uffd_fd, UFFDIO_ZEROPAGE, &uffd_zeropage)) {
+int e = errno;
 error_report("uffd_zero_page() failed: addr=%p length=%" PRIu64
 " mode=%" PRIx64 " errno=%i", addr, length,
-(uint64_t) uffd_zeropage.mode, errno);
-return -1;
+(uint64_t) uffd_zeropage.mode, e);
+return -e;
 }
 
 return 0;
@@ -306,7 +308,7 @@ int uffd_zero_page(int uffd_fd, void *addr, uint64_t 
length, bool dont_wake)
  * via UFFD-IO IOCTLs with MODE_DONTWAKE flag set, then after that all waits
  * for the whole memory range are satisfied in a single call to uffd_wakeup().
  *
- * Returns 0 on success, negative value in case of an error
+ * Returns 0 on success, -errno in case of an error
  *
  * @uffd_fd: UFFD file descriptor
  * @addr: base address
@@ -320,9 +322,10 @@ int uffd_wakeup(int uffd_fd, void *addr, uint64_t length)
 uffd_range.len = length;
 
 if (ioctl(uffd_fd, UFFDIO_WAKE, &uffd_range)) {
+int e = errno;
 error_report("uffd_wakeup() failed: addr=%p length=%" PRIu64 " 
errno=%i",
-addr, length, errno);
-return -1;
+addr, length, e);
+return -e;
 }
 
 return 0;
-- 
2.46.1

[PATCH v2 2/7] migration: Remove unused migrate_zero_blocks

[dave]

From: "Dr. David Alan Gilbert" 

migrate_zero_blocks is unused since
  eef0bae3a7 ("migration: Remove block migration")

Remove it.

Signed-off-by: Dr. David Alan Gilbert 
---
 migration/options.c | 7 ---
 migration/options.h | 1 -
 2 files changed, 8 deletions(-)

diff --git a/migration/options.c b/migration/options.c
index 9460c5dee9..6f549984cb 100644
--- a/migration/options.c
+++ b/migration/options.c
@@ -339,13 +339,6 @@ bool migrate_xbzrle(void)
 return s->capabilities[MIGRATION_CAPABILITY_XBZRLE];
 }
 
-bool migrate_zero_blocks(void)
-{
-MigrationState *s = migrate_get_current();
-
-return s->capabilities[MIGRATION_CAPABILITY_ZERO_BLOCKS];
-}
-
 bool migrate_zero_copy_send(void)
 {
 MigrationState *s = migrate_get_current();
diff --git a/migration/options.h b/migration/options.h
index 36e7b3723f..79084eed0d 100644
--- a/migration/options.h
+++ b/migration/options.h
@@ -40,7 +40,6 @@ bool migrate_release_ram(void);
 bool migrate_return_path(void);
 bool migrate_validate_uuid(void);
 bool migrate_xbzrle(void);
-bool migrate_zero_blocks(void);
 bool migrate_zero_copy_send(void);
 
 /*
-- 
2.46.1

[PATCH 0/3] Migration deadcode removal

[dave]

From: "Dr. David Alan Gilbert" 

Hi,
  This is a set of deadcode removal around migration
found by looking for unused symbols.

  Note this does remove the old zero-blocks
capability, but it's been meaningless anyway since block
migration went.

Dave

Dr. David Alan Gilbert (3):
  migration: Remove migrate_cap_set
  migration: Remove unused zero-blocks capability
  migration: Remove unused socket_send_channel_create_sync

 migration/options.c | 28 
 migration/options.h |  2 --
 migration/socket.c  | 18 --
 migration/socket.h  |  1 -
 qapi/migration.json | 10 +-
 5 files changed, 1 insertion(+), 58 deletions(-)

-- 
2.46.0

[PATCH 2/3] migration: Remove unused zero-blocks capability

[dave]

From: "Dr. David Alan Gilbert" 

migrate_zero_blocks is unused since
  eef0bae3a7 ("migration: Remove block migration")

Remove it.
That whole zero-blocks capability was just for old-school
block migration anyway.

Remove the capability as well.

Signed-off-by: Dr. David Alan Gilbert 
---
 migration/options.c |  8 
 migration/options.h |  1 -
 qapi/migration.json | 10 +-
 3 files changed, 1 insertion(+), 18 deletions(-)

diff --git a/migration/options.c b/migration/options.c
index 9460c5dee9..997e060612 100644
--- a/migration/options.c
+++ b/migration/options.c
@@ -177,7 +177,6 @@ Property migration_properties[] = {
 DEFINE_PROP_MIG_CAP("x-xbzrle", MIGRATION_CAPABILITY_XBZRLE),
 DEFINE_PROP_MIG_CAP("x-rdma-pin-all", MIGRATION_CAPABILITY_RDMA_PIN_ALL),
 DEFINE_PROP_MIG_CAP("x-auto-converge", MIGRATION_CAPABILITY_AUTO_CONVERGE),
-DEFINE_PROP_MIG_CAP("x-zero-blocks", MIGRATION_CAPABILITY_ZERO_BLOCKS),
 DEFINE_PROP_MIG_CAP("x-events", MIGRATION_CAPABILITY_EVENTS),
 DEFINE_PROP_MIG_CAP("x-postcopy-ram", MIGRATION_CAPABILITY_POSTCOPY_RAM),
 DEFINE_PROP_MIG_CAP("x-postcopy-preempt",
@@ -339,13 +338,6 @@ bool migrate_xbzrle(void)
 return s->capabilities[MIGRATION_CAPABILITY_XBZRLE];
 }
 
-bool migrate_zero_blocks(void)
-{
-MigrationState *s = migrate_get_current();
-
-return s->capabilities[MIGRATION_CAPABILITY_ZERO_BLOCKS];
-}
-
 bool migrate_zero_copy_send(void)
 {
 MigrationState *s = migrate_get_current();
diff --git a/migration/options.h b/migration/options.h
index 36e7b3723f..79084eed0d 100644
--- a/migration/options.h
+++ b/migration/options.h
@@ -40,7 +40,6 @@ bool migrate_release_ram(void);
 bool migrate_return_path(void);
 bool migrate_validate_uuid(void);
 bool migrate_xbzrle(void);
-bool migrate_zero_blocks(void);
 bool migrate_zero_copy_send(void);
 
 /*
diff --git a/qapi/migration.json b/qapi/migration.json
index b66cccf107..82d0fc962e 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -389,13 +389,6 @@
 # footprint is mlock()'d on demand or all at once.  Refer to
 # docs/rdma.txt for usage.  Disabled by default.  (since 2.0)
 #
-# @zero-blocks: During storage migration encode blocks of zeroes
-# efficiently.  This essentially saves 1MB of zeroes per block on
-# the wire.  Enabling requires source and target VM to support
-# this feature.  To enable it is sufficient to enable the
-# capability on the source VM.  The feature is disabled by
-# default.  (since 1.6)
-#
 # @events: generate events for each migration state change (since 2.4)
 #
 # @auto-converge: If enabled, QEMU will automatically throttle down
@@ -483,7 +476,7 @@
 # Since: 1.2
 ##
 { 'enum': 'MigrationCapability',
-  'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
+  'data': ['xbzrle', 'rdma-pin-all', 'auto-converge',
'events', 'postcopy-ram',
{ 'name': 'x-colo', 'features': [ 'unstable' ] },
'release-ram',
@@ -542,7 +535,6 @@
 #   {"state": false, "capability": "xbzrle"},
 #   {"state": false, "capability": "rdma-pin-all"},
 #   {"state": false, "capability": "auto-converge"},
-#   {"state": false, "capability": "zero-blocks"},
 #   {"state": true, "capability": "events"},
 #   {"state": false, "capability": "postcopy-ram"},
 #   {"state": false, "capability": "x-colo"}
-- 
2.46.0

[PATCH 1/3] migration: Remove migrate_cap_set

[dave]

From: "Dr. David Alan Gilbert" 

migrate_cap_set has been unused since
  18d154f575 ("migration: Remove 'blk/-b' option from migrate commands")

Remove it.

Signed-off-by: Dr. David Alan Gilbert 
---
 migration/options.c | 20 
 migration/options.h |  1 -
 2 files changed, 21 deletions(-)

diff --git a/migration/options.c b/migration/options.c
index 147cd2b8fd..9460c5dee9 100644
--- a/migration/options.c
+++ b/migration/options.c
@@ -605,26 +605,6 @@ bool migrate_caps_check(bool *old_caps, bool *new_caps, 
Error **errp)
 return true;
 }
 
-bool migrate_cap_set(int cap, bool value, Error **errp)
-{
-MigrationState *s = migrate_get_current();
-bool new_caps[MIGRATION_CAPABILITY__MAX];
-
-if (migration_is_running()) {
-error_setg(errp, "There's a migration process in progress");
-return false;
-}
-
-memcpy(new_caps, s->capabilities, sizeof(new_caps));
-new_caps[cap] = value;
-
-if (!migrate_caps_check(s->capabilities, new_caps, errp)) {
-return false;
-}
-s->capabilities[cap] = value;
-return true;
-}
-
 MigrationCapabilityStatusList *qmp_query_migrate_capabilities(Error **errp)
 {
 MigrationCapabilityStatusList *head = NULL, **tail = &head;
diff --git a/migration/options.h b/migration/options.h
index a0bd6edc06..36e7b3723f 100644
--- a/migration/options.h
+++ b/migration/options.h
@@ -58,7 +58,6 @@ bool migrate_tls(void);
 /* capabilities helpers */
 
 bool migrate_caps_check(bool *old_caps, bool *new_caps, Error **errp);
-bool migrate_cap_set(int cap, bool value, Error **errp);
 
 /* parameters */
 
-- 
2.46.0

[PATCH 3/3] migration: Remove unused socket_send_channel_create_sync

[dave]

From: "Dr. David Alan Gilbert" 

socket_send_channel_create_sync only use was removed by
  d0edb8a173 ("migration: Create the postcopy preempt channel asynchronously")

Remove it.

Signed-off-by: Dr. David Alan Gilbert 
---
 migration/socket.c | 18 --
 migration/socket.h |  1 -
 2 files changed, 19 deletions(-)

diff --git a/migration/socket.c b/migration/socket.c
index 9ab89b1e08..5ec65b8c03 100644
--- a/migration/socket.c
+++ b/migration/socket.c
@@ -42,24 +42,6 @@ void socket_send_channel_create(QIOTaskFunc f, void *data)
  f, data, NULL, NULL);
 }
 
-QIOChannel *socket_send_channel_create_sync(Error **errp)
-{
-QIOChannelSocket *sioc = qio_channel_socket_new();
-
-if (!outgoing_args.saddr) {
-object_unref(OBJECT(sioc));
-error_setg(errp, "Initial sock address not set!");
-return NULL;
-}
-
-if (qio_channel_socket_connect_sync(sioc, outgoing_args.saddr, errp) < 0) {
-object_unref(OBJECT(sioc));
-return NULL;
-}
-
-return QIO_CHANNEL(sioc);
-}
-
 struct SocketConnectData {
 MigrationState *s;
 char *hostname;
diff --git a/migration/socket.h b/migration/socket.h
index 46c233ecd2..04ebbe95a1 100644
--- a/migration/socket.h
+++ b/migration/socket.h
@@ -22,7 +22,6 @@
 #include "qemu/sockets.h"
 
 void socket_send_channel_create(QIOTaskFunc f, void *data);
-QIOChannel *socket_send_channel_create_sync(Error **errp);
 
 void socket_start_incoming_migration(SocketAddress *saddr, Error **errp);
 
-- 
2.46.0

[PATCH] envlist: Remove unused envlist_parse

[dave]

From: "Dr. David Alan Gilbert" 

envlist_parse, envlist_parse_set, envlist_parse_unset were added
in 2009 but never used, see:
  04a6dfebb6 ("linux-user: Add generic env variable handling")

Remove them.

Signed-off-by: Dr. David Alan Gilbert 
---
 include/qemu/envlist.h |  2 --
 util/envlist.c | 69 --
 2 files changed, 71 deletions(-)

diff --git a/include/qemu/envlist.h b/include/qemu/envlist.h
index 6006dfae44..b2883f6659 100644
--- a/include/qemu/envlist.h
+++ b/include/qemu/envlist.h
@@ -7,8 +7,6 @@ envlist_t *envlist_create(void);
 void envlist_free(envlist_t *);
 int envlist_setenv(envlist_t *, const char *);
 int envlist_unsetenv(envlist_t *, const char *);
-int envlist_parse_set(envlist_t *, const char *);
-int envlist_parse_unset(envlist_t *, const char *);
 char **envlist_to_environ(const envlist_t *, size_t *);
 
 #endif /* ENVLIST_H */
diff --git a/util/envlist.c b/util/envlist.c
index db937c0427..15fdbb109d 100644
--- a/util/envlist.c
+++ b/util/envlist.c
@@ -12,9 +12,6 @@ struct envlist {
 size_t el_count;/* number of entries */
 };
 
-static int envlist_parse(envlist_t *envlist,
-const char *env, int (*)(envlist_t *, const char *));
-
 /*
  * Allocates new envlist and returns pointer to it.
  */
@@ -51,72 +48,6 @@ envlist_free(envlist_t *envlist)
 g_free(envlist);
 }
 
-/*
- * Parses comma separated list of set/modify environment
- * variable entries and updates given enlist accordingly.
- *
- * For example:
- * envlist_parse(el, "HOME=foo,SHELL=/bin/sh");
- *
- * inserts/sets environment variables HOME and SHELL.
- *
- * Returns 0 on success, errno otherwise.
- */
-int
-envlist_parse_set(envlist_t *envlist, const char *env)
-{
-return (envlist_parse(envlist, env, &envlist_setenv));
-}
-
-/*
- * Parses comma separated list of unset environment variable
- * entries and removes given variables from given envlist.
- *
- * Returns 0 on success, errno otherwise.
- */
-int
-envlist_parse_unset(envlist_t *envlist, const char *env)
-{
-return (envlist_parse(envlist, env, &envlist_unsetenv));
-}
-
-/*
- * Parses comma separated list of set, modify or unset entries
- * and calls given callback for each entry.
- *
- * Returns 0 in case of success, errno otherwise.
- */
-static int
-envlist_parse(envlist_t *envlist, const char *env,
-int (*callback)(envlist_t *, const char *))
-{
-char *tmpenv, *envvar;
-char *envsave = NULL;
-int ret = 0;
-assert(callback != NULL);
-
-if ((envlist == NULL) || (env == NULL))
-return (EINVAL);
-
-tmpenv = g_strdup(env);
-envsave = tmpenv;
-
-do {
-envvar = strchr(tmpenv, ',');
-if (envvar != NULL) {
-*envvar = '\0';
-}
-if ((*callback)(envlist, tmpenv) != 0) {
-ret = errno;
-break;
-}
-tmpenv = envvar + 1;
-} while (envvar != NULL);
-
-g_free(envsave);
-return ret;
-}
-
 /*
  * Sets environment value to envlist in similar manner
  * than putenv(3).
-- 
2.46.0

[PATCH] q35: Remove unused mch_mcfg_base

[dave]

From: "Dr. David Alan Gilbert" 

mch_mcfg_base has been unused since it was added by
  6f1426ab0f ("ich9: APIs for pc guest info")
back in 2013.

Remove it.

Signed-off-by: Dr. David Alan Gilbert 
---
 hw/pci-host/q35.c | 10 --
 include/hw/pci-host/q35.h |  2 --
 2 files changed, 12 deletions(-)

diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index d5a657a02a..f3e713318e 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -662,16 +662,6 @@ static void mch_realize(PCIDevice *d, Error **errp)
OBJECT(&mch->smram));
 }
 
-uint64_t mch_mcfg_base(void)
-{
-bool ambiguous;
-Object *o = object_resolve_path_type("", TYPE_MCH_PCI_DEVICE, &ambiguous);
-if (!o) {
-return 0;
-}
-return MCH_HOST_BRIDGE_PCIEXBAR_DEFAULT;
-}
-
 static Property mch_props[] = {
 DEFINE_PROP_UINT16("extended-tseg-mbytes", MCHPCIState, ext_tseg_mbytes,
16),
diff --git a/include/hw/pci-host/q35.h b/include/hw/pci-host/q35.h
index 22fadfa3ed..ddafc3f2e3 100644
--- a/include/hw/pci-host/q35.h
+++ b/include/hw/pci-host/q35.h
@@ -181,8 +181,6 @@ struct Q35PCIHost {
 #define MCH_PCIE_DEV   1
 #define MCH_PCIE_FUNC  0
 
-uint64_t mch_mcfg_base(void);
-
 /*
  * Arbitrary but unique BNF number for IOAPIC device.
  *
-- 
2.46.0

[Qemu-devel] [PATCH] virtio-blk: add default value to serial attribute

[Dave Young]

From: Dave Young 

For virtio block device, if user does not specify the serial attribute,
There will be not serial availabe, this is not convinient for identify
the disk.

Doing something similar to ide disks, add a "VD?" default serial
number if user does not specify it.

Signed-off-by: Dave Young 
---
 hw/virtio-blk.c |9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

--- qemu-kvm.orig/hw/virtio-blk.c   2012-09-02 09:45:03.115696878 +0800
+++ qemu-kvm/hw/virtio-blk.c2012-09-20 20:57:56.177206991 +0800
@@ -22,6 +22,7 @@
 # include 
 #endif
 
+#define DEFAULT_VIRTIO_BLK_SERIAL_LEN 8
 typedef struct VirtIOBlock
 {
 VirtIODevice vdev;
@@ -33,6 +34,7 @@ typedef struct VirtIOBlock
 VirtIOBlkConf *blk;
 unsigned short sector_mask;
 DeviceState *qdev;
+int drive_serial;
 } VirtIOBlock;
 
 static VirtIOBlock *to_virtio_blk(VirtIODevice *vdev)
@@ -364,6 +366,7 @@ static void virtio_blk_handle_request(Vi
 MultiReqBuffer *mrb)
 {
 uint32_t type;
+char serial[DEFAULT_VIRTIO_BLK_SERIAL_LEN];
 
 if (req->elem.out_num < 1 || req->elem.in_num < 1) {
 error_report("virtio-blk missing headers");
@@ -388,12 +391,14 @@ static void virtio_blk_handle_request(Vi
 } else if (type & VIRTIO_BLK_T_GET_ID) {
 VirtIOBlock *s = req->dev;
 
+snprintf(serial, DEFAULT_VIRTIO_BLK_SERIAL_LEN,
+ "VD%05d", s->drive_serial);
 /*
  * NB: per existing s/n string convention the string is
  * terminated by '\0' only when shorter than buffer.
  */
 strncpy(req->elem.in_sg[0].iov_base,
-s->blk->serial ? s->blk->serial : "",
+s->blk->serial ? s->blk->serial : serial,
 MIN(req->elem.in_sg[0].iov_len, VIRTIO_BLK_ID_BYTES));
 virtio_blk_req_complete(req, VIRTIO_BLK_S_OK);
 g_free(req);
@@ -611,6 +616,7 @@ static const BlockDevOps virtio_block_op
 
 VirtIODevice *virtio_blk_init(DeviceState *dev, VirtIOBlkConf *blk)
 {
+static int drive_serial = 1;
 VirtIOBlock *s;
 static int virtio_blk_id;
 
@@ -632,6 +638,7 @@ VirtIODevice *virtio_blk_init(DeviceStat
   sizeof(struct virtio_blk_config),
   sizeof(VirtIOBlock));
 
+s->drive_serial = drive_serial++;
 s->vdev.get_config = virtio_blk_update_config;
 s->vdev.set_config = virtio_blk_set_config;
 s->vdev.get_features = virtio_blk_get_features;

[Qemu-devel] [PATCH] virtio-blk: add default serial id

[Dave Young]

For virtio block device, if user does not specify the serial attribute,
There will be not serial availabe, this is not convinient for identify
the disk.

Doing something similar to ide disks, add a "VD?" default serial
number if user does not specify it.

Signed-off-by: Dave Young 
---
 hw/virtio-blk.c |9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

--- qemu.orig/hw/virtio-blk.c
+++ qemu/hw/virtio-blk.c
@@ -22,6 +22,7 @@
 # include 
 #endif
 
+#define DEFAULT_VIRTIO_BLK_SERIAL_LEN 8
 typedef struct VirtIOBlock
 {
 VirtIODevice vdev;
@@ -33,6 +34,7 @@ typedef struct VirtIOBlock
 VirtIOBlkConf *blk;
 unsigned short sector_mask;
 DeviceState *qdev;
+int drive_serial;
 } VirtIOBlock;
 
 static VirtIOBlock *to_virtio_blk(VirtIODevice *vdev)
@@ -364,6 +366,7 @@ static void virtio_blk_handle_request(Vi
 MultiReqBuffer *mrb)
 {
 uint32_t type;
+char serial[DEFAULT_VIRTIO_BLK_SERIAL_LEN];
 
 if (req->elem.out_num < 1 || req->elem.in_num < 1) {
 error_report("virtio-blk missing headers");
@@ -388,12 +391,14 @@ static void virtio_blk_handle_request(Vi
 } else if (type & VIRTIO_BLK_T_GET_ID) {
 VirtIOBlock *s = req->dev;
 
+snprintf(serial, DEFAULT_VIRTIO_BLK_SERIAL_LEN,
+ "VD%05d", s->drive_serial);
 /*
  * NB: per existing s/n string convention the string is
  * terminated by '\0' only when shorter than buffer.
  */
 strncpy(req->elem.in_sg[0].iov_base,
-s->blk->serial ? s->blk->serial : "",
+s->blk->serial ? s->blk->serial : serial,
 MIN(req->elem.in_sg[0].iov_len, VIRTIO_BLK_ID_BYTES));
 virtio_blk_req_complete(req, VIRTIO_BLK_S_OK);
 g_free(req);
@@ -611,6 +616,7 @@ static const BlockDevOps virtio_block_op
 
 VirtIODevice *virtio_blk_init(DeviceState *dev, VirtIOBlkConf *blk)
 {
+static int drive_serial = 1;
 VirtIOBlock *s;
 static int virtio_blk_id;
 
@@ -632,6 +638,7 @@ VirtIODevice *virtio_blk_init(DeviceStat
   sizeof(struct virtio_blk_config),
   sizeof(VirtIOBlock));
 
+s->drive_serial = drive_serial++;
 s->vdev.get_config = virtio_blk_update_config;
 s->vdev.set_config = virtio_blk_set_config;
 s->vdev.get_features = virtio_blk_get_features;

Re: [Qemu-devel] [PATCH] add default virtio-blk serial id

[Dave Young]

Oops, local mta use wrong from line, should use below:
From: Dave Young 

On 09/20/2012 04:48 PM, Dave Young wrote:

> For virtio block device, if user does not specify the serial attribute,
> There will be not serial availabe, this is not convinient for identify
> the disk.
> 
> Doing something similar to ide disks, add a "VD?" default serial
> number if user does not specify it.
> 
> Signed-off-by: Dave Young 
> ---
>  hw/virtio-blk.c |9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> --- qemu.orig/hw/virtio-blk.c
> +++ qemu/hw/virtio-blk.c
> @@ -22,6 +22,7 @@
>  # include 
>  #endif
>  
> +#define DEFAULT_VIRTIO_BLK_SERIAL_LEN 8
>  typedef struct VirtIOBlock
>  {
>  VirtIODevice vdev;
> @@ -33,6 +34,7 @@ typedef struct VirtIOBlock
>  VirtIOBlkConf *blk;
>  unsigned short sector_mask;
>  DeviceState *qdev;
> +int drive_serial;
>  } VirtIOBlock;
>  
>  static VirtIOBlock *to_virtio_blk(VirtIODevice *vdev)
> @@ -364,6 +366,7 @@ static void virtio_blk_handle_request(Vi
>  MultiReqBuffer *mrb)
>  {
>  uint32_t type;
> +char serial[DEFAULT_VIRTIO_BLK_SERIAL_LEN];
>  
>  if (req->elem.out_num < 1 || req->elem.in_num < 1) {
>  error_report("virtio-blk missing headers");
> @@ -388,12 +391,14 @@ static void virtio_blk_handle_request(Vi
>  } else if (type & VIRTIO_BLK_T_GET_ID) {
>  VirtIOBlock *s = req->dev;
>  
> +snprintf(serial, DEFAULT_VIRTIO_BLK_SERIAL_LEN,
> + "VD%05d", s->drive_serial);
>  /*
>   * NB: per existing s/n string convention the string is
>   * terminated by '\0' only when shorter than buffer.
>   */
>  strncpy(req->elem.in_sg[0].iov_base,
> -s->blk->serial ? s->blk->serial : "",
> +s->blk->serial ? s->blk->serial : serial,
>  MIN(req->elem.in_sg[0].iov_len, VIRTIO_BLK_ID_BYTES));
>  virtio_blk_req_complete(req, VIRTIO_BLK_S_OK);
>  g_free(req);
> @@ -611,6 +616,7 @@ static const BlockDevOps virtio_block_op
>  
>  VirtIODevice *virtio_blk_init(DeviceState *dev, VirtIOBlkConf *blk)
>  {
> +static int drive_serial = 1;
>  VirtIOBlock *s;
>  static int virtio_blk_id;
>  
> @@ -632,6 +638,7 @@ VirtIODevice *virtio_blk_init(DeviceStat
>sizeof(struct virtio_blk_config),
>sizeof(VirtIOBlock));
>  
> +s->drive_serial = drive_serial++;
>  s->vdev.get_config = virtio_blk_update_config;
>  s->vdev.set_config = virtio_blk_set_config;
>  s->vdev.get_features = virtio_blk_get_features;



-- 
Thanks
Dave

[Qemu-devel] [PATCH v2] virtio-blk: add default serial id

[Dave Young]

For virtio block device, if user does not specify the serial attribute,
There will be no serial availabe, this is not convenient for identifying
the disk.

Doing something similar to ide disks, add a "VD?" default serial
number if user does not specify it.

[v1->v2 address comments from Eric Blake]:
fix spell errors in patch description
decrease drive_serial in virtio_blk_exit as well

Signed-off-by: Dave Young 
---
 hw/virtio-blk.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

--- qemu.orig/hw/virtio-blk.c
+++ qemu/hw/virtio-blk.c
@@ -22,6 +22,8 @@
 # include 
 #endif
 
+static int drive_serial = 1;
+#define DEFAULT_VIRTIO_BLK_SERIAL_LEN 8
 typedef struct VirtIOBlock
 {
 VirtIODevice vdev;
@@ -33,6 +35,7 @@ typedef struct VirtIOBlock
 VirtIOBlkConf *blk;
 unsigned short sector_mask;
 DeviceState *qdev;
+int drive_serial;
 } VirtIOBlock;
 
 static VirtIOBlock *to_virtio_blk(VirtIODevice *vdev)
@@ -364,6 +367,7 @@ static void virtio_blk_handle_request(Vi
 MultiReqBuffer *mrb)
 {
 uint32_t type;
+char serial[DEFAULT_VIRTIO_BLK_SERIAL_LEN];
 
 if (req->elem.out_num < 1 || req->elem.in_num < 1) {
 error_report("virtio-blk missing headers");
@@ -388,12 +392,14 @@ static void virtio_blk_handle_request(Vi
 } else if (type & VIRTIO_BLK_T_GET_ID) {
 VirtIOBlock *s = req->dev;
 
+snprintf(serial, DEFAULT_VIRTIO_BLK_SERIAL_LEN,
+ "VD%05d", s->drive_serial);
 /*
  * NB: per existing s/n string convention the string is
  * terminated by '\0' only when shorter than buffer.
  */
 strncpy(req->elem.in_sg[0].iov_base,
-s->blk->serial ? s->blk->serial : "",
+s->blk->serial ? s->blk->serial : serial,
 MIN(req->elem.in_sg[0].iov_len, VIRTIO_BLK_ID_BYTES));
 virtio_blk_req_complete(req, VIRTIO_BLK_S_OK);
 g_free(req);
@@ -632,6 +638,7 @@ VirtIODevice *virtio_blk_init(DeviceStat
   sizeof(struct virtio_blk_config),
   sizeof(VirtIOBlock));
 
+s->drive_serial = drive_serial++;
 s->vdev.get_config = virtio_blk_update_config;
 s->vdev.set_config = virtio_blk_set_config;
 s->vdev.get_features = virtio_blk_get_features;
@@ -664,4 +671,5 @@ void virtio_blk_exit(VirtIODevice *vdev)
 unregister_savevm(s->qdev, "virtio-blk", s);
 blockdev_mark_auto_del(s->bs);
 virtio_cleanup(vdev);
+drive_serial--;
 }

Re: [Qemu-devel] [PATCH v2] virtio-blk: add default serial id

[Dave Young]

On Fri, Sep 21, 2012 at 08:15:38AM -0600, Eric Blake wrote:
> On 09/21/2012 07:30 AM, Dave Young wrote:
> > 
> > For virtio block device, if user does not specify the serial attribute,
> > There will be no serial availabe, this is not convenient for identifying
> > the disk.
> > 
> > Doing something similar to ide disks, add a "VD?" default serial
> > number if user does not specify it.
> > 
> > [v1->v2 address comments from Eric Blake]:
> > fix spell errors in patch description
> > decrease drive_serial in virtio_blk_exit as well
> 
> Typically, patch changelogs belong...
> 
> > 
> > Signed-off-by: Dave Young 
> > ---
> 
> ...after the --- line, so that 'git am' doesn't make them part of git
> history.  Also, I'm not sure that decreasing the serial number is
> correct - you've now made it much easier to get duplicate serial numbers
> compared to my original complaint of 10 hotplug cycles.  Now all I
> have to do is:
> 
> create a guest with two disks
> hot unplug disk one
> hot plug a new disk
> 
> and voila, both disks will now have serial number 2.

Thanks for comment.

Add changelogs to git history is not bad IMO, this can reflect the changes
between diffrent version of the patches, it's quite normal. 

For the serial number decreasing issue, I think there's only these two ways to
select, there's no ideal way to resolve this issue.
My use case for this is for the kdump kernel to find proper disks,
after 1st kernel crashing 2nd kernel need find right disk to dump vmcore.
In this case v1 and v2 aproaches are both find to me.

>From my point of view, patch v1 is better though, I think unpluging 10 is
not a sane use case. It's not likely to happen.

> 
> > @@ -632,6 +638,7 @@ VirtIODevice *virtio_blk_init(DeviceStat
> >sizeof(struct virtio_blk_config),
> >sizeof(VirtIOBlock));
> >  
> > +s->drive_serial = drive_serial++;
> >  s->vdev.get_config = virtio_blk_update_config;
> >  s->vdev.set_config = virtio_blk_set_config;
> >  s->vdev.get_features = virtio_blk_get_features;
> > @@ -664,4 +671,5 @@ void virtio_blk_exit(VirtIODevice *vdev)
> >  unregister_savevm(s->qdev, "virtio-blk", s);
> >  blockdev_mark_auto_del(s->bs);
> >  virtio_cleanup(vdev);
> > +drive_serial--;
> >  }
> > 
> > 
> 
> -- 
> Eric Blake   ebl...@redhat.com+1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 

[Qemu-devel] [PATCH V3] virtio-blk: add default serial id

[Dave Young]

For virtio block device, if user does not specify the serial attribute,
There will be no serial availabe, this is not convenient for identifying
the disk.

Doing something similar to ide disks, add a "VD?" default serial
number if user does not specify it.

Signed-off-by: Dave Young 
---
 hw/virtio-blk.c |9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

--- qemu-kvm.orig/hw/virtio-blk.c   2012-09-02 09:45:03.115696878 +0800
+++ qemu-kvm/hw/virtio-blk.c2012-09-20 20:57:56.177206991 +0800
@@ -22,6 +22,7 @@
 # include 
 #endif
 
+#define DEFAULT_VIRTIO_BLK_SERIAL_LEN 8
 typedef struct VirtIOBlock
 {
 VirtIODevice vdev;
@@ -33,6 +34,7 @@ typedef struct VirtIOBlock
 VirtIOBlkConf *blk;
 unsigned short sector_mask;
 DeviceState *qdev;
+int drive_serial;
 } VirtIOBlock;
 
 static VirtIOBlock *to_virtio_blk(VirtIODevice *vdev)
@@ -364,6 +366,7 @@ static void virtio_blk_handle_request(Vi
 MultiReqBuffer *mrb)
 {
 uint32_t type;
+char serial[DEFAULT_VIRTIO_BLK_SERIAL_LEN];
 
 if (req->elem.out_num < 1 || req->elem.in_num < 1) {
 error_report("virtio-blk missing headers");
@@ -388,12 +391,14 @@ static void virtio_blk_handle_request(Vi
 } else if (type & VIRTIO_BLK_T_GET_ID) {
 VirtIOBlock *s = req->dev;
 
+snprintf(serial, DEFAULT_VIRTIO_BLK_SERIAL_LEN,
+ "VD%05d", s->drive_serial);
 /*
  * NB: per existing s/n string convention the string is
  * terminated by '\0' only when shorter than buffer.
  */
 strncpy(req->elem.in_sg[0].iov_base,
-s->blk->serial ? s->blk->serial : "",
+s->blk->serial ? s->blk->serial : serial,
 MIN(req->elem.in_sg[0].iov_len, VIRTIO_BLK_ID_BYTES));
 virtio_blk_req_complete(req, VIRTIO_BLK_S_OK);
 g_free(req);
@@ -611,6 +616,7 @@ static const BlockDevOps virtio_block_op
 
 VirtIODevice *virtio_blk_init(DeviceState *dev, VirtIOBlkConf *blk)
 {
+static int drive_serial = 1;
 VirtIOBlock *s;
 static int virtio_blk_id;
 
@@ -632,6 +638,7 @@ VirtIODevice *virtio_blk_init(DeviceStat
   sizeof(struct virtio_blk_config),
   sizeof(VirtIOBlock));
 
+s->drive_serial = drive_serial++;
 s->vdev.get_config = virtio_blk_update_config;
 s->vdev.set_config = virtio_blk_set_config;
 s->vdev.get_features = virtio_blk_get_features;

Re: [Qemu-devel] [PATCH V3] virtio-blk: add default serial id

[Dave Young]

Hi, Eric

This is in fact same with v1 except the spelling fixes.

I switched back to v1 because of your concern about the same id reusing
issue. For v1, unplugging 10 times is not likely and insane, so I
think we can safely ignore it.

Unless qemu-img create some uuid for disk imgs I think there's no way
to create some really ideal *uniq* ids.

On 09/26/2012 04:18 PM, Dave Young wrote:

> For virtio block device, if user does not specify the serial attribute,
> There will be no serial availabe, this is not convenient for identifying
> the disk.
> 
> Doing something similar to ide disks, add a "VD?" default serial
> number if user does not specify it.
> 
> Signed-off-by: Dave Young 
> ---
>  hw/virtio-blk.c |9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> --- qemu-kvm.orig/hw/virtio-blk.c 2012-09-02 09:45:03.115696878 +0800
> +++ qemu-kvm/hw/virtio-blk.c  2012-09-20 20:57:56.177206991 +0800
> @@ -22,6 +22,7 @@
>  # include 
>  #endif
>  
> +#define DEFAULT_VIRTIO_BLK_SERIAL_LEN 8
>  typedef struct VirtIOBlock
>  {
>  VirtIODevice vdev;
> @@ -33,6 +34,7 @@ typedef struct VirtIOBlock
>  VirtIOBlkConf *blk;
>  unsigned short sector_mask;
>  DeviceState *qdev;
> +int drive_serial;
>  } VirtIOBlock;
>  
>  static VirtIOBlock *to_virtio_blk(VirtIODevice *vdev)
> @@ -364,6 +366,7 @@ static void virtio_blk_handle_request(Vi
>  MultiReqBuffer *mrb)
>  {
>  uint32_t type;
> +char serial[DEFAULT_VIRTIO_BLK_SERIAL_LEN];
>  
>  if (req->elem.out_num < 1 || req->elem.in_num < 1) {
>  error_report("virtio-blk missing headers");
> @@ -388,12 +391,14 @@ static void virtio_blk_handle_request(Vi
>  } else if (type & VIRTIO_BLK_T_GET_ID) {
>  VirtIOBlock *s = req->dev;
>  
> +snprintf(serial, DEFAULT_VIRTIO_BLK_SERIAL_LEN,
> + "VD%05d", s->drive_serial);
>  /*
>   * NB: per existing s/n string convention the string is
>   * terminated by '\0' only when shorter than buffer.
>   */
>  strncpy(req->elem.in_sg[0].iov_base,
> -s->blk->serial ? s->blk->serial : "",
> +s->blk->serial ? s->blk->serial : serial,
>  MIN(req->elem.in_sg[0].iov_len, VIRTIO_BLK_ID_BYTES));
>  virtio_blk_req_complete(req, VIRTIO_BLK_S_OK);
>  g_free(req);
> @@ -611,6 +616,7 @@ static const BlockDevOps virtio_block_op
>  
>  VirtIODevice *virtio_blk_init(DeviceState *dev, VirtIOBlkConf *blk)
>  {
> +static int drive_serial = 1;
>  VirtIOBlock *s;
>  static int virtio_blk_id;
>  
> @@ -632,6 +638,7 @@ VirtIODevice *virtio_blk_init(DeviceStat
>sizeof(struct virtio_blk_config),
>sizeof(VirtIOBlock));
>  
> +s->drive_serial = drive_serial++;
>  s->vdev.get_config = virtio_blk_update_config;
>  s->vdev.set_config = virtio_blk_set_config;
>  s->vdev.get_features = virtio_blk_get_features;
> 
> 



-- 
Thanks
Dave

Re: [Qemu-devel] [PATCH v2] virtio-blk: add default serial id

[Dave Young]

On 10/05/2012 04:14 PM, Stefan Hajnoczi wrote:

> On Sun, Sep 23, 2012 at 10:37:09AM +0800, Dave Young wrote:
>> For the serial number decreasing issue, I think there's only these two ways 
>> to
>> select, there's no ideal way to resolve this issue.
>> My use case for this is for the kdump kernel to find proper disks,
>> after 1st kernel crashing 2nd kernel need find right disk to dump vmcore.
>> In this case v1 and v2 aproaches are both find to me.
>>
>> From my point of view, patch v1 is better though, I think unpluging 10 is
>> not a sane use case. It's not likely to happen.
> 
> I'm not sure auto-assigning serial numbers is a good idea.  The guest can use
> the serial number in /etc/fstab or other places where it expects the serial
> number to be persistent.
> 
> Your patch does not provide persistent serial numbers, so a change to the QEMU
> invocation could result in different serial numbers.  The guest will get
> confused or perhaps refuse to boot.


Yes, it introduce confusion, but in this way at least the serial number
can be persistent across guest reboot. Traditionally ide disks use this
way as well, such as QEMU_HARDISK_1, I think guest should not use
this in /etc/fstab.

> 
> I'd prefer if we don't expose a temporary serial number at all in order to
> avoid issues like this.
> 
> Stefan



-- 
Thanks
Dave

Re: [Qemu-devel] [PATCH v2] virtio-blk: add default serial id

[Dave Young]

On 10/09/2012 04:31 PM, Stefan Hajnoczi wrote:

> On Tue, Oct 09, 2012 at 10:27:26AM +0800, Dave Young wrote:
>> On 10/05/2012 04:14 PM, Stefan Hajnoczi wrote:
>>
>>> On Sun, Sep 23, 2012 at 10:37:09AM +0800, Dave Young wrote:
>>>> For the serial number decreasing issue, I think there's only these two 
>>>> ways to
>>>> select, there's no ideal way to resolve this issue.
>>>> My use case for this is for the kdump kernel to find proper disks,
>>>> after 1st kernel crashing 2nd kernel need find right disk to dump vmcore.
>>>> In this case v1 and v2 aproaches are both find to me.
>>>>
>>>> From my point of view, patch v1 is better though, I think unpluging 10 
>>>> is
>>>> not a sane use case. It's not likely to happen.
>>>
>>> I'm not sure auto-assigning serial numbers is a good idea.  The guest can 
>>> use
>>> the serial number in /etc/fstab or other places where it expects the serial
>>> number to be persistent.
>>>
>>> Your patch does not provide persistent serial numbers, so a change to the 
>>> QEMU
>>> invocation could result in different serial numbers.  The guest will get
>>> confused or perhaps refuse to boot.
>>
>>
>> Yes, it introduce confusion, but in this way at least the serial number
>> can be persistent across guest reboot. Traditionally ide disks use this
>> way as well, such as QEMU_HARDISK_1, I think guest should not use
>> this in /etc/fstab.
> 
> If you don't want to set a persistent serial number, use another mechanism to
> identify the disk.  For example, Linux has /dev/disk/by-path/ which identifies
> virtio-blk PCI adapters, IDE, SCSI disks, etc.

>

> Does this work for your use case?


I have tried this before, but after rebooting (kexec/kdump) the by-path
link was not created. It might be udev bug anyway, I'm not sure though.


> 
> Stefan
> 



-- 
Thanks
Dave

Re: [Qemu-devel] [PATCH 1/8] virtio-gpu/2d: add hardware spec include file

[Dave Airlie]

> Triggered by the framebuffer endian issues we have with stdvga I've
> started to check where we stand with virtio-gpu and whenever we have to
> fix something in the virtio protocol before setting in stone with the
> upstream merge.

Let me start by saying its not that I don't care about endianness, but
its a mess I had hoped to avoid until someone else care more about it.

We haven't even managed to get endianness fixed for real 3D gpu hardware yet,

We sort of have decent endianness support for the llvmpipe sw driver now, after
I spent a week trawling patches and fixing up the results.

So before we try fixing things, we probably need to design something
that defines
where all the swapping happens, and what formats the virgl "hw" device supports.
The main problem is getting an efficient solution that avoids double swapping
of the major items like texture and vertex data if we can in some scenarios.

Currently the virgl "hw" supports little endian defined formats, as
per the gallium
interface, i.e. B8G8R8A8 means blue/red/green/alpha,

http://gallium.readthedocs.org/en/latest/format.html
is the documentation.

>
>> +VIRTIO_GPU_FORMAT_B5G5R5A1_UNORM  = 5,
>> +VIRTIO_GPU_FORMAT_B5G6R5_UNORM= 7,
>
> Do we really wanna go down this route?  I'm inclined to just zap 16bpp
> support.

We have to support 16bpp as an OpenGL format no matter what, and this
is why endianness sucks, we have lots of strange ass formats we need
to send over the wire, that have no nicely defined endianness, like Z24S8.

>
>> +VIRTIO_GPU_FORMAT_R8_UNORM= 64,
>
> What is this btw?  Looks like gray or alpha, but why "R8" not "G8" or
> "A8" then?  Why the gap in the enumeration?

Red 8, the enumeration is taken from the gallium formats list, rather than
reinventing our own. Most modern GPU hardware doesn't really have
A8 texture support, as it was deprecated in newer OpenGL.

>
> What about 3d mode?  We are passing blobs between virglrenderer and
> guest driver:  capabilities and gallium 3d command stream.  What happens
> to them in case host and guest endianness don't match?  I think at least
> the capabilities have 32bit values which need to be swapped.  Dunno
> about the gallium commands ...

For 3D we probably need to define the gallium command streams to be
little endian, however the big problem is the data that is stored
inside objects.
Texture and vertex, constants, indices etc. How do we decide to swap these,
when do we swap things, on the DMA transfers to the host, do we just
swap the formats on the host side etc.

I probably need to spend some time working this out with BenH, but
I'm not really sure how we can avoid backing ourselves into a large inefficent
hole at some point.

Dave.

Re: [Qemu-devel] [PATCH 1/8] virtio-gpu/2d: add hardware spec include file

[Dave Airlie]

On 30 September 2014 17:55, Gerd Hoffmann  wrote:
>
> On Di, 2014-09-30 at 10:27 +1000, Dave Airlie wrote:
>> > Triggered by the framebuffer endian issues we have with stdvga I've
>> > started to check where we stand with virtio-gpu and whenever we have to
>> > fix something in the virtio protocol before setting in stone with the
>> > upstream merge.
>>
>> Let me start by saying its not that I don't care about endianness, but
>> its a mess I had hoped to avoid until someone else care more about it.
>
> Understood.  It's a big mess indeed.
>
>> So before we try fixing things, we probably need to design something
>> that defines
>> where all the swapping happens, and what formats the virgl "hw" device 
>> supports.
>
> 2D case is easy.  Everything is little endian.  kernel driver / qemu are
> doing the byteswaps for the structs sent over the control pipe.
>
> Problem with 3D is that both qemu and kernel driver passing through data
> where they don't even know what is inside, so they can't do the
> byteswapping.
>
>> The main problem is getting an efficient solution that avoids double swapping
>> of the major items like texture and vertex data if we can in some scenarios.
>
> Yes.
>
>>
>> Currently the virgl "hw" supports little endian defined formats, as
>> per the gallium
>> interface, i.e. B8G8R8A8 means blue/red/green/alpha,
>>
>> http://gallium.readthedocs.org/en/latest/format.html
>> is the documentation.
>
> Thanks.
>
>> >> +VIRTIO_GPU_FORMAT_B5G5R5A1_UNORM  = 5,
>> >> +VIRTIO_GPU_FORMAT_B5G6R5_UNORM= 7,
>> >
>> > Do we really wanna go down this route?  I'm inclined to just zap 16bpp
>> > support.
>>
>> We have to support 16bpp as an OpenGL format no matter what, and this
>> is why endianness sucks, we have lots of strange ass formats we need
>> to send over the wire, that have no nicely defined endianness, like Z24S8.
>
> Ok.  But for 2D we can just not support it, right?

We can, I expect some pushback at some point, people still want to
test with 16bpp
for other areas, and it would be nice to know they can. But I don't really care
about it personally. I just though we should provide at least a basic
number of working
bpps (8,16,32).


>> > What about 3d mode?  We are passing blobs between virglrenderer and
>> > guest driver:  capabilities and gallium 3d command stream.  What happens
>> > to them in case host and guest endianness don't match?  I think at least
>> > the capabilities have 32bit values which need to be swapped.  Dunno
>> > about the gallium commands ...
>>
>> For 3D we probably need to define the gallium command streams to be
>> little endian, however the big problem is the data that is stored
>> inside objects.
>> Texture and vertex, constants, indices etc. How do we decide to swap these,
>> when do we swap things, on the DMA transfers to the host, do we just
>> swap the formats on the host side etc.
>>
>> I probably need to spend some time working this out with BenH, but
>> I'm not really sure how we can avoid backing ourselves into a large 
>> inefficent
>> hole at some point.
>
> I surely don't wanna go down that route, and I think it is reasonable to
> just not support 3D/virgl mode if we would have to swap data.

I think initially not support 3D mode is the way to go until we can work it out.

>
>
> So, we could define *two* virgl feature bits.  One for little endian,
> one for bigendian.  endianness applies to the gallium command stream and
> to gallium formats using integers in host endianess.
>
> On the host side we'll go set the feature bit matching host endianness.
> qemu handles the virtqueue command struct swapping, and virglrenderer
> should only see native endian.
>
> On the guest side we'll look for the feature bit matching guest
> endianness, and if it isn't set due to guest + host having different
> byte order you'll get 2D support only.
>
> The endianness negotiation is a bit iffy, but that way it is possible to
> have virgl on bigendian without swapping everything twice.
>
>
> The other reasonable way would be to simply define virgl being little
> endian.  Bigendian guests / hosts would either simply not support 3D
> then, or implement swapping.  But in the bigendian-guest on
> bigendian-host case we'll swap everything twice then ...
>

I think we should probably move a few more formats from the 3D side
into the 2D side, so we can have the guests just pick the LE format
it requires

http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/include/pipe/p_format.h#n354

is what gallium currently does, and we could just provide XRGB, XBGR
formats in both endianness
and have the guest pick the one it wants to use.

The 2D pixman code would need updating to provide 2D support for these
formats as well.

I suspect I could add an endian cap for the 3D bits that I could pass
through from guest to host.

How do you test guests with big endian? Isn't it really slow?

Dave.

[Qemu-devel] patch: add delay= suboption to -display curses

[Dave Mielke]

The attached patch (qemu-curses-delay-1.patch) allows the user to specify that 
he needs -display curses to insert a delay in between key events. The current 
behaviour is that it inserts key events immediately, one right after another, 
which has proven to be too fast for some applications. Please let me know if 
there are any improvements you'd like me to make to this patch, with the goal 
that I'm hoping you'll accept it. A more detailed description of this patch is 
as follows:

Add support for the "-display curses" option to accept suboptions (-display 
curses[,option...), and add the "delay=" suboption. This suboption 
causes a millisecond-based delay to be inserted in between key events so that 
they won't be inserted immediately one after another. The delay is performed 
using a qemu virtual clock timer. If the "delay" option isn't specified, or if 
"delay=0" is specified, then the timer isn't used, thus making the default be 
the original behaviour. The "=" operand is optional - if it isn't 
specified then 20 is assumed.

-- 
Dave Mielke   | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario   | http://Mielke.cc/bible/
EMail: d...@mielke.cc | Canada  K2A 1H7   | http://FamilyRadio.com/
diff --git a/include/ui/console.h b/include/ui/console.h
index 8a86617..d131260 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -338,6 +338,7 @@ static inline int vnc_display_pw_expire(DisplayState *ds, 
time_t expires)
 #endif
 
 /* curses.c */
+void curses_parse_options(const char *options);
 void curses_display_init(DisplayState *ds, int full_screen);
 
 /* input.c */
diff --git a/qemu-options.hx b/qemu-options.hx
index c2c0823..1e407bd 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -820,9 +820,11 @@ ETEXI
 
 DEF("display", HAS_ARG, QEMU_OPTION_display,
 "-display sdl[,frame=on|off][,alt_grab=on|off][,ctrl_grab=on|off]\n"
-"[,window_close=on|off]|curses|none|\n"
-"gtk[,grab_on_hover=on|off]|\n"
-"vnc=[,]\n"
+"[,window_close=on|off]\n"
+" none\n"
+" curses[,delay[=]]\n"
+" gtk[,grab_on_hover=on|off]\n"
+" vnc=[,]\n"
 "select display type\n", QEMU_ARCH_ALL)
 STEXI
 @item -display @var{type}
diff --git a/ui/curses.c b/ui/curses.c
index b044790..45719a4 100644
--- a/ui/curses.c
+++ b/ui/curses.c
@@ -176,6 +176,82 @@ static void curses_cursor_position(DisplayChangeListener 
*dcl,
 
 static kbd_layout_t *kbd_layout = NULL;
 
+struct KeyEvent {
+struct KeyEvent *next;
+int code;
+bool down;
+};
+
+static struct KeyEvent *firstKeyEvent = NULL;
+static struct KeyEvent *lastKeyEvent = NULL;
+
+static unsigned long long keyEventDelay = 0;
+static QEMUTimer *keyEventTimer = NULL;
+
+static void curses_begin_key_event(void);
+
+static void curses_send_key_event(int code, bool down)
+{
+qemu_input_event_send_key_number(NULL, code, down);
+}
+
+static void curses_end_key_event(void *opaque)
+{
+struct KeyEvent *event = firstKeyEvent;
+
+if ((firstKeyEvent = event->next))
+{
+curses_begin_key_event();
+}
+else
+{
+lastKeyEvent = NULL;
+}
+
+g_free(event);
+}
+
+static void curses_begin_key_event(void)
+{
+struct KeyEvent *event = firstKeyEvent;
+
+if (!keyEventTimer)
+{
+keyEventTimer = timer_new_ms(QEMU_CLOCK_VIRTUAL, curses_end_key_event, 
NULL);
+}
+
+curses_send_key_event(event->code, event->down);
+timer_mod(keyEventTimer, qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 
keyEventDelay);
+}
+
+static void curses_enqueue_key_event(int code, bool down)
+{
+if (keyEventDelay)
+{
+struct KeyEvent *event;
+
+event = g_malloc(sizeof(*event));
+event->next = NULL;
+event->code = code;
+event->down = down;
+
+if (lastKeyEvent)
+{
+lastKeyEvent->next = event;
+lastKeyEvent = event;
+}
+else
+{
+firstKeyEvent = lastKeyEvent = event;
+curses_begin_key_event();
+}
+}
+else
+{
+curses_send_key_event(code, down);
+}
+}
+
 static void curses_refresh(DisplayChangeListener *dcl)
 {
 int chr, nextchr, keysym, keycode, keycode_alt;
@@ -276,32 +352,32 @@ static void curses_refresh(DisplayChangeListener *dcl)
 /* since terminals don't know about key press and release
  * events, we need to emit both for each key received */
 if (keycode & SHIFT) {
-qemu_input_event_send_key_number(NULL, SHIFT_CODE, true);
+curses_enqueue_key_event(SHIFT_CODE, true);
   

Re: [Qemu-devel] patch: add delay= suboption to -display curses

[Dave Mielke]

[quoted lines by Peter Maydell on 2014/05/25 at 01:04 +0100]

>Why is this a problem only for the curses UI frontend, and not for
>any of the other UIs which might send key events?

One reason is that most UIs send key events as they receive them from the 
keyboard, one at a time, whereas the curses UI gets a single key event from 
curses and then sends all of the scancodes which it takes to represent that 
key. In other words, a single key event from curses could result in as many as 
10 actual key events needing to be passed along - both the press and release 
for the actual key plus up to four modifiers (shift, control, alt, altgr).

Another reason is that it's not a problem for a lot of applications. I happened 
to hit it in an application, and, therefore, coded a fix for it.

-- 
Dave Mielke   | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario   | http://Mielke.cc/bible/
EMail: d...@mielke.cc | Canada  K2A 1H7   | http://FamilyRadio.com/

Re: [Qemu-devel] patch: add delay= suboption to -display curses

[Dave Mielke]

[quoted lines by Peter Maydell on 2014/05/25 at 10:11 +0100]

>Ah, I see. Still, I think it makes more sense for the queue and delay
>to be in the common key handling code, not in the curses frontend
>specifically.

Yes, you're right. While the curses UI is especially vulnerable to the problem, 
others could be as well, especially if they're driven by a software "user" 
rather than by a human being. Also, who's to say that there won't be a new UI 
in the future which won't run into the same problem. I'll move the code and 
submit a new patch.

Given that this'll require a brand new option, could you please let me know all 
the places that'll need updating insofar as documentation is concerned?

-- 
Dave Mielke   | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario   | http://Mielke.cc/bible/
EMail: d...@mielke.cc | Canada  K2A 1H7   | http://FamilyRadio.com/

Re: [Qemu-devel] patch: add delay= suboption to -display curses

[Dave Mielke]

[quoted lines by Peter Maydell on 2014/05/25 at 10:11 +0100]

>Ah, I see. Still, I think it makes more sense for the queue and delay
>to be in the common key handling code, not in the curses frontend
>specifically.

The code has been moved. I can see a couple of possibilities insofar as an 
option for it is concerned. One is to extend the existing -k option to accept 
language= as an optional prefix for its currnet operand, and to add delay=. The 
other is to add a brand new -keydelay option. Which would be the better 
approach?

I'm assuming that qemu-options.hx is the only file that needs to be updated 
insofar as documentation is concerned. Is that correct?

-- 
Dave Mielke   | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario   | http://Mielke.cc/bible/
EMail: d...@mielke.cc | Canada  K2A 1H7   | http://FamilyRadio.com/

Re: [Qemu-devel] [Qemu-trivial] patch: add delay= suboption to -display curses

[Dave Mielke]

[quoted lines by Michael Tokarev on 2014/05/25 at 16:41 +0400]

>In addition to what Peter said, I think this suboption is named poorly.
>Maybe it can be named, say, kbddelay, or keydelay, or something like that.
>Just "delay" may be interpreted as _video_ delay, ie, delay updating picture
>for so many millisecs.  After all, this is -display, which is about video,
>and keyboard is a secondary function...

Yes, that makes good sense.

>Also, you still haven't told us what application is having problem with it,
>it is some mystery "some app".  

Where I ran into it is DJGPP termios input on MS-DOS.

>And provided this hasn't been a problem for so many years, 

Perhaps it hasn't been observed before because the curses UI may not have that 
many users. I myself must use it as, being blind, it's much easier for me to 
work in text mode than in graphics mode.

>maybe we shouldn't add it in the first place?

Given that this feature does resolve a problem, given that it's default retains 
the original behaviour, and given that we have no idea whatsoever regarding 
when the problem may strike again, my personal opinion is that implementing it 
now would be a reasonable thing to do, especially since the current situation 
is that no one is being asked to figure it out, code it, etc.

-- 
Dave Mielke   | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario   | http://Mielke.cc/bible/
EMail: d...@mielke.cc | Canada  K2A 1H7   | http://FamilyRadio.com/

Re: [Qemu-devel] [PATCH 1/8] virtio-gpu/2d: add hardware spec include file

[Dave Airlie]

On 15 October 2014 20:05, Gerd Hoffmann  wrote:
>   Hi,
>
>> +/* VIRTIO_GPU_RESP_OK_DISPLAY_INFO */
>> +#define VIRTIO_GPU_MAX_SCANOUTS 16
>> +struct virtio_gpu_resp_display_info {
>> +struct virtio_gpu_ctrl_hdr hdr;
>> +struct virtio_gpu_display_one {
>> +uint32_t enabled;
>> +uint32_t width;
>> +uint32_t height;
>> +uint32_t x;
>> +uint32_t y;
>> +uint32_t flags;
>> +} pmodes[VIRTIO_GPU_MAX_SCANOUTS];
>
> One more thing: I think it would be a good idea to add the display
> resolution here.  We start seeing highres displays on desktops, and the
> guest should know whenever the host display runs at 100 or 300 dpi ...
>
> What do you think?

Passing host display side into the guest isn't going to help, unless
you are running in full screen,

I suppose the guest could adjust the numbers, but what happens with
viewers, if I connect on a hidpi and move to a lodpi screen.

I think this would require a lot more thought in how it would work in
some use-cases.

That said reserving 2 32 bit fields for possible screen measurements
might future proof things a little, though most OSes use EDID to detect
this sort of thing, so we might not find a great use for it later.

Dave.

Re: [Qemu-devel] [PATCH 1/8] virtio-gpu/2d: add hardware spec include file

[Dave Airlie]

>
> Lets try to get away with 32bpp only in 2d mode then.
>
> bochsdrm likewise supports 32bpp only and I yet have to see a request
> for 16bpp or even 8bpp support.
>
>> I think we should probably move a few more formats from the 3D side
>> into the 2D side, so we can have the guests just pick the LE format
>> it requires
>>
>> http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/include/pipe/p_format.h#n354
>>
>> is what gallium currently does, and we could just provide XRGB, XBGR
>> formats in both endianness
>> and have the guest pick the one it wants to use.
>
>PIPE_FORMAT_R8G8B8A8_UNORM  = 67,
>PIPE_FORMAT_X8B8G8R8_UNORM  = 68,
>
>PIPE_FORMAT_A8B8G8R8_UNORM  = 121,
>PIPE_FORMAT_R8G8B8X8_UNORM  = 134,
>
> With the last two ones being in a /* TODO: re-order these */ block.
> How stable are these numbers?

In theory the mesa/gallium numbers aren't stable, though I've never
seen them change yet,

If they diverge in the future I'll just provide a remapping table
inside the guest driver.

So it should be fine to expose these formats for 2D use.

> Initially this doesn't matter much as the host will support only one
> endianness anyway.
>
> But in case we get the byteswapping work reasonable well some day and
> the host supports both be and le virgl we'll know that way which
> endianness the guest is using.
>
>> How do you test guests with big endian? Isn't it really slow?
>
> emulated pseries machine with fedora ppc64.  Yes, it is slow.  Building
> a kernel with virtio-gpu driver takes a day or so.

I spent a little while trying to get a ppc64 f20 install to complete, just
using the F20 qemu ppc64 system package but hit a bug I
think is related to missing SIMD instructions, so I'm not sure how best
to move forward with getting a test platform here.

Dave.

Re: [Qemu-devel] [virtio-dev] [PATCH 2/2] virtio-gpu/2d: add docs/specs/virtio-gpu.txt

[Dave Airlie]

>> Can the host refuse due to lack of resources?
>
> Yes.  virtgpu_ctrl_hdr.type in the response will be set to
> VIRTGPU_RESP_ERR_* then.  Current implementation does that only on
> malloc() failure, there is no accounting (yet) to limit the amout of
> memory the guest is allowed to allocate.

We do probably need to work out some sort of accounting system, it can
probably reliably only be a total value of resources, since we've no
idea if the host driver will store them in VRAM or main memory. Quite
how to fail gracefully is a question, probably need to report to the
guest what context did the allocation and see if we can destroy it.

>> > +
>> > +VIRTGPU_CMD_RESOURCE_INVAL_BACKING:
>> > +  Command: struct virtgpu_resource_inval_backing
>>
>> Why is it called INVAL_BACKING instead of DETACH_BACKING?  "Detach" is
>> logical since there is also an "attach" command.
>
> No particular reason I think.  Dave?
>

Not reason I can remember, I think I was thinking of having separate
inval and detach at one point, but it didn't really make any sense, so
renaming to detach is fine with me.

Dave.

Re: [Qemu-devel] [virtio-dev] [PATCH 0/2] virtio-gpu: hardware specification

[Dave Airlie]

On 12 September 2014 01:09, Gerd Hoffmann  wrote:
>   Hi folks,
>
> Lets kick off the virtio-gpu review process, starting with the virtio
> protocol.
>
> This is a tiny patch series for qemu.  Patch #1 carries the header file
> describing the virtual hardware: config space, command structs being
> sent over the rings, defines etc.  Patch #2 adds a text file describing
> virtio-gpu to docs/specs/.  It covers 2D support only for now.
>
> For anybody who wants to dig a bit deeper:  Here are the branches for
> qemu and the linux kernel:
>
>   https://www.kraxel.org/cgit/qemu/log/?h=rebase/vga-wip
>   https://www.kraxel.org/cgit/linux/log/?h=virtio-gpu-rebase
>
> The qemu patches are in a reasonable state.  The linux kernel patches
> are not cleaned up yet, you probably want to look at the final tree
> only.
>
> Work has been done by Dave Airlie  and me.  The
> authorship info in git got lost in the qemu patch cleanup process
> though.  Suggestions how to handle that best?  Simply add both mine
> and Dave's signed-off-by to all virtio-gpu qemu patches?  Is that fine
> with you Dave?  Anyone has better ideas?

I don't mind just adding a line in the commit msgs with Authors in it,
along with both signoffs.

Dave.

Re: [Qemu-devel] [virtio-dev] Re: [PATCH 2/2] virtio-gpu/2d: add docs/specs/virtio-gpu.txt

[Dave Airlie]

On 14 September 2014 19:16, Michael S. Tsirkin  wrote:
> On Thu, Sep 11, 2014 at 05:09:33PM +0200, Gerd Hoffmann wrote:
>> Signed-off-by: Gerd Hoffmann 
>> ---
>>  docs/specs/virtio-gpu.txt | 165 
>> ++
>>  1 file changed, 165 insertions(+)
>>  create mode 100644 docs/specs/virtio-gpu.txt
>
> Please don't put this hardware spec in QEMU.
> Contribute it to OASIS Virtio TC instead.
> If you need help with that, please let me know.

I think we'd be premature in putting this anywhere that isn't
alongside the code until we've addressed at least any resource
allocation or possible security concerns.

Dave.

[Qemu-devel] qemu - SCSI disk "Device Model", "Serial Number", and "Firmware Version"?

[Dave Seddon]

Greetings,

Just wondering if it would be difficult to add the ability to define the
SCSI disk "Device Model", "Serial Number", and "Firmware Version".  I've
been using the '-device lsi' successfully to emulate the LSI controller,
but now I want to emulate certain disks too.

e.g.  I've been using this:
---
...
-drive 
if=none,id=disk00,file=/home/das/documents/qemu/disk00.img.qcow,media=disk,cache=writeback
 \
-device lsi \
-device scsi-disk,drive=disk00,bus=scsi.0 \
...
---


The reason this would be really cool is that tools like smartmontools
seem to match on the "Device Model", and the device-model "QEMU" hasn't
made it into the list yet.

I found hunting around the net that somebody has tried to make this
work.  I'm not sure if it works.
'-drive ...,serial=xyz'



This is how the QEMU disks are currently seen in dmesg:
---
scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK0.12 PQ: 0
ANSI: 3
 target0:0:0: tagged command queuing enabled, command queue depth 16.
 target0:0:0: Beginning Domain Validation
 target0:0:0: Domain Validation skipping write tests
 target0:0:0: Ending Domain Validation
---

This is an example of a real disk, that I would like to 'fake':
---
scsi 2:0:0:0: Direct-Access ATA  ST3500320NS  SN06 PQ: 0 ANSI: 5
sd 2:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: 73 00 00 08
sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
sd 2:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: 73 00 00 08
sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
---


Here's an example of the nasty/QEMU output of smartmontools:
---
# smartctl -d sat --all /dev/sg0
smartctl version 5.38 [i686-spcdn-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Device Model: [No Information Found]
Serial Number:[No Information Found]
Firmware Version: �"
Device is:Not in smartctl database [for details use: -P showall]
ATA Version is:   1
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:Tue Jun  7 16:57:08 2011 UTC
SMART is only available in ATA Version 3 Revision 3 or greater.
We will try to proceed in spite of this.
SMART support is: Ambiguous - ATA IDENTIFY DEVICE words 82-83 don't show if 
SMART supported.
  Checking for SMART support by trying SMART ENABLE command.
  SMART ENABLE appeared to work!  Continuing.
SMART support is: Ambiguous - ATA IDENTIFY DEVICE words 85-87 don't show if 
SMART is enabled.
A mandatory SMART command failed: exiting. To continue, add one or more '-T 
permissive' options
---


Here's an example of the output of smartmontools from a real disk:
---
# smartctl -d sat --all /dev/sg1
smartctl version 5.38 [i686-spcdn-linux-gnu] Copyright (C) 2002-8 Bruce
Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Device Model: ST3500320NS <--- CAN WE SIMULATE THIS?
Serial Number:9QMCAMS6<--- AND THIS?
Firmware Version: SN06<--- AND THIS?
User Capacity:500,107,862,016 bytes
Device is:Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  ATA-8-ACS revision 4
Local Time is:Tue Jun  7 06:01:29 2011 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
---



Looking in the source, I can see that the "QEMU HARDDISK" for example is
statically defined.  Would this be difficult to make an option for the
'-drive '?
---
[root@tester hw]# grep -R 'QEMU' scsi-disk.c
QEMUIOVector qiov;
QEMUBH *bh;
memcpy(&outbuf[16], "QEMU CD-ROM ", 16);
memcpy(&outbuf[16], "QEMU HARDDISK   ", 16);
memcpy(&outbuf[8], "QEMU", 8);
s->version = qemu_strdup(QEMU_VERSION);
---

Kind regards,
Dave Seddon
d...@seddon.ca

Re: [Qemu-devel] qemu - SCSI disk "Device Model", "Serial Number", and "Firmware Version"?

[Dave Seddon]

Greetings,

Thanks for all the responses.

Overall it sounds like supporting this is capability would be fairly
easy.  However, Sadly for me it sounds like this won't be useful to
people generally unless they are trying to virtulize something that
relies on these codes. 

Answers to:

Paulo:

Statement:  Here we should perhaps try to improve the ATA emulation.
Response:  It would probably be helpful to improve both SCSI and ATA
emulation.


Markus:

Question:  That's not what I see.  What version of QEMU are you using?
Answer:  Using current package for Ubuntu 0.12.5 (that's probably a bad
word, give all the @redhat emails. sorry :) )  What do you see?  I did
download the source and check, hence the grep snippet.

Statement:  No.  Hardcoded to "QEMU HARDDISK   ".
Response:  Why couldn't this be a configuration item?

Thanks for your reference to: docs/qdev-device-use.txt
And also for the 'scsi-hd' example.  I can't see why, if the
"serial=S,ver=V" options are supported, that "model=" couldn't also be
added.  - I will try this.

Statement:  Doubt it would be difficult.  But would it be useful?
Agree with what your saying about specific calls, however, in my case
I'm trying to run a vendor supplied image which "only supports" certain
disks.  It is currently borking because it doesn't like the disks.  I
strongly doubt it does any disk specific calls.  They are doing this to
stop us installing disks bigger than 500GB, for example.  I'm trying to
make "appliance" software run virtually.


Kevin:
Q:  But this is scsi-disk - what does smartctl even try here?
A:  True.  SMART only applied to ATA.  I should not have included this
smartctl example, however the 'dmesg' output is still relevant.


----

Kind regards,
Dave Seddon

On Tue, 2011-06-07 at 17:04 +1000, Dave Seddon wrote:
> Greetings,
> 
> Just wondering if it would be difficult to add the ability to define the
> SCSI disk "Device Model", "Serial Number", and "Firmware Version".  I've
> been using the '-device lsi' successfully to emulate the LSI controller,
> but now I want to emulate certain disks too.
> 
> e.g.  I've been using this:
> ---
> ...
>   -drive 
> if=none,id=disk00,file=/home/das/documents/qemu/disk00.img.qcow,media=disk,cache=writeback
>  \
>   -device lsi \
>   -device scsi-disk,drive=disk00,bus=scsi.0 \
> ...
> ---
> 
> 
> The reason this would be really cool is that tools like smartmontools
> seem to match on the "Device Model", and the device-model "QEMU" hasn't
> made it into the list yet.
> 
> I found hunting around the net that somebody has tried to make this
> work.  I'm not sure if it works.
> '-drive ...,serial=xyz'
> 
> 
> 
> This is how the QEMU disks are currently seen in dmesg:
> ---
> scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK0.12 PQ: 0
> ANSI: 3
>  target0:0:0: tagged command queuing enabled, command queue depth 16.
>  target0:0:0: Beginning Domain Validation
>  target0:0:0: Domain Validation skipping write tests
>  target0:0:0: Ending Domain Validation
> ---
> 
> This is an example of a real disk, that I would like to 'fake':
> ---
> scsi 2:0:0:0: Direct-Access ATA  ST3500320NS  SN06 PQ: 0 ANSI: 5
> sd 2:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
> sd 2:0:0:0: [sda] Write Protect is off
> sd 2:0:0:0: [sda] Mode Sense: 73 00 00 08
> sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support 
> DPO or FUA
> sd 2:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
> sd 2:0:0:0: [sda] Write Protect is off
> sd 2:0:0:0: [sda] Mode Sense: 73 00 00 08
> sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support 
> DPO or FUA
> ---
> 
> 
> Here's an example of the nasty/QEMU output of smartmontools:
> ---
> # smartctl -d sat --all /dev/sg0
> smartctl version 5.38 [i686-spcdn-linux-gnu] Copyright (C) 2002-8 Bruce Allen
> Home page is http://smartmontools.sourceforge.net/
> 
> === START OF INFORMATION SECTION ===
> Device Model: [No Information Found]
> Serial Number:[No Information Found]
> Firmware Version: �

Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest

[Dave Anderson]

- Original Message -
> At 10/21/2011 03:11 PM, Jan Kiszka Write:
> > On 2011-10-20 12:03, Wen Congyang wrote:
> >> At 10/20/2011 05:41 PM, Jan Kiszka Write:
> >>> On 2011-10-20 03:22, Wen Congyang wrote:
> >>>>>> I didn't read full story but 'crash' is used for investigating kernel 
> >>>>>> core generated
> >>>>>> by kdump for several years. Considering support service guys, virsh 
> >>>>>> dump should support
> >>>>>> a format for crash because they can't work well at investigating 
> >>>>>> vmcore by gdb.
> >>>>>>
> >>>>>> crash has several functionality useful for them as 'show kerne log', 
> >>>>>> 'focus on a cpu'
> >>>>>> 'for-each-task', 'for-each-vma', 'extract ftrace log' etc.
> >>>>>>
> >>>>>> Anyway, if a man, who is not developper of qemu/kvm, should learn 2 
> >>>>>> tools for
> >>>>>> investigating kernel dump, it sounds harmful.
> >>>>>
> >>>>> Right, that's why everything (live debugging & crash analysis) should be
> >>>>> consolidated on the long run over gdb. crash is architecturally obsolete
> >>>>> today - not saying it is useless!
> >>>>
> >>>> I do not know why crash is obsoleted today. Is there a new better tool 
> >>>> to instead
> >>>> crash?
> >>>
> >>> I'm not aware of equally powerful (python) scripts for gdb as
> >>> replacement, but I think it's worth starting a porting effort at
> >>> some point.
> >>>
> >>>>
> >>>> At least, I always use crash to live debugging & crash analysis.
> >>>
> >>> Then you may answer some questions to me:
> >>>  - Can you attach to a remote target (kgdb, qemu, etc.) and how?
> >>
> >> No. crash's live debugging only can work the kernel is live. I can use it 
> >> get
> >> some var's value, or some other information from kernel. If kernel panics,
> >> we can use gdb to attach to a remote target as you said. But on end user 
> >> machine,
> >> we can not do it, we should dump the memory into a file and analyze it in 
> >> another
> >> machine while the end user's guest can be restart.
> >>
> >>>  - Can you use it with latest gdb versions or is the gdb functionality
> >>>hard-wired due to an embedded gdb core in crash (that's how I
> >>>understood Christoph's reply to this topic)
> >>
> >> If I use crash, I can not use latest gdb versions. Do we always need to use
> >> the latest gdb versions? Currently, gdb-7.0 is embedded into crash, and it
> >> is enough to me. If the gdb embedded into crash cannot anaylze the vmcore, 
> >> I
> >> think we can update it and rebuild crash.
> > 
> > crash is simply designed the wrong way around (from today's
> > perspective): it should augment upstream gdb instead of forking it.
> 
> Cc Dave Anderson. He knows how crash uses gdb.
> 
> I think that crash does not fork a task to execute gdb, and gdb is a
> part of crash.

I'm not sure what the question is, but you can consider crash as a huge
wrapper around its embedded gdb, which it invokes as "gdb vmlinux", and
then takes over the user interface.  It doesn't have a clue as to what
the memory source is, i.e., whether it's one of the almost 20 different
dumpfile formats that it supports (including "virsh dump"), or if it's
running against a live system.  It has its own command set, although
you can enter some gdb commands, write gdb scripts, etc.  But the main
purpose of the embedded gdb is for the crash-level sources to be able
to gather data structure information, disassemble text, add-symbol-file
kernel modules, and so on.  There is no kgdb remote linkage. 

It's currently embedding gdb-7.0, although as we speak I'm updating it
to gdb-7.3.1 because the compiler guys have decided that dwarf4 should be
used by default.

It would be kind of cool if there was a "/dev/mem"-like interface
to a KVM guest's physical memory, so that you could sit on a KVM host
and enter "crash vmlinux-of-guest /dev/mem-of-guest" in order to
run live analysis of a guest.

Anyway, sorry if it doesn't meet your needs...

Dave

Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest

[Dave Anderson]

- Original Message -

> The question is that: 'virsh dump' can not be used when host pci device
> is used by guest. We are discussing how to fix the problem. We have determined
> that introduce a new monitor command dump. Jan suggested that the core file's
> format is gdb standard core format. Does crash support such format?  If no,
> is it possible to support such format?

If you are talking about an ELF core dump of the user-space qemu-kvm process
running on the host, then it's certainly not supported.  

As to whether it's possible, I suppose it could be done if a phyical-memory-read
function could be created for it, similar to what I asked about for live 
analysis
of a guest kernel run on/from the KVM host.  

Dave
 

Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest

[Dave Anderson]

- Original Message -
> On 10/24/2011 04:25 PM, Dave Anderson wrote:
> > > The question is that: 'virsh dump' can not be used when host pci device
> > > is used by guest. We are discussing how to fix the problem. We have 
> > > determined
> > > that introduce a new monitor command dump. Jan suggested that the core 
> > > file's
> > > format is gdb standard core format. Does crash support such format?  If 
> > > no,
> > > is it possible to support such format?
> >
> > If you are talking about an ELF core dump of the user-space qemu-kvm process
> > running on the host, then it's certainly not supported.
> 
> No, an ELF image of the guest's physical memory.

Well then that should be pretty straight forward to support.  Depending upon
how similar it would be to the "standard" kdump ELF format, the only other
issue is how to determine the physical base address at which the kernel is
loaded, in order to be able to translate the mapped kernel-text/static-data
virtual region of the x86_64 arch (the __START_KERNEL_map region).
 
> > As to whether it's possible, I suppose it could be done if a 
> > phyical-memory-read
> > function could be created for it, similar to what I asked about for live 
> > analysis
> > of a guest kernel run on/from the KVM host.
> 
> We could use the gdb protocol for this.  Currently it reads/writes
> virtual memory, but we could extend the gdbserver command to make these
> commands apply to physical memory.

Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest

[Dave Anderson]

- Original Message -

> > > No, an ELF image of the guest's physical memory.
> >
> > Well then that should be pretty straight forward to support.  Depending upon
> > how similar it would be to the "standard" kdump ELF format, the only other
> > issue is how to determine the physical base address at which the kernel is
> > loaded, in order to be able to translate the mapped kernel-text/static-data
> > virtual region of the x86_64 arch (the __START_KERNEL_map region).
> >
> 
> I guess an elf note would work for that?

Right -- here is an example of a RHEL6 ELF kdump header:

$ readelf -a vmcore
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class: ELF64
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - System V
  ABI Version:   0
  Type:  CORE (Core file)
  Machine:   Advanced Micro Devices X86-64
  Version:   0x1
  Entry point address:   0x0
  Start of program headers:  64 (bytes into file)
  Start of section headers:  0 (bytes into file)
  Flags: 0x0
  Size of this header:   64 (bytes)
  Size of program headers:   56 (bytes)
  Number of program headers: 6
  Size of section headers:   0 (bytes)
  Number of section headers: 0
  Section header string table index: 0

There are no sections in this file.

There are no sections in this file.

Program Headers:
  Type   Offset VirtAddr   PhysAddr
 FileSizMemSiz  Flags  Align
  NOTE   0x0190 0x 0x
 0x083c 0x083c 0
  LOAD   0x09cc 0x8100 0x0100
 0x00ba3000 0x00ba3000  RWE0
  LOAD   0x00ba39cc 0x8100 0x
 0x000a 0x000a  RWE0
  LOAD   0x00c439cc 0x8110 0x0010
 0x01f0 0x01f0  RWE0
  LOAD   0x02b439cc 0x81000a00 0x0a00
 0xc5fc2840 0xc5fc2840  RWE0
  LOAD   0xc8b0620c 0x8101 0x0001
 0x3000 0x3000  RWE0

There is no dynamic section in this file.

There are no relocations in this file.

There are no unwind sections in this file.

No version information found in this file.

Notes at offset 0x0190 with length 0x083c:
  Owner Data size   Description
  CORE  0x0150  NT_PRSTATUS (prstatus structure)
  CORE  0x0150  NT_PRSTATUS (prstatus structure)
  VMCOREINFO0x055b  Unknown note type: (0x)
$

In this example, the phys_base (of zero) can be determined by looking 
at the first PT_LOAD segment, and comparing the PhysAddr and the VirtAddr
values -- given that __START_KERNEL_map region is based at 8.
The remaining physical memory chunks are described by the subsequent 
unity-mapped segments.

The NT_PRSTATUS notes are register dumps of each cpu, where this vmcore
was from a 2-cpu system.  But the crash utility is capable of surviving
without them.  It can also get by without the VMCOREINFO note, which is
primarily there for use by the "makedumpfile" utility, which is used to
compress ELF kdumps and filter out unwanted pages, and then make a different 
dumpfile format entirely.

This may be another stupid question -- but does the guest failure mode
render it incapable of using kdump?

Dave

Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest

[Dave Anderson]

- Original Message -
> On 10/25/2011 10:23 AM, Avi Kivity wrote:
> > On 10/25/2011 10:06 AM, Wen Congyang wrote:
> >> Hi, Avi Kivity, Dave Anderson
> >>
> >> I have two questions about it:
> >>
> >> 1. How to know the guest's physical base address in qemu?
> >
> > In fact, it's impossible.
> >
> > Perhaps crash can scan through the core looking for a signature.  Need
> > to be careful since multiple signatures may be detected (a kdump kernel,
> > a kernel image in pagecache, or a nested guest).
> 
> Crash uses a heuristic based on the IDT base to identify the base from
> migrate-to-file output.  It also needs CR3 in order to read from virtual
> address.

Just to clarify -- the need for the IDT base and cr3 is *only* true for 
KVM dumps using the "savevm" format.  

With ELF-format kdumps, the phys_base is simply determined from the PT_LOAD
segment that describes the kernel's __START_KERNEL_map region.  I don't know
why that couldn't be done in this proposed case.  
 
Dave

Re: [Qemu-devel] [RFC] dump memory when host pci device is used by guest

[Dave Anderson]

02  R15: 0030f8379780
> ORIG_RAX: 0001  CS: 0033  SS: 002b
> crash>
> 
> I wrote a sample(not finished). It only can works on x86_64(both host and 
> guest)
> I use it to create a core file:
> # readelf -h /tmp/vm2.save
> ELF Header:
>   Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
>   Class: ELF64
>   Data:  2's complement, little endian
>   Version:   1 (current)
>   OS/ABI:UNIX - System V
>   ABI Version:   0
>   Type:  CORE (Core file)
>   Machine:   Advanced Micro Devices X86-64
>   Version:   0x1
>   Entry point address:   0x0
>   Start of program headers:  64 (bytes into file)
>   Start of section headers:  0 (bytes into file)
>   Flags: 0x0
>   Size of this header:   64 (bytes)
>   Size of program headers:   56 (bytes)
>   Number of program headers: 9
>   Size of section headers:   0 (bytes)
>   Number of section headers: 0
>   Section header string table index: 0
> # readelf -l /tmp/vm2.save
> 
> Elf file type is CORE (Core file)
> Entry point 0x0
> There are 9 program headers, starting at offset 64
> 
> Program Headers:
>   Type   Offset VirtAddr   PhysAddr
>  FileSizMemSiz  Flags  Align
>   NOTE   0x0238 0x 0x
>  0x02c8 0x02c8 0
>   LOAD   0x0500 0x8100 0x0100
>  0x1f00 0x1f00 0
>   LOAD   0x1f000500 0x 0x
>  0x0100 0x0100 0
>   LOAD   0x2500 0x 0x2000
>  0x0002 0x0002 0
>   LOAD   0x20020500 0x 0x2087
>  0x0001 0x0001 0
>   LOAD   0x20030500 0x 0x2085
>  0x0002 0x0002 0
>   LOAD   0x20050500 0x 0x2084
>  0x0001 0x0001 0
>   LOAD   0x20060500 0x 0x2004
>  0x0080 0x0080 0
>   LOAD   0x20860500 0x 0x2002
>  0x0002 0x0002 0
> 
> I can use crash to anaylze the file, but I can not use gdb to anaylze it.
> # gdb /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux /tmp/vm2.save
> GNU gdb (GDB) Red Hat Enterprise Linux (7.2-48.el6)
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from
> /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux...done.
> [New ]
> [New ]
> #0  0x8103be8b in ?? ()
> (gdb) bt
> #0  0x8103be8b in ?? ()
> Cannot access memory at address 0x8170dec8
> (gdb) q
> 
> My first and the most important question is that: Is there necessary
> to continue this work?
> 
> The attachment is the sample patch.
> 
> Thanks
> Wen Congyang

>From an enterprise/support point of view, the wholesale replacement
of the current use of the savevm dumpfile format by "virsh dump" with
this ELF style format would be a *huge* improvement. 

Dave Anderson
 

[Qemu-devel] [Bug 393430] Re: kvm: use PulseAudio instead of ALSA

[Dave Walker]

The Debian big referenced suggested using ALSA over OSS, this bug is
related to favouring PA over ALSA.  The Debian issue was resolved with:

--- kvm-79+dfsg/debian/rules
+++ kvm-82+dfsg/debian/rules
@@ -141,7 +141,9 @@
 config.status: configure
dh_testdir
# Add here commands to configure the package.
-   ./configure --prefix=/usr
+   ./configure --prefix=/usr \
+--audio-drv-list="alsa oss sdl" \
+--audio-card-list="ac97 adlib cs4231a gus"
 
 
 build-arch: patch config.status build-arch-stamp


However, the current debian qemu-kvm package contains:
--audio-drv-list="alsa oss sdl pa" \
--audio-card-list="ac97 es1370 sb16 cs4231a adlib gus hda" \


Neither of these configure options are set in debian/rules.  This probably 
requires further investigation.

Thanks.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/393430

Title:
  kvm: use PulseAudio instead of ALSA

Status in QEMU:
  Incomplete
Status in “kvm” package in Ubuntu:
  Incomplete
Status in “kvm” package in Debian:
  Fix Released

Bug description:
  Binary package hint: kvm

  kvm in jaunty prefers to use OSS drivers rather than ALSA:
  # dpkg -l | grep kvm
  ii  kvm1:84+dfsg-0ubuntu11Full virtualization on i386 
and amd64 hardwa
  # kvm -audio-help | grep ^Name
  Name: oss
  Name: alsa
  Name: sdl
  Name: pa
  Name: none
  Name: wav
  #

  Because of that, once a virtual machine with working audio card
  starts, the kvm grabs the audio card entirely for itself. Any
  subsequent operations on audio card either from the host machine, or
  from the other audio-enabled virtual machines lock up (apparently
  awaiting on on access to the audio card).

  The bug is echo of the corresponding debian bug:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508018

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/393430/+subscriptions

Re: [Qemu-devel] multihead & multiseat in qemu

[Dave Airlie]

On Fri, Mar 21, 2014 at 11:27 PM, Gerd Hoffmann  wrote:
>   Hi,
>
> I'm thinking about how to handle multihead and multiseat in qemu best.
>
> On multihead:  Mouse in virtual machines works best with absolute
> coordinates, and the way this is done today is to assign a (virtual) usb
> tablet to the guest.  With multihead this becomes a bit difficuilt.
> Today we try to calculate the coordinates for the tablet that they cover
> all displays, which has a number of drawbacks.  I think it would be
> better to operate more like a touchscreen, i.e. have one touch input
> device for each monitor.  For that to work the guest must know which
> touch device belongs to which monitor.

Yeah I think I'm in agreement with this, one touch device per monitor,

> On multiseat:  Very simliar problem here (thats why both issues in one
> mail):  The guest needs to know which devices belong to which seat.
>
> Qemu needs the grouping/assignment information too, to the the input
> routing right (i.e. input from this window needs to go to that virtual
> input device etc).  Doing the configuration twice (once for qemu, once
> for the guest) and make sure they actually match would be annoying
> though.  So I think we should configure qemu only, then pass that
> information to the guest somehow.
>
> Question is how to do that best?

The GNOME guys have been working on auto config of touch devices,
I need to find who is doing that work and what they are triggering on,
since X just provides the devices currently, I think we might need some agent
in the guest for this.

>
> I'd like to have some way to assign tags such as seat=foo or head=1 to
> devices.  Preferably in some way which can easily picked up with udev
> rules, so it is easily usable by system-logind and Xorg server.

The only current example of seat autoconfiguration is for the usb hubs
from displaylink I think, which have video/audio/ethernet/usb behind a
hub that udev detects as being part of a seat, I'd need to look up the
specifics,

> We have virtio devices (virtio-gpu for example).  For these it is easy,
> we can put something into the virtio protocol, and the guest driver can
> create a sysfs file where udev/systemd can pick it up.
>
> We have pci devices (cirrus for example).  One idea for them would be to
> create a vendor-specific pci capabiliy for tags.  Probably needs some
> small utility to read them, or kernel driver support to export them via
> sysfs.
>
> We have usb devices (kbd/mouse/tablet).  We could put something into the
> string table, or have some vendor-specific descriptor.  Same problem
> here, not easy accessible, needs a tool or kernel support.
>
> Comments?  Better ideas?  Other suggestions?

It does seems like tagging the devices somehow would be better than providing
a seat device, like we could in theory have a pci and usb controller
per seat, and
have devices move around between them, this would be like what we for
the real hw,
however per-device tags does look like it might be nicer in the long run.

Dave.

[Qemu-devel] updated virtio-gpu code

[Dave Airlie]

Hey,

I've pushed a new version of the unaccelerated virtio-gpu code to my repo

git://git.freedesktop.org/~airlied/qemu virtio-gpu

this is Gerd vga-wip branch, with the virtgpu_hw file moved, removing
the event queue and a config space added with a events_read,
events_clear u32.

I've also pushed the changes to the kms driver to use this,
http://cgit.freedesktop.org/~airlied/linux/log/?h=virtio-vga-3d

Gerd, I've also dropped my experimental config space hacks and pushed
the two pci/vga fixes into that branch as well.

Just out of interest, with sdl and remote-viewer I seem to get 2
displays, one for the VGA time, and a separate one for the driver
loaded, any ideas why?

Dave.

Re: [Qemu-devel] updated virtio-gpu code

[Dave Airlie]

>
> Just out of interest, with sdl and remote-viewer I seem to get 2
> displays, one for the VGA time, and a separate one for the driver
> loaded, any ideas why?

Ah this seems to be an artefact of my libvirt xml which demands I add
a non-virtio vga device, thanks strict parser!

Dave.

Re: [Qemu-devel] [PATCH 7/8] virtio-vga: v1

[Dave Airlie]

On Fri, Dec 6, 2013 at 6:58 PM, Dave Airlie  wrote:
> On Fri, Dec 6, 2013 at 6:24 PM, Gerd Hoffmann  wrote:
>>   Hi,
>>
>>> Now the advice given was to have virtio-vga wrap virtio-gpu-base but
>>> from what I can see it really can't. Since it needs to act and look
>>> like a PCI device
>>
>> Oops, yes.  VirtIOPCIProxy wasn't on my radar.  That makes things a bit
>> more messy.  Can you just push what you have now somewhere?  I'll take a
>> closer look next week.
>
> http://cgit.freedesktop.org/~airlied/qemu/log/?h=virtio-gpu-inherit
>
> Well I didn't really get anything working, but the top commit in that
> branch was where I was on my last random fail.
>
> I think another object is probably required, or making the base one
> not abstract.
>
Hi Gerd,

just repinging on this, not sure if you can see a solution that works
with VirtIOPCIProxy that avoids wrapping.

Dave.

Re: [Qemu-devel] input, virtio-vga & multihead -- current state

[Dave Airlie]

On Thu, Jan 30, 2014 at 2:28 AM, Gerd Hoffmann  wrote:
>>  * Didn't came very far in testing.  Guest kernel just says:
>>[   50.712897] [drm] got -2147483647 outputs
>>I've used
>>http://cgit.freedesktop.org/~airlied/linux/log/?h=virtio-vga
>
> Switched to virtio-vga-3d branch -- that is working better.  Handover
> from vesafb to virtio-vga drm driver doesn't work though ...
>

Excellent, I'm a bit snowed under in non-virgl work at the moment,
hoping next week
to pick myself back into the virt world,

This look good to me and yes virtio-vga-3d is the branch the other one I need
to probably kill with fire, I'll apply your patch to it to fix the handover.

I'll try and get this stuff running here to play around with.

Dave.

[Qemu-devel] gpu and console chicken and egg

[Dave Airlie]

So I've hit a bit of a init ordering issue that I'm not sure how best to solve,

Just some background:
In order for the virt GPU and the UI layer (SDL or GTK etc) to
interact properly over OpenGL use, I have created and OpenGL provider
in the console, and the UI layer can register callbacks for a single
GL provider (only one makes sense really) when it starts up. This is
mainly to be used for context management and swap buffers management.

Now in the virtio GPU I'd was going to use a virtio feature to say
whether the qemu hw can support the 3D renderer, dependant on whether
it was linked with the virgl renderer and whether the current UI was
GL capable.

I also have the virtio gpu code checking in its update_display
callback whether the first console has acquired a GL backend.

Now the problem:
The virtio hw is initialised before the console layers. So the feature
bits are all set at that point, before the UI ever registers a GL
interface layer. So is there a method to modify the advertised feature
bits later in the setup sequence before the guest is started? Can I
call something from the update display callback?

Otherwise I was thinking I would need something in my config space on
top of feature bits to say the hw is actually 3d capable.

Dave.

Re: [Qemu-devel] gpu and console chicken and egg

[Dave Airlie]

On Wed, Dec 4, 2013 at 6:23 PM, Gerd Hoffmann  wrote:
> On Mi, 2013-12-04 at 17:02 +1000, Dave Airlie wrote:
>> So I've hit a bit of a init ordering issue that I'm not sure how best to 
>> solve,
>>
>> Just some background:
>> In order for the virt GPU and the UI layer (SDL or GTK etc) to
>> interact properly over OpenGL use, I have created and OpenGL provider
>> in the console, and the UI layer can register callbacks for a single
>> GL provider (only one makes sense really) when it starts up. This is
>> mainly to be used for context management and swap buffers management.
>>
>> Now in the virtio GPU I'd was going to use a virtio feature to say
>> whether the qemu hw can support the 3D renderer, dependant on whether
>> it was linked with the virgl renderer and whether the current UI was
>> GL capable.
>
> Hmm, why does it depend on the UI?  Wasn't the plan to render into a
> dma-buf no matter what?  Then either read the rendered result from the
> dmabuf (non-gl UI like vnc) or let the (gl-capable) UI pass the dma-buf
> to the compositor?

That would be the hopeful plan, however so far my brief investigation says
I'm possibly being a bit naive with what EGL can do. I'm still talking to the
EGL and wayland people about how best to model this, but either way
this won't work with nvidia drivers which is a case we need to handle, so
we need to interact between the UI GL usage and the renderer. Also
non-Linux platforms would want this in some way I'd assume, at least
so virtio-gpu is usable with qemu on them.

I've started looking at how to integrate GL with the gtk frontend as well.

> Also note that the virtio-gpu gl-capability needs to be configurable for
> live migration reasons, so you can migrate between hosts with different
> 3d capabilities.  Something like -device
> virtio-gpu,gl={none,gl2,gl3,host} where "none" turns it off, "gl
> $version" specifies the gl support level and "host" makes it depend on
> the host capabilities (simliar to -cpu host).  For starters you can
> leave out "host" and depend on the user set this.

GL isn't that simple, and I'm not sure I can make it that simple unfortunately,
the renderer requires certain extensions on top of the base GL 2.1 and GL3.0.
live migration with none might be the first answer, and then we'd have to expend
serious effort on making live migration work for any sort of different
GL drivers.
Reading everything back while renderering continues could be a lot of
fun. (or pain).

>> So is there a method to modify the advertised feature
>> bits later in the setup sequence before the guest is started?
>
> You can register a callback to be notified when the guest is
> started/stopped (qemu_add_vm_change_state_handler).  That could be used
> although it is a bit hackish.

I don't think this will let me change the feature bits though since the virtio
PCI layer has already picked them up I think. I just wondered if we have any
examples of changing features later.

>
> PS: Now that 1.7 is out of the door and 2.0 tree is open for development
> we should start getting the bits which are ready merged to make your
> patch backlog smaller.  SDL2 would be a good start I think.
>

I should probably resubmit the multi-head changes and SDL2 changes and
we should look at merging them first. The input thing is kind off up in the
air, we could probably just default to using hints from the video setup,
and move towards having an agent do it properly in the guest.

I've just spent a week reintegrating virtio-gpu with the 3D renderer so I can
make sure I haven't backed myself into a corner, it kinda leaves 3 major things
outstanding:

a) dma-buf/EGL, EGLimage vs EGLstream, nothing exists upstream, so
unknown timeframe.
I don't think we should block merging on this, also dma-buf doesn't
exist on Windows/MacOSX
so qemu there should still get virtio-gpu available.

b) dataplane - I'd really like this, the renderer is a lot slower when
its not in a thread, and it
looks bad on benchmarks. I expect other stuff needs to happen before this.

c) GTK multi-head + GL support - I'd like to have the GTK UI be able
for multi-head as well
my first attempt moved a lot of code around, I'm not really sure what
the secondary head
windows should contain vs the primary head.

Dave.

Re: [Qemu-devel] gpu and console chicken and egg

[Dave Airlie]

On Thu, Dec 5, 2013 at 6:52 PM, Gerd Hoffmann  wrote:
>   Hi,
>
>> > Hmm, why does it depend on the UI?  Wasn't the plan to render into a
>> > dma-buf no matter what?  Then either read the rendered result from the
>> > dmabuf (non-gl UI like vnc) or let the (gl-capable) UI pass the dma-buf
>> > to the compositor?
>>
>> That would be the hopeful plan, however so far my brief investigation says
>> I'm possibly being a bit naive with what EGL can do. I'm still talking to the
>> EGL and wayland people about how best to model this, but either way
>> this won't work with nvidia drivers which is a case we need to handle, so
>> we need to interact between the UI GL usage and the renderer.
>
> Hmm.  That implies we simply can't combine hardware-accelerated 3d
> rendering with vnc, correct?

For SDL + spice/vnc I've added a readback capabilty to the renderer,
and hooked things up if there is > 1 DisplayChangeListener then it'll
do readbacks, and keep the surface updated, this slows things down,
but it does work.

but yes it means we can't just run the qemu process in its sandbox
without a connection to the X server for it to do GL rendering, or
without using SDL,

I don't think we should block merging the initial code on this, it was
always a big problem on its own that needed solving.

>> GL isn't that simple, and I'm not sure I can make it that simple 
>> unfortunately,
>> the renderer requires certain extensions on top of the base GL 2.1 and GL3.0.
>> live migration with none might be the first answer, and then we'd have to 
>> expend
>> serious effort on making live migration work for any sort of different
>> GL drivers.
>> Reading everything back while renderering continues could be a lot of
>> fun. (or pain).
>
> We probably want to start with gl={none,host} then.  Live migration only
> supported with "none".
>
> If we can't combine remote displays with 3d rendering (nvidia issue
> above) live migration with 3d makes little sense anyway.

Well we can, we just can't do it without also having a local display
connection, but yes it does limit the migration capabilities quite a
lot!

>> I don't think this will let me change the feature bits though since the 
>> virtio
>> PCI layer has already picked them up I think. I just wondered if we have any
>> examples of changing features later.
>
> I think you can.  There are no helper functions for it though, you
> probably have to walk the data structures and fiddle with the bits
> directly.
>
> Maybe it is easier to just have a command line option to enable/disable
> 3d globally, and a global variable with the 3d status.  Being able to
> turn off all 3d is probably useful anyway.  Either as standalone option
> or as display option (i.e. -display sdl,3d={on,off,auto}).  Then do a
> simple check for 3d availability when *parsing* the options.  That'll
> also remove the need for the 3d option for virtio-gpu, it can just check
> the global flag instead.

Ah yes that might work, and just fail if we request 3D but can't fulfil it.
>
>> I should probably resubmit the multi-head changes and SDL2 changes and
>> we should look at merging them first.
>

I've got some outstanding things to redo on the virtio-gpu/vga bits, then I'll
resubmit the sdl2 and unaccelerated virtio-gpu bits.

Dave.

Re: [Qemu-devel] [PATCH 7/8] virtio-vga: v1

[Dave Airlie]

On Thu, Nov 21, 2013 at 9:06 PM, Gerd Hoffmann  wrote:
> On Do, 2013-11-21 at 13:12 +1000, Dave Airlie wrote:
>> On Wed, Nov 20, 2013 at 10:02 PM, Gerd Hoffmann  wrote:
>> > On Mi, 2013-11-20 at 15:52 +1000, Dave Airlie wrote:
>> >> From: Dave Airlie 
>> >>
>> >> This is a virtio-vga device built on top of the virtio-gpu device.
>> >
>> > Ah, I see what you use the wrapping for.  Hmm.  I think you should use a
>> > common base class instead, i.e. something like virtio-gpu-base which
>> > holds all the common stuff.  Both virtio-gpu and virtio-vga can use that
>> > as TypeInfo->parent then.  This way virtio-vga doesn't have to muck with
>> > virtio-gpu internals.  virtio-gpu-base can be tagged as abstract class
>> > (using .abstract = true) so it will not be instantiated directly.
>> >
>>
>> I'm not sure what that buys me here, I need the virtio-vga to attach
>> the vga ops the first console that the virtio-gpu registers, it can't
>> be a separate console, and since virtio-gpu initialises before
>> virtio-vga I can't tell it to not register the console.
>
> virtio-gpu-core registers no consoles.  It just export the hw_ops
> functions.   virtio-gpu-core inly initializes the stuff which is
> identical for both virtio-gpu and virtio-vga, everything else is left to
> the init functions of the subclasses.
>
> virtio-gpu uses virtio-gpu-core as parent.  Registers the the consoles,
> using the hw_ops functions exported by virtio-gpu-core.  Also sets the
> pci class to DISPLAY_OTHER.
>
> virtio-vga uses virtio-gpu-core as parent too.  Registers the consoles,
> using functions basically doing "if vgamode then call vga hw_ops else
> call virtio-gpu-core hw_ops".  Simliar to what you have today but
> without the funky wrapping.  Sets pci class to DISPLAY_VGA and
> initializes vga stuff.
>
> cheers,
>   Gerd

Okay I'm really missing something here and I think I've confused
myself completely.

My plan was

virtio-gpu-base - VirtIOGPUBase object - VirtIODevice parent_obj -
abstract class - contains vqs + exposes ops

virtio-gpu - virtio-gpu-base wrapper with init sequence for non-VGA
virtio gpus (mmio + pci)
virtio-gpu-pci - VirtIOPCIProxy parent_obj - contains a VirtIOGPU vdev
that it instantiates in its instance init like all the PCI wrappers

Now the advice given was to have virtio-vga wrap virtio-gpu-base but
from what I can see it really can't. Since it needs to act and look
like a PCI device

virtio-vga: Also has a VirtIOPCIProxy parent_obj, however as
virtio-gpu-base is abstract I can't directly instantiate it, and I
can't instantiate virtio-gpu as its the wrong thing,

so do I really need to add another class? rename virtio-vga to
virtio-pci-vga and add a new virtio-vga that just wraps
virtio-gpu-base?

This is getting a lot messier than the code I had, and the benefits
are escaping me, which must mean I'm misinterpreting the instructions
given.

This then led to another question how do I call the virtio-gpu-base
init functions? directly? as I can't use qdev as they are abstract
from what I can see.

Dave.

Re: [Qemu-devel] [PATCH 7/8] virtio-vga: v1

[Dave Airlie]

On Fri, Dec 6, 2013 at 6:24 PM, Gerd Hoffmann  wrote:
>   Hi,
>
>> Now the advice given was to have virtio-vga wrap virtio-gpu-base but
>> from what I can see it really can't. Since it needs to act and look
>> like a PCI device
>
> Oops, yes.  VirtIOPCIProxy wasn't on my radar.  That makes things a bit
> more messy.  Can you just push what you have now somewhere?  I'll take a
> closer look next week.

http://cgit.freedesktop.org/~airlied/qemu/log/?h=virtio-gpu-inherit

Well I didn't really get anything working, but the top commit in that
branch was where I was on my last random fail.

I think another object is probably required, or making the base one
not abstract.

Dave.

[Qemu-devel] gtk3 mouse warping

[Dave Airlie]

does the gtk3 mouse warping work for anyone else?

I've just been testing with gtk3 + virtio-vga and the mouse seems to
bounce around a lot off the edges of the window, but never make it
into it.

Dave.

Re: [Qemu-devel] gtk3 mouse warping

[Dave Airlie]

On Mon, Dec 9, 2013 at 10:49 AM, Dave Airlie  wrote:
> does the gtk3 mouse warping work for anyone else?
>
> I've just been testing with gtk3 + virtio-vga and the mouse seems to
> bounce around a lot off the edges of the window, but never make it
> into it.

It appears to be an issue with cursor hotspot offsets only, which might
explain why nobody else has seen it yet.

Dave.

Re: [Qemu-devel] gtk3 mouse warping

[Dave Airlie]

On Mon, Dec 9, 2013 at 1:54 PM, Dave Airlie  wrote:
> On Mon, Dec 9, 2013 at 10:49 AM, Dave Airlie  wrote:
>> does the gtk3 mouse warping work for anyone else?
>>
>> I've just been testing with gtk3 + virtio-vga and the mouse seems to
>> bounce around a lot off the edges of the window, but never make it
>> into it.
>
> It appears to be an issue with cursor hotspot offsets only, which might
> explain why nobody else has seen it yet.

Oops ignore me, looks like a virtio-gpu bug, I just didn't notice
before with SDL.

Dave.

[Qemu-devel] [PATCH 1/2] gtk: don't warp point in absolute mode

[Dave Airlie]

From: Dave Airlie 

This makes gtk act the same way as the current sdl backend, which doesn't
do the warp in this case.

If your guest GPU has hw pointer this leads you get endless loops where the
warp causes motion causes input events, causes the guest to move the cursor
causes warp.

Signed-off-by: Dave Airlie 
---
 ui/gtk.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/ui/gtk.c b/ui/gtk.c
index 6316f5b..2abf289 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -338,6 +338,9 @@ static void gd_mouse_set(DisplayChangeListener *dcl,
 GdkDeviceManager *mgr;
 gint x_root, y_root;
 
+if (kbd_mouse_is_absolute())
+   return;
+
 dpy = gtk_widget_get_display(s->drawing_area);
 mgr = gdk_display_get_device_manager(dpy);
 gdk_window_get_root_coords(gtk_widget_get_window(s->drawing_area),
-- 
1.8.3.1

[Qemu-devel] [PATCH 2/2] gtk: respect cursor visibility

[Dave Airlie]

From: Dave Airlie 

If the guest asks for no cursor, switch gtk to using the null cursor.

Signed-off-by: Dave Airlie 
---
 ui/gtk.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/ui/gtk.c b/ui/gtk.c
index 2abf289..f60e66f 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -158,6 +158,8 @@ typedef struct GtkDisplayState
 bool external_pause_update;
 
 bool modifier_pressed[ARRAY_SIZE(modifier_keycode)];
+
+GdkCursor *current_cursor;
 } GtkDisplayState;
 
 static GtkDisplayState *global_state;
@@ -338,6 +340,11 @@ static void gd_mouse_set(DisplayChangeListener *dcl,
 GdkDeviceManager *mgr;
 gint x_root, y_root;
 
+if (!visible)
+   gdk_window_set_cursor(gtk_widget_get_window(s->drawing_area), 
s->null_cursor);
+else
+   gdk_window_set_cursor(gtk_widget_get_window(s->drawing_area), 
s->current_cursor);
+
 if (kbd_mouse_is_absolute())
return;
 
@@ -369,21 +376,23 @@ static void gd_cursor_define(DisplayChangeListener *dcl,
 {
 GtkDisplayState *s = container_of(dcl, GtkDisplayState, dcl);
 GdkPixbuf *pixbuf;
-GdkCursor *cursor;
+
+if (s->current_cursor) {
+#if !GTK_CHECK_VERSION(3, 0, 0)
+gdk_cursor_unref(s->current_cursor);
+#else
+g_object_unref(s->current_cursor);
+#endif
+s->current_cursor = NULL;
+}
 
 pixbuf = gdk_pixbuf_new_from_data((guchar *)(c->data),
   GDK_COLORSPACE_RGB, true, 8,
   c->width, c->height, c->width * 4,
   NULL, NULL);
-cursor = 
gdk_cursor_new_from_pixbuf(gtk_widget_get_display(s->drawing_area),
+s->current_cursor = 
gdk_cursor_new_from_pixbuf(gtk_widget_get_display(s->drawing_area),
 pixbuf, c->hot_x, c->hot_y);
-gdk_window_set_cursor(gtk_widget_get_window(s->drawing_area), cursor);
 g_object_unref(pixbuf);
-#if !GTK_CHECK_VERSION(3, 0, 0)
-gdk_cursor_unref(cursor);
-#else
-g_object_unref(cursor);
-#endif
 }
 
 static void gd_switch(DisplayChangeListener *dcl,
-- 
1.8.3.1

[Qemu-devel] gtk cursor patches

[Dave Airlie]

These were just fallout fixes from exploring gtk multi-head with virtio-gpu,

hopefully they are useful to people before then, not sure if the 
warping/absolute interaction is defined or not.

Dave.

[Qemu-devel] [PATCH 5/8] console: add ability to wrap a console.

[Dave Airlie]

From: Dave Airlie 

In order to implement virtio-vga on top of virtio-gpu we need
to be able to wrap the first console virtio-gpu registers from
inside virtio-vga which initialises after virtio-gpu. With this
interface virtio-vga can store the virtio-gpu interfaces, and
call them from its own ones.

Signed-off-by: Dave Airlie 
---
 include/ui/console.h |  7 +++
 ui/console.c | 13 +
 2 files changed, 20 insertions(+)

diff --git a/include/ui/console.h b/include/ui/console.h
index f6e8957..2ad9238 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -285,6 +285,13 @@ QemuConsole *graphic_console_init(DeviceState *dev,
   const GraphicHwOps *ops,
   void *opaque);
 
+void graphic_console_wrap(QemuConsole *con,
+ DeviceState *dev,
+ const GraphicHwOps *ops,
+ void *opaque,
+  const GraphicHwOps **orig_ops,
+  void **orig_opaque);
+
 void graphic_hw_update(QemuConsole *con);
 void graphic_hw_invalidate(QemuConsole *con);
 void graphic_hw_text_update(QemuConsole *con, console_ch_t *chardata);
diff --git a/ui/console.c b/ui/console.c
index def11ea..f2d6721 100644
--- a/ui/console.c
+++ b/ui/console.c
@@ -1619,6 +1619,19 @@ QemuConsole *graphic_console_init(DeviceState *dev,
 return s;
 }
 
+void graphic_console_wrap(QemuConsole *con,
+ DeviceState *dev,
+ const GraphicHwOps *hw_ops,
+ void *opaque,
+  const GraphicHwOps **orig_ops,
+  void **orig_opaque)
+{
+*orig_opaque = con->hw;
+*orig_ops = con->hw_ops;
+con->hw_ops = hw_ops;
+con->hw = opaque;
+}
+
 QemuConsole *qemu_console_lookup_by_index(unsigned int index)
 {
 if (index >= MAX_CONSOLES) {
-- 
1.8.3.1

[Qemu-devel] [RFC] sdl2 + virtio-gpu repost

[Dave Airlie]

Hi,

This is a repost of the latest SDL2 UI layer along with virtio-gpu,

I've merged the SDL2 base and multi-head patches into one, and I've split
out the display notifiers stuff and the sdl2 demo hack.

The virtio-gpu/vga wrapping is still unresolved, I've failed to find a cleaner
way yet, hopefully Gerd will advise further, but having 4 virtio-gpu- objects
we getting ugly fast. I've also included a doc on the basic queues used in the
virtio-gpu and what commands are sent on them.

I'd really like to get the sdl2 base patch merged at least,

Dave.

[Qemu-devel] [PATCH 1/8] ui/sdl2 : initial port to SDL 2.0 (v2.0)

[Dave Airlie]

From: Dave Airlie 

I've ported the SDL1.2 code over, and rewritten it to use the SDL2 interface.

The biggest changes were in the input handling, where SDL2 has done a major
overhaul, and I've had to include a generated translation file to get from
SDL2 codes back to qemu compatible ones. I'm still not sure how the keyboard
layout code works in qemu, so there may be further work if someone can point
me a test case that works with SDL1.2 and doesn't with SDL2.

Some SDL env vars we used to set are no longer used by SDL2,
Windows, OSX support is untested,

I don't think we can link to SDL1.2 and SDL2 at the same time, so I felt
using --with-sdlabi=2.0 to select the new code should be fine, like how
gtk does it.

v1.1: fix keys in text console
v1.2: fix shutdown, cleanups a bit of code, support ARGB cursor

v2.0: merge the SDL multihead patch into this, g_new the number of consoles
needed, wrap DCL inside per-console structure.

Signed-off-by: Dave Airlie 
---
 configure|  23 +-
 ui/Makefile.objs |   4 +-
 ui/sdl.c |   3 +
 ui/sdl2.c| 981 +++
 ui/sdl2_scancode_translate.h | 260 
 ui/sdl_keysym.h  |   3 +-
 6 files changed, 1267 insertions(+), 7 deletions(-)
 create mode 100644 ui/sdl2.c
 create mode 100644 ui/sdl2_scancode_translate.h

diff --git a/configure b/configure
index 0666228..3b7490d 100755
--- a/configure
+++ b/configure
@@ -171,6 +171,7 @@ docs=""
 fdt=""
 pixman=""
 sdl=""
+sdlabi="1.2"
 virtfs=""
 vnc="yes"
 sparse="no"
@@ -322,6 +323,7 @@ query_pkg_config() {
 }
 pkg_config=query_pkg_config
 sdl_config="${SDL_CONFIG-${cross_prefix}sdl-config}"
+sdl2_config="${SDL2_CONFIG-${cross_prefix}sdl2-config}"
 
 # If the user hasn't specified ARFLAGS, default to 'rv', just as make does.
 ARFLAGS="${ARFLAGS-rv}"
@@ -727,6 +729,8 @@ for opt do
   ;;
   --enable-sdl) sdl="yes"
   ;;
+  --with-sdlabi=*) sdlabi="$optarg"
+  ;;
   --disable-qom-cast-debug) qom_cast_debug="no"
   ;;
   --enable-qom-cast-debug) qom_cast_debug="yes"
@@ -1113,6 +1117,7 @@ echo "  --disable-strip  disable stripping 
binaries"
 echo "  --disable-werror disable compilation abort on warning"
 echo "  --disable-sdldisable SDL"
 echo "  --enable-sdl enable SDL"
+echo "  --with-sdlabiselect preferred SDL ABI 1.2 or 2.0"
 echo "  --disable-gtkdisable gtk UI"
 echo "  --enable-gtk enable gtk UI"
 echo "  --disable-virtfs disable VirtFS"
@@ -1781,12 +1786,22 @@ fi
 
 # Look for sdl configuration program (pkg-config or sdl-config).  Try
 # sdl-config even without cross prefix, and favour pkg-config over sdl-config.
-if test "`basename $sdl_config`" != sdl-config && ! has ${sdl_config}; then
-  sdl_config=sdl-config
+
+if test $sdlabi == "2.0"; then
+sdl_config=$sdl2_config
+sdlname=sdl2
+sdlconfigname=sdl2_config
+else
+sdlname=sdl
+sdlconfigname=sdl_config
+fi
+
+if test "`basename $sdl_config`" != $sdlconfigname && ! has ${sdl_config}; then
+  sdl_config=$sdlconfigname
 fi
 
-if $pkg_config sdl --exists; then
-  sdlconfig="$pkg_config sdl"
+if $pkg_config $sdlname --exists; then
+  sdlconfig="$pkg_config $sdlname"
   _sdlversion=`$sdlconfig --modversion 2>/dev/null | sed 's/[^0-9]//g'`
 elif has ${sdl_config}; then
   sdlconfig="$sdl_config"
diff --git a/ui/Makefile.objs b/ui/Makefile.objs
index f33be47..721ad37 100644
--- a/ui/Makefile.objs
+++ b/ui/Makefile.objs
@@ -9,12 +9,12 @@ vnc-obj-y += vnc-jobs.o
 
 common-obj-y += keymaps.o console.o cursor.o input.o qemu-pixman.o
 common-obj-$(CONFIG_SPICE) += spice-core.o spice-input.o spice-display.o
-common-obj-$(CONFIG_SDL) += sdl.o sdl_zoom.o x_keymap.o
+common-obj-$(CONFIG_SDL) += sdl.o sdl_zoom.o x_keymap.o sdl2.o
 common-obj-$(CONFIG_COCOA) += cocoa.o
 common-obj-$(CONFIG_CURSES) += curses.o
 common-obj-$(CONFIG_VNC) += $(vnc-obj-y)
 common-obj-$(CONFIG_GTK) += gtk.o x_keymap.o
 
-$(obj)/sdl.o $(obj)/sdl_zoom.o: QEMU_CFLAGS += $(SDL_CFLAGS) 
+$(obj)/sdl.o $(obj)/sdl_zoom.o $(obj)/sdl2.o: QEMU_CFLAGS += $(SDL_CFLAGS) 
 
 $(obj)/gtk.o: QEMU_CFLAGS += $(GTK_CFLAGS) $(VTE_CFLAGS)
diff --git a/ui/sdl.c b/ui/sdl.c
index 9d8583c..736bb95 100644
--- a/ui/sdl.c
+++ b/ui/sdl.c
@@ -26,6 +26,8 @@
 #undef WIN32_LEAN_AND_MEAN
 
 #include 
+
+#if SDL_MAJOR_VERSION == 1
 #include 
 
 #include "qemu-common.h"
@@ -966,3 +968,4 @@ void sdl_display_init(DisplayState *ds, int full_screen, 
int no_frame)
 
 atexit(sdl_cleanup);
 }
+#endif
diff --git a/ui/sdl2.c b/ui/sdl2.c
new file mode 100644
ind

[Qemu-devel] [PATCH 2/8] console: add state notifiers for ui<->display

[Dave Airlie]

From: Dave Airlie 

These are to be used for the UI to signal the video display,
and vice-versa about changes in the state of a console, like
size and offsets in relation to other consoles for input handling.

Signed-off-by: Dave Airlie 
---
 include/ui/console.h |  8 +++-
 ui/console.c | 26 ++
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/include/ui/console.h b/include/ui/console.h
index 4156a87..f6e8957 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -173,6 +173,9 @@ typedef struct DisplayChangeListenerOps {
   int x, int y, int on);
 void (*dpy_cursor_define)(DisplayChangeListener *dcl,
   QEMUCursor *cursor);
+
+void (*dpy_notify_state)(DisplayChangeListener *dcl,
+int x, int y, uint32_t width, uint32_t height);
 } DisplayChangeListenerOps;
 
 struct DisplayChangeListener {
@@ -223,7 +226,8 @@ void dpy_text_resize(QemuConsole *con, int w, int h);
 void dpy_mouse_set(QemuConsole *con, int x, int y, int on);
 void dpy_cursor_define(QemuConsole *con, QEMUCursor *cursor);
 bool dpy_cursor_define_supported(QemuConsole *con);
-
+void dpy_notify_state(QemuConsole *con, int x, int y,
+  uint32_t width, uint32_t height);
 static inline int surface_stride(DisplaySurface *s)
 {
 return pixman_image_get_stride(s->image);
@@ -274,6 +278,7 @@ typedef struct GraphicHwOps {
 void (*gfx_update)(void *opaque);
 void (*text_update)(void *opaque, console_ch_t *text);
 void (*update_interval)(void *opaque, uint64_t interval);
+void (*notify_state)(void *opaque, int idx, int x, int y, uint32_t width, 
uint32_t height);
 } GraphicHwOps;
 
 QemuConsole *graphic_console_init(DeviceState *dev,
@@ -283,6 +288,7 @@ QemuConsole *graphic_console_init(DeviceState *dev,
 void graphic_hw_update(QemuConsole *con);
 void graphic_hw_invalidate(QemuConsole *con);
 void graphic_hw_text_update(QemuConsole *con, console_ch_t *chardata);
+void graphic_hw_notify_state(QemuConsole *con, int x, int y, uint32_t width, 
uint32_t height);
 
 QemuConsole *qemu_console_lookup_by_index(unsigned int index);
 QemuConsole *qemu_console_lookup_by_device(DeviceState *dev);
diff --git a/ui/console.c b/ui/console.c
index 502e160..def11ea 100644
--- a/ui/console.c
+++ b/ui/console.c
@@ -265,6 +265,16 @@ void graphic_hw_invalidate(QemuConsole *con)
 }
 }
 
+void graphic_hw_notify_state(QemuConsole *con, int x, int y, uint32_t width, 
uint32_t height)
+{
+if (!con) {
+con = active_console;
+}
+if (con && con->hw_ops->notify_state) {
+con->hw_ops->notify_state(con->hw, con->index, x, y, width, height);
+}
+}
+
 static void ppm_save(const char *filename, struct DisplaySurface *ds,
  Error **errp)
 {
@@ -1525,6 +1535,22 @@ bool dpy_cursor_define_supported(QemuConsole *con)
 return false;
 }
 
+void dpy_notify_state(QemuConsole *con, int x, int y,
+  uint32_t width, uint32_t height)
+{
+DisplayState *s = con->ds;
+DisplayChangeListener *dcl;
+
+QLIST_FOREACH(dcl, &s->listeners, next) {
+if (con != (dcl->con ? dcl->con : active_console)) {
+continue;
+}
+if (dcl->ops->dpy_notify_state) {
+dcl->ops->dpy_notify_state(dcl, x, y, width, height);
+}
+}
+}
+
 /***/
 /* register display */
 
-- 
1.8.3.1

[Qemu-devel] [PATCH 6/8] virtio-gpu: v0.2 of the virtio based GPU code.

[Dave Airlie]

From: Dave Airlie 

This is the basic virtio-gpu which is

multi-head capable,
ARGB cursor support,
unaccelerated.

Some more info is in docs/specs/virtio-gpu.txt.

changes since v0.1:
add reset handling
fix display info response
fix cursor generation issues
drop 3d stuff that snuck in

Signed-off-by: Dave Airlie 
---
 default-configs/x86_64-softmmu.mak |   1 +
 docs/specs/virtio-gpu.txt  |  89 +
 hw/display/Makefile.objs   |   2 +
 hw/display/virtgpu_hw.h| 142 
 hw/display/virtio-gpu.c| 649 +
 hw/virtio/virtio-pci.c |  49 +++
 hw/virtio/virtio-pci.h |  15 +
 include/hw/pci/pci.h   |   1 +
 include/hw/virtio/virtio-gpu.h |  89 +
 9 files changed, 1037 insertions(+)
 create mode 100644 docs/specs/virtio-gpu.txt
 create mode 100644 hw/display/virtgpu_hw.h
 create mode 100644 hw/display/virtio-gpu.c
 create mode 100644 include/hw/virtio/virtio-gpu.h

diff --git a/default-configs/x86_64-softmmu.mak 
b/default-configs/x86_64-softmmu.mak
index 31bddce..1a00b78 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -9,6 +9,7 @@ CONFIG_VGA_PCI=y
 CONFIG_VGA_ISA=y
 CONFIG_VGA_CIRRUS=y
 CONFIG_VMWARE_VGA=y
+CONFIG_VIRTIO_GPU=y
 CONFIG_VMMOUSE=y
 CONFIG_SERIAL=y
 CONFIG_PARALLEL=y
diff --git a/docs/specs/virtio-gpu.txt b/docs/specs/virtio-gpu.txt
new file mode 100644
index 000..987d807
--- /dev/null
+++ b/docs/specs/virtio-gpu.txt
@@ -0,0 +1,89 @@
+Initial info on virtio-gpu:
+
+virtio-gpu is a virtio based graphics adapter. The initial version provides 
support for:
+
+- ARGB Hardware cursors
+- multiple outputs
+
+There are no acceleration features available in the first release of this 
device, 3D acceleration features will be provided later via an interface to an 
external renderer.
+
+The virtio-gpu exposes 3 vqs to the guest,
+
+1) control vq - guest->host queue for sending commands and getting responses 
when required.
+2) cursor vq - guest->host queue for sending cursor position and resource 
updates
+3) event vq - host->guest queue for sending async events like display 
topography updates and errors (todo).
+
+How to use the virtio-gpu:
+
+The virtio-gpu is based around the concept of resources private to the host, 
the guest must DMA transfer into these resources. This is a design requirement 
in order to interface with future 3D rendering. In the unaccelerated there is 
no support for DMA transfers from resources, just to them.
+
+Resources are initially simple 2D resources, consisting of a width, height and 
format along with an identifier. The guest must then attach backing store to 
the resources in order for DMA transfers to work. This is like a GART in a real 
GPU.
+
+A typical guest user would create a 2D resource using 
VIRTGPU_CMD_RESOURCE_CREATE_2D, attach backing store using 
VIRTGPU_CMD_RESOURCE_ATTACH_BACKING, then attach the resource to a scanout 
using VIRTGPU_CMD_SET_SCANOUT, then use VIRTGPU_CMD_TRANSFER_SEND_2D to send 
updates to the resource, and finally VIRTGPU_CMD_RESOURCE_FLUSH to flush the 
scanout buffers to screen.
+
+Command queue:
+
+VIRTGPU_CMD_GET_DISPLAY_INFO:
+Retrieve the current output configuration.
+
+This sends a response in the same queue slot. The response contains the max 
number of scanouts the host can support,
+along with a list of per-scanout information. The info contains whether the
+scanout is enabled, what its preferred x, y, width and height are and some 
future flags.
+
+VIRTGPU_CMD_RESOURCE_CREATE_2D:
+Create a 2D resource on the host.
+
+This creates a 2D resource on the host with the specified width, height and 
format. Only a small subset of formats are support. The resource ids are 
generated by the guest.
+
+VIRTGPU_CMD_RESOURCE_UNREF:
+Destroy a resource.
+
+This informs the host that a resource is no longer required by the guest.
+
+VIRTGPU_CMD_SET_SCANOUT:
+Set the scanout parameters for a single output.
+
+This sets the scanout parameters for a single scanout. The resource_id is the
+resource to be scanned out from, along with a rectangle specified by x, y, 
width and height.
+
+VIRTGPU_CMD_RESOURCE_FLUSH:
+Flush a scanout resource
+
+This flushes a resource to screen, it takes a rectangle and a resource id,
+and flushes any scanouts the resource is being used on.
+
+VIRTGPU_CMD_TRANSFER_TO_HOST_2D:
+Transfer from guest memory to host resource.
+
+This takes a resource id along with an destination offset into the resource,
+and a box to transfer from the host backing for the resource.
+
+VIRTGPU_CMD_RESOURCE_ATTACH_BACKING:
+Assign backing pages to a resource.
+
+This assign an array of guest pages as the backing store for a resource. These
+pages are then used for the transfer operations for that resource from that
+point on.
+
+VIRTGPU_CMD_RESOURCE_DETACH_BACKING:
+Detach backing pages from a resource.
+
+This detaches any backing pages from a resource, to be used i

[Qemu-devel] [PATCH 3/8] sdl2: add display notify change support

[Dave Airlie]

From: Dave Airlie 

this adds support for the callbacks from the console layer, when the gpu
changes the layouts.

Signed-off-by: Dave Airlie 
---
 ui/sdl2.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/ui/sdl2.c b/ui/sdl2.c
index 2eb3e9c..dd8cd2b 100644
--- a/ui/sdl2.c
+++ b/ui/sdl2.c
@@ -880,6 +880,15 @@ static void sdl_mouse_define(DisplayChangeListener *dcl,
 SDL_SetCursor(guest_sprite);
 }
 
+static void sdl_notify_state(DisplayChangeListener *dcl,
+ int x, int y, uint32_t width, uint32_t height)
+{
+struct sdl2_console_state *scon = container_of(dcl, struct 
sdl2_console_state, dcl);
+
+scon->x = x;
+scon->y = y;
+}
+
 static void sdl_cleanup(void)
 {
 if (guest_sprite)
@@ -894,6 +903,7 @@ static const DisplayChangeListenerOps dcl_ops = {
 .dpy_refresh   = sdl_refresh,
 .dpy_mouse_set = sdl_mouse_warp,
 .dpy_cursor_define = sdl_mouse_define,
+.dpy_notify_state  = sdl_notify_state,
 };
 
 void sdl_display_init(DisplayState *ds, int full_screen, int no_frame)
-- 
1.8.3.1

[Qemu-devel] [PATCH 4/8] sdl2: add UI to toggle head 1 on/off

[Dave Airlie]

From: Dave Airlie 

This just adds ctrl-alt-n to toggle head 1 on/off for testing and demo purposes.

Signed-off-by: Dave Airlie 
---
 ui/sdl2.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/ui/sdl2.c b/ui/sdl2.c
index dd8cd2b..c52dcd9 100644
--- a/ui/sdl2.c
+++ b/ui/sdl2.c
@@ -522,6 +522,13 @@ static void handle_keydown(SDL_Event *ev)
 if (gui_key_modifier_pressed) {
 keycode = sdl_keyevent_to_keycode(&ev->key);
 switch (keycode) {
+case 0x31:
+/* spawn a new connected monitor if we have one */
+if (sdl2_console[1].surface)
+graphic_hw_notify_state(sdl2_console[1].dcl.con, 0, 0, 0, 0);
+else
+graphic_hw_notify_state(sdl2_console[1].dcl.con, 0, 0, 1024, 
768);
+break;
 case 0x21: /* 'f' key on US keyboard */
 toggle_full_screen(scon);
 gui_keysym = 1;
-- 
1.8.3.1

[Qemu-devel] [PATCH 7/8] virtio-vga: v1

[Dave Airlie]

From: Dave Airlie 

This is a virtio-vga device built on top of the virtio-gpu device.

Signed-off-by: Dave Airlie 
---
 Makefile   |   2 +-
 default-configs/x86_64-softmmu.mak |   1 +
 hw/display/Makefile.objs   |   1 +
 hw/display/virtio-vga.c| 156 +
 hw/pci/pci.c   |   2 +
 include/sysemu/sysemu.h|   2 +-
 pc-bios/vgabios-virtio.bin | Bin 0 -> 40448 bytes
 roms/Makefile  |   2 +-
 roms/config.vga.virtio |   6 ++
 vl.c   |  13 
 10 files changed, 182 insertions(+), 3 deletions(-)
 create mode 100644 hw/display/virtio-vga.c
 create mode 100644 pc-bios/vgabios-virtio.bin
 create mode 100644 roms/config.vga.virtio

diff --git a/Makefile b/Makefile
index bdff4e4..a7dabe4 100644
--- a/Makefile
+++ b/Makefile
@@ -291,7 +291,7 @@ bepocz
 
 ifdef INSTALL_BLOBS
 BLOBS=bios.bin sgabios.bin vgabios.bin vgabios-cirrus.bin \
-vgabios-stdvga.bin vgabios-vmware.bin vgabios-qxl.bin \
+vgabios-stdvga.bin vgabios-vmware.bin vgabios-qxl.bin vgabios-virtio.bin \
 acpi-dsdt.aml q35-acpi-dsdt.aml \
 ppc_rom.bin openbios-sparc32 openbios-sparc64 openbios-ppc QEMU,tcx.bin \
 pxe-e1000.rom pxe-eepro100.rom pxe-ne2k_pci.rom \
diff --git a/default-configs/x86_64-softmmu.mak 
b/default-configs/x86_64-softmmu.mak
index 1a00b78..22d8587 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -10,6 +10,7 @@ CONFIG_VGA_ISA=y
 CONFIG_VGA_CIRRUS=y
 CONFIG_VMWARE_VGA=y
 CONFIG_VIRTIO_GPU=y
+CONFIG_VIRTIO_VGA=y
 CONFIG_VMMOUSE=y
 CONFIG_SERIAL=y
 CONFIG_PARALLEL=y
diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index 10e4066..63427e9 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -34,3 +34,4 @@ obj-$(CONFIG_VGA) += vga.o
 common-obj-$(CONFIG_QXL) += qxl.o qxl-logger.o qxl-render.o
 
 obj-$(CONFIG_VIRTIO_GPU) += virtio-gpu.o
+obj-$(CONFIG_VIRTIO_VGA) += virtio-vga.o
diff --git a/hw/display/virtio-vga.c b/hw/display/virtio-vga.c
new file mode 100644
index 000..9e8eff9
--- /dev/null
+++ b/hw/display/virtio-vga.c
@@ -0,0 +1,156 @@
+#include "hw/hw.h"
+#include "hw/pci/pci.h"
+#include "ui/console.h"
+#include "vga_int.h"
+#include "hw/virtio/virtio-pci.h"
+
+/*
+ * virtio-vga: This extends VirtIOGPUPCI
+ */
+#define TYPE_VIRTIO_VGA "virtio-vga"
+#define VIRTIO_VGA(obj) \
+OBJECT_CHECK(VirtIOVGA, (obj), TYPE_VIRTIO_VGA)
+
+typedef struct VirtIOVGA VirtIOVGA;
+struct VirtIOVGA {
+struct VirtIOGPUPCI gpu;
+VGACommonState vga;
+const struct GraphicHwOps *wrapped_ops;
+void *wrapped_opaque;
+};
+
+static void virtio_vga_invalidate_display(void *opaque)
+{
+VirtIOVGA *vvga = opaque;
+
+if (!vvga->gpu.vdev.enable) {
+   vvga->vga.hw_ops->invalidate(&vvga->vga);
+   return;
+}
+
+vvga->wrapped_ops->invalidate(vvga->wrapped_opaque);
+}
+
+static void virtio_vga_update_display(void *opaque)
+{
+VirtIOVGA *vvga = opaque;
+
+if (!vvga->gpu.vdev.enable) {
+   vvga->vga.hw_ops->gfx_update(&vvga->vga);
+}
+vvga->wrapped_ops->gfx_update(vvga->wrapped_opaque);
+}
+
+static void virtio_vga_text_update(void *opaque, console_ch_t *chardata)
+{
+VirtIOVGA *vvga = opaque;
+
+if (!vvga->gpu.vdev.enable) {
+   if (vvga->vga.hw_ops->text_update)
+   vvga->vga.hw_ops->text_update(&vvga->vga, chardata);
+}
+vvga->wrapped_ops->text_update(vvga->wrapped_opaque, chardata);
+}
+
+static void virtio_vga_notify_state(void *opaque, int idx, int x, int y, 
uint32_t width, uint32_t height)
+{
+VirtIOVGA *vvga = opaque;
+
+if (!vvga->gpu.vdev.enable) {
+if (vvga->vga.hw_ops->notify_state)
+   vvga->vga.hw_ops->notify_state(&vvga->vga, idx, x, y, width, 
height);
+}
+vvga->wrapped_ops->notify_state(vvga->wrapped_opaque, idx, x, y, width, 
height);
+}
+
+static const GraphicHwOps virtio_vga_ops = {
+.invalidate = virtio_vga_invalidate_display,
+.gfx_update = virtio_vga_update_display,
+.text_update = virtio_vga_text_update,
+.notify_state = virtio_vga_notify_state,
+};
+
+/* VGA device wrapper around PCI device around virtio GPU */
+static int virtio_vga_init(VirtIOPCIProxy *vpci_dev)
+{
+VirtIOVGA *vvga = VIRTIO_VGA(vpci_dev);
+DeviceState *vdev = DEVICE(&vvga->gpu.vdev);
+VGACommonState *vga = &vvga->vga;
+
+qdev_set_parent_bus(vdev, BUS(&vpci_dev->bus));
+if (qdev_init(vdev) < 0) {
+   return -1;
+}
+
+graphic_console_wrap(vvga->gpu.vdev.con[0], DEVICE(vpci_dev), 
&virtio_vga_ops, vvga, &vvga->wrapped_ops, &vvga->wrapped_opaque);
+vga->con = vvga->gpu.vdev.con[0];
+
+vga_common_init(vga, OBJECT(v

[Qemu-devel] [PATCH 8/8] HACK: just to make things start easier with libvirt

[Dave Airlie]

From: Dave Airlie 

---
 hw/display/vga-pci.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/display/vga-pci.c b/hw/display/vga-pci.c
index b3a45c8..e4bea17 100644
--- a/hw/display/vga-pci.c
+++ b/hw/display/vga-pci.c
@@ -146,6 +146,7 @@ static int pci_std_vga_initfn(PCIDevice *dev)
 PCIVGAState *d = DO_UPCAST(PCIVGAState, dev, dev);
 VGACommonState *s = &d->vga;
 
+   return 0;
 /* vga + console init */
 vga_common_init(s, OBJECT(dev));
 vga_init(s, OBJECT(dev), pci_address_space(dev), pci_address_space_io(dev),
@@ -195,7 +196,7 @@ static void vga_class_init(ObjectClass *klass, void *data)
 k->romfile = "vgabios-stdvga.bin";
 k->vendor_id = PCI_VENDOR_ID_QEMU;
 k->device_id = PCI_DEVICE_ID_QEMU_VGA;
-k->class_id = PCI_CLASS_DISPLAY_VGA;
+k->class_id = 0;// PCI_CLASS_DISPLAY_VGA;
 dc->vmsd = &vmstate_vga_pci;
 dc->props = vga_pci_properties;
 set_bit(DEVICE_CATEGORY_DISPLAY, dc->categories);
-- 
1.8.3.1

[Qemu-devel] [PATCH] virtio-gpu: use glib alloc/free routines

[Dave Airlie]

From: Dave Airlie 

Oh I forgot to fix these up previously.

Signed-off-by: Dave Airlie 
---
 hw/display/virtio-gpu.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 7bf2fbb..28dcd1e 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -137,7 +137,7 @@ static void virtgpu_resource_create_2d(VirtIOGPU *g,
 pixman_format_code_t pformat;
 struct virtgpu_simple_resource *res;
 
-res = calloc(1, sizeof(struct virtgpu_simple_resource));
+res = g_new0(struct virtgpu_simple_resource, 1);
 if (!res)
return;
 
@@ -159,7 +159,7 @@ static void virtgpu_resource_destroy(struct 
virtgpu_simple_resource *res)
 {
 pixman_image_unref(res->image);
 QLIST_REMOVE(res, next);
-free(res);
+g_free(res);
 }
 
 static void virtgpu_resource_unref(VirtIOGPU *g,
@@ -310,12 +310,10 @@ static void virtgpu_resource_attach_backing(VirtIOGPU *g,
 if (!res)
return;
 
-res_iovs = malloc(att_rb->nr_entries * sizeof(struct iovec));
-if (!res_iovs)
-   return;
+res_iovs = g_new0(struct iovec, att_rb->nr_entries);
 
 if (iov_cnt > 1) {
-   data = malloc(gsize);
+   data = g_malloc(gsize);
iov_to_buf(iov, iov_cnt, 0, data, gsize);
 } else
data = iov[0].iov_base;
@@ -337,7 +335,7 @@ static void virtgpu_resource_attach_backing(VirtIOGPU *g,
 res->iov_cnt = att_rb->nr_entries;
 
 if (iov_cnt > 1)
-   free(data);
+g_free(data);
 }
 
 static void virtgpu_resource_inval_backing(VirtIOGPU *g,
@@ -354,7 +352,7 @@ static void virtgpu_resource_inval_backing(VirtIOGPU *g,
 for (i = 0; i < res->iov_cnt; i++) {
cpu_physical_memory_unmap(res->iov[i].iov_base, res->iov[i].iov_len, 1, 
res->iov[i].iov_len);
 }
-free(res->iov);
+g_free(res->iov);
 res->iov_cnt = 0;
 res->iov = NULL;
 }
-- 
1.8.3.1

Re: [Qemu-devel] [RFC] sdl2 + virtio-gpu repost

[Dave Airlie]

On Tue, Dec 10, 2013 at 2:05 PM, Dave Airlie  wrote:
> Hi,
>
> This is a repost of the latest SDL2 UI layer along with virtio-gpu,
>
> I've merged the SDL2 base and multi-head patches into one, and I've split
> out the display notifiers stuff and the sdl2 demo hack.
>
> The virtio-gpu/vga wrapping is still unresolved, I've failed to find a cleaner
> way yet, hopefully Gerd will advise further, but having 4 virtio-gpu- objects
> we getting ugly fast. I've also included a doc on the basic queues used in the
> virtio-gpu and what commands are sent on them.

Oh I added one more patch to use glib allocation routines in
virtio-gpu, I forgot that was on my list!

Dave.

Re: [Qemu-devel] [PATCH 1/8] ui/sdl2 : initial port to SDL 2.0 (v2.0)

[Dave Airlie]

On Wed, Dec 11, 2013 at 12:35 AM, Gerd Hoffmann  wrote:
>   Hi,
>
>> The biggest changes were in the input handling, where SDL2 has done a major
>> overhaul, and I've had to include a generated translation file to get from
>> SDL2 codes back to qemu compatible ones. I'm still not sure how the keyboard
>> layout code works in qemu, so there may be further work if someone can point
>> me a test case that works with SDL1.2 and doesn't with SDL2.
>
> I've picked it up, cleaned up a bit (more to be done), switched over to
> new input core.  Simplified the keyboard mess, the new input support in
> SDL2 allows us to reduce it to a single+simple lookup table.  Pushed
> here:

Oh thanks for that, looks a lot cleaner esp the input handling, let me
know if there
is anything you'd like me to look at.

I wasn't sure if we wanted to keep the old text console switching
stuff on console 0 or not,
I see you've ripped it out, I can't say I ever used it anyways.

I've also started reworking gtk for multi-head and have the basics
working there as well.

Dave.