[Qemu-devel] [PATCH] spice: allow to specify drm rendernode

[Marc-André Lureau]

When multiple GPU are available, picking the first one isn't always the
best choice. Learn to specify a device rendernode.

Signed-off-by: Marc-André Lureau 
---
 include/ui/egl-helpers.h |  3 +--
 ui/egl-helpers.c | 10 +++---
 ui/spice-core.c  |  5 -
 qemu-options.hx  |  6 +-
 4 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/include/ui/egl-helpers.h b/include/ui/egl-helpers.h
index 03fcf4bba2..88a13e827b 100644
--- a/include/ui/egl-helpers.h
+++ b/include/ui/egl-helpers.h
@@ -14,8 +14,7 @@ extern int qemu_egl_rn_fd;
 extern struct gbm_device *qemu_egl_rn_gbm_dev;
 extern EGLContext qemu_egl_rn_ctx;
 
-int qemu_egl_rendernode_open(void);
-int egl_rendernode_init(void);
+int egl_rendernode_init(const char *rendernode);
 int egl_get_fd_for_texture(uint32_t tex_id, EGLint *stride, EGLint *fourcc);
 
 #endif
diff --git a/ui/egl-helpers.c b/ui/egl-helpers.c
index cd24568a5e..417462b76d 100644
--- a/ui/egl-helpers.c
+++ b/ui/egl-helpers.c
@@ -44,13 +44,17 @@ int qemu_egl_rn_fd;
 struct gbm_device *qemu_egl_rn_gbm_dev;
 EGLContext qemu_egl_rn_ctx;
 
-int qemu_egl_rendernode_open(void)
+static int qemu_egl_rendernode_open(const char *rendernode)
 {
 DIR *dir;
 struct dirent *e;
 int r, fd;
 char *p;
 
+if (rendernode) {
+return open(rendernode, O_RDWR | O_CLOEXEC | O_NOCTTY | O_NONBLOCK);
+}
+
 dir = opendir("/dev/dri");
 if (!dir) {
 return -1;
@@ -85,11 +89,11 @@ int qemu_egl_rendernode_open(void)
 return fd;
 }
 
-int egl_rendernode_init(void)
+int egl_rendernode_init(const char *rendernode)
 {
 qemu_egl_rn_fd = -1;
 
-qemu_egl_rn_fd = qemu_egl_rendernode_open();
+qemu_egl_rn_fd = qemu_egl_rendernode_open(rendernode);
 if (qemu_egl_rn_fd == -1) {
 error_report("egl: no drm render node available");
 goto err;
diff --git a/ui/spice-core.c b/ui/spice-core.c
index 1452e77fd1..39ccab7561 100644
--- a/ui/spice-core.c
+++ b/ui/spice-core.c
@@ -501,6 +501,9 @@ static QemuOptsList qemu_spice_opts = {
 },{
 .name = "gl",
 .type = QEMU_OPT_BOOL,
+},{
+.name = "rendernode",
+.type = QEMU_OPT_STRING,
 #endif
 },
 { /* end of list */ }
@@ -833,7 +836,7 @@ void qemu_spice_init(void)
  "incompatible with -spice port/tls-port");
 exit(1);
 }
-if (egl_rendernode_init() != 0) {
+if (egl_rendernode_init(qemu_opt_get(opts, "rendernode")) != 0) {
 error_report("Failed to initialize EGL render node for SPICE GL");
 exit(1);
 }
diff --git a/qemu-options.hx b/qemu-options.hx
index ac036b4cbd..b64087d934 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1066,7 +1066,7 @@ DEF("spice", HAS_ARG, QEMU_OPTION_spice,
 "   [,streaming-video=[off|all|filter]][,disable-copy-paste]\n"
 "   [,disable-agent-file-xfer][,agent-mouse=[on|off]]\n"
 "   [,playback-compression=[on|off]][,seamless-migration=[on|off]]\n"
-"   [,gl=[on|off]]\n"
+"   [,gl=[on|off]][,rendernode=]\n"
 "   enable spice\n"
 "   at least one of {port, tls-port} is mandatory\n",
 QEMU_ARCH_ALL)
@@ -1161,6 +1161,10 @@ Enable/disable spice seamless migration. Default is off.
 @item gl=[on|off]
 Enable/disable OpenGL context. Default is off.
 
+@item rendernode=
+DRM render node for OpenGL rendering. If not specified, it will pick
+the first available. (Since 2.9)
+
 @end table
 ETEXI
 
-- 
2.11.0.295.gd7dffce1c.dirty

Re: [Qemu-devel] [PATCH v3] net: e1000e: fix an infinite loop issue

[Dmitry Fleytman]

Reviewed-by: Dmitry Fleytman 

> On 10 Feb 2017, at 04:19 AM, Li Qiang  wrote:
> 
> This issue is like the issue in e1000 network card addressed in
> this commit:
> e1000: eliminate infinite loops on out-of-bounds transfer start.
> 
> Signed-off-by: Li Qiang 
> ---
> 
> Change since v2:
> fix error in e1000e_ring_empty
> eliminate unnecessory detect code in loop
> 
> Changes since v1:
> make wraparound detect in e1000e_ring_empty
> 
> hw/net/e1000e_core.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c
> index 2b11499..dc94188 100644
> --- a/hw/net/e1000e_core.c
> +++ b/hw/net/e1000e_core.c
> @@ -806,7 +806,8 @@ typedef struct E1000E_RingInfo_st {
> static inline bool
> e1000e_ring_empty(E1000ECore *core, const E1000E_RingInfo *r)
> {
> -return core->mac[r->dh] == core->mac[r->dt];
> +return core->mac[r->dh] == core->mac[r->dt] ||
> +core->mac[r->dt] >= core->mac[r->dlen] / E1000_RING_DESC_LEN;
> }
> 
> static inline uint64_t
> @@ -1522,6 +1523,10 @@ e1000e_write_packet_to_guest(E1000ECore *core, struct 
> NetRxPkt *pkt,
> desc_size = core->rx_desc_buf_size;
> }
> 
> +if (e1000e_ring_empty(core, rxi)) {
> +return;
> +}
> +
> base = e1000e_ring_head_descr(core, rxi);
> 
> pci_dma_read(d, base, &desc, core->rx_desc_len);
> -- 
> 1.8.3.1
> 

Re: [Qemu-devel] libslirp and QEMU slirp

[Renzo Davoli]

Hi,

On Wed, Feb 08, 2017 at 11:10:50PM +0100, Samuel Thibault wrote:
> Hello,
> 
> Stefan Hajnoczi, on Mon 06 Feb 2017 11:55:05 +, wrote:
> > I'm proposing this topic for discussion because there might be common
> > ground for Samuel from QEMU and the VDE folks to collaborate.
> > 
> > Samuel: Should QEMU join forces with libslirp?
> 
> Well, there are not that many forces from the QEMU side :)
Neither on VDE side ;-) but many ants can move mountains...
> 
> - we are using timers for icmp announcements
> - qemu needs to be able to save/restore state, with compatibility with
> previous versions

libslirp is using qemu's slirp code. 
If you try a diff between your "slirp" directory and libslirp's "src" directory
you'll find that there are only 3 lines added:
(at the date of the code extraction, e.g. qemu git's tag 
1f8b56e7cebc71d80aec27a4760024b56acc957a)

In slirp.h:
#include 

Which includes stubs and specific implementations to give slirp all the stuff
provided by qemu's core or other libraries used by qemu.

In tcp_subr.c:
400a401,403
>   if ((ret = unixtcp_fconnect(so, af)) >= 0)
>   return ret;

which adds a nice feature that IMHO would be useful in qemu, too.
unixtcp_fconnect creates a TCP to AF_UNIX socket redirection.
The VM running on qemu (or in VDE a VM connected to the virtual net)
can redirect a default route port (say 10.0.2.2:6000) to a UNIX socket
(say /tmp/.X11-unix/0). In this example X clients using the X display 
10.0.2.2:0 
can appear on the X server of the host.

Timers have been reimplemented using the qemu's API.
save/restore are dummy stubs in libslirp. Qemu's code is still there but it is 
not used
by libslirp.

In this way we can inherit all bugfixes and new feature from Qemu at almost no 
cost.

It would be a nice project to create a common codebase for libslirp.
The project sould be interesting for other VM projects (virtualbox-OSE?) and
maybe many others. We could collect several ants...

Libslirp/QEMU integration is not so difficult.
As a first step:
* Qemu could add the UNIX socket redirect feature, or at least a 
unixtcp_fconnect dummy function
returning -1 (#ifndef LIBSLIRP)
* #include 
could be added in slirp.h (inside an #ifdef LIBSLIRP).
In this way we could share exactly the same codebase.

One further step:
* discuss how to reduce/eliminate qemu-specific dependence
* create an API for save/restore

These are only my two (euro)cents.

ciao
renzo

Re: [Qemu-devel] [PATCH v2] linux-user: Add FICLONE and FICLONERANGE ioctls

[Laurent Vivier]

Le 11/02/2017 à 23:26, Helge Deller a écrit :
> Add missing FICLONE and FICLONERANGE ioctls.
> 
> Changes to v1:
> - Added STRUCT_file_clone_range as suggested by Laurent Vivier
> 
> Signed-off-by: Helge Deller 

Reviewed-by: Laurent Vivier 

> 
> diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
> index 2f6e85b..e6997ff 100644
> --- a/linux-user/ioctls.h
> +++ b/linux-user/ioctls.h
> @@ -112,6 +112,11 @@
>  #ifdef FIBMAP
>   IOCTL(FIBMAP, IOC_W | IOC_R, MK_PTR(TYPE_LONG))
>  #endif
> +#ifdef FICLONE
> + IOCTL(FICLONE, IOC_W, TYPE_INT)
> + IOCTL(FICLONERANGE, IOC_W, MK_PTR(MK_STRUCT(STRUCT_file_clone_range)))
> +#endif
> +
>  #ifdef FIGETBSZ
>   IOCTL(FIGETBSZ, IOC_R, MK_PTR(TYPE_LONG))
>  #endif
> diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
> index 4442c22..72ca5b1 100644
> --- a/linux-user/syscall_defs.h
> +++ b/linux-user/syscall_defs.h
> @@ -1086,6 +1086,10 @@ struct target_pollfd {
>  
>  #define TARGET_FIBMAP TARGET_IO(0x00,1)  /* bmap access */
>  #define TARGET_FIGETBSZ   TARGET_IO(0x00,2)  /* get the block size used for 
> bmap */
> +
> +#define TARGET_FICLONETARGET_IOW(0x94, 9, int)
> +#define TARGET_FICLONERANGE TARGET_IOW(0x94, 13, struct file_clone_range)
> +
>  /* Note that the ioctl numbers claim type "long" but the actual type
>   * used by the kernel is "int".
>   */
> diff --git a/linux-user/syscall_types.h b/linux-user/syscall_types.h
> index 2b8c0c6..24631b0 100644
> --- a/linux-user/syscall_types.h
> +++ b/linux-user/syscall_types.h
> @@ -232,6 +232,12 @@ STRUCT(dm_target_versions,
>  STRUCT(dm_target_msg,
> TYPE_ULONGLONG) /* sector */
>  
> +STRUCT(file_clone_range,
> +   TYPE_LONGLONG, /* src_fd */
> +   TYPE_ULONGLONG, /* src_offset */
> +   TYPE_ULONGLONG, /* src_length */
> +   TYPE_ULONGLONG) /* dest_offset */
> +
>  STRUCT(fiemap_extent,
> TYPE_ULONGLONG, /* fe_logical */
> TYPE_ULONGLONG, /* fe_physical */
> 

Re: [Qemu-devel] [PATCH v7 1/2] q35: Improve sample configuration files

[Marcel Apfelbaum]

On 02/10/2017 07:25 PM, Andrea Bolognani wrote:

Instead of having a single sample configuration file,
we now have several:

  * q35-emulated.cfg documents the default devices QEMU
adds to a q35 guest and the additional devices that
are pretty much guaranteed to be present in a
physical q35-based machine;

  * q35-virtio-graphical.cfg can be used to start a
fully-featured (USB, graphical console, audio, etc.)
guest that uses VirtIO instead of emulated devices;

  * q35-virtio-serial.cfg is similar but has a minimal
set of devices and uses the serial console.

All configuration files are fully commented and neatly
organized.
---
 docs/q35-chipset.cfg  | 152 --
 docs/q35-emulated.cfg | 288 ++
 docs/q35-virtio-graphical.cfg | 248 
 docs/q35-virtio-serial.cfg| 193 
 4 files changed, 729 insertions(+), 152 deletions(-)
 delete mode 100644 docs/q35-chipset.cfg
 create mode 100644 docs/q35-emulated.cfg
 create mode 100644 docs/q35-virtio-graphical.cfg
 create mode 100644 docs/q35-virtio-serial.cfg

diff --git a/docs/q35-chipset.cfg b/docs/q35-chipset.cfg
deleted file mode 100644
index e4ddb7d..000
--- a/docs/q35-chipset.cfg
+++ /dev/null
@@ -1,152 +0,0 @@
-
-#
-# qemu -M q35 creates a bare machine with just the very essential
-# chipset devices being present:
-#
-# 00.0 - Host bridge
-# 1f.0 - ISA bridge / LPC
-# 1f.2 - SATA (AHCI) controller
-# 1f.3 - SMBus controller
-#
-# This config file documents the other devices and how they are
-# created.  You can simply use "-readconfig $thisfile" to create
-# them all.  Here is a overview:
-#
-# 19.0 - Ethernet controller (not created, our e1000 emulation
-# doesn't emulate the ich9 device).
-# 1a.* - USB Controller #2 (ehci + uhci companions)
-# 1b.0 - HD Audio Controller
-# 1c.* - PCI Express Ports
-# 1d.* - USB Controller #1 (ehci + uhci companions,
-#   "qemu -M q35 -usb" creates these too)
-# 1e.0 - PCI Bridge
-#
-
-[device "ich9-ehci-2"]
-  driver = "ich9-usb-ehci2"
-  multifunction = "on"
-  bus = "pcie.0"
-  addr = "1a.7"
-
-[device "ich9-uhci-4"]
-  driver = "ich9-usb-uhci4"
-  multifunction = "on"
-  bus = "pcie.0"
-  addr = "1a.0"
-  masterbus = "ich9-ehci-2.0"
-  firstport = "0"
-
-[device "ich9-uhci-5"]
-  driver = "ich9-usb-uhci5"
-  multifunction = "on"
-  bus = "pcie.0"
-  addr = "1a.1"
-  masterbus = "ich9-ehci-2.0"
-  firstport = "2"
-
-[device "ich9-uhci-6"]
-  driver = "ich9-usb-uhci6"
-  multifunction = "on"
-  bus = "pcie.0"
-  addr = "1a.2"
-  masterbus = "ich9-ehci-2.0"
-  firstport = "4"
-
-
-[device "ich9-hda-audio"]
-  driver = "ich9-intel-hda"
-  bus = "pcie.0"
-  addr = "1b.0"
-
-
-[device "ich9-pcie-port-1"]
-  driver = "ioh3420"
-  multifunction = "on"
-  bus = "pcie.0"
-  addr = "1c.0"
-  port = "1"
-  chassis = "1"
-
-[device "ich9-pcie-port-2"]
-  driver = "ioh3420"
-  multifunction = "on"
-  bus = "pcie.0"
-  addr = "1c.1"
-  port = "2"
-  chassis = "2"
-
-[device "ich9-pcie-port-3"]
-  driver = "ioh3420"
-  multifunction = "on"
-  bus = "pcie.0"
-  addr = "1c.2"
-  port = "3"
-  chassis = "3"
-
-[device "ich9-pcie-port-4"]
-  driver = "ioh3420"
-  multifunction = "on"
-  bus = "pcie.0"
-  addr = "1c.3"
-  port = "4"
-  chassis = "4"
-
-##
-# Example PCIe switch with two downstream ports
-#
-#[device "pcie-switch-upstream-port-1"]
-#  driver = "x3130-upstream"
-#  bus = "ich9-pcie-port-4"
-#  addr = "00.0"
-#
-#[device "pcie-switch-downstream-port-1-1"]
-#  driver = "xio3130-downstream"
-#  multifunction = "on"
-#  bus = "pcie-switch-upstream-port-1"
-#  addr = "00.0"
-#  port = "1"
-#  chassis = "5"
-#
-#[device "pcie-switch-downstream-port-1-2"]
-#  driver = "xio3130-downstream"
-#  multifunction = "on"
-#  bus = "pcie-switch-upstream-port-1"
-#  addr = "00.1"
-#  port = "1"
-#  chassis = "6"
-
-[device "ich9-ehci-1"]
-  driver = "ich9-usb-ehci1"
-  multifunction = "on"
-  bus = "pcie.0"
-  addr = "1d.7"
-
-[device "ich9-uhci-1"]
-  driver = "ich9-usb-uhci1"
-  multifunction = "on"
-  bus = "pcie.0"
-  addr = "1d.0"
-  masterbus = "ich9-ehci-1.0"
-  firstport = "0"
-
-[device "ich9-uhci-2"]
-  driver = "ich9-usb-uhci2"
-  multifunction = "on"
-  bus = "pcie.0"
-  addr = "1d.1"
-  masterbus = "ich9-ehci-1.0"
-  firstport = "2"
-
-[device "ich9-uhci-3"]
-  driver = "ich9-usb-uhci3"
-  multifunction = "on"
-  bus = "pcie.0"
-  addr = "1d.2"
-  masterbus = "ich9-ehci-1.0"
-  firstport = "4"
-
-
-[device "ich9-pci-bridge"]
-  driver = "i82801b11-bridge"
-  bus = "pcie.0"
-  addr = "1e.0"
diff --git a/docs/q35-emulated.cfg b/docs/q35-emulated.cfg
new file mode 100644
index 000..c6416d6
--- /dev/null
+++ b/docs/q35-emulated.cfg
@@ -0,0 +1,288 @@
+# q35 - Emulated guest (graphical console)
+# =

[Qemu-devel] [PATCH] nios2: Add Altera JTAG UART emulation

[Juro Bystricky]

Add the Altera JTAG UART model.

Hardware emulation based on:
https://www.altera.com/en_US/pdfs/literature/ug/ug_embedded_ip.pdf
(Please see "Register Map" on page 65)

Signed-off-by: Juro Bystricky 
---
V2: - Removed link to hw specs(checkpatch: line over 90 characters)
V3: - New link to do hw specs
V4: - Modified check for correct fifo size
- Made fifo_size a property
- Use register offsets instead of register indeces
- Removed redundant test for fifo overflow
- Modified commit message
V5: - definine ALTERA_JTAG_UART_REGS_MEM_SIZE 
- Modified commit message
- Replaced DEFAULT_FIFO_SIZE by ALTERA_JUART_DEFAULT_FIFO_SIZE
- Modified test for fifo size
- Simplified error message in altera_juart_create().
---
 default-configs/nios2-softmmu.mak |   1 +
 hw/char/Makefile.objs |   1 +
 hw/char/altera_juart.c| 282 ++
 include/hw/char/altera_juart.h|  46 +++
 4 files changed, 330 insertions(+)
 create mode 100644 hw/char/altera_juart.c
 create mode 100644 include/hw/char/altera_juart.h

diff --git a/default-configs/nios2-softmmu.mak 
b/default-configs/nios2-softmmu.mak
index 74dc70c..6159846 100644
--- a/default-configs/nios2-softmmu.mak
+++ b/default-configs/nios2-softmmu.mak
@@ -4,3 +4,4 @@ CONFIG_NIOS2=y
 CONFIG_SERIAL=y
 CONFIG_PTIMER=y
 CONFIG_ALTERA_TIMER=y
+CONFIG_ALTERA_JUART=y
diff --git a/hw/char/Makefile.objs b/hw/char/Makefile.objs
index 6ea76fe..f0d0e25 100644
--- a/hw/char/Makefile.objs
+++ b/hw/char/Makefile.objs
@@ -27,5 +27,6 @@ common-obj-$(CONFIG_LM32) += lm32_juart.o
 common-obj-$(CONFIG_LM32) += lm32_uart.o
 common-obj-$(CONFIG_MILKYMIST) += milkymist-uart.o
 common-obj-$(CONFIG_SCLPCONSOLE) += sclpconsole.o sclpconsole-lm.o
+common-obj-$(CONFIG_ALTERA_JUART) += altera_juart.o
 
 obj-$(CONFIG_VIRTIO) += virtio-serial-bus.o
diff --git a/hw/char/altera_juart.c b/hw/char/altera_juart.c
new file mode 100644
index 000..584f73b
--- /dev/null
+++ b/hw/char/altera_juart.c
@@ -0,0 +1,282 @@
+/*
+ * QEMU model of the Altera JTAG UART.
+ *
+ * Copyright (c) 2016-2017 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ *
+ * The Altera JTAG UART hardware registers are described in:
+ * https://www.altera.com/en_US/pdfs/literature/ug/ug_embedded_ip.pdf
+ * (In particular "Register Map" on page 65)
+ */
+
+#include "qemu/osdep.h"
+#include "hw/char/altera_juart.h"
+#include "sysemu/sysemu.h"
+#include "qemu/error-report.h"
+
+/* Data register */
+#define OFFSET_R_DATA   0
+#define DATA_RVALID BIT(15)
+#define DATA_RAVAIL 0x
+
+/* Control register */
+#define OFFSET_R_CONTROL 4
+#define CONTROL_RE  BIT(0)
+#define CONTROL_WE  BIT(1)
+#define CONTROL_RI  BIT(8)
+#define CONTROL_WI  BIT(9)
+#define CONTROL_AC  BIT(10)
+#define CONTROL_WSPACE  0x
+
+#define CONTROL_WMASK (CONTROL_RE | CONTROL_WE | CONTROL_AC)
+
+#define TYPE_ALTERA_JUART "altera-juart"
+#define ALTERA_JUART(obj) \
+OBJECT_CHECK(AlteraJUARTState, (obj), TYPE_ALTERA_JUART)
+
+/* Two registers 4 bytes wide each */
+#define ALTERA_JTAG_UART_REGS_MEM_SIZE  (2 * 4)
+
+/*
+ * The JTAG UART core generates an interrupt when either of the individual
+ * interrupt conditions is pending and enabled.
+ */
+static void altera_juart_update_irq(AlteraJUARTState *s)
+{
+unsigned int irq;
+
+irq = ((s->jcontrol & CONTROL_WE) && (s->jcontrol & CONTROL_WI)) ||
+  ((s->jcontrol & CONTROL_RE) && (s->jcontrol & CONTROL_RI));
+
+qemu_set_irq(s->irq, irq);
+}
+
+static uint64_t altera_juart_read(void *opaque, hwaddr addr, unsigned int size)
+{
+AlteraJUARTState *s = opaque;
+uint32_t r;
+
+switch (addr) {
+case OFFSET_R_DATA:
+r = s->rx_fifo[(s->rx_fifo_pos - s->rx_fifo_len) & (s->rx_fifo_size - 
1)];
+if (s->rx_fifo_len) {
+s->rx_fifo_len--;
+qemu_chr_fe_accept_input(&s->chr);
+s->jdata = r | DATA_RVALID | (s->rx_fifo_len << 16);
+s->jcontrol |= CONTROL_RI;
+} else {
+s->jdata = 0;
+s->jcontrol &= ~CONTROL_RI;
+}
+
+altera_juart_update_irq(s);
+return s->jdata;
+
+case OFFSET_R_CONTROL:
+return s->jcontrol;
+}
+
+return 0;
+}
+
+static void altera_juart_write(void *opaque, hwaddr addr,
+   uint64_t value, unsigned int size)
+{
+AlteraJUARTState *s = opaque;
+unsigned char c;
+
+switch (addr) {
+case OFFSET_R_DATA:
+c = value & 0xFF;
+/*
+ * We do not decrement the write fifo,
+ * we "tranmsmit" instanteniously,

Re: [Qemu-devel] [RFC] virtio-pci: Allow PCIe virtio devices on root bus

[Marcel Apfelbaum]

On 02/10/2017 02:37 AM, David Gibson wrote:

On Thu, Feb 09, 2017 at 10:04:47AM +0100, Laszlo Ersek wrote:

On 02/09/17 05:16, David Gibson wrote:

On Wed, Feb 08, 2017 at 11:40:50AM +0100, Laszlo Ersek wrote:

On 02/08/17 07:16, David Gibson wrote:

Marcel,

Your original patch adding PCIe support to virtio-pci.c has the
limitation noted below that PCIe won't be enabled if the device is on
the root bus (rather than under a root or downstream port).  As
reasoned below, I think removing the check is correct, even for x86
(though it would rarely be useful there).  But I could well have
missed something.  Let me know if so...



Virtio devices can appear as either vanilla PCI or PCI-Express devices
depending on the bus they're connected to.  At the moment it will only
appear as vanilla PCI if connected to the root bus of a PCIe host bridge.

Presumably this is to reflect the fact that PCIe devices usually need to
be connected to a root (or further downstream) port rather than directly
on the root bus.  However, due to the odd requirements of the PAPR spec on the 
'pseries'
machine type, it's normal for PCIe devices to appear on the root bus
without root ports.

Further, even on x86, there's no inherent reason we couldn't present a
virtio device as an "integrated device" (typically used for things built
into the PCI chipset), and those devices *do* typically appear on the root
bus.


I'm not personally making a counter-argument, just qouting some of
the relevant parts of "docs/pcie.txt" ("PCI EXPRESS GUIDELINES"):


So, an earlier discussion more or less concluded that the PCIe
guidelines don't really work with PAPR guests.  That comes because
PAPR was designed with PowerVM in mind which allows PCI passthrough
but doesn't do any emulated PCI devices.  So they wanted to present
passed through devices (virtual or phyical) to the guest without
inserting virtual root ports.

Now, you can argue that this was a silly decision in PAPR, and you
could well be right, but there it is.


I can totally accept this, but then we should state it as a fact near
the top of "docs/pcie.txt".




Place only the following kinds of devices directly on the Root Complex:
(1) PCI Devices (e.g. network card, graphics card, IDE controller),
not controllers. Place only legacy PCI devices on
the Root Complex. These will be considered Integrated Endpoints.
Note: Integrated Endpoints are not hot-pluggable.

Although the PCI Express spec does not forbid PCI Express devices as
Integrated Endpoints, existing hardware mostly integrates legacy PCI
devices with the Root Complex.


"Mostly".. on my laptop at least the GPU shows up as an integrated PCI
Express endpoint, so it's certainly not the case that *all* root bus
devices are legacy.


Guest OSes are suspected to behave

strangely when PCI Express devices are integrated
with the Root Complex.


Clearly not that strangely, that often, since my laptop works just fine.



[...]

2.2 PCI Express only hierarchy
==
Always use PCI Express Root Ports to start PCI Express hierarchies.


Above you mention "it's normal for PCIe devices to appear on the root bus without 
root ports".


Well "normal" perhaps wasn't the right word.  Let's say precedented,
if uncommon.


Let me turn the question around: is it a *problem* for "pseries" if
we require root ports? If so, why exactly?


That's.. a complex question.  At least Linux guests (and we don't
support any others yet) might cope with the addition of root ports.
Maybe.  I have discussed this option with BenH and others.

However it is gratuitously different from how PCIe devices will
typically appear for the same guest running under PowerVM.  Although I
suspect Linux would cope with the "normal standard" rather than "PAPR
standard" presentation, I'm not as confident about it as I would like.

Another consideration here is that other PCIe capable qemu emulated
devices, such as XHCI, will present fine as PCIe integrated endpoints
when attached to the root bus.  Libvirt won't do that usually, of
course, and it may not be the recommended way of doing things (on PC)
but it's possible.  I don't see any particular reason that virtio-pci
should enforce the root port requirement more so than any other
device.


On 02/08/17 07:16, David Gibson wrote:


pcie_endpoint_cap_init() already automatically adjusts to advertise as
an integrated device rather than a "normal" PCIe endpoint when attached to
a root bus.  So we can remove the check for root bus within virtio and
allow (at the user's discretion) a PCIe virtio bus to be attached to a
root bus.


If Marcel thinks this is a good change, then I think we should go
through "docs/pcie.txt" with a fine-toothed comb, and update all
relevant spots. (If Marcel agrees, perhaps you can include such
hunks in your patch at once.)


Actually, I think that would be a neverending process.  Maybe better
to put in a whole different spa

Re: [Qemu-devel] [PATCH v5 08/10] PC: Support dynamic sysbus on pc_i440fx

[Marcel Apfelbaum]

On 02/06/2017 06:31 PM, Michael S. Tsirkin wrote:

On Sun, Feb 05, 2017 at 01:12:03AM -0800, b...@skyportsystems.com wrote:

From: Ben Warren 

This allows pc_i440fx-based machines to add new devices such as
VM Generation ID directly to the sysbus.

Signed-off-by: Ben Warren 




Hi,


Only point is, we might have to add more flags like
cannot_instantiate_with_device_add_yet
to a bunch of devices.

Marcel, you did a similar thing for q35, can you
take a look here as well pls?



The change is a must because the new vmgenid device
is a sysbus device and QEMU will not allow it without
marking explicitly that i440fx supports sysbus device.

As you already mentioned, we need to make sure that
all sysbus devices that can be added to the PC machines
are marked with "cannot_instantiate_with_device_add_yet".

Sadly I see no easy way, but going manually over each one...

Thanks,
Marcel


---
 hw/i386/pc_piix.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 9f102aa..c8ad99c 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -435,6 +435,7 @@ static void pc_i440fx_machine_options(MachineClass *m)
 m->hot_add_cpu = pc_hot_add_cpu;
 m->default_machine_opts = "firmware=bios-256k.bin";
 m->default_display = "std";
+m->has_dynamic_sysbus = true;
 }

 static void pc_i440fx_2_9_machine_options(MachineClass *m)
--
2.7.4

[Qemu-devel] beginning contribution

[Shubham Kumar]

Can I start with any of the tasks listed on  
http://wiki.qemu-project.org/index.php/Contribute/BiteSizedTasks
and submit the changes ??

Regards
Shubham Kumar

Re: [Qemu-devel] [PULL 050/107] prep: add IBM RS/6000 7020 (40p) machine emulation

[Artyom Tarasenko]

On Thu, Feb 2, 2017 at 6:13 AM, David Gibson
 wrote:
> From: Hervé Poussineau 
>
> Machine supports both Open Hack'Ware and OpenBIOS.
> Open Hack'Ware is the default because OpenBIOS is currently unable to boot
> PReP boot partitions or PReP kernels.
>
> Signed-off-by: Hervé Poussineau 
> [dwg: Correct compile failure with KVM located by Thomas Huth]
> Signed-off-by: David Gibson 
> ---
>  default-configs/ppc-softmmu.mak |   1 +
>  hw/ppc/prep.c   | 230 
> 
>  2 files changed, 231 insertions(+)
>
> diff --git a/default-configs/ppc-softmmu.mak b/default-configs/ppc-softmmu.mak
> index e567658..7dd004e 100644
> --- a/default-configs/ppc-softmmu.mak
> +++ b/default-configs/ppc-softmmu.mak
> @@ -18,6 +18,7 @@ CONFIG_I82378=y
>  CONFIG_PC87312=y
>  CONFIG_MACIO=y
>  CONFIG_PCSPK=y
> +CONFIG_CS4231A=y
>  CONFIG_CUDA=y
>  CONFIG_ADB=y
>  CONFIG_MAC_NVRAM=y
> diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
> index 9fb89d3..ca7959c 100644
> --- a/hw/ppc/prep.c
> +++ b/hw/ppc/prep.c
> @@ -2,6 +2,7 @@
>   * QEMU PPC PREP hardware System Emulator
>   *
>   * Copyright (c) 2003-2007 Jocelyn Mayer
> + * Copyright (c) 2017 Hervé Poussineau
>   *
>   * Permission is hereby granted, free of charge, to any person obtaining a 
> copy
>   * of this software and associated documentation files (the "Software"), to 
> deal
> @@ -43,17 +44,21 @@
>  #include "hw/isa/pc87312.h"
>  #include "sysemu/block-backend.h"
>  #include "sysemu/arch_init.h"
> +#include "sysemu/kvm.h"
>  #include "sysemu/qtest.h"
>  #include "exec/address-spaces.h"
>  #include "trace.h"
>  #include "elf.h"
>  #include "qemu/cutils.h"
> +#include "kvm_ppc.h"
>
>  /* SMP is not enabled, for now */
>  #define MAX_CPUS 1
>
>  #define MAX_IDE_BUS 2
>
> +#define CFG_ADDR 0xf510
> +
>  #define BIOS_SIZE (1024 * 1024)
>  #define BIOS_FILENAME "ppc_rom.bin"
>  #define KERNEL_LOAD_ADDR 0x0100
> @@ -316,6 +321,12 @@ static uint32_t PREP_io_800_readb (void *opaque, 
> uint32_t addr)
>
>  #define NVRAM_SIZE0x2000
>
> +static void fw_cfg_boot_set(void *opaque, const char *boot_device,
> +Error **errp)
> +{
> +fw_cfg_modify_i16(opaque, FW_CFG_BOOT_DEVICE, boot_device[0]);
> +}
> +
>  static void ppc_prep_reset(void *opaque)
>  {
>  PowerPCCPU *cpu = opaque;
> @@ -677,4 +688,223 @@ static void prep_machine_init(MachineClass *mc)
>  mc->default_boot_order = "cad";
>  }
>
> +static int prep_set_cmos_checksum(DeviceState *dev, void *opaque)
> +{
> +uint16_t checksum = *(uint16_t *)opaque;
> +ISADevice *rtc;
> +
> +if (object_dynamic_cast(OBJECT(dev), "mc146818rtc")) {
> +rtc = ISA_DEVICE(dev);
> +rtc_set_memory(rtc, 0x2e, checksum & 0xff);
> +rtc_set_memory(rtc, 0x3e, checksum & 0xff);
> +rtc_set_memory(rtc, 0x2f, checksum >> 8);
> +rtc_set_memory(rtc, 0x3f, checksum >> 8);
> +}
> +return 0;
> +}
> +
> +static void ibm_40p_init(MachineState *machine)
> +{
> +CPUPPCState *env = NULL;
> +uint16_t cmos_checksum;
> +PowerPCCPU *cpu;
> +DeviceState *dev;
> +SysBusDevice *pcihost;
> +Nvram *m48t59 = NULL;
> +PCIBus *pci_bus;
> +ISABus *isa_bus;
> +void *fw_cfg;
> +int i;
> +uint32_t kernel_base = 0, initrd_base = 0;
> +long kernel_size = 0, initrd_size = 0;
> +char boot_device;
> +
> +/* init CPU */
> +if (!machine->cpu_model) {
> +machine->cpu_model = "604";
> +}
> +cpu = cpu_ppc_init(machine->cpu_model);
> +if (!cpu) {
> +error_report("could not initialize CPU '%s'",
> + machine->cpu_model);
> +exit(1);
> +}
> +env = &cpu->env;
> +if (PPC_INPUT(env) != PPC_FLAGS_INPUT_6xx) {
> +error_report("only 6xx bus is supported on this machine");
> +exit(1);
> +}
> +
> +if (env->flags & POWERPC_FLAG_RTC_CLK) {
> +/* POWER / PowerPC 601 RTC clock frequency is 7.8125 MHz */
> +cpu_ppc_tb_init(env, 7812500UL);

Is this necessary? Looks like it sets both decrementer and cpu
frequency to 7.8125 MHz,
so the machine with -cpu 601 is working very slow.

> +} else {
> +/* Set time-base frequency to 100 Mhz */
> +cpu_ppc_tb_init(env, 100UL * 1000UL * 1000UL);
> +}
> +qemu_register_reset(ppc_prep_reset, cpu);
> +
> +/* PCI host */
> +dev = qdev_create(NULL, "raven-pcihost");
> +if (!bios_name) {
> +bios_name = BIOS_FILENAME;
> +}
> +qdev_prop_set_string(dev, "bios-name", bios_name);
> +qdev_prop_set_uint32(dev, "elf-machine", PPC_ELF_MACHINE);
> +pcihost = SYS_BUS_DEVICE(dev);
> +object_property_add_child(qdev_get_machine(), "raven", OBJECT(dev), 
> NULL);
> +qdev_init_nofail(dev);
> +pci_bus = PCI_BUS(qdev_get_child_bus(dev, "pci.0"));
> +if (!pci_bus) {
> +error_report("could not create PCI host controller");
> +exit(1);
> +}
> +
> +/* PCI -> ISA bridge */
> +dev = DE

[Qemu-devel] AIX KDB under 40p

[Artyom Tarasenko]

With -cpu 601 it's slow, but interesting:

qemu-system-ppc -M 40p -bios p12h0456.img -hda aix-5.1-cd1.iso -cpu 601

^^^ -cpu 601 is crucial. With the default CPU (604) it just hangs
after a greeting.

 And after 90 minutes,  on the serial line

AIX Version pinmore.c, s.@(#)65 1.1
Instruction Storage Interrupt - PROC
[kdb_get_virtual_memory] no real storage @ 646E6D60
KDB(0)> f
pvthread+00 STACK:
WARNING: bad IAR: 646E6D60, display stack from LR: 646E6D5D
KDB(0)>
KDB(0)> dr
r0  :   r1  : 00595910  r2  : 00595C58  r3  : 0001  r4  : 01C08180
r5  :   r6  :   r7  :   r8  :   r9  : 
r10 :   r11 :   r12 : 646E6D61  r13 : 00606178  r14 : 00B8
r15 : 0020  r16 : 0020  r17 : 0803004D  r18 : 005AF0BC  r19 : 003FED04
r20 : 00606178  r21 : 0020  r22 : 00606000  r23 : 3F50  r24 : 3F48
r25 : 3F3C  r26 :   r27 : 63683A2C  r28 : 3A24  r29 : 3A20
r30 : 00590C70  r31 : 
KDB(0)>



-- 
Regards,
Artyom Tarasenko

SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu

[Qemu-devel] [PATCH 0/2] m68k: Update MCF interrupt controller and MAINTAINERS

[Thomas Huth]

Here's a patch to QOMify the ColdFire interrupt controller, and
another patch to update MAINTAINERS - I'd like to volunteer to
maintain the two orphan ColdFire machines.

Thomas Huth (2):
  hw/m68k: QOMify the ColdFire interrupt controller
  MAINTAINERS: Add odd fixer the ColdFire boards

 MAINTAINERS|  7 +--
 hw/m68k/mcf_intc.c | 48 
 2 files changed, 49 insertions(+), 6 deletions(-)

-- 
2.7.4

[Qemu-devel] [PATCH 2/2] MAINTAINERS: Add odd fixer the ColdFire boards

[Thomas Huth]

I did some work with real ColdFire boards in the past, and after
QOMifying most of the ColdFire devices recently, too, I feel confident
that I could at least take care of odd fixes for these boards.

Signed-off-by: Thomas Huth 
---
 MAINTAINERS | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7afbada..4fb2ed0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -561,7 +561,8 @@ F: hw/lm32/milkymist.c
 M68K Machines
 -
 an5206
-S: Orphan
+M: Thomas Huth 
+S: Odd Fixes
 F: hw/m68k/an5206.c
 F: hw/m68k/mcf5206.c
 
@@ -570,11 +571,13 @@ S: Orphan
 F: hw/m68k/dummy_m68k.c
 
 mcf5208
-S: Orphan
+M: Thomas Huth 
+S: Odd Fixes
 F: hw/m68k/mcf5208.c
 F: hw/m68k/mcf_intc.c
 F: hw/char/mcf_uart.c
 F: hw/net/mcf_fec.c
+F: include/hw/m68k/mcf*.h
 
 MicroBlaze Machines
 ---
-- 
2.7.4

[Qemu-devel] [PATCH 1/2] hw/m68k: QOMify the ColdFire interrupt controller

[Thomas Huth]

Use type_init() and friends to adapt the ColdFire interrupt
controller to the latest QEMU device conventions.

Signed-off-by: Thomas Huth 
---
 hw/m68k/mcf_intc.c | 48 
 1 file changed, 44 insertions(+), 4 deletions(-)

diff --git a/hw/m68k/mcf_intc.c b/hw/m68k/mcf_intc.c
index cf58132..8198afa 100644
--- a/hw/m68k/mcf_intc.c
+++ b/hw/m68k/mcf_intc.c
@@ -9,10 +9,16 @@
 #include "qemu-common.h"
 #include "cpu.h"
 #include "hw/hw.h"
+#include "hw/sysbus.h"
 #include "hw/m68k/mcf.h"
 #include "exec/address-spaces.h"
 
+#define TYPE_MCF_INTC "mcf-intc"
+#define MCF_INTC(obj) OBJECT_CHECK(mcf_intc_state, (obj), TYPE_MCF_INTC)
+
 typedef struct {
+SysBusDevice parent_obj;
+
 MemoryRegion iomem;
 uint64_t ipr;
 uint64_t imr;
@@ -138,8 +144,10 @@ static void mcf_intc_set_irq(void *opaque, int irq, int 
level)
 mcf_intc_update(s);
 }
 
-static void mcf_intc_reset(mcf_intc_state *s)
+static void mcf_intc_reset(DeviceState *dev)
 {
+mcf_intc_state *s = MCF_INTC(dev);
+
 s->imr = ~0ull;
 s->ipr = 0;
 s->ifr = 0;
@@ -154,17 +162,49 @@ static const MemoryRegionOps mcf_intc_ops = {
 .endianness = DEVICE_NATIVE_ENDIAN,
 };
 
+static void mcf_intc_instance_init(Object *obj)
+{
+mcf_intc_state *s = MCF_INTC(obj);
+
+memory_region_init_io(&s->iomem, obj, &mcf_intc_ops, s, "mcf", 0x100);
+}
+
+static void mcf_intc_class_init(ObjectClass *oc, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(oc);
+
+set_bit(DEVICE_CATEGORY_MISC, dc->categories);
+dc->reset = mcf_intc_reset;
+}
+
+static const TypeInfo mcf_intc_gate_info = {
+.name  = TYPE_MCF_INTC,
+.parent= TYPE_SYS_BUS_DEVICE,
+.instance_size = sizeof(mcf_intc_state),
+.instance_init = mcf_intc_instance_init,
+.class_init= mcf_intc_class_init,
+};
+
+static void mcf_intc_register_types(void)
+{
+type_register_static(&mcf_intc_gate_info);
+}
+
+type_init(mcf_intc_register_types)
+
 qemu_irq *mcf_intc_init(MemoryRegion *sysmem,
 hwaddr base,
 M68kCPU *cpu)
 {
+DeviceState  *dev;
 mcf_intc_state *s;
 
-s = g_malloc0(sizeof(mcf_intc_state));
+dev = qdev_create(NULL, TYPE_MCF_INTC);
+qdev_init_nofail(dev);
+
+s = MCF_INTC(dev);
 s->cpu = cpu;
-mcf_intc_reset(s);
 
-memory_region_init_io(&s->iomem, NULL, &mcf_intc_ops, s, "mcf", 0x100);
 memory_region_add_subregion(sysmem, base, &s->iomem);
 
 return qemu_allocate_irqs(mcf_intc_set_irq, s, 64);
-- 
2.7.4

Re: [Qemu-devel] [PATCH] nios2: Add Altera JTAG UART emulation

[Marek Vasut]

On 02/12/2017 07:55 PM, Juro Bystricky wrote:

Subject should contain [PATCH v5] ...

> Add the Altera JTAG UART model.
> 
> Hardware emulation based on:
> https://www.altera.com/en_US/pdfs/literature/ug/ug_embedded_ip.pdf
> (Please see "Register Map" on page 65)

[...]

> +static void altera_juart_write(void *opaque, hwaddr addr,
> +   uint64_t value, unsigned int size)
> +{
> +AlteraJUARTState *s = opaque;
> +unsigned char c;
> +
> +switch (addr) {
> +case OFFSET_R_DATA:
> +c = value & 0xFF;
> +/*
> + * We do not decrement the write fifo,
> + * we "tranmsmit" instanteniously, CONTROL_WI always asserted

Nit, fix this comment (transmit, instantly) and it's alignment.

I don't quite understand what this comment is trying to tell me though.

> + */
> +s->jcontrol |= CONTROL_WI;
> +s->jdata = c;
> +qemu_chr_fe_write(&s->chr, &c, 1);
> +altera_juart_update_irq(s);
> +break;
> +
> +case OFFSET_R_CONTROL:
> +/* Only RE and WE are writable */
> +value &= CONTROL_WMASK;
> +s->jcontrol &= ~CONTROL_WMASK;
> +s->jcontrol |= value;
> +
> +/* Writing 1 to AC clears it to 0 */
> +if (value & CONTROL_AC) {
> +s->jcontrol &= ~CONTROL_AC;
> +}
> +altera_juart_update_irq(s);
> +break;
> +}
> +}

[...]

> +void altera_juart_create(int channel, const hwaddr addr, qemu_irq irq, 
> uint32_t fifo_size)
> +{
> +DeviceState *dev;
> +SysBusDevice *bus;
> +Chardev *chr;
> +const char chr_name[] = "juart";
> +char label[ARRAY_SIZE(chr_name) + 1];
> +
> +dev = qdev_create(NULL, TYPE_ALTERA_JUART);
> +
> +if (channel >= MAX_SERIAL_PORTS) {
> +error_report("Only %d serial ports are supported by QEMU",
> + MAX_SERIAL_PORTS);
> +exit(1);
> +}
> +
> +chr = serial_hds[channel];
> +if (!chr) {
> +snprintf(label, ARRAY_SIZE(label), "%s%d", chr_name, channel);
> +chr = qemu_chr_new(label, "null");
> +if (!chr) {
> +error_report("Failed to assign serial port to altera %s", label);
> +exit(1);
> +}
> +}
> +qdev_prop_set_chr(dev, "chardev", chr);
> +
> +/*
> + * FIFO size can be set from 8 to 32,768 bytes.
> + * Only powers of two are allowed.
> + */
> +if (fifo_size < 8 || fifo_size > 3276 || (fifo_size & ~(1 << 
> ctz32(fifo_size {

32768 , not 3276 ...

> +error_report("juart%d: Invalid FIFO size. [%u]", channel, fifo_size);
> +exit(1);
> +}
> +
> +qdev_prop_set_uint32(dev, "fifo-size", fifo_size);
> +bus = SYS_BUS_DEVICE(dev);
> +qdev_init_nofail(dev);
> +
> +if (addr != (hwaddr)-1) {
> +sysbus_mmio_map(bus, 0, addr);
> +}
> +
> +sysbus_connect_irq(bus, 0, irq);
> +}

[...]

> +typedef struct AlteraJUARTState {
> +SysBusDevice busdev;
> +MemoryRegion mmio;
> +CharBackend chr;
> +qemu_irq irq;
> +
> +unsigned int rx_fifo_size;
> +unsigned int rx_fifo_pos;
> +unsigned int rx_fifo_len;
> +uint32_t jdata;
> +uint32_t jcontrol;
> +uint8_t *rx_fifo;
> +} AlteraJUARTState;
> +
> +void altera_juart_create(int channel, const hwaddr addr, qemu_irq irq,
> +uint32_t fifo_size);

Fix the alignment here so it doesn't look so braindead, align under the
first open parenthesis.

> +#endif /* ALTERA_JUART_H */
> 


-- 
Best regards,
Marek Vasut

Re: [Qemu-devel] beginning contribution

[Fam Zheng]

On Mon, 02/13 01:26, Shubham Kumar wrote:
> 
> Can I start with any of the tasks listed on  
> http://wiki.qemu-project.org/index.php/Contribute/BiteSizedTasks
> and submit the changes ??

Yes, you are welcome to! Please see also
http://wiki.qemu-project.org/Contribute/SubmitAPatch for how to submit a change.

Fam

Re: [Qemu-devel] [PATCH 0/3] ppc: replace debug printf with trace points

[David Gibson]

On Fri, Feb 10, 2017 at 10:27:21AM +0100, Laurent Vivier wrote:
> This series replaces the remaining DPRINTF()
> found under hw/ppc and replace them with trace
> points.
> 
> Laurent Vivier (3):
>   mac99: replace debug printf with trace points
>   ppc4xx: replace debug printf with trace points
>   spapr: replace debug printf with trace points
> 
>  hw/ppc/mac_newworld.c | 15 +++
>  hw/ppc/ppc4xx_pci.c   | 13 +++--
>  hw/ppc/spapr_ovec.c   | 17 +++--
>  hw/ppc/trace-events   | 12 
>  4 files changed, 21 insertions(+), 36 deletions(-)

Applied to ppc-for-2.9, thanks.


-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH v5 08/10] PC: Support dynamic sysbus on pc_i440fx

[Ben Warren]

Hi
> On Feb 12, 2017, at 11:55 AM, Marcel Apfelbaum  
> wrote:
> 
> On 02/06/2017 06:31 PM, Michael S. Tsirkin wrote:
>> On Sun, Feb 05, 2017 at 01:12:03AM -0800, b...@skyportsystems.com wrote:
>>> From: Ben Warren 
>>> 
>>> This allows pc_i440fx-based machines to add new devices such as
>>> VM Generation ID directly to the sysbus.
>>> 
>>> Signed-off-by: Ben Warren 
>> 
> 
> Hi,
> 
>> Only point is, we might have to add more flags like
>> cannot_instantiate_with_device_add_yet
>> to a bunch of devices.
>> 
>> Marcel, you did a similar thing for q35, can you
>> take a look here as well pls?
>> 
> 
> The change is a must because the new vmgenid device
> is a sysbus device and QEMU will not allow it without
> marking explicitly that i440fx supports sysbus device.
> 
As recommended by Igor, I was able to make the vmgenid work with DeviceClass as 
parent (i.e. not on sysbus), so this work can be deferred until it’s really 
needed.  The next patch set (hopefully posted tonight) will drop this patch.
> As you already mentioned, we need to make sure that
> all sysbus devices that can be added to the PC machines
> are marked with "cannot_instantiate_with_device_add_yet".
> 
> Sadly I see no easy way, but going manually over each one...
> 
> Thanks,
> Marcel
> 
—Ben
>>> ---
>>> hw/i386/pc_piix.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>> 
>>> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
>>> index 9f102aa..c8ad99c 100644
>>> --- a/hw/i386/pc_piix.c
>>> +++ b/hw/i386/pc_piix.c
>>> @@ -435,6 +435,7 @@ static void pc_i440fx_machine_options(MachineClass *m)
>>> m->hot_add_cpu = pc_hot_add_cpu;
>>> m->default_machine_opts = "firmware=bios-256k.bin";
>>> m->default_display = "std";
>>> +m->has_dynamic_sysbus = true;
>>> }
>>> 
>>> static void pc_i440fx_2_9_machine_options(MachineClass *m)
>>> --
>>> 2.7.4
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [Qemu-devel] [PATCH] nios2: Add Altera JTAG UART emulation

[Bystricky, Juro]

> Subject should contain [PATCH v5] ...

mea culpa, to my defense I did specify --subject-prefix="PATCH v5" 
but did not realize "git send-email file.patch" seems to ignore it

Normally I do something like this (which works fine):
"git send-email -1 --subject-prefix="PATCH v5" 


[...]

> > + * We do not decrement the write fifo,
> > + * we "tranmsmit" instanteniously, CONTROL_WI always asserted
> 
> Nit, fix this comment (transmit, instantly) and it's alignment.
> 
> I don't quite understand what this comment is trying to tell me though.
>
comment removed as too confusing

> > +/*
> > + * FIFO size can be set from 8 to 32,768 bytes.
> > + * Only powers of two are allowed.
> > + */
> > +if (fifo_size < 8 || fifo_size > 3276 || (fifo_size & ~(1 <<
> ctz32(fifo_size {
> 
> 32768 , not 3276 ...

Thanks, good catch. Fixed.

[...]

> > +void altera_juart_create(int channel, const hwaddr addr, qemu_irq irq,
> > +uint32_t
> fifo_size);
> 
> Fix the alignment here so it doesn't look so braindead, align under the
> first open parenthesis.
> 

Fixed

Thanks

Juro

[Qemu-devel] [PATCH v6] nios2: Add Altera JTAG UART emulation

[Juro Bystricky]

Add the Altera JTAG UART model.

Hardware emulation based on:
https://www.altera.com/en_US/pdfs/literature/ug/ug_embedded_ip.pdf
(Please see "Register Map" on page 65)

Signed-off-by: Juro Bystricky 
---
V2: - Removed link to hw specs(checkpatch: line over 90 characters)
V3: - New link to do hw specs
V4: - Modified check for correct fifo size
- Made fifo_size a property
- Use register offsets instead of register indeces
- Removed redundant test for fifo overflow
- Modified commit message
V5: - definine ALTERA_JTAG_UART_REGS_MEM_SIZE 
- Modified commit message
- Replaced DEFAULT_FIFO_SIZE by ALTERA_JUART_DEFAULT_FIFO_SIZE
- Modified test for fifo size
- Simplified error message in altera_juart_create().
V6: - Removed confusing comments in altera_juart_write()
- Fixed error in altera_juart_create: max fifo size is 32768 not 3276
- altera_juart.h: fixed function prototype alignment
---
 default-configs/nios2-softmmu.mak |   1 +
 hw/char/Makefile.objs |   1 +
 hw/char/altera_juart.c| 278 ++
 include/hw/char/altera_juart.h|  46 +++
 4 files changed, 326 insertions(+)
 create mode 100644 hw/char/altera_juart.c
 create mode 100644 include/hw/char/altera_juart.h

diff --git a/default-configs/nios2-softmmu.mak 
b/default-configs/nios2-softmmu.mak
index 74dc70c..6159846 100644
--- a/default-configs/nios2-softmmu.mak
+++ b/default-configs/nios2-softmmu.mak
@@ -4,3 +4,4 @@ CONFIG_NIOS2=y
 CONFIG_SERIAL=y
 CONFIG_PTIMER=y
 CONFIG_ALTERA_TIMER=y
+CONFIG_ALTERA_JUART=y
diff --git a/hw/char/Makefile.objs b/hw/char/Makefile.objs
index 6ea76fe..f0d0e25 100644
--- a/hw/char/Makefile.objs
+++ b/hw/char/Makefile.objs
@@ -27,5 +27,6 @@ common-obj-$(CONFIG_LM32) += lm32_juart.o
 common-obj-$(CONFIG_LM32) += lm32_uart.o
 common-obj-$(CONFIG_MILKYMIST) += milkymist-uart.o
 common-obj-$(CONFIG_SCLPCONSOLE) += sclpconsole.o sclpconsole-lm.o
+common-obj-$(CONFIG_ALTERA_JUART) += altera_juart.o
 
 obj-$(CONFIG_VIRTIO) += virtio-serial-bus.o
diff --git a/hw/char/altera_juart.c b/hw/char/altera_juart.c
new file mode 100644
index 000..21baf66
--- /dev/null
+++ b/hw/char/altera_juart.c
@@ -0,0 +1,278 @@
+/*
+ * QEMU model of the Altera JTAG UART.
+ *
+ * Copyright (c) 2016-2017 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ *
+ * The Altera JTAG UART hardware registers are described in:
+ * https://www.altera.com/en_US/pdfs/literature/ug/ug_embedded_ip.pdf
+ * (In particular "Register Map" on page 65)
+ */
+
+#include "qemu/osdep.h"
+#include "hw/char/altera_juart.h"
+#include "sysemu/sysemu.h"
+#include "qemu/error-report.h"
+
+/* Data register */
+#define OFFSET_R_DATA   0
+#define DATA_RVALID BIT(15)
+#define DATA_RAVAIL 0x
+
+/* Control register */
+#define OFFSET_R_CONTROL 4
+#define CONTROL_RE  BIT(0)
+#define CONTROL_WE  BIT(1)
+#define CONTROL_RI  BIT(8)
+#define CONTROL_WI  BIT(9)
+#define CONTROL_AC  BIT(10)
+#define CONTROL_WSPACE  0x
+
+#define CONTROL_WMASK (CONTROL_RE | CONTROL_WE | CONTROL_AC)
+
+#define TYPE_ALTERA_JUART "altera-juart"
+#define ALTERA_JUART(obj) \
+OBJECT_CHECK(AlteraJUARTState, (obj), TYPE_ALTERA_JUART)
+
+/* Two registers 4 bytes wide each */
+#define ALTERA_JTAG_UART_REGS_MEM_SIZE  (2 * 4)
+
+/*
+ * The JTAG UART core generates an interrupt when either of the individual
+ * interrupt conditions is pending and enabled.
+ */
+static void altera_juart_update_irq(AlteraJUARTState *s)
+{
+unsigned int irq;
+
+irq = ((s->jcontrol & CONTROL_WE) && (s->jcontrol & CONTROL_WI)) ||
+  ((s->jcontrol & CONTROL_RE) && (s->jcontrol & CONTROL_RI));
+
+qemu_set_irq(s->irq, irq);
+}
+
+static uint64_t altera_juart_read(void *opaque, hwaddr addr, unsigned int size)
+{
+AlteraJUARTState *s = opaque;
+uint32_t r;
+
+switch (addr) {
+case OFFSET_R_DATA:
+r = s->rx_fifo[(s->rx_fifo_pos - s->rx_fifo_len) & (s->rx_fifo_size - 
1)];
+if (s->rx_fifo_len) {
+s->rx_fifo_len--;
+qemu_chr_fe_accept_input(&s->chr);
+s->jdata = r | DATA_RVALID | (s->rx_fifo_len << 16);
+s->jcontrol |= CONTROL_RI;
+} else {
+s->jdata = 0;
+s->jcontrol &= ~CONTROL_RI;
+}
+
+altera_juart_update_irq(s);
+return s->jdata;
+
+case OFFSET_R_CONTROL:
+return s->jcontrol;
+}
+
+return 0;
+}
+
+static void altera_juart_write(void *opaque, hwaddr addr,
+   uint64_t value, unsigned int size)
+{
+AlteraJUARTState *s = opaque;
+   

Re: [Qemu-devel] [QEMU-PPC] [PATCH V2 05/10] target/ppc: Add patb_entry to sPAPRMachineState

[David Gibson]

On Fri, Feb 10, 2017 at 04:25:55PM +1100, Suraj Jitindar Singh wrote:
> ISA v3.00 adds the idea of a partition table which is used to store the
> address translation details for all partitions on the system. The partition
> table consists of double word entries indexed by partition id where the second
> double word contains the location of the process table in guest memory. The
> process table is registered by the guest via a h-call.
> 
> We need somewhere to store the address of the process table so we add an entry
> to the sPAPRMachineState struct called patb_entry to represent the second
> doubleword of a single partition table entry corresponding to the current
> guest. We need to store this value so we know if the guest is using radix or
> hash translation and the location of the corresponding process table in guest
> memory. Since we only have a single guest per qemu instance, we only need one
> entry.
> 
> Since the partition table is technically a hypervisor resource we require that
> access to it is abstracted by the virtual hypervisor through the calls
> [set/get]_patbe(). Currently the value of the entry is never set (and thus
> defaults to 0 indicating hash), but it will be required to both implement
> POWER9 kvm support and tcg radix support.
> 
> We also add this field to be migrated as part of the sPAPRMachineState as we
> will need it on the receiving side as the guest will never tell us this
> information again and we need it to perform translation.
> 
> Signed-off-by: Suraj Jitindar Singh 
> ---
>  hw/ppc/spapr.c | 19 +++
>  include/hw/ppc/spapr.h |  1 +
>  target/ppc/cpu.h   |  2 ++
>  3 files changed, 22 insertions(+)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index e465d7a..057adae 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -1018,6 +1018,20 @@ static void 
> emulate_spapr_hypercall(PPCVirtualHypervisor *vhyp,
>  }
>  }
>  
> +static void spapr_set_patbe(PPCVirtualHypervisor *vhyp, uint64_t val)
> +{
> +sPAPRMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
> +
> +spapr->patb_entry = val;
> +}
> +
> +static uint64_t spapr_get_patbe(PPCVirtualHypervisor *vhyp)
> +{
> +sPAPRMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());

So, it'll amount to the same thing of course, but using
SPAPR_MACHINE(vhyp) here is a little more logically correct.

> +
> +return spapr->patb_entry;
> +}
> +
>  #define HPTE(_table, _i)   (void *)(((uint64_t *)(_table)) + ((_i) * 2))
>  #define HPTE_VALID(_hpte)  (tswap64(*((uint64_t *)(_hpte))) & HPTE64_V_VALID)
>  #define HPTE_DIRTY(_hpte)  (tswap64(*((uint64_t *)(_hpte))) & 
> HPTE64_V_HPTE_DIRTY)
> @@ -1141,6 +1155,8 @@ static void ppc_spapr_reset(void)
>  /* Check for unknown sysbus devices */
>  foreach_dynamic_sysbus_device(find_unknown_sysbus_device, NULL);
>  
> +spapr->patb_entry = 0;

I'm assuming that the patb_entry has some control bits making this
distinguishable from a process table at GPA 0?

>  /* Allocate and/or reset the hash page table */
>  spapr_reallocate_hpt(spapr,
>   spapr_hpt_shift_for_ramsize(machine->maxram_size),
> @@ -1340,6 +1356,7 @@ static const VMStateDescription vmstate_spapr = {
>  VMSTATE_UINT64_TEST(rtc_offset, sPAPRMachineState, version_before_3),
>  
>  VMSTATE_PPC_TIMEBASE_V(tb, sPAPRMachineState, 2),
> +VMSTATE_UINT64(patb_entry, sPAPRMachineState),

Ah.. yeah, you can't just add things to the VMStateDescription,
because that'll break parsing of existing migration streams.  You
could bump the version, but that breaks backwards migration.

So, the usual approach here is to add a new optional subsection - see
vmstate_spapr_ov5_cas for an example.  In this case you could have the
.needed function return true only if pathb_entry != 0 - so it won't be
transmitted for either POWER7/8 or for POWER9 in legacy mode, which
seems to make sense.

>  VMSTATE_END_OF_LIST()
>  },
>  .subsections = (const VMStateDescription*[]) {
> @@ -2733,6 +2750,8 @@ static void spapr_machine_class_init(ObjectClass *oc, 
> void *data)
>  nc->nmi_monitor_handler = spapr_nmi;
>  smc->phb_placement = spapr_phb_placement;
>  vhc->hypercall = emulate_spapr_hypercall;
> +vhc->set_patbe = spapr_set_patbe;
> +vhc->get_patbe = spapr_get_patbe;
>  }
>  
>  static const TypeInfo spapr_machine_info = {
> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> index a2d8964..c6a929a 100644
> --- a/include/hw/ppc/spapr.h
> +++ b/include/hw/ppc/spapr.h
> @@ -63,6 +63,7 @@ struct sPAPRMachineState {
>  
>  void *htab;
>  uint32_t htab_shift;
> +uint64_t patb_entry; /* Process tbl registed in H_REGISTER_PROCESS_TABLE 
> */
>  hwaddr rma_size;
>  int vrma_adjust;
>  ssize_t rtas_size;
> diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
> index 425e79d..a148729 100644
> --- a/target/ppc/cpu.h
> +++ b/target/ppc/cpu.h
> @@ -1218,6 +1218,8 @@ struct PPCVirtua

Re: [Qemu-devel] [QEMU-PPC] [PATCH V2 02/10] target/ppc: Fix LPCR DPFD mask define

[David Gibson]

On Fri, Feb 10, 2017 at 04:25:52PM +1100, Suraj Jitindar Singh wrote:
> The DPFD field in the LPCR is 3 bits wide. This has always been defined
> as 0x3 << shift which indicates a 2 bit field, which is incorrect.
> Correct this.
> 
> Signed-off-by: Suraj Jitindar Singh 

Since this is a correct fix all on its own, I've applied it to
ppc-for-2.9.

> ---
>  target/ppc/cpu.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
> index bc2a2ce..bb96dd5 100644
> --- a/target/ppc/cpu.h
> +++ b/target/ppc/cpu.h
> @@ -381,7 +381,7 @@ struct ppc_slb_t {
>  #define LPCR_ISL  (1ull << (63 - 2))
>  #define LPCR_KBV  (1ull << (63 - 3))
>  #define LPCR_DPFD_SHIFT   (63 - 11)
> -#define LPCR_DPFD (0x3ull << LPCR_DPFD_SHIFT)
> +#define LPCR_DPFD (0x7ull << LPCR_DPFD_SHIFT)
>  #define LPCR_VRMASD_SHIFT (63 - 16)
>  #define LPCR_VRMASD   (0x1full << LPCR_VRMASD_SHIFT)
>  #define LPCR_RMLS_SHIFT   (63 - 37)

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 0/7] POWER9 TCG and softfloat enablements - part16 + s390 float fixes

[David Gibson]

On Fri, Feb 10, 2017 at 12:53:04PM +0530, Bharata B Rao wrote:
> This series contains 2 new instructions (xscvqpudz, xscvqpuwz) and
> round-to-odd variants of 6 instructions (xsaddqpo, xsmulqpo, xsdivqpo,
> xscvqpdpo, xssqrtqpo, xssubqpo)
>  
> This also includes softfloat enhancements that are needed by
> the above instructions. These softfloat patches have been posted
> separately earlier and reviewed. Including them here as the new
> instructions here depend on them.
> 
> I also saw that target-s390 also needs float128_to_uint64() and
> float128_to_uint32(). Implemented the latter in this series and
> made fixes in s390 code to use them. Note that s390 changes have
> been compile-tested only. The last two patches ideally needn't
> be part of this series, but included them here as s390 fixes
> depend on the softfloat changes that are part of this patchset.

4 & 5 also applied to my tree.  6 & 7 I'll leave to go through the
s390 tree.

> 
> Bharata B Rao (7):
>   softfloat: Add round-to-odd rounding mode
>   softfloat: Add float128_to_uint64_round_to_zero()
>   softfloat: Add float128_to_uint32_round_to_zero()
>   target-ppc: Implement round to odd variants of quad FP instructions
>   target-ppc: Add xscvqpudz and xscvqpuwz instructions
>   softfloat: Add float128_to_uint32()
>   target-s390: Use float128_to_uint[64/32] where required
> 
>  fpu/softfloat.c | 125 
> +++-
>  include/fpu/softfloat.h |   6 ++
>  target/ppc/fpu_helper.c |  44 ++---
>  target/ppc/helper.h |   2 +
>  target/ppc/translate/vsx-impl.inc.c |   2 +
>  target/ppc/translate/vsx-ops.inc.c  |   4 +-
>  target/s390x/fpu_helper.c   |   6 +-
>  7 files changed, 161 insertions(+), 28 deletions(-)
> 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 0/7] POWER9 TCG and softfloat enablements - part16 + s390 float fixes

[David Gibson]

On Fri, Feb 10, 2017 at 12:53:04PM +0530, Bharata B Rao wrote:
1;4601;0c> This series contains 2 new instructions (xscvqpudz, xscvqpuwz) and
> round-to-odd variants of 6 instructions (xsaddqpo, xsmulqpo, xsdivqpo,
> xscvqpdpo, xssqrtqpo, xssubqpo)
>  
> This also includes softfloat enhancements that are needed by
> the above instructions. These softfloat patches have been posted
> separately earlier and reviewed. Including them here as the new
> instructions here depend on them.
> 
> I also saw that target-s390 also needs float128_to_uint64() and
> float128_to_uint32(). Implemented the latter in this series and
> made fixes in s390 code to use them. Note that s390 changes have
> been compile-tested only. The last two patches ideally needn't
> be part of this series, but included them here as s390 fixes
> depend on the softfloat changes that are part of this patchset.

I've applied 1-3 to ppc-for-2.9, still looking at the rest.

> 
> Bharata B Rao (7):
>   softfloat: Add round-to-odd rounding mode
>   softfloat: Add float128_to_uint64_round_to_zero()
>   softfloat: Add float128_to_uint32_round_to_zero()
>   target-ppc: Implement round to odd variants of quad FP instructions
>   target-ppc: Add xscvqpudz and xscvqpuwz instructions
>   softfloat: Add float128_to_uint32()
>   target-s390: Use float128_to_uint[64/32] where required
> 
>  fpu/softfloat.c | 125 
> +++-
>  include/fpu/softfloat.h |   6 ++
>  target/ppc/fpu_helper.c |  44 ++---
>  target/ppc/helper.h |   2 +
>  target/ppc/translate/vsx-impl.inc.c |   2 +
>  target/ppc/translate/vsx-ops.inc.c  |   4 +-
>  target/s390x/fpu_helper.c   |   6 +-
>  7 files changed, 161 insertions(+), 28 deletions(-)
> 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 5/6] target-ppc: support for 32-bit carry and overflow

[David Gibson]

On Fri, Feb 10, 2017 at 09:49:17AM +0530, Nikunj A Dadhania wrote:
> David Gibson  writes:
> 
> > [ Unknown signature status ]
> > On Thu, Feb 09, 2017 at 04:04:04PM +0530, Nikunj A Dadhania wrote:
> >> POWER ISA 3.0 adds CA32 and OV32 status in 64-bit mode. Add the flags
> >> and corresponding defines. Moreover, CA32 is set when CA is set and
> >> OV32 is set when OV is set, there is no need to have a new
> >> fields in the CPUPPCState structure.
> >> 
> >> Signed-off-by: Nikunj A Dadhania 
> >
> > Um.. I don't quite understand this.  If CA always has the same value
> > as CA32, what's the point?
> 
> I am not clear either. I think that as CA was set for both 32/64-bit
> mode, that couldn't be changed for backward compatibility. CA32 should
> have affected only the instructions working one word variants.
> 
> Re-scanning the ISA 3.0, found this in 3.3.9 Fixed-Point Arithmetic
> Instructions:
> 
> =
> addic, addic., subfic, addc, subfc, adde, subfe,
> addme, subfme, addze, and subfze always set CA, to
> reflect the carry out of bit 0 in 64-bit mode and out of bit
> 32 in 32-bit mode. These instructions also always set
> CA32 to reflect the carry out of bit 32.
> =
> 
> Which is conflicting to what is said in 3.2.2 Fixed-Point Exception
> Register:
> =
> Carry32 (CA32)
> CA32 is set whenever CA is set, and is set to
> the same value that CA is defined to be set to
> in 32-bit mode.
> =

Well, that's certainly confusing.

Can you try and find out what's going on here within IBM, and repost
these patches once there's a straight story about how this bit works.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

[Qemu-devel] [Qemu-ppc] [PATCH] target/ppc: Stop parsing pvr list in H_CAS when exact match found

[Suraj Jitindar Singh]

The pvr-list passed in H_Client_Architecture_Support is used to
communicate the supported pvrs of the client program. When an
exact match is found you are allowed to stop parsing the list and continue
the boot process.

Currently while explicit_match is set when we find an exact match, we still
set a compat mode based on best_compat irrespective of whether an exact
match was found or not. This is wrong since it means we can only ever run
in an architected state, not a raw state since we always set a compat mode.
We are basically ignoring the case were we find an exact match.

Fix the code to stop parsing the pvr list when an exact match is found.
This means that best_compat will always be zero in the case of an exact
match which means we will not set a compat mode an thus run in raw mode,
which is the desired functionality when we have an exact match.

Fixes: 152ef803ceb1 ("pseries: Rewrite CAS PVR compatibility logic")

Signed-off-by: Suraj Jitindar Singh 

---
 hw/ppc/spapr_hcall.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 590105a..215c385 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -1028,6 +1028,7 @@ static target_ulong 
h_client_architecture_support(PowerPCCPU *cpu,
 
 if ((cpu->env.spr[SPR_PVR] & pvr_mask) == (pvr & pvr_mask)) {
 explicit_match = true;
+break;
 } else {
 if (ppc_check_compat(cpu, pvr, best_compat, max_compat)) {
 best_compat = pvr;
-- 
2.5.5

Re: [Qemu-devel] [QEMU-PPC] [PATCH V2 05/10] target/ppc: Add patb_entry to sPAPRMachineState

[Suraj Jitindar Singh]

On Mon, 2017-02-13 at 13:17 +1100, David Gibson wrote:
> On Fri, Feb 10, 2017 at 04:25:55PM +1100, Suraj Jitindar Singh wrote:
> > 
> > ISA v3.00 adds the idea of a partition table which is used to store
> > the
> > address translation details for all partitions on the system. The
> > partition
> > table consists of double word entries indexed by partition id where
> > the second
> > double word contains the location of the process table in guest
> > memory. The
> > process table is registered by the guest via a h-call.
> > 
> > We need somewhere to store the address of the process table so we
> > add an entry
> > to the sPAPRMachineState struct called patb_entry to represent the
> > second
> > doubleword of a single partition table entry corresponding to the
> > current
> > guest. We need to store this value so we know if the guest is using
> > radix or
> > hash translation and the location of the corresponding process
> > table in guest
> > memory. Since we only have a single guest per qemu instance, we
> > only need one
> > entry.
> > 
> > Since the partition table is technically a hypervisor resource we
> > require that
> > access to it is abstracted by the virtual hypervisor through the
> > calls
> > [set/get]_patbe(). Currently the value of the entry is never set
> > (and thus
> > defaults to 0 indicating hash), but it will be required to both
> > implement
> > POWER9 kvm support and tcg radix support.
> > 
> > We also add this field to be migrated as part of the
> > sPAPRMachineState as we
> > will need it on the receiving side as the guest will never tell us
> > this
> > information again and we need it to perform translation.
> > 
> > Signed-off-by: Suraj Jitindar Singh 
> > ---
> >  hw/ppc/spapr.c | 19 +++
> >  include/hw/ppc/spapr.h |  1 +
> >  target/ppc/cpu.h   |  2 ++
> >  3 files changed, 22 insertions(+)
> > 
> > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > index e465d7a..057adae 100644
> > --- a/hw/ppc/spapr.c
> > +++ b/hw/ppc/spapr.c
> > @@ -1018,6 +1018,20 @@ static void
> > emulate_spapr_hypercall(PPCVirtualHypervisor *vhyp,
> >  }
> >  }
> >  
> > +static void spapr_set_patbe(PPCVirtualHypervisor *vhyp, uint64_t
> > val)
> > +{
> > +sPAPRMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
> > +
> > +spapr->patb_entry = val;
> > +}
> > +
> > +static uint64_t spapr_get_patbe(PPCVirtualHypervisor *vhyp)
> > +{
> > +sPAPRMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
> So, it'll amount to the same thing of course, but using
> SPAPR_MACHINE(vhyp) here is a little more logically correct.
Ok, will fix that up
> 
> > 
> > +
> > +return spapr->patb_entry;
> > +}
> > +
> >  #define HPTE(_table, _i)   (void *)(((uint64_t *)(_table)) + ((_i)
> > * 2))
> >  #define HPTE_VALID(_hpte)  (tswap64(*((uint64_t *)(_hpte))) &
> > HPTE64_V_VALID)
> >  #define HPTE_DIRTY(_hpte)  (tswap64(*((uint64_t *)(_hpte))) &
> > HPTE64_V_HPTE_DIRTY)
> > @@ -1141,6 +1155,8 @@ static void ppc_spapr_reset(void)
> >  /* Check for unknown sysbus devices */
> >  foreach_dynamic_sysbus_device(find_unknown_sysbus_device,
> > NULL);
> >  
> > +spapr->patb_entry = 0;
> I'm assuming that the patb_entry has some control bits making this
> distinguishable from a process table at GPA 0?
Yeah, so process table size is also contained here which must be >= 24,
so this is technically an invalid entry, which is what we want for a
default value.
> 
> > 
> >  /* Allocate and/or reset the hash page table */
> >  spapr_reallocate_hpt(spapr,
> >   spapr_hpt_shift_for_ramsize(machine-
> > >maxram_size),
> > @@ -1340,6 +1356,7 @@ static const VMStateDescription vmstate_spapr
> > = {
> >  VMSTATE_UINT64_TEST(rtc_offset, sPAPRMachineState,
> > version_before_3),
> >  
> >  VMSTATE_PPC_TIMEBASE_V(tb, sPAPRMachineState, 2),
> > +VMSTATE_UINT64(patb_entry, sPAPRMachineState),
> Ah.. yeah, you can't just add things to the VMStateDescription,
> because that'll break parsing of existing migration streams.  You
> could bump the version, but that breaks backwards migration.
> 
> So, the usual approach here is to add a new optional subsection - see
> vmstate_spapr_ov5_cas for an example.  In this case you could have
> the
> .needed function return true only if pathb_entry != 0 - so it won't
> be
> transmitted for either POWER7/8 or for POWER9 in legacy mode, which
> seems to make sense.
Sounds like a good way of doing it which will behave how we want. I'll
do it like you suggest.
> 
> > 
> >  VMSTATE_END_OF_LIST()
> >  },
> >  .subsections = (const VMStateDescription*[]) {
> > @@ -2733,6 +2750,8 @@ static void
> > spapr_machine_class_init(ObjectClass *oc, void *data)
> >  nc->nmi_monitor_handler = spapr_nmi;
> >  smc->phb_placement = spapr_phb_placement;
> >  vhc->hypercall = emulate_spapr_hypercall;
> > +vhc->set_patbe = spapr_set_patbe;
> > +vhc->get_patbe = spapr_get_patbe;
> >  }
> > 

Re: [Qemu-devel] [QEMU-PPC] [PATCH V2 06/10] target/ppc: Don't use SDR1 when running under a POWER9 cpu model

[David Gibson]

On Fri, Feb 10, 2017 at 04:25:56PM +1100, Suraj Jitindar Singh wrote:
> The SDR1 register was used on pre-POWER9 processors to store the location
> of the hash page table, however now this information will be stored in the
> partition table so we don't have SDR1 anymore. Additionally this register
> was only applicable for powernv as it is a hypervisor resource and thus
> shouldn't be accessed on a pseries machine.
> 
> We no longer generate the SDR1 register if we are on a POWER9 or later cpu.
> We also rename the functions ppc_hash64_set_sdr1->ppc_hash64_set_htab and
> ppc_store_sdr1->ppc_store_htab to indicate that they are primarily
> concerned with setting htab_[base/mask].
> 
> We still set SDR1 in ppc_hash64_set_external_hpt for non-POWER9 cpus as
> this is used for kvm-pr to tell the hypervisor where the hash table is,
> note this means kvm-pr isn't yet supported on a POWER9 cpu model.
> 
> We set SDR1 in ppc_store_htab for non-POWER9 cpus as this is the called
> by the powernv machine code to restore the sdr1 (and htab_[mask/base])
> on incoming migration, note this means that the powernv machine isn't
> yet supported on a POWER9 cpu model.
> 
> We also adapt the debug code to only print the SDR1 value if the register
> has been created.
> 
> Signed-off-by: Suraj Jitindar Singh 

I think this is a bit over-enthusiastic in some places.

> ---
>  target/ppc/cpu.h|  2 +-
>  target/ppc/kvm.c|  2 +-
>  target/ppc/machine.c|  4 ++--
>  target/ppc/misc_helper.c|  3 ++-
>  target/ppc/mmu-hash64.c | 12 +---
>  target/ppc/mmu-hash64.h |  2 +-
>  target/ppc/mmu_helper.c | 12 +---
>  target/ppc/translate.c  |  7 +--
>  target/ppc/translate_init.c | 17 ++---
>  9 files changed, 44 insertions(+), 17 deletions(-)
> 
> diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
> index a148729..1ae0719 100644
> --- a/target/ppc/cpu.h
> +++ b/target/ppc/cpu.h
> @@ -1265,7 +1265,7 @@ int ppc_cpu_handle_mmu_fault(CPUState *cpu, vaddr 
> address, int rw,
>  #endif
>  
>  #if !defined(CONFIG_USER_ONLY)
> -void ppc_store_sdr1 (CPUPPCState *env, target_ulong value);
> +void ppc_store_htab(CPUPPCState *env, target_ulong value);
>  #endif /* !defined(CONFIG_USER_ONLY) */
>  void ppc_store_msr (CPUPPCState *env, target_ulong value);
>  
> diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> index 663d2e7..5e2323c 100644
> --- a/target/ppc/kvm.c
> +++ b/target/ppc/kvm.c
> @@ -1228,7 +1228,7 @@ static int kvmppc_get_books_sregs(PowerPCCPU *cpu)
>  }
>  
>  if (!env->external_htab) {
> -ppc_store_sdr1(env, sregs.u.s.sdr1);
> +ppc_store_htab(env, sregs.u.s.sdr1);

If the CPU has no SDR1, the sdr1 field in sregs can't really mean
anything, so the name change is not relevant here.

>  }
>  
>  /* Sync SLB */
> diff --git a/target/ppc/machine.c b/target/ppc/machine.c
> index df9f7a4..f6d5ade 100644
> --- a/target/ppc/machine.c
> +++ b/target/ppc/machine.c
> @@ -77,7 +77,7 @@ static int cpu_load_old(QEMUFile *f, void *opaque, int 
> version_id)
>  for (i = 0; i < 1024; i++)
>  qemu_get_betls(f, &env->spr[i]);
>  if (!env->external_htab) {
> -ppc_store_sdr1(env, sdr1);
> +ppc_store_htab(env, sdr1);

Likewise here - this function is only called reading an old migration
stream that expects an SDR1 to be present anyway.

>  }
>  qemu_get_be32s(f, &env->vscr);
>  qemu_get_be64s(f, &env->spe_acc);
> @@ -230,7 +230,7 @@ static int cpu_post_load(void *opaque, int version_id)
>  
>  if (!env->external_htab) {
>  /* Restore htab_base and htab_mask variables */
> -ppc_store_sdr1(env, env->spr[SPR_SDR1]);
> +ppc_store_htab(env, env->spr[SPR_SDR1]);

For POWER9 this will be a no-op:
   - for powernv the hpt will be set by the loading of the partition
 table, making this irrelevant
   - for pseries, it won't be called since external_htab will be true

So this case doesn't require the name change either.

>  }
>  
>  /* Invalidate all msr bits except MSR_TGPR/MSR_HVB before restoring */
> diff --git a/target/ppc/misc_helper.c b/target/ppc/misc_helper.c
> index ab432ba..49ba767 100644
> --- a/target/ppc/misc_helper.c
> +++ b/target/ppc/misc_helper.c
> @@ -84,7 +84,8 @@ void helper_store_sdr1(CPUPPCState *env, target_ulong val)
>  
>  if (!env->external_htab) {
>  if (env->spr[SPR_SDR1] != val) {
> -ppc_store_sdr1(env, val);
> +env->spr[SPR_SDR1] = val;
> +ppc_store_htab(env, val);

This is only called for CPUs which actually have an SDR1, so no name
change required by this caller.

>  tlb_flush(CPU(cpu));
>  }
>  }
> diff --git a/target/ppc/mmu-hash64.c b/target/ppc/mmu-hash64.c
> index 7c5d589..e658873 100644
> --- a/target/ppc/mmu-hash64.c
> +++ b/target/ppc/mmu-hash64.c
> @@ -285,13 +285,12 @@ target_ulong helper_load_slb_vsid(CPUPPCState *env, 
> target_ulong rb)
>  /*
>   * 64-bit hash t

Re: [Qemu-devel] [QEMU-PPC] [PATCH V2 07/10] target/ppc/POWER9: Add POWER9 mmu fault handler

[David Gibson]

On Fri, Feb 10, 2017 at 04:25:57PM +1100, Suraj Jitindar Singh wrote:
> Add a new mmu fault handler for the POWER9 cpu and add it as the handler
> for the POWER9 cpu definition.
> 
> This handler checks if the guest is radix or hash based on the value in the
> partition table entry and calls the correct fault handler accordingly.
> 
> The hash fault handling code has also been updated to check if the
> partition is using segment tables.
> 
> Currently only legacy hash (no segment tables) is supported.
> 
> Signed-off-by: Suraj Jitindar Singh 
> ---
>  target/ppc/mmu-hash64.c |  9 
>  target/ppc/mmu.h| 50 
> +
>  target/ppc/mmu_helper.c | 40 
>  target/ppc/translate_init.c |  2 +-
>  4 files changed, 100 insertions(+), 1 deletion(-)
>  create mode 100644 target/ppc/mmu.h
> 
> diff --git a/target/ppc/mmu-hash64.c b/target/ppc/mmu-hash64.c
> index e658873..ada8876 100644
> --- a/target/ppc/mmu-hash64.c
> +++ b/target/ppc/mmu-hash64.c
> @@ -27,6 +27,7 @@
>  #include "kvm_ppc.h"
>  #include "mmu-hash64.h"
>  #include "exec/log.h"
> +#include "mmu.h"
>  
>  //#define DEBUG_SLB
>  
> @@ -766,6 +767,14 @@ int ppc_hash64_handle_mmu_fault(PowerPCCPU *cpu, vaddr 
> eaddr,
>  /* 2. Translation is on, so look up the SLB */
>  slb = slb_lookup(cpu, eaddr);
>  if (!slb) {
> +/* No entry found, check if in-memory segment tables are in use */
> +if (ppc64_use_proc_tbl(cpu)) {
> +/* TODO - Unsupported */
> +qemu_log_mask(LOG_UNIMP, "%s: unimplemented - segment table 
> support",
> +  __func__);
> +/* Not much we can do here, generate a segment interrupt */

I'd suggest a hw_error() here, or an error_report() and abort(1), both
of which will noisily crash.  qemu_log() is not much used these days,
and as I recall actually setting up the log file to get this
information is a bit of a pain.

> +}
> +/* Segment still not found, generate the appropriate interrupt */
>  if (rwx == 2) {
>  cs->exception_index = POWERPC_EXCP_ISEG;
>  env->error_code = 0;
> diff --git a/target/ppc/mmu.h b/target/ppc/mmu.h
> new file mode 100644
> index 000..9375921
> --- /dev/null
> +++ b/target/ppc/mmu.h

AFAICT the stuff in here is pretty much specific to the v3 MMU, so I
think this should be renamed accordingly (just as we have mmu-hash64.h
for hash specific things).

> @@ -0,0 +1,50 @@
> +/*
> + *  PowerPC emulation generic mmu definitions for qemu.
> + *
> + *  Copyright (c) 2017 Suraj Jitindar Singh, IBM Corporation
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, see 
> .
> + */
> +
> +#ifndef MMU_H
> +#define MMU_H
> +
> +#ifndef CONFIG_USER_ONLY
> +
> +/* Partition Table Entry Fields */
> +#define PATBE1_GR 0x8000
> +
> +#ifdef TARGET_PPC64
> +
> +static inline bool ppc64_use_proc_tbl(PowerPCCPU *cpu)
> +{
> +return !!(cpu->env.spr[SPR_LPCR] & LPCR_UPRT);
> +}
> +
> +static inline bool ppc64_radix_guest(PowerPCCPU *cpu)
> +{
> +PPCVirtualHypervisorClass *vhc =
> +PPC_VIRTUAL_HYPERVISOR_GET_CLASS(cpu->vhyp);
> +return !!(vhc->get_patbe(cpu->vhyp) & PATBE1_GR);
> +}
> +
> +int ppc64_v3_handle_mmu_fault(PowerPCCPU *cpu, vaddr eaddr, int rwx,
> +  int mmu_idx);
> +
> +#endif /* TARGET_PPC64 */
> +
> +#endif /* CONFIG_USER_ONLY */
> +
> +#endif /* MMU_H */
> diff --git a/target/ppc/mmu_helper.c b/target/ppc/mmu_helper.c
> index e893e72..71ad771 100644
> --- a/target/ppc/mmu_helper.c
> +++ b/target/ppc/mmu_helper.c
> @@ -28,6 +28,8 @@
>  #include "exec/cpu_ldst.h"
>  #include "exec/log.h"
>  #include "helper_regs.h"
> +#include "qemu/error-report.h"
> +#include "mmu.h"
>  
>  //#define DEBUG_MMU
>  //#define DEBUG_BATS
> @@ -1280,6 +1282,17 @@ void dump_mmu(FILE *f, fprintf_function cpu_fprintf, 
> CPUPPCState *env)
>  case POWERPC_MMU_2_07a:
>  dump_slb(f, cpu_fprintf, ppc_env_get_cpu(env));
>  break;
> +case POWERPC_MMU_3_00:
> +if (ppc64_radix_guest(ppc_env_get_cpu(env))) {
> +/* TODO - Unsupported */
> +} else {
> +if (ppc64_use_proc_tbl(ppc_env_get_cpu(env))) {
> +/* TODO - Unsupported */
> +} else {
> +  

Re: [Qemu-devel] [Qemu-ppc] [PATCH] target/ppc: Stop parsing pvr list in H_CAS when exact match found

[David Gibson]

On Mon, Feb 13, 2017 at 02:30:27PM +1100, Suraj Jitindar Singh wrote:
> The pvr-list passed in H_Client_Architecture_Support is used to
> communicate the supported pvrs of the client program. When an
> exact match is found you are allowed to stop parsing the list and continue
> the boot process.
> 
> Currently while explicit_match is set when we find an exact match, we still
> set a compat mode based on best_compat irrespective of whether an exact
> match was found or not. This is wrong since it means we can only ever run
> in an architected state, not a raw state since we always set a compat mode.
> We are basically ignoring the case were we find an exact match.
> 
> Fix the code to stop parsing the pvr list when an exact match is found.
> This means that best_compat will always be zero in the case of an exact
> match which means we will not set a compat mode an thus run in raw mode,
> which is the desired functionality when we have an exact match.
> 
> Fixes: 152ef803ceb1 ("pseries: Rewrite CAS PVR compatibility logic")
> 
> Signed-off-by: Suraj Jitindar Singh 

Nack.  That change was deliberately intended to prefer compatibility
modes, only ever using a "raw" mode if there's no matching
compatibility mode.

Using compatibility modes as often as possible makes migration across
different host types substantially easier to handle and more likely to
succeed.

> 
> ---
>  hw/ppc/spapr_hcall.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> index 590105a..215c385 100644
> --- a/hw/ppc/spapr_hcall.c
> +++ b/hw/ppc/spapr_hcall.c
> @@ -1028,6 +1028,7 @@ static target_ulong 
> h_client_architecture_support(PowerPCCPU *cpu,
>  
>  if ((cpu->env.spr[SPR_PVR] & pvr_mask) == (pvr & pvr_mask)) {
>  explicit_match = true;
> +break;
>  } else {
>  if (ppc_check_compat(cpu, pvr, best_compat, max_compat)) {
>  best_compat = pvr;

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 2/3] COLO: Shutdown related socket fd while do failover

[Hailiang Zhang]

On 2017/2/9 3:53, Dr. David Alan Gilbert wrote:

* Hailiang Zhang (zhang.zhanghaili...@huawei.com) wrote:

On 2017/1/18 19:01, Dr. David Alan Gilbert wrote:

* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:

If the net connection between primary host and secondary host breaks
while COLO/COLO incoming threads are doing read() or write().
It will block until connection is timeout, and the failover process
will be blocked because of it.

So it is necessary to shutdown all the socket fds used by COLO
to avoid this situation. Besides, we should close the corresponding
file descriptors after failvoer BH shutdown them,
Or there will be an error.


Hi,
There are two parts to this patch:
 a) Add some semaphores to sequence failover
 b) Use shutdown()

At first I wondered if perhaps they should be split; but I see
the reason for the semaphores is mostly to stop the race between
the fd's getting closed and the shutdown() calls; so I think it's
OK.



Hi,

Yes, you are right, maybe i should add some comments about that.
Will do in next version.


Do you have any problems with these semaphores during powering off the
guest?



No, we didn't encounter any problems or trigger any bugs in our test
with this semaphores. In what places do you doubt it may has problems ? :)


I just wondered about other exit cases other than failover; e.g. what
if the guest shutdown or something like that, would it get stuck
waiting for the colo_incoming_sem.



Sorry for the late reply, too busy with our project these days ...

Your worry makes sense, we have processed the shutdown case specially,
Let qemu does a checkpoint process (It seems that, we should kick colo
thread which might be waiting for colo_checkpoint_sem.) before exit colo therad.
And for the secondary sides, if it receives shutdown request, it will exit
colo incoming thread after some cleanup works.


Thanks.
Hailiang



Dave


Thanks,
Hailiang


Dave





Signed-off-by: zhanghailiang 
Signed-off-by: Li Zhijian 
Reviewed-by: Dr. David Alan Gilbert 
Cc: Dr. David Alan Gilbert 
---
   include/migration/migration.h |  3 +++
   migration/colo.c  | 43 
+++
   2 files changed, 46 insertions(+)

diff --git a/include/migration/migration.h b/include/migration/migration.h
index 487ac1e..7cac877 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -113,6 +113,7 @@ struct MigrationIncomingState {
   QemuThread colo_incoming_thread;
   /* The coroutine we should enter (back) after failover */
   Coroutine *migration_incoming_co;
+QemuSemaphore colo_incoming_sem;

   /* See savevm.c */
   LoadStateEntry_Head loadvm_handlers;
@@ -182,6 +183,8 @@ struct MigrationState
   QSIMPLEQ_HEAD(src_page_requests, MigrationSrcPageRequest) 
src_page_requests;
   /* The RAMBlock used in the last src_page_request */
   RAMBlock *last_req_rb;
+/* The semaphore is used to notify COLO thread that failover is finished */
+QemuSemaphore colo_exit_sem;

   /* The semaphore is used to notify COLO thread to do checkpoint */
   QemuSemaphore colo_checkpoint_sem;
diff --git a/migration/colo.c b/migration/colo.c
index 08b2e46..3222812 100644
--- a/migration/colo.c
+++ b/migration/colo.c
@@ -59,6 +59,18 @@ static void secondary_vm_do_failover(void)
   /* recover runstate to normal migration finish state */
   autostart = true;
   }
+/*
+ * Make sure COLO incoming thread not block in recv or send,
+ * If mis->from_src_file and mis->to_src_file use the same fd,
+ * The second shutdown() will return -1, we ignore this value,
+ * It is harmless.
+ */
+if (mis->from_src_file) {
+qemu_file_shutdown(mis->from_src_file);
+}
+if (mis->to_src_file) {
+qemu_file_shutdown(mis->to_src_file);
+}

   old_state = failover_set_state(FAILOVER_STATUS_ACTIVE,
  FAILOVER_STATUS_COMPLETED);
@@ -67,6 +79,8 @@ static void secondary_vm_do_failover(void)
"secondary VM", FailoverStatus_lookup[old_state]);
   return;
   }
+/* Notify COLO incoming thread that failover work is finished */
+qemu_sem_post(&mis->colo_incoming_sem);
   /* For Secondary VM, jump to incoming co */
   if (mis->migration_incoming_co) {
   qemu_coroutine_enter(mis->migration_incoming_co);
@@ -81,6 +95,18 @@ static void primary_vm_do_failover(void)
   migrate_set_state(&s->state, MIGRATION_STATUS_COLO,
 MIGRATION_STATUS_COMPLETED);

+/*
+ * Wake up COLO thread which may blocked in recv() or send(),
+ * The s->rp_state.from_dst_file and s->to_dst_file may use the
+ * same fd, but we still shutdown the fd for twice, it is harmless.
+ */
+if (s->to_dst_file) {
+qemu_file_shutdown(s->to_dst_file);
+}
+if (s->rp_state.from_dst_file) {
+qemu_file_shutdown(s->rp_state.from_dst

Re: [Qemu-devel] [RFC] virtio-pci: Allow PCIe virtio devices on root bus

[David Gibson]

On Sun, Feb 12, 2017 at 09:05:46PM +0200, Marcel Apfelbaum wrote:
> On 02/10/2017 02:37 AM, David Gibson wrote:
> > On Thu, Feb 09, 2017 at 10:04:47AM +0100, Laszlo Ersek wrote:
> > > On 02/09/17 05:16, David Gibson wrote:
> > > > On Wed, Feb 08, 2017 at 11:40:50AM +0100, Laszlo Ersek wrote:
> > > > > On 02/08/17 07:16, David Gibson wrote:
> > > > > > Marcel,
> > > > > > 
> > > > > > Your original patch adding PCIe support to virtio-pci.c has the
> > > > > > limitation noted below that PCIe won't be enabled if the device is 
> > > > > > on
> > > > > > the root bus (rather than under a root or downstream port).  As
> > > > > > reasoned below, I think removing the check is correct, even for x86
> > > > > > (though it would rarely be useful there).  But I could well have
> > > > > > missed something.  Let me know if so...
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Virtio devices can appear as either vanilla PCI or PCI-Express 
> > > > > > devices
> > > > > > depending on the bus they're connected to.  At the moment it will 
> > > > > > only
> > > > > > appear as vanilla PCI if connected to the root bus of a PCIe host 
> > > > > > bridge.
> > > > > > 
> > > > > > Presumably this is to reflect the fact that PCIe devices usually 
> > > > > > need to
> > > > > > be connected to a root (or further downstream) port rather than 
> > > > > > directly
> > > > > > on the root bus.  However, due to the odd requirements of the PAPR 
> > > > > > spec on the 'pseries'
> > > > > > machine type, it's normal for PCIe devices to appear on the root bus
> > > > > > without root ports.
> > > > > > 
> > > > > > Further, even on x86, there's no inherent reason we couldn't 
> > > > > > present a
> > > > > > virtio device as an "integrated device" (typically used for things 
> > > > > > built
> > > > > > into the PCI chipset), and those devices *do* typically appear on 
> > > > > > the root
> > > > > > bus.
> > > > > 
> > > > > I'm not personally making a counter-argument, just qouting some of
> > > > > the relevant parts of "docs/pcie.txt" ("PCI EXPRESS GUIDELINES"):
> > > > 
> > > > So, an earlier discussion more or less concluded that the PCIe
> > > > guidelines don't really work with PAPR guests.  That comes because
> > > > PAPR was designed with PowerVM in mind which allows PCI passthrough
> > > > but doesn't do any emulated PCI devices.  So they wanted to present
> > > > passed through devices (virtual or phyical) to the guest without
> > > > inserting virtual root ports.
> > > > 
> > > > Now, you can argue that this was a silly decision in PAPR, and you
> > > > could well be right, but there it is.
> > > 
> > > I can totally accept this, but then we should state it as a fact near
> > > the top of "docs/pcie.txt".
> > > 
> > > > 
> > > > > > Place only the following kinds of devices directly on the Root 
> > > > > > Complex:
> > > > > > (1) PCI Devices (e.g. network card, graphics card, IDE 
> > > > > > controller),
> > > > > > not controllers. Place only legacy PCI devices on
> > > > > > the Root Complex. These will be considered Integrated 
> > > > > > Endpoints.
> > > > > > Note: Integrated Endpoints are not hot-pluggable.
> > > > > > 
> > > > > > Although the PCI Express spec does not forbid PCI Express 
> > > > > > devices as
> > > > > > Integrated Endpoints, existing hardware mostly integrates 
> > > > > > legacy PCI
> > > > > > devices with the Root Complex.
> > > > 
> > > > "Mostly".. on my laptop at least the GPU shows up as an integrated PCI
> > > > Express endpoint, so it's certainly not the case that *all* root bus
> > > > devices are legacy.
> > > > 
> > > > > Guest OSes are suspected to behave
> > > > > > strangely when PCI Express devices are integrated
> > > > > > with the Root Complex.
> > > > 
> > > > Clearly not that strangely, that often, since my laptop works just fine.
> > > > 
> > > > > > 
> > > > > > [...]
> > > > > > 
> > > > > > 2.2 PCI Express only hierarchy
> > > > > > ==
> > > > > > Always use PCI Express Root Ports to start PCI Express hierarchies.
> > > > > 
> > > > > Above you mention "it's normal for PCIe devices to appear on the root 
> > > > > bus without root ports".
> > > > 
> > > > Well "normal" perhaps wasn't the right word.  Let's say precedented,
> > > > if uncommon.
> > > > 
> > > > > Let me turn the question around: is it a *problem* for "pseries" if
> > > > > we require root ports? If so, why exactly?
> > > > 
> > > > That's.. a complex question.  At least Linux guests (and we don't
> > > > support any others yet) might cope with the addition of root ports.
> > > > Maybe.  I have discussed this option with BenH and others.
> > > > 
> > > > However it is gratuitously different from how PCIe devices will
> > > > typically appear for the same guest running under PowerVM.  Although I
> > > > suspect Linux would cope with the "normal standard" rather than "PAPR
> > > > standard" pres

Re: [Qemu-devel] [QEMU-PPC] [PATCH V2 00/10] target/ppc: Implement POWER9 pseries tcg

[David Gibson]

On Fri, Feb 10, 2017 at 04:25:50PM +1100, Suraj Jitindar Singh wrote:
> This is V2 of the patch series to implement tcg emulation support for a
> POWER9 cpu model for the pseries machine type running a legacy kernel.
> That is a kernel which doesn't use the new radix mmu mode or the new hash
> mmu mode with segment tables.
> 
> To use a POWER9 cpu provide the command line option "-cpu POWER9".
> 
> This series attempts to avoid precluding KVM-HV support for the POWER9
> cpu model but doesn't attempt to support KVM-PR or the powernv machine
> for the POWER9 cpu model as these aren't currently supported or
> implemented and further code changes will be required in the event these
> are implemented.
> 
> This series will be followed shortly by one to implement radix support and
> currently trying to boot a kernel with support for radix with this series
> will fail on the H_REGISTER_PROCESS_TABLE hcall.

I've applied 1-4 to ppc-for-2.9.  That leaves something rather
incomplete, but then that's pretty much already true for our POWER9
support.

> 
> The changes from V1 are as follows:
> 
>  - Drop patches which have already been merged.
>  - Instead of allocating a whole partition table we allocate a single
>entry in the sPAPRMachineState and access it via the virtual hypv.
>  - Changes to how we handle SDR1 and renaming of associated functions.
>  - Drop patch to use the new pte format, guest kernels expect the old
>format anyway, so this will only be applicable when POWER9 powernv
>support is added, so delay adding support for this until then.
>  - Rename the mmu fault handler to ppc64_v3_handle_mmu_fault.
>  - Move segment table searching into the fault handler instead of in
>slb_lookup().
>  - Move adding the POWER9 pseries cpu model to the end of the series.
> 
> Suraj Jitindar Singh (10):
>   target/ppc/POWER9: Add ISAv3.00 MMU definition
>   target/ppc: Fix LPCR DPFD mask define
>   target/ppc/POWER9: Adapt LPCR handling for POWER9
>   target/ppc/POWER9: Direct all instr and data storage interrupts to the
> hypv
>   target/ppc: Add patb_entry to sPAPRMachineState
>   target/ppc: Don't use SDR1 when running under a POWER9 cpu model
>   target/ppc/POWER9: Add POWER9 mmu fault handler
>   target/ppc/POWER9: Add POWER9 pa-features definition
>   target/ppc/POWER9: Add cpu_has_work function for POWER9
>   hw/ppc/spapr: Add POWER9 to pseries cpu models
> 
>  hw/ppc/spapr.c  | 37 ++
>  hw/ppc/spapr_cpu_core.c |  3 ++
>  include/hw/ppc/spapr.h  |  1 +
>  target/ppc/cpu-qom.h|  5 ++-
>  target/ppc/cpu.h| 24 +++-
>  target/ppc/kvm.c|  2 +-
>  target/ppc/machine.c|  4 +-
>  target/ppc/misc_helper.c|  3 +-
>  target/ppc/mmu-hash64.c | 49 +---
>  target/ppc/mmu-hash64.h |  2 +-
>  target/ppc/mmu.h| 50 +
>  target/ppc/mmu_helper.c | 54 +--
>  target/ppc/translate.c  |  7 +++-
>  target/ppc/translate_init.c | 91 
> +++--
>  14 files changed, 302 insertions(+), 30 deletions(-)
>  create mode 100644 target/ppc/mmu.h
> 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [QEMU-PPC] [PATCH V2 09/10] target/ppc/POWER9: Add cpu_has_work function for POWER9

[David Gibson]

On Fri, Feb 10, 2017 at 04:25:59PM +1100, Suraj Jitindar Singh wrote:
> The cpu has work function is used to mask interrupts used to determine
> if there is work for the cpu based on the LPCR. Add a function to do this
> for POWER9 and add it to the POWER9 cpu definition. This is similar to that
> for POWER8 except using the LPCR bits as defined for POWER9.
> 
> Signed-off-by: Suraj Jitindar Singh 

Reviewed-by: David Gibson 

> ---
>  target/ppc/translate_init.c | 45 
> +
>  1 file changed, 45 insertions(+)
> 
> diff --git a/target/ppc/translate_init.c b/target/ppc/translate_init.c
> index a3a23d8..cc8ab1f 100644
> --- a/target/ppc/translate_init.c
> +++ b/target/ppc/translate_init.c
> @@ -8776,10 +8776,54 @@ static bool ppc_pvr_match_power9(PowerPCCPUClass 
> *pcc, uint32_t pvr)
>  return false;
>  }
>  
> +static bool cpu_has_work_POWER9(CPUState *cs)
> +{
> +PowerPCCPU *cpu = POWERPC_CPU(cs);
> +CPUPPCState *env = &cpu->env;
> +
> +if (cs->halted) {
> +if (!(cs->interrupt_request & CPU_INTERRUPT_HARD)) {
> +return false;
> +}
> +/* External Exception */
> +if ((env->pending_interrupts & (1u << PPC_INTERRUPT_EXT)) &&
> +(env->spr[SPR_LPCR] & LPCR_EEE)) {
> +return true;
> +}
> +/* Decrementer Exception */
> +if ((env->pending_interrupts & (1u << PPC_INTERRUPT_DECR)) &&
> +(env->spr[SPR_LPCR] & LPCR_DEE)) {
> +return true;
> +}
> +/* Machine Check or Hypervisor Maintenance Exception */
> +if ((env->pending_interrupts & (1u << PPC_INTERRUPT_MCK |
> +1u << PPC_INTERRUPT_HMI)) && (env->spr[SPR_LPCR] & LPCR_OEE)) {
> +return true;
> +}
> +/* Privileged Doorbell Exception */
> +if ((env->pending_interrupts & (1u << PPC_INTERRUPT_DOORBELL)) &&
> +(env->spr[SPR_LPCR] & LPCR_PDEE)) {
> +return true;
> +}
> +/* Hypervisor Doorbell Exception */
> +if ((env->pending_interrupts & (1u << PPC_INTERRUPT_HDOORBELL)) &&
> +(env->spr[SPR_LPCR] & LPCR_HDEE)) {
> +return true;
> +}
> +if (env->pending_interrupts & (1u << PPC_INTERRUPT_RESET)) {
> +return true;
> +}
> +return false;
> +} else {
> +return msr_ee && (cs->interrupt_request & CPU_INTERRUPT_HARD);
> +}
> +}
> +
>  POWERPC_FAMILY(POWER9)(ObjectClass *oc, void *data)
>  {
>  DeviceClass *dc = DEVICE_CLASS(oc);
>  PowerPCCPUClass *pcc = POWERPC_CPU_CLASS(oc);
> +CPUClass *cc = CPU_CLASS(oc);
>  
>  dc->fw_name = "PowerPC,POWER9";
>  dc->desc = "POWER9";
> @@ -8790,6 +8834,7 @@ POWERPC_FAMILY(POWER9)(ObjectClass *oc, void *data)
>   PCR_COMPAT_2_05;
>  pcc->init_proc = init_proc_POWER9;
>  pcc->check_pow = check_pow_nocheck;
> +cc->has_work = cpu_has_work_POWER9;
>  pcc->insns_flags = PPC_INSNS_BASE | PPC_ISEL | PPC_STRING | PPC_MFTB |
> PPC_FLOAT | PPC_FLOAT_FSEL | PPC_FLOAT_FRES |
> PPC_FLOAT_FSQRT | PPC_FLOAT_FRSQRTE |

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [QEMU-PPC] [PATCH V2 08/10] target/ppc/POWER9: Add POWER9 pa-features definition

[David Gibson]

On Fri, Feb 10, 2017 at 04:25:58PM +1100, Suraj Jitindar Singh wrote:
> Add a pa-features definition which includes all of the new fields which
> have been added, note we don't claim support for any of these new features
> at this stage.
> 
> Signed-off-by: Suraj Jitindar Singh 

Reviewed-by: David Gibson 

> ---
>  hw/ppc/spapr.c | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 057adae..44eb014 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -356,6 +356,20 @@ static void spapr_populate_pa_features(CPUPPCState *env, 
> void *fdt, int offset)
>  0x80, 0x00, 0x00, 0x00, 0x00, 0x00,
>  0x00, 0x00, 0x00, 0x00, 0x80, 0x00,
>  0x80, 0x00, 0x80, 0x00, 0x00, 0x00 };
> +/* Currently we don't advertise any of the "new" ISAv3.00 functionality 
> */
> +uint8_t pa_features_300[] = { 64, 0,
> +0xf6, 0x1f, 0xc7, 0xc0, 0x80, 0xf0, /*  0 -  5 */
> +0x80, 0x00, 0x00, 0x00, 0x00, 0x00, /*  6 - 11 */
> +0x00, 0x00, 0x00, 0x00, 0x80, 0x00, /* 12 - 17 */
> +0x80, 0x00, 0x80, 0x00, 0x00, 0x00, /* 18 - 23 */
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 24 - 29 */
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 30 - 35 */
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 36 - 41 */
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 42 - 47 */
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 48 - 53 */
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 54 - 59 */
> +0x00, 0x00, 0x00, 0x00   }; /* 60 - 63 */
> +
>  uint8_t *pa_features;
>  size_t pa_size;
>  
> @@ -370,6 +384,10 @@ static void spapr_populate_pa_features(CPUPPCState *env, 
> void *fdt, int offset)
>  pa_features = pa_features_207;
>  pa_size = sizeof(pa_features_207);
>  break;
> +case POWERPC_MMU_3_00:
> +pa_features = pa_features_300;
> +pa_size = sizeof(pa_features_300);
> +break;
>  default:
>  return;
>  }

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [QEMU-PPC] [PATCH V2 10/10] hw/ppc/spapr: Add POWER9 to pseries cpu models

[David Gibson]

On Fri, Feb 10, 2017 at 04:26:00PM +1100, Suraj Jitindar Singh wrote:
> Add POWER9 cpu to list of spapr core models which allows it to be specified
> as the cpu model for a pseries guest (e.g. -machine pseries -cpu POWER9).
> 
> This now allows a POWER9 cpu to boot to userspace in tcg emulation for a
> pseries machine with a legacy kernel.
> 
> Signed-off-by: Suraj Jitindar Singh 

Reviewed-by: David Gibson 

> ---
>  hw/ppc/spapr_cpu_core.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
> index 9dddaeb..71253f9 100644
> --- a/hw/ppc/spapr_cpu_core.c
> +++ b/hw/ppc/spapr_cpu_core.c
> @@ -360,6 +360,9 @@ static const char *spapr_core_models[] = {
>  
>  /* POWER8NVL */
>  "POWER8NVL_v1.0",
> +
> +/* POWER9 */
> +"POWER9_v1.0",
>  };
>  
>  void spapr_cpu_core_class_init(ObjectClass *oc, void *data)

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 0/3] block devices record/replay update

[Pavel Dovgalyuk]

Ping?

Pavel Dovgalyuk

> -Original Message-
> From: Pavel Dovgalyuk [mailto:pavel.dovga...@ispras.ru]
> Sent: Tuesday, January 31, 2017 2:57 PM
> To: qemu-devel@nongnu.org
> Cc: kw...@redhat.com; pbonz...@redhat.com; dovga...@ispras.ru; 
> qemu-bl...@nongnu.org;
> mre...@redhat.com
> Subject: [PATCH 0/3] block devices record/replay update
> 
> This set of patches includes several fixes for preserving
> the state of the block device images while recording and replaying
> virtual machine execution.
> 
> blkreplay driver now creates temporary overlay for underlaying devices
> This patch implicitly enables '-snapshot' behavior in record/replay mode.
> blkreplay layer creates temporary overlays on top of underlaying
> disk images. It is needed, because creating an overlay over blkreplay
> with explicit '-snapshot' option breaks the determinism.
> 
> ---
> 
> Pavel Dovgalyuk (3):
>   block: implement bdrv_snapshot_goto for blkreplay
>   blkreplay: create temporary overlay for underlaying devices
>   replay: disable default snapshot for record/replay
> 
> 
>  block/blkreplay.c |   84 
> +
>  stubs/replay.c|1 +
>  vl.c  |   10 +-
>  3 files changed, 93 insertions(+), 2 deletions(-)
> 
> --
> Pavel Dovgalyuk

Re: [Qemu-devel] [PATCH] replay: add record/replay for audio passthrough

[Pavel Dovgalyuk]

Ping?

Pavel Dovgalyuk


> -Original Message-
> From: Pavel Dovgalyuk [mailto:pavel.dovga...@ispras.ru]
> Sent: Tuesday, January 31, 2017 2:59 PM
> To: qemu-devel@nongnu.org
> Cc: pbonz...@redhat.com; dovga...@ispras.ru; kra...@redhat.com
> Subject: [PATCH] replay: add record/replay for audio passthrough
> 
> This patch adds recording and replaying audio data. Is saves synchronization
> information for audio out and inputs from the microphone.
> 
> Signed-off-by: Pavel Dovgalyuk 
> ---
>  audio/audio.c|   11 +-
>  audio/audio.h|5 +++
>  audio/mixeng.c   |   31 ++
>  docs/replay.txt  |7 
>  include/sysemu/replay.h  |7 
>  replay/Makefile.objs |1 +
>  replay/replay-audio.c|   79 
> ++
>  replay/replay-internal.h |4 ++
>  8 files changed, 142 insertions(+), 3 deletions(-)
>  create mode 100644 replay/replay-audio.c
> 
> diff --git a/audio/audio.c b/audio/audio.c
> index 1ee95a5..79c0788 100644
> --- a/audio/audio.c
> +++ b/audio/audio.c
> @@ -28,6 +28,7 @@
>  #include "qemu/timer.h"
>  #include "sysemu/sysemu.h"
>  #include "qemu/cutils.h"
> +#include "sysemu/replay.h"
> 
>  #define AUDIO_CAP "audio"
>  #include "audio_int.h"
> @@ -1113,7 +1114,7 @@ static void audio_reset_timer (AudioState *s)
>  {
>  if (audio_is_timer_needed ()) {
>  if (!timer_pending(s->ts)) {
> -timer_mod (s->ts,
> +timer_mod(s->ts,
>  qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + conf.period.ticks);
>  }
>  }
> @@ -1389,6 +1390,7 @@ static void audio_run_out (AudioState *s)
> 
>  prev_rpos = hw->rpos;
>  played = hw->pcm_ops->run_out (hw, live);
> +replay_audio_out(&played);
>  if (audio_bug (AUDIO_FUNC, hw->rpos >= hw->samples)) {
>  dolog ("hw->rpos=%d hw->samples=%d played=%d\n",
> hw->rpos, hw->samples, played);
> @@ -1452,9 +1454,12 @@ static void audio_run_in (AudioState *s)
> 
>  while ((hw = audio_pcm_hw_find_any_enabled_in (hw))) {
>  SWVoiceIn *sw;
> -int captured, min;
> +int captured = 0, min;
> 
> -captured = hw->pcm_ops->run_in (hw);
> +if (replay_mode != REPLAY_MODE_PLAY) {
> +captured = hw->pcm_ops->run_in(hw);
> +}
> +replay_audio_in(&captured, hw->conv_buf, &hw->wpos, hw->samples);
> 
>  min = audio_pcm_hw_find_min_in (hw);
>  hw->total_samples_captured += captured - min;
> diff --git a/audio/audio.h b/audio/audio.h
> index c3c5198..f4339a1 100644
> --- a/audio/audio.h
> +++ b/audio/audio.h
> @@ -166,4 +166,9 @@ int wav_start_capture (CaptureState *s, const char *path, 
> int freq,
>  bool audio_is_cleaning_up(void);
>  void audio_cleanup(void);
> 
> +void audio_sample_to_uint64(void *samples, int pos,
> +uint64_t *left, uint64_t *right);
> +void audio_sample_from_uint64(void *samples, int pos,
> +uint64_t left, uint64_t right);
> +
>  #endif /* QEMU_AUDIO_H */
> diff --git a/audio/mixeng.c b/audio/mixeng.c
> index 66c0328..c23508e 100644
> --- a/audio/mixeng.c
> +++ b/audio/mixeng.c
> @@ -267,6 +267,37 @@ f_sample *mixeng_clip[2][2][2][3] = {
>  }
>  };
> 
> +
> +void audio_sample_to_uint64(void *samples, int pos,
> +uint64_t *left, uint64_t *right)
> +{
> +struct st_sample *sample = samples;
> +sample += pos;
> +#ifdef FLOAT_MIXENG
> +error_report(
> +"Coreaudio and floating point samples are not supported by replay 
> yet");
> +abort();
> +#else
> +*left = sample->l;
> +*right = sample->r;
> +#endif
> +}
> +
> +void audio_sample_from_uint64(void *samples, int pos,
> +uint64_t left, uint64_t right)
> +{
> +struct st_sample *sample = samples;
> +sample += pos;
> +#ifdef FLOAT_MIXENG
> +error_report(
> +"Coreaudio and floating point samples are not supported by replay 
> yet");
> +abort();
> +#else
> +sample->l = left;
> +sample->r = right;
> +#endif
> +}
> +
>  /*
>   * August 21, 1998
>   * Copyright 1998 Fabrice Bellard.
> diff --git a/docs/replay.txt b/docs/replay.txt
> index 03e1931..486c1e0 100644
> --- a/docs/replay.txt
> +++ b/docs/replay.txt
> @@ -225,3 +225,10 @@ recording the virtual machine this filter puts all 
> packets coming from
>  the outer world into the log. In replay mode packets from the log are
>  injected into the network device. All interactions with network backend
>  in replay mode are disabled.
> +
> +Audio devices
> +-
> +
> +Audio data is recorded and replay automatically. The command line for 
> recording
> +and replaying must contain identical specifications of audio hardware, e.g.:
> + -soundhw ac97
> diff --git a/include/sysemu/replay.h b/include/sysemu/replay.h
> index 7aad20b..f1c0712 100644
> --- a/include/sysemu/replay.h
> +++ b/include/syse

Re: [Qemu-devel] [PATCH] audio: make audio poll timer deterministic

[Pavel Dovgalyuk]

Ping?

Pavel Dovgalyuk


> -Original Message-
> From: Pavel Dovgalyuk [mailto:pavel.dovga...@ispras.ru]
> Sent: Tuesday, January 31, 2017 2:59 PM
> To: qemu-devel@nongnu.org
> Cc: pbonz...@redhat.com; dovga...@ispras.ru; kra...@redhat.com
> Subject: [PATCH] audio: make audio poll timer deterministic
> 
> This patch changes resetting strategy of the audio polling timer.
> It does not change expiration time if the timer is already set.
> 
> Signed-off-by: Pavel Dovgalyuk 
> ---
>  audio/audio.c |6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/audio/audio.c b/audio/audio.c
> index c845a44..1ee95a5 100644
> --- a/audio/audio.c
> +++ b/audio/audio.c
> @@ -1112,8 +1112,10 @@ static int audio_is_timer_needed (void)
>  static void audio_reset_timer (AudioState *s)
>  {
>  if (audio_is_timer_needed ()) {
> -timer_mod (s->ts,
> -qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + conf.period.ticks);
> +if (!timer_pending(s->ts)) {
> +timer_mod (s->ts,
> +qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + conf.period.ticks);
> +}
>  }
>  else {
>  timer_del (s->ts);

Re: [Qemu-devel] [PATCH v3] net: e1000e: fix an infinite loop issue

[Jason Wang]

On 2017年02月12日 19:38, Dmitry Fleytman wrote:
Reviewed-by: Dmitry Fleytman >




Applied.

Thanks

On 10 Feb 2017, at 04:19 AM, Li Qiang > wrote:


This issue is like the issue in e1000 network card addressed in
this commit:
e1000: eliminate infinite loops on out-of-bounds transfer start.

Signed-off-by: Li Qiang mailto:liqiang...@360.cn>>
---

Change since v2:
fix error in e1000e_ring_empty
eliminate unnecessory detect code in loop

Changes since v1:
make wraparound detect in e1000e_ring_empty

hw/net/e1000e_core.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c
index 2b11499..dc94188 100644
--- a/hw/net/e1000e_core.c
+++ b/hw/net/e1000e_core.c
@@ -806,7 +806,8 @@ typedef struct E1000E_RingInfo_st {
static inline bool
e1000e_ring_empty(E1000ECore *core, const E1000E_RingInfo *r)
{
-return core->mac[r->dh] == core->mac[r->dt];
+return core->mac[r->dh] == core->mac[r->dt] ||
+core->mac[r->dt] >= core->mac[r->dlen] / 
E1000_RING_DESC_LEN;

}

static inline uint64_t
@@ -1522,6 +1523,10 @@ e1000e_write_packet_to_guest(E1000ECore *core, 
struct NetRxPkt *pkt,

desc_size = core->rx_desc_buf_size;
}

+if (e1000e_ring_empty(core, rxi)) {
+return;
+}
+
base = e1000e_ring_head_descr(core, rxi);

pci_dma_read(d, base, &desc, core->rx_desc_len);
--
1.8.3.1

Re: [Qemu-devel] [PATCH v5 00/17] Dirty bitmaps postcopy migration

[Fam Zheng]

On Tue, 02/07 18:05, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
> 
> There is a new version of dirty bitmap postcopy migration series.

Doesn't apply to master now, could you rebase?

Fam

Re: [Qemu-devel] [RFC][PATCH] qemu-img: make convert async

[Fam Zheng]

On Sun, 02/12 03:06, Max Reitz wrote:
> On 02.02.2017 17:06, Peter Lieven wrote:
> > this is something I have been thinking about for almost 2 years now.
> > we heavily have the following two use cases when using qemu-img convert.
> > 
> > a) reading from NFS and writing to iSCSI for deploying templates
> > b) reading from iSCSI and writing to NFS for backups
> > 
> > In both processes we use libiscsi and libnfs so we have no kernel pagecache.
> > As qemu-img convert is implemented with sync operations that means we
> > read one buffer and then write it. No parallelism and each sync request
> > takes as long as it takes until it is completed.
> > 
> > What I put together is an approach to use aio routines for the conversion
> > process to have ideally read and write happening in parallel.
> > 
> > The code is far from clean or complete, but I would appreaciate comments
> > and thoughts from you.
> > 
> > So far I have the following runtimes when reading an uncompressed QCOW2 from
> > NFS and writing it to iSCSI (raw):
> > 
> > qemu-img (master)
> >  nfs -> iscsi 33 secs
> >  nfs -> ram   19 secs
> >  ram -> iscsi 14 secs
> > 
> > qemu-img-async
> >  nfs -> iscsi 23 secs
> >  nfs -> ram   17 secs
> >  ram -> iscsi 14 secs
> > 
> > Its visible that on master the runtimes add up as expected. The async branch
> > is faster, but not as fast as I would have expected. I would expect the 
> > runtime
> > to be as slow as the slowest of the two involved transfers.
> > 
> > Thank you,
> > Peter
> > 
> > Signed-off-by: Peter Lieven 
> > ---
> >  qemu-img.c | 271 
> > +
> >  1 file changed, 199 insertions(+), 72 deletions(-)
> 
> Asynchronous convert sounds good. But your implementation looks a bit
> weird to me.
> 
> Your implementation has four "slots" which receive work from a central
> work queue that they then process. You can do that, but it looks
> counter-intuitive to me. (Or if you do that, I would do it using
> coroutines: Start up four coroutines that simply submit blk_co_* requests.)
> 
> What I would have done (if using AIO) is the following: Seek through the
> image, finding the next bit of work to do (without having a central work
> queue). Then submit an AIO request with a newly allocated piece of data
> (not using fixed slots). Continue until four requests are in flight,
> then wait until one is settled.
> 
> I think this would simplify the design. Also, it's basically what the
> mirror block job does.
> 
> Which brings me to a totally different point: At some point we intended
> to convert as many qemu-img functions to block jobs as possible.
> Unfortunately, we only ever did one and that's commit. If we were to
> convert convert to mirror, then we'd get async for free.
> 
> But the effort of converting convert to mirror is probably much larger
> than adding async to convert...

My 2 cents.

In the long run it still seems to me as a worthwhile deal. Now we know it will
have a useful advantage by bringing in async, maybe it's a good time to do it!

Related, I have had the feeling that block jobs can be cleaned up too: backup,
commit, stream can all reuse mirror code to achieve the "async" feature that
Vladmir is proposing, in an AIO way which is more resource friendly than
coroutine worker pool.

Fam

Re: [Qemu-devel] [PATCH] block: Swap request limit definitions

[Fam Zheng]

On Sun, 02/12 02:47, Max Reitz wrote:
> Defining BDRV_REQUEST_MAX_SECTORS based on BDRV_REQUEST_MAX_BYTES is
> simpler than the other way around.
> 
> Signed-off-by: Max Reitz 
> ---
>  include/block/block.h | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/include/block/block.h b/include/block/block.h
> index 4e81f2069b..101ef33f6b 100644
> --- a/include/block/block.h
> +++ b/include/block/block.h
> @@ -114,9 +114,8 @@ typedef struct HDGeometry {
>  #define BDRV_SECTOR_SIZE   (1ULL << BDRV_SECTOR_BITS)
>  #define BDRV_SECTOR_MASK   ~(BDRV_SECTOR_SIZE - 1)
>  
> -#define BDRV_REQUEST_MAX_SECTORS MIN(SIZE_MAX >> BDRV_SECTOR_BITS, \
> - INT_MAX >> BDRV_SECTOR_BITS)
> -#define BDRV_REQUEST_MAX_BYTES (BDRV_REQUEST_MAX_SECTORS << BDRV_SECTOR_BITS)
> +#define BDRV_REQUEST_MAX_BYTES  MIN(SIZE_MAX, INT_MAX)
> +#define BDRV_REQUEST_MAX_SECTORS(BDRV_REQUEST_MAX_BYTES >> 
> BDRV_SECTOR_BITS)
>  
>  /*
>   * Allocation status flags
> -- 
> 2.11.0
> 
> 

Reviewed-by: Fam Zheng 

Re: [Qemu-devel] [Qemu-ppc] [PATCH] hw/pci-host/prep: Do not use hw_error() in realize function

[David Gibson]

On Thu, Feb 09, 2017 at 12:14:41PM +0100, Thomas Huth wrote:
> hw_error() is for CPU related errors only (it prints out a
> register dump and calls abort()), so we should not use it
> if we just failed to load the bios image. Apart from that,
> realize() functions should not exit directly but always set
> the errp with error_setg() in case of errors instead.
> Additionally, move some code around and delete the bios memory
> subregion again in case of such an error, so that we leave a
> clean state when returning to the caller.
> 
> Signed-off-by: Thomas Huth 

Applied to ppc-for-2.9.

> ---
>  hw/pci-host/prep.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/pci-host/prep.c b/hw/pci-host/prep.c
> index 5580293..260a119 100644
> --- a/hw/pci-host/prep.c
> +++ b/hw/pci-host/prep.c
> @@ -309,7 +309,6 @@ static void raven_realize(PCIDevice *d, Error **errp)
>  memory_region_set_readonly(&s->bios, true);
>  memory_region_add_subregion(get_system_memory(), (uint32_t)(-BIOS_SIZE),
>  &s->bios);
> -vmstate_register_ram_global(&s->bios);
>  if (s->bios_name) {
>  filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, s->bios_name);
>  if (filename) {
> @@ -328,12 +327,15 @@ static void raven_realize(PCIDevice *d, Error **errp)
>  }
>  }
>  }
> +g_free(filename);
>  if (bios_size < 0 || bios_size > BIOS_SIZE) {
> -/* FIXME should error_setg() */
> -hw_error("qemu: could not load bios image '%s'\n", s->bios_name);
> +memory_region_del_subregion(get_system_memory(), &s->bios);
> +error_setg(errp, "Could not load bios image '%s'", s->bios_name);
> +return;
>  }
> -g_free(filename);
>  }
> +
> +vmstate_register_ram_global(&s->bios);
>  }
>  
>  static const VMStateDescription vmstate_raven = {
> @@ -361,7 +363,6 @@ static void raven_class_init(ObjectClass *klass, void 
> *data)
>  /*
>   * Reason: PCI-facing part of the host bridge, not usable without
>   * the host-facing part, which can't be device_add'ed, yet.
> - * Reason: realize() method uses hw_error().
>   */
>  dc->cannot_instantiate_with_device_add_yet = true;
>  }

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 1/1] hw/net/spapr_llan: 6 byte mac address device tree entry

[David Gibson]

On Tue, Nov 22, 2016 at 10:19:38AM +1100, Sam Bobroff wrote:
> The spapr-vlan device in QEMU has always presented it's MAC address in
> the device tree as an 8 byte value, even though PAPR requires it to be
> 6 bytes.  This is because, at the time, AIX required the value to be 8
> bytes.  However, modern versions of AIX support the (correct) 6
> byte value so they no longer require the workaround.
> 
> It would be neatest to always provide a 6 byte value but that would
> cause a problem with old Linux kernel ibmveth drivers, so the old 8
> byte value is still presented when necessary.
> 
> Since commit 13f85203e (3.10, May 2013) the driver has been able to
> handle 6 or 8 byte addresses so versions after that don't need to be
> considered specially.
> 
> Drivers from kernels before that can also handle either type of
> address, but not always:
> * If the first byte's lowest bits are 10, the address must be 6 bytes.
> * Otherwise, the address must be 8 bytes.
> (The two bits in question are significant in a MAC address: they
> indicate a locally-administered unicast address.)
> 
> So to maintain compatibility the old 8 byte value is presented when
> the lowest two bits of the first byte are not 10.
> 
> Signed-off-by: Sam Bobroff 

Sorry, I didn't see this one until now.

Since we need a workaround for the workaround, is it actually worth
going to the 6-byte property?

> ---
> 
> v3:
> 
> Made code comments more accurate.
> 
> v2:
> 
> Re-introduced the old workaround so that old Linux kernel drivers aren't
> broken, at the cost of AIX seeing the old value for for non-locally generated
> or broadcast addresses (this shouldn't matter because those addresses probably
> aren't used on virtual adapters).
> 
> Reworded first paragraph of commit message because AIX seems to still support
> the old 8 byte value.
> 
>  hw/net/spapr_llan.c | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/hw/net/spapr_llan.c b/hw/net/spapr_llan.c
> index 01ecb02..74910e8 100644
> --- a/hw/net/spapr_llan.c
> +++ b/hw/net/spapr_llan.c
> @@ -385,18 +385,24 @@ static int spapr_vlan_devnode(VIOsPAPRDevice *dev, void 
> *fdt, int node_off)
>  int ret;
>  
>  /* Some old phyp versions give the mac address in an 8-byte
> - * property.  The kernel driver has an insane workaround for this;
> + * property.  The kernel driver (before 3.10) has an insane workaround;
>   * rather than doing the obvious thing and checking the property
>   * length, it checks whether the first byte has 0b10 in the low
>   * bits.  If a correct 6-byte property has a different first byte
>   * the kernel will get the wrong mac address, overrunning its
>   * buffer in the process (read only, thank goodness).
>   *
> - * Here we workaround the kernel workaround by always supplying an
> - * 8-byte property, with the mac address in the last six bytes */
> -memcpy(&padded_mac[2], &vdev->nicconf.macaddr, ETH_ALEN);
> -ret = fdt_setprop(fdt, node_off, "local-mac-address",
> -  padded_mac, sizeof(padded_mac));
> + * Here we return a 6-byte address unless that would break a pre-3.10
> + * driver.  In that case we return a padded 8-byte address to allow the 
> old
> + * workaround to succeed. */
> +if ((vdev->nicconf.macaddr.a[0] & 0x3) == 0x2) {
> +ret = fdt_setprop(fdt, node_off, "local-mac-address",
> +  &vdev->nicconf.macaddr, ETH_ALEN);
> +} else {
> +memcpy(&padded_mac[2], &vdev->nicconf.macaddr, ETH_ALEN);
> +ret = fdt_setprop(fdt, node_off, "local-mac-address",
> +  padded_mac, sizeof(padded_mac));
> +}
>  if (ret < 0) {
>  return ret;
>  }

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 0/7] pc/spapr: unify handling of possible CPUs

[David Gibson]

On Fri, Feb 10, 2017 at 11:31:08AM +0100, Igor Mammedov wrote:
> On Thu,  9 Feb 2017 12:08:31 +0100
> Igor Mammedov  wrote:
> 
> [...]
> > 
> > Series depends on:
> >   [PATCH 0/3] spapr: fix cpu core hotunplug call flow
> >   https://www.mail-archive.com/qemu-devel@nongnu.org/msg427214.html
> > which is staged for next pull req in SPAPR tree.
> 
> David,
> 
> could you merge it through your ppc tree as this series
> depends on above patches that are there but not in master yet.

Ok, I've merged it into ppc-for-2.9, including the v2 6/7 and 8/7.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

[Qemu-devel] [PATCH v3 1/3] i386/cpu: add crash-information QOM property

[Denis V. Lunev]

From: Anton Nefedov 

Windows reports BSOD parameters through Hyper-V crash MSRs. This
information is very useful for initial crash analysis and thus
it would be nice to have a way to fetch it.

Signed-off-by: Anton Nefedov 
Signed-off-by: Denis V. Lunev 
---
 include/sysemu/kvm.h |  2 ++
 kvm-all.c|  1 +
 qapi-schema.json | 24 +++
 stubs/Makefile.objs  |  1 +
 stubs/kvm-crash.c|  8 
 target/i386/cpu.c| 54 
 target/i386/cpu.h|  3 +++
 target/i386/kvm.c| 41 +++
 8 files changed, 134 insertions(+)
 create mode 100644 stubs/kvm-crash.c

diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index 3045ee7..02a363d 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -527,4 +527,6 @@ int kvm_set_one_reg(CPUState *cs, uint64_t id, void 
*source);
  */
 int kvm_get_one_reg(CPUState *cs, uint64_t id, void *target);
 int kvm_get_max_memslots(void);
+
+void kvm_arch_save_crash_info(CPUState *cpu);
 #endif
diff --git a/kvm-all.c b/kvm-all.c
index a27c880..abfe92d 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -2000,6 +2000,7 @@ int kvm_cpu_exec(CPUState *cpu)
 ret = EXCP_INTERRUPT;
 break;
 case KVM_SYSTEM_EVENT_CRASH:
+kvm_arch_save_crash_info(cpu);
 qemu_mutex_lock_iothread();
 qemu_system_guest_panicked();
 qemu_mutex_unlock_iothread();
diff --git a/qapi-schema.json b/qapi-schema.json
index cbdffdd..9cb6ac5 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -5846,6 +5846,30 @@
   'data': [ 'pause', 'poweroff' ] }
 
 ##
+# @GuestPanicInformation:
+#
+# Information about a guest panic
+#
+# Since: 2.9
+##
+{'union': 'GuestPanicInformation',
+ 'data': { 'hyper-v': 'GuestPanicInformationHyperV' } }
+
+##
+# @GuestPanicInformationHyperV:
+#
+# Hyper-V specific guest panic information (HV crash MSRs)
+#
+# Since: 2.9
+##
+{'struct': 'GuestPanicInformationHyperV',
+ 'data': { 'arg1': 'uint64',
+   'arg2': 'uint64',
+   'arg3': 'uint64',
+   'arg4': 'uint64',
+   'arg5': 'uint64' } }
+
+##
 # @rtc-reset-reinjection:
 #
 # This command will reset the RTC interrupt reinjection backlog.
diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
index a187295..3b1632a 100644
--- a/stubs/Makefile.objs
+++ b/stubs/Makefile.objs
@@ -35,3 +35,4 @@ stub-obj-y += qmp_pc_dimm_device_list.o
 stub-obj-y += target-monitor-defs.o
 stub-obj-y += target-get-monitor-def.o
 stub-obj-y += pc_madt_cpu_entry.o
+stub-obj-y += kvm-crash.o
diff --git a/stubs/kvm-crash.c b/stubs/kvm-crash.c
new file mode 100644
index 000..b2f502d
--- /dev/null
+++ b/stubs/kvm-crash.c
@@ -0,0 +1,8 @@
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "sysemu/kvm.h"
+
+void kvm_arch_save_crash_info(CPUState *cs)
+{
+return;
+}
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index eb49980..275e236 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -3495,6 +3495,57 @@ static void x86_cpu_register_feature_bit_props(X86CPU 
*cpu,
 x86_cpu_register_bit_prop(cpu, name, &cpu->env.features[w], bitnr);
 }
 
+static GuestPanicInformation *x86_cpu_get_crash_info(CPUState *cs)
+{
+X86CPU *cpu = X86_CPU(cs);
+CPUX86State *env = &cpu->env;
+GuestPanicInformation *panic_info = NULL;
+
+if (env->features[FEAT_HYPERV_EDX] & HV_X64_GUEST_CRASH_MSR_AVAILABLE) {
+GuestPanicInformationHyperV *panic_info_hv =
+g_malloc0(sizeof(GuestPanicInformationHyperV));
+panic_info = g_malloc0(sizeof(GuestPanicInformation));
+
+panic_info->type = GUEST_PANIC_INFORMATION_KIND_HYPER_V;
+panic_info->u.hyper_v.data = panic_info_hv;
+
+assert(HV_X64_MSR_CRASH_PARAMS >= 5);
+panic_info_hv->arg1 = cpu->hv_msr_crash_params[0];
+panic_info_hv->arg2 = cpu->hv_msr_crash_params[1];
+panic_info_hv->arg3 = cpu->hv_msr_crash_params[2];
+panic_info_hv->arg4 = cpu->hv_msr_crash_params[3];
+panic_info_hv->arg5 = cpu->hv_msr_crash_params[4];
+}
+
+return panic_info;
+}
+static void x86_cpu_get_crash_info_qom(Object *obj, Visitor *v,
+   const char *name, void *opaque,
+   Error **errp)
+{
+CPUState *cs = CPU(obj);
+GuestPanicInformation *panic_info;
+
+if (!cs->crash_occurred) {
+error_setg(errp, "No crash occured");
+return;
+}
+
+panic_info = x86_cpu_get_crash_info(cs);
+if (panic_info == NULL) {
+error_setg(errp, "No crash information");
+return;
+}
+
+visit_type_GuestPanicInformation(v, "crash-information", &panic_info,
+ errp);
+
+if (panic_info->type == GUEST_PANIC_INFORMATION_KIND_HYPER_V) {
+g_free(panic_info->u.hyper_v.data);
+}
+g_free(panic_info);
+}
+
 static void x86_cpu_initfn(Obj

[Qemu-devel] [PATCH v3 3/3] vl: log available guest crash information

[Denis V. Lunev]

From: Anton Nefedov 

There is a suitable log mask for the purpose.

Signed-off-by: Anton Nefedov 
Signed-off-by: Denis V. Lunev 
---
 vl.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/vl.c b/vl.c
index d5a183f..873aa4e 100644
--- a/vl.c
+++ b/vl.c
@@ -1709,6 +1709,8 @@ void qemu_system_reset(bool report)
 
 void qemu_system_guest_panicked(GuestPanicInformation *info)
 {
+qemu_log_mask(LOG_GUEST_ERROR, "Guest crashed\n");
+
 if (current_cpu) {
 current_cpu->crash_occurred = true;
 }
@@ -1723,6 +1725,13 @@ void qemu_system_guest_panicked(GuestPanicInformation 
*info)
 
 if (info) {
 if (info->type == GUEST_PANIC_INFORMATION_KIND_HYPER_V) {
+qemu_log_mask(LOG_GUEST_ERROR, "HV crash parameters: (%#"PRIx64
+  " %#"PRIx64" %#"PRIx64" %#"PRIx64" %#"PRIx64")\n",
+  info->u.hyper_v.data->arg1,
+  info->u.hyper_v.data->arg2,
+  info->u.hyper_v.data->arg3,
+  info->u.hyper_v.data->arg4,
+  info->u.hyper_v.data->arg5);
 g_free(info->u.hyper_v.data);
 }
 g_free(info);
-- 
2.7.4

[Qemu-devel] [PATCH v3 2/3] report guest crash information in GUEST_PANICKED event

[Denis V. Lunev]

From: Anton Nefedov 

it's not very convenient to use the crash-information property interface,
so provide a CPU class callback to get the guest crash information, and pass
that information in the event

Signed-off-by: Anton Nefedov 
Signed-off-by: Denis V. Lunev 
---
 hw/misc/pvpanic.c   |  2 +-
 hw/ppc/spapr_rtas.c |  3 ++-
 include/qom/cpu.h   | 10 ++
 include/sysemu/sysemu.h |  2 +-
 kvm-all.c   |  2 +-
 qapi/event.json |  6 --
 qom/cpu.c   | 11 +++
 target/i386/cpu.c   |  1 +
 target/s390x/kvm.c  |  4 ++--
 vl.c| 14 +++---
 10 files changed, 44 insertions(+), 11 deletions(-)

diff --git a/hw/misc/pvpanic.c b/hw/misc/pvpanic.c
index 0ac1e6a..57da7f2 100644
--- a/hw/misc/pvpanic.c
+++ b/hw/misc/pvpanic.c
@@ -42,7 +42,7 @@ static void handle_event(int event)
 }
 
 if (event & PVPANIC_PANICKED) {
-qemu_system_guest_panicked();
+qemu_system_guest_panicked(NULL);
 return;
 }
 }
diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
index bb19944..619f32c 100644
--- a/hw/ppc/spapr_rtas.c
+++ b/hw/ppc/spapr_rtas.c
@@ -334,7 +334,8 @@ static void rtas_ibm_os_term(PowerPCCPU *cpu,
 {
 target_ulong ret = 0;
 
-qapi_event_send_guest_panicked(GUEST_PANIC_ACTION_PAUSE, &error_abort);
+qapi_event_send_guest_panicked(GUEST_PANIC_ACTION_PAUSE, false, NULL,
+   &error_abort);
 
 rtas_st(rets, 0, ret);
 }
diff --git a/include/qom/cpu.h b/include/qom/cpu.h
index ca4d0fb..f95a6c3 100644
--- a/include/qom/cpu.h
+++ b/include/qom/cpu.h
@@ -156,6 +156,7 @@ typedef struct CPUClass {
uint8_t *buf, int len, bool is_write);
 void (*dump_state)(CPUState *cpu, FILE *f, fprintf_function cpu_fprintf,
int flags);
+GuestPanicInformation* (*get_crash_info)(CPUState *cpu);
 void (*dump_statistics)(CPUState *cpu, FILE *f,
 fprintf_function cpu_fprintf, int flags);
 int64_t (*get_arch_id)(CPUState *cpu);
@@ -469,6 +470,15 @@ int cpu_write_elf32_qemunote(WriteCoreDumpFunction f, 
CPUState *cpu,
  void *opaque);
 
 /**
+ * cpu_get_crash_info:
+ * @cpu: The CPU to get crash information for
+ *
+ * Gets the previously saved crash information.
+ * Caller is responsible for freeing the data.
+ */
+GuestPanicInformation *cpu_get_crash_info(CPUState *cpu);
+
+/**
  * CPUDumpFlags:
  * @CPU_DUMP_CODE:
  * @CPU_DUMP_FPU: dump FPU register state, not just integer
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 4d50694..2c39bed 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -64,7 +64,7 @@ int qemu_shutdown_requested_get(void);
 int qemu_reset_requested_get(void);
 void qemu_system_killed(int signal, pid_t pid);
 void qemu_system_reset(bool report);
-void qemu_system_guest_panicked(void);
+void qemu_system_guest_panicked(GuestPanicInformation *info);
 size_t qemu_target_page_bits(void);
 
 void qemu_add_exit_notifier(Notifier *notify);
diff --git a/kvm-all.c b/kvm-all.c
index abfe92d..8fe69bb 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -2002,7 +2002,7 @@ int kvm_cpu_exec(CPUState *cpu)
 case KVM_SYSTEM_EVENT_CRASH:
 kvm_arch_save_crash_info(cpu);
 qemu_mutex_lock_iothread();
-qemu_system_guest_panicked();
+qemu_system_guest_panicked(cpu_get_crash_info(cpu));
 qemu_mutex_unlock_iothread();
 ret = 0;
 break;
diff --git a/qapi/event.json b/qapi/event.json
index 7bf539b..970ff02 100644
--- a/qapi/event.json
+++ b/qapi/event.json
@@ -488,7 +488,9 @@
 #
 # @action: action that has been taken, currently always "pause"
 #
-# Since: 1.5
+# @info: optional information about a panic
+#
+# Since: 1.5 (@info since 2.9)
 #
 # Example:
 #
@@ -497,7 +499,7 @@
 #
 ##
 { 'event': 'GUEST_PANICKED',
-  'data': { 'action': 'GuestPanicAction' } }
+  'data': { 'action': 'GuestPanicAction', '*info': 'GuestPanicInformation' } }
 
 ##
 # @QUORUM_FAILURE:
diff --git a/qom/cpu.c b/qom/cpu.c
index d57faf3..5158f31 100644
--- a/qom/cpu.c
+++ b/qom/cpu.c
@@ -218,6 +218,17 @@ static bool cpu_common_exec_interrupt(CPUState *cpu, int 
int_req)
 return false;
 }
 
+GuestPanicInformation *cpu_get_crash_info(CPUState *cpu)
+{
+CPUClass *cc = CPU_GET_CLASS(cpu);
+GuestPanicInformation *res = NULL;
+
+if (cc->get_crash_info) {
+res = cc->get_crash_info(cpu);
+}
+return res;
+}
+
 void cpu_dump_state(CPUState *cpu, FILE *f, fprintf_function cpu_fprintf,
 int flags)
 {
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 275e236..8bed688 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -3738,6 +3738,7 @@ static void x86_cpu_common_class_init(ObjectClass *oc, 
void *data)
 cc->do_interrupt = x86_cpu_do_interrupt;
 cc->cpu_exec_interrupt = x86_cpu_exec_inte

[Qemu-devel] [PATCH v3 0/3] kvm: report available guest crash parameters

[Denis V. Lunev]

Windows reports BSOD parameters through Hyper-V crash MSRs. This
information is very useful for initial crash analysis and thus
it would be nice to see it in the QEMU log file. There is suitable
log mask for the purpose.

Linux guest does not provide this information, but still it would
be nice to log that we have crashed.

Changes from v2:
- fixed PPC compilation

Changes since v1:
- patches resplit
- created property to query crash parameters
- crash parameters added to panic event

Signed-off-by: Anton Nefedov 
Signed-off-by: Denis V. Lunev 
CC: Paolo Bonzini 
CC: Marcelo Tosatti 
CC: Richard Henderson 
CC: Eduardo Habkost 
CC: Eric Blake 
CC: Markus Armbruster 

Anton Nefedov (3):
  i386/cpu: add crash-information QOM property
  report guest crash information in GUEST_PANICKED event
  vl: log available guest crash information

 hw/misc/pvpanic.c   |  2 +-
 hw/ppc/spapr_rtas.c |  3 ++-
 include/qom/cpu.h   | 10 +
 include/sysemu/kvm.h|  2 ++
 include/sysemu/sysemu.h |  2 +-
 kvm-all.c   |  3 ++-
 qapi-schema.json| 24 +
 qapi/event.json |  6 --
 qom/cpu.c   | 11 ++
 stubs/Makefile.objs |  1 +
 stubs/kvm-crash.c   |  8 +++
 target/i386/cpu.c   | 55 +
 target/i386/cpu.h   |  3 +++
 target/i386/kvm.c   | 41 
 target/s390x/kvm.c  |  4 ++--
 vl.c| 23 ++---
 16 files changed, 187 insertions(+), 11 deletions(-)
 create mode 100644 stubs/kvm-crash.c

-- 
2.7.4

Re: [Qemu-devel] [PATCH 1/1] mirror: do not increase offset during initial zero_or_discard phase - pls consider this as V3 patch

[Denis V. Lunev]

On 02/03/2017 06:08 PM, Denis V. Lunev wrote:
> On 02/03/2017 06:06 PM, Denis V. Lunev wrote:
>> From: Anton Nefedov 
>>
>> If explicit zeroing out before mirroring is required for the target image,
>> it moves the block job offset counter to EOF, then offset and len counters
>> count the image size twice. There is no harm but stats are confusing,
>> specifically the progress of the operation is always reported as 99% by
>> management tools.
>>
>> The patch skips offset increase for the first "technical" pass over the
>> image. This should not cause any further harm.
>>
>> Signed-off-by: Anton Nefedov 
>> Signed-off-by: Denis V. Lunev 
>> Reviewed-by: Eric Blake 
>> Reviewed-by: Stefan Hajnoczi 
>> CC: Jeff Cody 
>> CC: Kevin Wolf 
>> CC: Max Reitz 
> actually this is V3 patch. Sorry for broken subject.
>
> Den
ping

Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 1/1] hw/net/spapr_llan: 6 byte mac address device tree entry

[Thomas Huth]

On 13.02.2017 06:33, David Gibson wrote:
> On Tue, Nov 22, 2016 at 10:19:38AM +1100, Sam Bobroff wrote:
>> The spapr-vlan device in QEMU has always presented it's MAC address in
>> the device tree as an 8 byte value, even though PAPR requires it to be
>> 6 bytes.  This is because, at the time, AIX required the value to be 8
>> bytes.  However, modern versions of AIX support the (correct) 6
>> byte value so they no longer require the workaround.
>>
>> It would be neatest to always provide a 6 byte value but that would
>> cause a problem with old Linux kernel ibmveth drivers, so the old 8
>> byte value is still presented when necessary.
>>
>> Since commit 13f85203e (3.10, May 2013) the driver has been able to
>> handle 6 or 8 byte addresses so versions after that don't need to be
>> considered specially.
>>
>> Drivers from kernels before that can also handle either type of
>> address, but not always:
>> * If the first byte's lowest bits are 10, the address must be 6 bytes.
>> * Otherwise, the address must be 8 bytes.
>> (The two bits in question are significant in a MAC address: they
>> indicate a locally-administered unicast address.)
>>
>> So to maintain compatibility the old 8 byte value is presented when
>> the lowest two bits of the first byte are not 10.
>>
>> Signed-off-by: Sam Bobroff 
> 
> Sorry, I didn't see this one until now.
> 
> Since we need a workaround for the workaround, is it actually worth
> going to the 6-byte property?

8-byte addresses are just wrong, all other network devices and the
standard use 6-byte MAC addresses instead. So we should use 6-byte
addresses in QEMU whenever it is possible, too. Unfortunately there are
still guests in the field that use this bad assumption with 8 byte
addresses, so I think this work-around is the best we can and should do
right now.

 Thomas




signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PATCH] usb: xhci: break loop after ctrl transfer complete

[P J P]

From: Prasad J Pandit 

xHCI controller emulator loops through the transfer ring to
transfer control/data between host memory and device endpoints.
It continues to do so after processing 'Status Stage' TD which
is the last descriptor in control transfer. Add break to avoid
infinite loop.

Reported-by: Li Qiang 
Signed-off-by: Prasad J Pandit 
---
 hw/usb/hcd-xhci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c
index 54b3901..7e2d345 100644
--- a/hw/usb/hcd-xhci.c
+++ b/hw/usb/hcd-xhci.c
@@ -2252,6 +2252,7 @@ static void xhci_kick_epctx(XHCIEPContext *epctx, 
unsigned int streamid)
 if (xfer->complete) {
 xhci_ep_free_xfer(xfer);
 xfer = NULL;
+break;
 }
 
 if (epctx->state == EP_HALTED) {
-- 
2.9.3