Re: [Qemu-devel] [PATCH V1 06/10] docs: add qemu-clock documentation

[KONRAD Frederic]

Le 17/10/2016 à 20:31, Peter Maydell a écrit :

On 5 October 2016 at 23:11,   wrote:

From: KONRAD Frederic 

This adds the qemu-clock documentation.

Signed-off-by: KONRAD Frederic 
---
 docs/clock.txt | 109 +
 1 file changed, 109 insertions(+)
 create mode 100644 docs/clock.txt

diff --git a/docs/clock.txt b/docs/clock.txt
new file mode 100644
index 000..b25c5ab
--- /dev/null
+++ b/docs/clock.txt
@@ -0,0 +1,109 @@
+
+What is a QEMU_CLOCK
+
+
+A QEMU_CLOCK is a QOM Object developed for the purpose of modeling a clock tree
+with QEMU.


This doesn't match the type name you use in the code.


+It only simulates the clock by keeping a copy of the current frequency and
+doesn't model the signal itself such as pin toggle or duty cycle.
+
+It allows to model the impact of badly configured PLL, clock source selection
+or disabled clock on the models.


So is a QEMU_CLOCK a clock source?
How does this scheme model "I'm a device, and I have a clock
input (ie a clock sink)" ?


A qemu-clk is a clock pin. It can be either input or output.

So for a clock source device:

typedef struct {
DeviceState parent_obj;

uint32_t rate;
struct qemu_clk out;
} FixedClock;

out is actually a clock output.

During instance init:

object_initialize(&s->out, sizeof(s->out), TYPE_CLOCK);
qemu_clk_attach_to_device(DEVICE(obj), &s->out, "clk_out");

So after that: any device which wants to get the clock pin can do it
like this (fixed is a FixedClock):

qemu_clk_get_pin(DEVICE(fixed), "clk_out");

Or like this: fixed->out.

For a clock sink device:

typedef struct CRF_APB {
< ... >
/* input clocks */
qemu_clk pss_ref_clk;
qemu_clk video_clk;
qemu_clk pss_alt_ref_clk;
qemu_clk aux_refclk;
qemu_clk gt_crx_ref_clk;
< ... >
} CRF_APB;

Those are actually clock input. But this is the same object.

It works the same way for instance init:
object_initialize(&s->pss_ref_clk,
  sizeof(s->pss_ref_clk), TYPE_CLOCK);
qemu_clk_attach_to_device(DEVICE(obj),
  &s->pss_ref_clk, "pss_ref_clk");

But you might want to register a callback when the rate is updated:
qemu_clk_set_callback(s->pss_ref_clk, cb, s);

cb will be called when the clock tree is refreshed.
When the callback is called it will take the opaque passed to
qemu_clk_set_callback() and the rate of the previous clock in the chain.
This callback need to return the rate which will be passed to the next
clock in the chain.

So if we connect those two previous models together:

qemu_clk_bind_clock(qemu_clk_get_pin(DEVICE(s->fixed),
 "clk_out"),
qemu_clk_get_pin(DEVICE(s->crf),
 "pss_ref_clk"));

When the clock source is refreshed for example during realize for
FixedClock:
qemu_clk_update_rate(&s->out, s->rate);

It will call refresh on all the connected clocks with the rate modified
by it's own callback if there is a callback defined, so here:
qemu_clk_update_rate(pss_ref_clk, (rate of FixedClock));
As we defined cb as a update_rate callback it will be notified with the
rate of the previous clock.




+Binding the clock together to create a tree
+===
+
+In order to create a clock tree with QEMU_CLOCK two or more clock must be bound
+together. Let's say there are two clocks clk_a and clk_b:
+Using qemu_clk_bind(clk_a, clk_b) will bind clk_a and clk_b.
+
+Binding two qemu-clk together creates a unidirectional link which means that
+changing the rate of clk_a will propagate to clk_b and not the opposite.
+The binding process automatically refreshes clk_b rate.
+
+Clock can be bound and unbound during execution for modeling eg: a clock
+selector.
+
+A clock can drive more than one other clock. eg with this code:
+qemu_clk_bind(clk_a, clk_b);
+qemu_clk_bind(clk_a, clk_c);
+
+A clock rate change one clk_a will propagate to clk_b and clk_c.


What's the rate of a clock initially? Do you need to call
qemu_clk_update_rate() during board construction for a
fixed clock (or is it forbidden to call it during board
construction? during device reset?)


The rate is initially 0. The clock tree is refreshed from the sources to 
the device. And the fixed-clock model calls qemu_clk_update_rate()

in realize.


Presumably it's a programming error to bind a bunch of clocks
in a loop...


Yes and connecting a qemu-clock which is actually considered as an
input to an output as well.



+
+Implementing a callback on a rate change
+
+
+The function prototype is the following:
+typedef uint64_t (*qemu_clk_rate_change_cb)(void *opaque, uint64_t rate);
+
+It's main goal is to modify the rate before it's passed to the next clocks in
+the tree.
+
+eg: for a 4x PLL the function will be:
+uint64_t qemu_clk_rate_change_cb(void *opaque, uint

Re: [Qemu-devel] [PATCH v3 09/13] pc: kvm_apic: pass APIC ID depending on xAPIC/x2APIC mode

[Igor Mammedov]

On Mon, 17 Oct 2016 19:51:12 -0200
Eduardo Habkost  wrote:

> On Thu, Oct 13, 2016 at 11:52:43AM +0200, Igor Mammedov wrote:
> > Signed-off-by: Igor Mammedov 
> > ---
> > v4:
> >  - drop kvm_has_x2apic_api() and reuse kvm_enable_x2apic() instead
> > ---
> >  hw/i386/kvm/apic.c | 12 ++--
> >  1 file changed, 10 insertions(+), 2 deletions(-)
> > 
> > diff --git a/hw/i386/kvm/apic.c b/hw/i386/kvm/apic.c
> > index be55102..9a7dd03 100644
> > --- a/hw/i386/kvm/apic.c
> > +++ b/hw/i386/kvm/apic.c
> > @@ -34,7 +34,11 @@ static void kvm_put_apic_state(APICCommonState *s, 
> > struct kvm_lapic_state *kapic
> >  int i;
> >  
> >  memset(kapic, 0, sizeof(*kapic));
> > -kvm_apic_set_reg(kapic, 0x2, s->id << 24);
> > +if (kvm_enable_x2apic() && s->apicbase & MSR_IA32_APICBASE_EXTD) {  
> 
> This is going to enable x2apic unconditionally (not just check if
> x2apic was enabled). Is this really what you want to do?
Fixed,
 v4 is in reply to the same note from Radim

> 
> 
> > +kvm_apic_set_reg(kapic, 0x2, s->initial_apic_id);
> > +} else {
> > +kvm_apic_set_reg(kapic, 0x2, s->id << 24);
> > +}
> >  kvm_apic_set_reg(kapic, 0x8, s->tpr);
> >  kvm_apic_set_reg(kapic, 0xd, s->log_dest << 24);
> >  kvm_apic_set_reg(kapic, 0xe, s->dest_mode << 28 | 0x0fff);
> > @@ -59,7 +63,11 @@ void kvm_get_apic_state(DeviceState *dev, struct 
> > kvm_lapic_state *kapic)
> >  APICCommonState *s = APIC_COMMON(dev);
> >  int i, v;
> >  
> > -s->id = kvm_apic_get_reg(kapic, 0x2) >> 24;
> > +if (kvm_enable_x2apic() && s->apicbase & MSR_IA32_APICBASE_EXTD) {
> > +assert(kvm_apic_get_reg(kapic, 0x2) == s->initial_apic_id);
> > +} else {
> > +s->id = kvm_apic_get_reg(kapic, 0x2) >> 24;
> > +}
> >  s->tpr = kvm_apic_get_reg(kapic, 0x8);
> >  s->arb_id = kvm_apic_get_reg(kapic, 0x9);
> >  s->log_dest = kvm_apic_get_reg(kapic, 0xd) >> 24;
> > -- 
> > 2.7.4
> >   
> 

Re: [Qemu-devel] [PATCH V1 02/10] qemu-clk: allow to attach a clock to a device

[KONRAD Frederic]

Le 17/10/2016 à 20:13, Peter Maydell a écrit :

On 5 October 2016 at 23:10,   wrote:

From: KONRAD Frederic 

This allows to attach a clock to a DeviceState.
Contrary to gpios, the clock pins are not contained in the DeviceState but
with the child property so they can appears in the qom-tree.


Is this API patterned along the same lines as some other
API we already have ? If so, it would be helpful to mention
it in the commit message.

(Also this series would probably benefit from somebody who
actually knows how the QOM APIs are supposed to work having
a look at it.)


I CC'ed Andreas maybe he can help.




Signed-off-by: KONRAD Frederic 
---
 include/qemu/qemu-clock.h | 24 +++-
 qemu-clock.c  | 23 +++
 2 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/include/qemu/qemu-clock.h b/include/qemu/qemu-clock.h
index e7acd68..1d56a2e 100644
--- a/include/qemu/qemu-clock.h
+++ b/include/qemu/qemu-clock.h
@@ -33,8 +33,30 @@
 typedef struct qemu_clk {
 /*< private >*/
 Object parent_obj;
+char *name;/* name of this clock in the device. */
 } *qemu_clk;

-#endif /* QEMU_CLOCK_H */
+/**
+ * qemu_clk_attach_to_device:
+ * @dev: the device on which the clock need to be attached.
+ * @clk: the clock which need to be attached.
+ * @name: the name of the clock can't be NULL.
+ *
+ * Attach @clk named @name to the device @dev.


I'm not quite sure what this function does, but it looks like
what it actually does is attach @clk to device @dev as a
clock named @name.


+ *
+ */
+void qemu_clk_attach_to_device(DeviceState *dev, qemu_clk clk,
+   const char *name);

+/**
+ * qemu_clk_get_pin:
+ * @dev: the device which contain the clock.
+ * @name: the name of the clock.
+ *
+ * Get the clock named @name located in the device @dev, or NULL if not found.
+ *
+ * Returns the clock named @name contained in @dev.
+ */
+qemu_clk qemu_clk_get_pin(DeviceState *dev, const char *name);


I don't understand the name of this function. It says "get_pin"
but it returns a clock, not a pin ?


Yes actually you're right. Only we only use this function outside the
model. In the machine when you want to connects the clock model
together. That's why I called it like that. But I can change if you
want.




+#endif /* QEMU_CLOCK_H */
diff --git a/qemu-clock.c b/qemu-clock.c
index ceea98d..0ba6caf 100644
--- a/qemu-clock.c
+++ b/qemu-clock.c
@@ -25,6 +25,7 @@
 #include "qemu/qemu-clock.h"
 #include "hw/hw.h"
 #include "qemu/log.h"
+#include "qapi/error.h"

 #ifndef DEBUG_QEMU_CLOCK
 #define DEBUG_QEMU_CLOCK 0
@@ -36,6 +37,28 @@
 }\
 } while (0);

+void qemu_clk_attach_to_device(DeviceState *dev, qemu_clk clk,
+   const char *name)
+{
+assert(name);
+assert(!clk->name);


This is really checking that the clock hasn't already been attached
to something else, right?


Yes.




+object_property_add_child(OBJECT(dev), name, OBJECT(clk), &error_abort);
+clk->name = g_strdup(name);


When does this string get freed?


Nowhere actually! I'll fix that.




+}
+
+qemu_clk qemu_clk_get_pin(DeviceState *dev, const char *name)
+{
+gchar *path = NULL;
+Object *clk;
+bool ambiguous;
+
+path = g_strdup_printf("%s/%s", object_get_canonical_path(OBJECT(dev)),
+   name);
+clk = object_resolve_path(path, &ambiguous);


Needs a QOM API expert, but I'm about 90% certain that you
don't need to go via the canonical path to get hold of
an object that's a child of some other object you already
have. (Also object_resolve_path() accepts NULL if you
don't care about the return value in 'ambiguous', but I
think you'll end up not needing to call it at all.)
Possibly you want object_resolve_path_component(OBJECT(dev), name) ?


+g_free(path);
+return QEMU_CLOCK(clk);
+}
+
 static const TypeInfo qemu_clk_info = {
 .name  = TYPE_CLOCK,
 .parent= TYPE_OBJECT,
--
2.5.5



thanks
-- PMM

[Qemu-devel] [PATCH v2] vl: exit qemu on guest panic if -no-shutdown is not set

[Christian Borntraeger]

For automated testing purposes it can be helpful to exit qemu
(poweroff) when the guest panics. Make this the default unless
-no-shutdown is specified.

For internal-errors like errors from KVM_RUN the behaviour is
not changed, in other words QEMU does not exit to allow debugging
in the QEMU monitor.

Signed-off-by: Christian Borntraeger 
---
 qapi-schema.json | 4 ++--
 vl.c | 5 +
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index ded1179..2b83ee4 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -4488,10 +4488,10 @@
 #
 # @pause: system pauses
 #
-# Since: 2.1
+# Since: 2.1 (poweroff since 2.8)
 ##
 { 'enum': 'GuestPanicAction',
-  'data': [ 'pause' ] }
+  'data': [ 'pause', 'poweroff' ] }
 
 ##
 # @rtc-reset-reinjection
diff --git a/vl.c b/vl.c
index c657acd..e1ef81f 100644
--- a/vl.c
+++ b/vl.c
@@ -1783,6 +1783,11 @@ void qemu_system_guest_panicked(void)
 }
 qapi_event_send_guest_panicked(GUEST_PANIC_ACTION_PAUSE, &error_abort);
 vm_stop(RUN_STATE_GUEST_PANICKED);
+if (!no_shutdown) {
+qapi_event_send_guest_panicked(GUEST_PANIC_ACTION_POWEROFF,
+   &error_abort);
+qemu_system_shutdown_request();
+}
 }
 
 void qemu_system_reset_request(void)
-- 
2.5.5

[Qemu-devel] [PATCH] display: cirrus: check vga bits per pixel(bpp) value

[P J P]

From: Prasad J Pandit 

In Cirrus CLGD 54xx VGA Emulator, if cirrus graphics mode is VGA,
'cirrus_get_bpp' returns zero(0), which could lead to a divide
by zero error in while copying pixel data. The same could occur
via blit pitch values. Add check to avoid it.

Reported-by: Huawei PSIRT 
Signed-off-by: Prasad J Pandit 
---
 hw/display/cirrus_vga.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/hw/display/cirrus_vga.c b/hw/display/cirrus_vga.c
index 3d712d5..bdb092e 100644
--- a/hw/display/cirrus_vga.c
+++ b/hw/display/cirrus_vga.c
@@ -272,6 +272,9 @@ static void cirrus_update_memory_access(CirrusVGAState *s);
 static bool blit_region_is_unsafe(struct CirrusVGAState *s,
   int32_t pitch, int32_t addr)
 {
+if (!pitch) {
+return true;
+}
 if (pitch < 0) {
 int64_t min = addr
 + ((int64_t)s->cirrus_blt_height-1) * pitch;
@@ -715,7 +718,7 @@ static int 
cirrus_bitblt_videotovideo_patterncopy(CirrusVGAState * s)
 s->cirrus_addr_mask));
 }
 
-static void cirrus_do_copy(CirrusVGAState *s, int dst, int src, int w, int h)
+static int cirrus_do_copy(CirrusVGAState *s, int dst, int src, int w, int h)
 {
 int sx = 0, sy = 0;
 int dx = 0, dy = 0;
@@ -729,6 +732,9 @@ static void cirrus_do_copy(CirrusVGAState *s, int dst, int 
src, int w, int h)
 int width, height;
 
 depth = s->vga.get_bpp(&s->vga) / 8;
+if (!depth) {
+return 0;
+}
 s->vga.get_resolution(&s->vga, &width, &height);
 
 /* extra x, y */
@@ -783,6 +789,8 @@ static void cirrus_do_copy(CirrusVGAState *s, int dst, int 
src, int w, int h)
 cirrus_invalidate_region(s, s->cirrus_blt_dstaddr,
s->cirrus_blt_dstpitch, s->cirrus_blt_width,
s->cirrus_blt_height);
+
+return 1;
 }
 
 static int cirrus_bitblt_videotovideo_copy(CirrusVGAState * s)
@@ -790,11 +798,9 @@ static int cirrus_bitblt_videotovideo_copy(CirrusVGAState 
* s)
 if (blit_is_unsafe(s))
 return 0;
 
-cirrus_do_copy(s, s->cirrus_blt_dstaddr - s->vga.start_addr,
+return cirrus_do_copy(s, s->cirrus_blt_dstaddr - s->vga.start_addr,
 s->cirrus_blt_srcaddr - s->vga.start_addr,
 s->cirrus_blt_width, s->cirrus_blt_height);
-
-return 1;
 }
 
 /***
-- 
2.7.4

Re: [Qemu-devel] [PATCH] script/clean-includes: added duplicate #include check

[Anand J]

On Thu, Oct 13, 2016 at 12:10 AM, Anand J  wrote:

> Added script to check duplicate #include entries. This check will scan and
> print the files in which duplicate #include entries are present.
>
> Script might output false postive entries as well. Such entries should
> not be removed. So if it finds any duplicate entries script will terminate
> with an exit status 1. Then each and every file should be checked manually
> and corrected if necessary.
>
> Added an additional option --ignore-duphead in the clean-includes
> script to disable this check if all the duplicate #includes are
> genuine. The check in enabled by default.
>
> NOTE: Removed some of the genuine duplicate entries in the code base.
>
> Signed-off-by: Anand J 
> ---
>  accel.c |  1 -
>  cputlb.c|  1 -
>  gdbstub.c   |  1 -
>  hw/i386/acpi-build.c|  1 -
>  hw/microblaze/boot.c|  1 -
>  hw/mips/mips_malta.c|  1 -
>  hw/nvram/fw_cfg.c   |  1 -
>  hw/pci-bridge/pci_expander_bridge.c |  1 -
>  hw/ppc/ppc405_boards.c  |  1 -
>  hw/ppc/spapr.c  |  1 -
>  hw/timer/grlib_gptimer.c|  1 -
>  hw/tpm/tpm_tis.c|  1 -
>  hw/unicore32/puv3.c |  1 -
>  hw/usb/dev-mtp.c|  1 -
>  include/hw/i386/pc.h|  1 -
>  monitor.c   |  2 --
>  qemu-io-cmds.c  |  1 -
>  qmp.c   |  1 -
>  scripts/clean-includes  | 50 +++---
> ---
>  target-i386/machine.c   |  3 ---
>  target-mips/machine.c   |  1 -
>  target-ppc/machine.c|  1 -
>  target-ppc/mem_helper.c |  1 -
>  target-sparc/machine.c  |  3 ---
>  target-xtensa/translate.c   |  1 -
>  tests/crypto-tls-x509-helpers.h |  3 ---
>  tests/vhost-user-test.c |  2 --
>  util/oslib-posix.c  |  1 -
>  vl.c|  1 -
>  29 files changed, 37 insertions(+), 49 deletions(-)
>
> diff --git a/accel.c b/accel.c
> index 403eb5e..b5a4210 100644
> --- a/accel.c
> +++ b/accel.c
> @@ -25,7 +25,6 @@
>
>  #include "qemu/osdep.h"
>  #include "sysemu/accel.h"
> -#include "hw/boards.h"
>  #include "qemu-common.h"
>  #include "sysemu/arch_init.h"
>  #include "sysemu/sysemu.h"
> diff --git a/cputlb.c b/cputlb.c
> index 3c99c34..59b3969 100644
> --- a/cputlb.c
> +++ b/cputlb.c
> @@ -19,7 +19,6 @@
>
>  #include "qemu/osdep.h"
>  #include "cpu.h"
> -#include "exec/exec-all.h"
>  #include "exec/memory.h"
>  #include "exec/address-spaces.h"
>  #include "exec/cpu_ldst.h"
> diff --git a/gdbstub.c b/gdbstub.c
> index ecea8c4..67eb028 100644
> --- a/gdbstub.c
> +++ b/gdbstub.c
> @@ -31,7 +31,6 @@
>
>  #define MAX_PACKET_LENGTH 4096
>
> -#include "cpu.h"
>  #include "qemu/sockets.h"
>  #include "sysemu/kvm.h"
>  #include "exec/semihost.h"
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index e999654..b2baa60 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -30,7 +30,6 @@
>  #include "qom/cpu.h"
>  #include "hw/i386/pc.h"
>  #include "target-i386/cpu.h"
> -#include "hw/timer/hpet.h"
>  #include "hw/acpi/acpi-defs.h"
>  #include "hw/acpi/acpi.h"
>  #include "hw/acpi/cpu.h"
> diff --git a/hw/microblaze/boot.c b/hw/microblaze/boot.c
> index 9eebb1a..1834d22 100644
> --- a/hw/microblaze/boot.c
> +++ b/hw/microblaze/boot.c
> @@ -30,7 +30,6 @@
>  #include "qemu/option.h"
>  #include "qemu/config-file.h"
>  #include "qemu/error-report.h"
> -#include "qemu-common.h"
>  #include "sysemu/device_tree.h"
>  #include "sysemu/sysemu.h"
>  #include "hw/loader.h"
> diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
> index e90857e..61aa8eb 100644
> --- a/hw/mips/mips_malta.c
> +++ b/hw/mips/mips_malta.c
> @@ -47,7 +47,6 @@
>  #include "elf.h"
>  #include "hw/timer/mc146818rtc.h"
>  #include "hw/timer/i8254.h"
> -#include "sysemu/block-backend.h"
>  #include "sysemu/blockdev.h"
>  #include "exec/address-spaces.h"
>  #include "hw/sysbus.h" /* SysBusDevice */
> diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
> index 92aa563..1f0c3e9 100644
> --- a/hw/nvram/fw_cfg.c
> +++ b/hw/nvram/fw_cfg.c
> @@ -29,7 +29,6 @@
>  #include "hw/isa/isa.h"
>  #include "hw/nvram/fw_cfg.h"
>  #include "hw/sysbus.h"
> -#include "hw/boards.h"
>  #include "trace.h"
>  #include "qemu/error-report.h"
>  #include "qemu/config-file.h"
> diff --git a/hw/pci-bridge/pci_expander_bridge.c
> b/hw/pci-bridge/pci_expander_bridge.c
> index 1cc598f..6ac187f 100644
> --- a/hw/pci-bridge/pci_expander_bridge.c
> +++ b/hw/pci-bridge/pci_expander_bridge.c
> @@ -15,7 +15,6 @@
>  #include "hw/pci/pci.h"
>  #include "hw/pci/pci_bus.h"
>  #include "hw/pci/pci_host.h"
> -#include "hw/pci/pci_bus.h"
>  #include "hw/pci/pci_bridge.h"
>  #include "hw/i386/pc.h"
>  #include "qemu/r

Re: [Qemu-devel] [PULL 06/22] linux-user: Fix syslog() syscall support

[Riku Voipio]

On Mon, Oct 17, 2016 at 04:24:24PM +0300, riku.voi...@linaro.org wrote:
> From: Aleksandar Markovic 
> 
> There are currently several problems related to syslog() support.
> 
> For example, if the second argument "bufp" of target syslog() syscall
> is NULL, the current implementation always returns error code EFAULT.
> However, NULL is a perfectly valid value for the second argument for
> many use cases of this syscall. This is, for example, visible from
> this excerpt of man page for syslog(2):
> 
> > EINVAL Bad arguments (e.g., bad type; or for type 2, 3, or 4, buf is
> >NULL, or len is less than zero; or for type 8, the level is
> >outside the range 1 to 8).
> 
> Moreover, the argument "bufp" is ignored for all cases of values of the
> first argument, except 2, 3 and 4. This means that for such cases
> (the first argument is not 2, 3 or 4), there is no need to pass "buf"
> between host and target, and it can be set to NULL while calling host's
> syslog(), without loss of emulation accuracy.
> 
> Note also that if "bufp" is NULL and the first argument is 2, 3 or 4, the
> correct returned error code is EINVAL, not EFAULT.
> 
> All these details are reflected in this patch.
> 
> "#ifdef TARGET_NR_syslog" is also proprerly inserted when needed.
> 
> Support for Qemu's "-strace" switch for syslog() syscall is included too.
> 
> LTP tests syslog11 and syslog12 pass with this patch (while fail without
> it), on any platform.
> 
> Signed-off-by: Aleksandar Markovic 
> Signed-off-by: Riku Voipio 
> ---
>  linux-user/strace.c   | 72 
> +++
>  linux-user/strace.list|  2 +-
>  linux-user/syscall.c  | 49 
>  linux-user/syscall_defs.h | 25 
>  4 files changed, 141 insertions(+), 7 deletions(-)
> 
> diff --git a/linux-user/strace.c b/linux-user/strace.c
> index a0e45b5..679f840 100644
> --- a/linux-user/strace.c
> +++ b/linux-user/strace.c
> @@ -1827,6 +1827,78 @@ print_rt_sigprocmask(const struct syscallname *name,
>  }
>  #endif
>  
> +#ifdef TARGET_NR_syslog
> +static void
> +print_syslog_action(abi_ulong arg, int last)
> +{
> +const char *type;
> +
> +switch (arg) {
> +case TARGET_SYSLOG_ACTION_CLOSE: {
> +type = "SYSLOG_ACTION_CLOSE";
> +break;
> +}
> +case TARGET_SYSLOG_ACTION_OPEN: {
> +type = "SYSLOG_ACTION_OPEN";
> +break;
> +}
> +case TARGET_SYSLOG_ACTION_READ: {
> +type = "SYSLOG_ACTION_READ";
> +break;
> +}
> +case TARGET_SYSLOG_ACTION_READ_ALL: {
> +type = "SYSLOG_ACTION_READ_ALL";
> +break;
> +}
> +case TARGET_SYSLOG_ACTION_READ_CLEAR: {
> +type = "SYSLOG_ACTION_READ_CLEAR";
> +break;
> +}
> +case TARGET_SYSLOG_ACTION_CLEAR: {
> +type = "SYSLOG_ACTION_CLEAR";
> +break;
> +}
> +case TARGET_SYSLOG_ACTION_CONSOLE_OFF: {
> +type = "SYSLOG_ACTION_CONSOLE_OFF";
> +break;
> +}
> +case TARGET_SYSLOG_ACTION_CONSOLE_ON: {
> +type = "SYSLOG_ACTION_CONSOLE_ON";
> +break;
> +}
> +case TARGET_SYSLOG_ACTION_CONSOLE_LEVEL: {
> +type = "SYSLOG_ACTION_CONSOLE_LEVEL";
> +break;
> +}
> +case TARGET_SYSLOG_ACTION_SIZE_UNREAD: {
> +type = "SYSLOG_ACTION_SIZE_UNREAD";
> +break;
> +}
> +case TARGET_SYSLOG_ACTION_SIZE_BUFFER: {
> +type = "SYSLOG_ACTION_SIZE_BUFFER";
> +break;
> +}
> +default: {
> +print_raw_param("%ld", arg, last);
> +return;
> +}
> +}
> +gemu_log("%s%s", type, get_comma(last));
> +}
> +
> +static void
> +print_syslog(const struct syscallname *name,
> +abi_long arg0, abi_long arg1, abi_long arg2,
> +abi_long arg3, abi_long arg4, abi_long arg5)
> +{
> +print_syscall_prologue(name);
> +print_syslog_action(arg0, 0);
> +print_pointer(arg1, 0);
> +print_raw_param("%d", arg2, 1);
> +print_syscall_epilogue(name);
> +}
> +#endif
> +
>  #ifdef TARGET_NR_mknod
>  static void
>  print_mknod(const struct syscallname *name,
> diff --git a/linux-user/strace.list b/linux-user/strace.list
> index f6dd044..2c7ad2b 100644
> --- a/linux-user/strace.list
> +++ b/linux-user/strace.list
> @@ -1486,7 +1486,7 @@
>  { TARGET_NR_sys_kexec_load, "sys_kexec_load" , NULL, NULL, NULL },
>  #endif
>  #ifdef TARGET_NR_syslog
> -{ TARGET_NR_syslog, "syslog" , NULL, NULL, NULL },
> +{ TARGET_NR_syslog, "syslog" , NULL, print_syslog, NULL },
>  #endif
>  #ifdef TARGET_NR_sysmips
>  { TARGET_NR_sysmips, "sysmips" , NULL, NULL, NULL },
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index 05b4c41..a3e7d51 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -9339,14 +9339,51 @@ abi_long 

Re: [Qemu-devel] qemu master tests/vmstate prints "Failed to load simple/primitive:b_1" etc

[Markus Armbruster]

Paolo Bonzini  writes:

> On 17/10/2016 21:15, Dr. David Alan Gilbert wrote:
>> * Peter Maydell (peter.mayd...@linaro.org) wrote:
>>> On 17 October 2016 at 19:51, Dr. David Alan Gilbert  
>>> wrote:
 * Peter Maydell (peter.mayd...@linaro.org) wrote:
> I've just noticed that qemu master running 'make check' prints
>   GTESTER tests/test-vmstate
> Failed to load simple/primitive:b_1
> Failed to load simple/primitive:i64_2
> Failed to load simple/primitive:i32_1
> Failed to load simple/primitive:i32_1
>
> but the test doesn't fail.
>
> Can we either (a) silence this output if it's spurious or (b) have
> it cause the test to fail if it's real (and fix the cause of the
> failure ;-)), please?

 The test (has always) tried loading truncated versions of the migration
 stream and made sure that it receives an error from vmstate_load_state.

 However I just added an error so we can see which field fails to load
 in a migration where we just used to get a 'migration has failed with -22'

 Is there a way to silence error_report's that's already in use in tests?
>>>
>>> We have some nasty hacks (like check for 'qtest_enabled()' before
>>> calling error_report()) but we don't have anything in the
>>> tree today that's a more coherent approach to the "test
>>> deliberately provoked this error" problem.

I guess the "more coherent approach" would be some way to run a piece of
code with error reporting suppressed.

For unit tests, a need to supress error reporting indicates the code
under test should perhaps error_setg() instead of error_report().
Unlikely to completely eliminate the need to suppress error reporting,
though.

>> Errors go to either the current monitor (if it's non-qmp) or
>> stderr; so could we create a dummy monitor to eat the errors
>> and make it current around that part?
>
> I guess you could reimplement the functions of stubs/mon-printf.c and
> stubs/mon-is-qmp.c.

qemu-error.c does all its output via error_vprintf():

void error_vprintf(const char *fmt, va_list ap)
{
if (cur_mon && !monitor_cur_is_qmp()) {
monitor_vprintf(cur_mon, fmt, ap);
} else {
vfprintf(stderr, fmt, ap);
}
}

Thus, custom monitor_cur_is_qmp() and monitor_vprintf() let you capture
its output.

Using (or rather abusing) this to suppress error reporting for an entire
program would be easy enough.  But I doubt it's a convenient way to
suppress more narrowly.

I figure a monitor connected to a "null" chardev would work better
there.  If we need that anyway, using it for the "entire program" case
as well is probably easiest.

Re: [Qemu-devel] [very-WIP 1/7] migration: Add VMSTATE_WITH_TMP

[Dr. David Alan Gilbert]

* Jianjun Duan (du...@linux.vnet.ibm.com) wrote:
> 
> 
> On 10/17/2016 12:16 PM, Dr. David Alan Gilbert wrote:
> > * Jianjun Duan (du...@linux.vnet.ibm.com) wrote:
> >>
> >>
> >> On 10/17/2016 11:52 AM, Dr. David Alan Gilbert wrote:
> >>> * Jianjun Duan (du...@linux.vnet.ibm.com) wrote:
> 
> 
>  On 10/16/2016 08:31 PM, David Gibson wrote:
> > On Tue, Oct 11, 2016 at 06:18:30PM +0100, Dr. David Alan Gilbert (git) 
> > wrote:
> >> From: "Dr. David Alan Gilbert" 
> >>
> >> VMSTATE_WITH_TMP is for handling structures where some calculation
> >> or rearrangement of the data needs to be performed before the data
> >> hits the wire.
> >> For example,  where the value on the wire is an offset from a
> >> non-migrated base, but the data in the structure is the actual pointer.
> >>
> >> To use it, a temporary type is created and a vmsd used on that type.
> >> The first element of the type must be 'parent' a pointer back to the
> >> type of the main structure.  VMSTATE_WITH_TMP takes care of allocating
> >> and freeing the temporary before running the child vmsd.
> >>
> >> The post_load/pre_save on the child vmsd can copy things from the 
> >> parent
> >> to the temporary using the parent pointer and do any other calculations
> >> needed; it can then use normal VMSD entries to do the actual data
> >> storage without having to fiddle around with qemu_get_*/qemu_put_*
> >>
>  If customized put/get can do transformation and dumping/loading data
>  to/from the parent structure, you don't have to go through
>  pre_save/post_load, and may get rid of parent pointer.
> >>>
> >>> Yes but I'd rather try and get rid of the customized put/get from
> >>> every device, because then people start using qemu_put/qemu_get in them 
> >>> all.
> >>>
> >> Then customized handling need to happen in pre_save/post_load. I think
> >> you need a way to pass TMP pointer around?
> > 
> > But then why is that better than having the parent pointer?
> > 
> IIUC, from the put_tmp, I didn't see how tmp is filled with data. I
> suppose it is to be filled by pre_save. So tmp pointer needs to find a
> way from inside pre_save to put_tmp. How does it happen?

The tmp.parent pointer is filled by the '*(void **)tmp = pv;' in the put_tmp and
get_tmp.
Only after that is the child vmsd run and it's passed the tmp pointer; it's the
child's pre_save/pre_load that has the chance to do whatever it likes to fill 
the
tmp.

Dave

> Thanks,
> Jianjun
> 
> 
> > Dave
> > 
> >>
> >> Thanks,
> >> Jianjun
> >>> Dave
> >>>
> 
>  Thanks,
>  Jianjun
> 
> >> Signed-off-by: Dr. David Alan Gilbert 
> >
> > The requirement for the parent pointer is a little clunky, but I don't
> > quickly see a better way, and it is compile-time verified.  As noted
> > elsewhere I think this is a really useful approach which could allow a
> > bunch of internal state cleanups while preserving migration.
> >
> > Reviewed-by: David Gibson 
> >
> >> ---
> >>  include/migration/vmstate.h | 20 
> >>  migration/vmstate.c | 38 
> >> ++
> >>  2 files changed, 58 insertions(+)
> >>
> >> diff --git a/include/migration/vmstate.h b/include/migration/vmstate.h
> >> index 9500da1..efb0e90 100644
> >> --- a/include/migration/vmstate.h
> >> +++ b/include/migration/vmstate.h
> >> @@ -259,6 +259,7 @@ extern const VMStateInfo vmstate_info_cpudouble;
> >>  extern const VMStateInfo vmstate_info_timer;
> >>  extern const VMStateInfo vmstate_info_buffer;
> >>  extern const VMStateInfo vmstate_info_unused_buffer;
> >> +extern const VMStateInfo vmstate_info_tmp;
> >>  extern const VMStateInfo vmstate_info_bitmap;
> >>  extern const VMStateInfo vmstate_info_qtailq;
> >>  
> >> @@ -651,6 +652,25 @@ extern const VMStateInfo vmstate_info_qtailq;
> >>  .offset = offsetof(_state, _field),  \
> >>  }
> >>  
> >> +/* Allocate a temporary of type 'tmp_type', set tmp->parent to _state
> >> + * and execute the vmsd on the temporary.  Note that we're working 
> >> with
> >> + * the whole of _state here, not a field within it.
> >> + * We compile time check that:
> >> + *That _tmp_type contains a 'parent' member that's a pointer to 
> >> the
> >> + *'_state' type
> >> + *That the pointer is right at the start of _tmp_type.
> >> + */
> >> +#define VMSTATE_WITH_TMP(_state, _tmp_type, _vmsd) { \
> >> +.name = "tmp",   \
> >> +.size = sizeof(_tmp_type) +  \
> >> +QEMU_BUILD_BUG_EXPR(offsetof(_tmp_type, parent) 
> >> != 0) + \
> >> +type_check_pointer(_state, 

Re: [Qemu-devel] [PATCH v4 RESEND 0/3] IOMMU: intel_iommu support map and unmap notifications

[Alex Williamson]

On Tue, 18 Oct 2016 16:52:04 +1100
David Gibson  wrote:

> On Mon, Oct 17, 2016 at 10:47:02PM -0600, Alex Williamson wrote:
> > On Tue, 18 Oct 2016 15:06:55 +1100
> > David Gibson  wrote:
> >   
> > > On Mon, Oct 17, 2016 at 10:07:36AM -0600, Alex Williamson wrote:  
> > > > On Mon, 17 Oct 2016 18:44:21 +0300
> > > > "Aviv B.D"  wrote:
> > > > 
> > > > > From: "Aviv Ben-David" 
> > > > > 
> > > > > * Advertize Cache Mode capability in iommu cap register. 
> > > > >   This capability is controlled by "cache-mode" property of 
> > > > > intel-iommu device.
> > > > >   To enable this option call QEMU with "-device 
> > > > > intel-iommu,cache-mode=true".
> > > > > 
> > > > > * On page cache invalidation in intel vIOMMU, check if the domain 
> > > > > belong to
> > > > >   registered notifier, and notify accordingly.
> > > > > 
> > > > > Currently this patch still doesn't enabling VFIO devices support with 
> > > > > vIOMMU 
> > > > > present. Current problems:
> > > > > * vfio_iommu_map_notify is not aware about memory range belong to 
> > > > > specific 
> > > > >   VFIOGuestIOMMU.
> > > > 
> > > > Could you elaborate on why this is an issue?
> > > > 
> > > > > * memory_region_iommu_replay hangs QEMU on start up while it itterate 
> > > > > over 
> > > > >   64bit address space. Commenting out the call to this function 
> > > > > enables 
> > > > >   workable VFIO device while vIOMMU present.
> > > > 
> > > > This has been discussed previously, it would be incorrect for vfio not
> > > > to call the replay function.  The solution is to add an iommu driver
> > > > callback to efficiently walk the mappings within a MemoryRegion.
> > > 
> > > Right, replay is a bit of a hack.  There are a couple of other
> > > approaches that might be adequate without a new callback:
> > >- Make the VFIOGuestIOMMU aware of the guest address range mapped
> > >  by the vIOMMU.  Intel currently advertises that as a full 64-bit
> > >  address space, but I bet that's not actually true in practice.
> > >- Have the IOMMU MR advertise a (minimum) page size for vIOMMU
> > >  mappings.  That may let you stpe through the range with greater
> > >  strides  
> > 
> > Hmm, VT-d supports at least a 39-bit address width and always supports
> > a minimum 4k page size, so yes that does reduce us from 2^52 steps down
> > to 2^27,  
> 
> Right, which is probably doable, if not ideal
> 
> > but it's still absurd to walk through the raw address space.  
> 
> Well.. it depends on the internal structure of the IOMMU.  For Power,
> it's traditionally just a 1-level page table, so we can't actually do
> any better than stepping through each IOMMU page.

Intel always has a least a 3-level page table AIUI.
 
> > It does however seem correct to create the MemoryRegion with a width
> > that actually matches the IOMMU capability, but I don't think that's a
> > sufficient fix by itself.  Thanks,  
> 
> I suspect it would actually make it workable in the short term.
> 
> But I don't disagree that a "traverse" or "replay" callback of some
> sort in the iommu_ops is a better idea long term.  Having a fallback
> to the current replay implementation if the callback isn't supplied
> seems pretty reasonable though.

Exactly, the callback could be optional where IOMMUs that supply a
relatively small IOVA window could fallback to the code we have today.
Thanks,

Alex

[Qemu-devel] [PATCH 3/3] ppc/xics: change the icp_ routines API to use an 'ICPState *' argument

[Cédric Le Goater]

The routines :

void icp_set_cppr(ICPState *icp, uint8_t cppr);
void icp_set_mfrr(ICPState *icp, uint8_t mfrr);
void icp_eoi(ICPState *icp, uint32_t xirr);

now use one 'ICPState *icp' argument instead of a 'XICSState *' and a
server arguments. The backlink on XICSState* is used whenever needed.

Signed-off-by: Cédric Le Goater 
---
 hw/intc/xics.c| 25 ++---
 hw/intc/xics_spapr.c  | 18 +++---
 include/hw/ppc/xics.h |  6 +++---
 3 files changed, 24 insertions(+), 25 deletions(-)

diff --git a/hw/intc/xics.c b/hw/intc/xics.c
index 9f2c81a7f140..095c16a30082 100644
--- a/hw/intc/xics.c
+++ b/hw/intc/xics.c
@@ -326,22 +326,20 @@ static void icp_check_ipi(ICPState *ss)
 qemu_irq_raise(ss->output);
 }
 
-static void icp_resend(XICSState *xics, int server)
+static void icp_resend(ICPState *ss)
 {
-ICPState *ss = xics->ss + server;
 ICSState *ics;
 
 if (ss->mfrr < CPPR(ss)) {
 icp_check_ipi(ss);
 }
-QLIST_FOREACH(ics, &xics->ics, list) {
+QLIST_FOREACH(ics, &ss->xics->ics, list) {
 ics_resend(ics);
 }
 }
 
-void icp_set_cppr(XICSState *xics, int server, uint8_t cppr)
+void icp_set_cppr(ICPState *ss, uint8_t cppr)
 {
-ICPState *ss = xics->ss + server;
 uint8_t old_cppr;
 uint32_t old_xisr;
 
@@ -361,15 +359,13 @@ void icp_set_cppr(XICSState *xics, int server, uint8_t 
cppr)
 }
 } else {
 if (!XISR(ss)) {
-icp_resend(xics, server);
+icp_resend(ss);
 }
 }
 }
 
-void icp_set_mfrr(XICSState *xics, int server, uint8_t mfrr)
+void icp_set_mfrr(ICPState *ss, uint8_t mfrr)
 {
-ICPState *ss = xics->ss + server;
-
 ss->mfrr = mfrr;
 if (mfrr < CPPR(ss)) {
 icp_check_ipi(ss);
@@ -398,23 +394,22 @@ uint32_t icp_ipoll(ICPState *ss, uint32_t *mfrr)
 return ss->xirr;
 }
 
-void icp_eoi(XICSState *xics, int server, uint32_t xirr)
+void icp_eoi(ICPState *ss, uint32_t xirr)
 {
-ICPState *ss = xics->ss + server;
 ICSState *ics;
 uint32_t irq;
 
 /* Send EOI -> ICS */
 ss->xirr = (ss->xirr & ~CPPR_MASK) | (xirr & CPPR_MASK);
-trace_xics_icp_eoi(server, xirr, ss->xirr);
+trace_xics_icp_eoi(ss->cs->cpu_index, xirr, ss->xirr);
 irq = xirr & XISR_MASK;
-QLIST_FOREACH(ics, &xics->ics, list) {
+QLIST_FOREACH(ics, &ss->xics->ics, list) {
 if (ics_valid_irq(ics, irq)) {
 ics_eoi(ics, irq);
 }
 }
 if (!XISR(ss)) {
-icp_resend(xics, server);
+icp_resend(ss);
 }
 }
 
@@ -673,7 +668,7 @@ static int ics_simple_post_load(ICSState *ics, int 
version_id)
 int i;
 
 for (i = 0; i < ics->xics->nr_servers; i++) {
-icp_resend(ics->xics, i);
+icp_resend(&ics->xics->ss[i]);
 }
 
 return 0;
diff --git a/hw/intc/xics_spapr.c b/hw/intc/xics_spapr.c
index a09e1b033df7..b4e55012e039 100644
--- a/hw/intc/xics_spapr.c
+++ b/hw/intc/xics_spapr.c
@@ -43,9 +43,10 @@ static target_ulong h_cppr(PowerPCCPU *cpu, 
sPAPRMachineState *spapr,
target_ulong opcode, target_ulong *args)
 {
 CPUState *cs = CPU(cpu);
+ICPState *icp = &spapr->xics->ss[cs->cpu_index];
 target_ulong cppr = args[0];
 
-icp_set_cppr(spapr->xics, cs->cpu_index, cppr);
+icp_set_cppr(icp, cppr);
 return H_SUCCESS;
 }
 
@@ -59,7 +60,7 @@ static target_ulong h_ipi(PowerPCCPU *cpu, sPAPRMachineState 
*spapr,
 return H_PARAMETER;
 }
 
-icp_set_mfrr(spapr->xics, server, mfrr);
+icp_set_mfrr(spapr->xics->ss + server, mfrr);
 return H_SUCCESS;
 }
 
@@ -67,7 +68,8 @@ static target_ulong h_xirr(PowerPCCPU *cpu, sPAPRMachineState 
*spapr,
target_ulong opcode, target_ulong *args)
 {
 CPUState *cs = CPU(cpu);
-uint32_t xirr = icp_accept(spapr->xics->ss + cs->cpu_index);
+ICPState *icp = &spapr->xics->ss[cs->cpu_index];
+uint32_t xirr = icp_accept(icp);
 
 args[0] = xirr;
 return H_SUCCESS;
@@ -77,8 +79,8 @@ static target_ulong h_xirr_x(PowerPCCPU *cpu, 
sPAPRMachineState *spapr,
  target_ulong opcode, target_ulong *args)
 {
 CPUState *cs = CPU(cpu);
-ICPState *ss = &spapr->xics->ss[cs->cpu_index];
-uint32_t xirr = icp_accept(ss);
+ICPState *icp = &spapr->xics->ss[cs->cpu_index];
+uint32_t xirr = icp_accept(icp);
 
 args[0] = xirr;
 args[1] = cpu_get_host_ticks();
@@ -89,9 +91,10 @@ static target_ulong h_eoi(PowerPCCPU *cpu, sPAPRMachineState 
*spapr,
   target_ulong opcode, target_ulong *args)
 {
 CPUState *cs = CPU(cpu);
+ICPState *icp = &spapr->xics->ss[cs->cpu_index];
 target_ulong xirr = args[0];
 
-icp_eoi(spapr->xics, cs->cpu_index, xirr);
+icp_eoi(icp, xirr);
 return H_SUCCESS;
 }
 
@@ -99,8 +102,9 @@ static target_ulong h_ipoll(PowerPCCPU *cpu, 
sPAPRMachineState *spapr,
 target_ulong opcode, target_ulong *args)
 {
 CPUSt

[Qemu-devel] [PATCH 0/3] ppc/xics: interface cleanups

[Cédric Le Goater]

Hello,

Here are a couple of changes removing duplicated code and modifying
the remaining icp_ routines still using a 'XICSState *' as argument.

Thanks,

C. 

Cédric Le Goater (3):
  ppc/xics: add a xics_set_nr_servers common routine
  ppc/xics: add a XICSState backlink in ICPState
  ppc/xics: change the icp_ routines API to use an 'ICPState *' argument

 hw/intc/xics.c| 50 --
 hw/intc/xics_kvm.c| 13 +
 hw/intc/xics_spapr.c  | 31 ---
 include/hw/ppc/xics.h | 10 +++---
 4 files changed, 52 insertions(+), 52 deletions(-)

-- 
2.7.4

[Qemu-devel] [PATCH 2/3] ppc/xics: add a XICSState backlink in ICPState

[Cédric Le Goater]

The link will be used to change the API of the icp_* routines which
are still using an XICSState as an argument.

Signed-off-by: Cédric Le Goater 
---
 hw/intc/xics.c| 1 +
 include/hw/ppc/xics.h | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/hw/intc/xics.c b/hw/intc/xics.c
index c051eebb446b..9f2c81a7f140 100644
--- a/hw/intc/xics.c
+++ b/hw/intc/xics.c
@@ -198,6 +198,7 @@ void xics_set_nr_servers(XICSState *xics, uint32_t 
nr_servers,
 object_initialize(icp, sizeof(*icp), typename);
 snprintf(name, sizeof(name), "icp[%d]", i);
 object_property_add_child(OBJECT(xics), name, OBJECT(icp), errp);
+icp->xics = xics;
 }
 }
 
diff --git a/include/hw/ppc/xics.h b/include/hw/ppc/xics.h
index 573b1920536b..1468d6a89088 100644
--- a/include/hw/ppc/xics.h
+++ b/include/hw/ppc/xics.h
@@ -117,6 +117,8 @@ struct ICPState {
 uint8_t mfrr;
 qemu_irq output;
 bool cap_irq_xics_enabled;
+
+XICSState *xics;
 };
 
 #define TYPE_ICS_BASE "ics-base"
-- 
2.7.4

[Qemu-devel] [PATCH 1/3] ppc/xics: add a xics_set_nr_servers common routine

[Cédric Le Goater]

xics_spapr and xics_kvm nearly define the same 'set_nr_servers'
handler. Only the type of the ICP differs. So let's make a common one
to remove some duplicated code.

Signed-off-by: Cédric Le Goater 
---
 hw/intc/xics.c| 24 +---
 hw/intc/xics_kvm.c| 13 +
 hw/intc/xics_spapr.c  | 13 +
 include/hw/ppc/xics.h |  2 ++
 4 files changed, 25 insertions(+), 27 deletions(-)

diff --git a/hw/intc/xics.c b/hw/intc/xics.c
index 7fac964fbd27..c051eebb446b 100644
--- a/hw/intc/xics.c
+++ b/hw/intc/xics.c
@@ -183,6 +183,24 @@ static void xics_prop_set_nr_irqs(Object *obj, Visitor *v, 
const char *name,
 info->set_nr_irqs(xics, value, errp);
 }
 
+void xics_set_nr_servers(XICSState *xics, uint32_t nr_servers,
+ const char *typename, Error **errp)
+{
+int i;
+
+xics->nr_servers = nr_servers;
+
+xics->ss = g_malloc0(xics->nr_servers * sizeof(ICPState));
+for (i = 0; i < xics->nr_servers; i++) {
+char name[32];
+ICPState *icp = &xics->ss[i];
+
+object_initialize(icp, sizeof(*icp), typename);
+snprintf(name, sizeof(name), "icp[%d]", i);
+object_property_add_child(OBJECT(xics), name, OBJECT(icp), errp);
+}
+}
+
 static void xics_prop_get_nr_servers(Object *obj, Visitor *v,
  const char *name, void *opaque,
  Error **errp)
@@ -198,7 +216,7 @@ static void xics_prop_set_nr_servers(Object *obj, Visitor 
*v,
  Error **errp)
 {
 XICSState *xics = XICS_COMMON(obj);
-XICSStateClass *info = XICS_COMMON_GET_CLASS(xics);
+XICSStateClass *xsc = XICS_COMMON_GET_CLASS(xics);
 Error *error = NULL;
 int64_t value;
 
@@ -213,8 +231,8 @@ static void xics_prop_set_nr_servers(Object *obj, Visitor 
*v,
 return;
 }
 
-assert(info->set_nr_servers);
-info->set_nr_servers(xics, value, errp);
+assert(xsc->set_nr_servers);
+xsc->set_nr_servers(xics, value, errp);
 }
 
 static void xics_common_initfn(Object *obj)
diff --git a/hw/intc/xics_kvm.c b/hw/intc/xics_kvm.c
index 9c2f198fd142..17694eaa8709 100644
--- a/hw/intc/xics_kvm.c
+++ b/hw/intc/xics_kvm.c
@@ -373,18 +373,7 @@ static void xics_kvm_set_nr_irqs(XICSState *xics, uint32_t 
nr_irqs,
 static void xics_kvm_set_nr_servers(XICSState *xics, uint32_t nr_servers,
 Error **errp)
 {
-int i;
-
-xics->nr_servers = nr_servers;
-
-xics->ss = g_malloc0(xics->nr_servers * sizeof(ICPState));
-for (i = 0; i < xics->nr_servers; i++) {
-char buffer[32];
-object_initialize(&xics->ss[i], sizeof(xics->ss[i]), TYPE_KVM_ICP);
-snprintf(buffer, sizeof(buffer), "icp[%d]", i);
-object_property_add_child(OBJECT(xics), buffer, OBJECT(&xics->ss[i]),
-  errp);
-}
+xics_set_nr_servers(xics, nr_servers, TYPE_KVM_ICP, errp);
 }
 
 static void rtas_dummy(PowerPCCPU *cpu, sPAPRMachineState *spapr,
diff --git a/hw/intc/xics_spapr.c b/hw/intc/xics_spapr.c
index e8d0623c2cb5..a09e1b033df7 100644
--- a/hw/intc/xics_spapr.c
+++ b/hw/intc/xics_spapr.c
@@ -249,18 +249,7 @@ static void xics_spapr_set_nr_irqs(XICSState *xics, 
uint32_t nr_irqs,
 static void xics_spapr_set_nr_servers(XICSState *xics, uint32_t nr_servers,
   Error **errp)
 {
-int i;
-
-xics->nr_servers = nr_servers;
-
-xics->ss = g_malloc0(xics->nr_servers * sizeof(ICPState));
-for (i = 0; i < xics->nr_servers; i++) {
-char buffer[32];
-object_initialize(&xics->ss[i], sizeof(xics->ss[i]), TYPE_ICP);
-snprintf(buffer, sizeof(buffer), "icp[%d]", i);
-object_property_add_child(OBJECT(xics), buffer, OBJECT(&xics->ss[i]),
-  errp);
-}
+xics_set_nr_servers(xics, nr_servers, TYPE_ICP, errp);
 }
 
 static void xics_spapr_realize(DeviceState *dev, Error **errp)
diff --git a/include/hw/ppc/xics.h b/include/hw/ppc/xics.h
index 66ae55ded387..573b1920536b 100644
--- a/include/hw/ppc/xics.h
+++ b/include/hw/ppc/xics.h
@@ -188,6 +188,8 @@ void xics_spapr_free(XICSState *icp, int irq, int num);
 
 void xics_cpu_setup(XICSState *icp, PowerPCCPU *cpu);
 void xics_cpu_destroy(XICSState *icp, PowerPCCPU *cpu);
+void xics_set_nr_servers(XICSState *xics, uint32_t nr_servers,
+ const char *typename, Error **errp);
 
 /* Internal XICS interfaces */
 int xics_get_cpu_index_by_dt_id(int cpu_dt_id);
-- 
2.7.4

Re: [Qemu-devel] [PATCH] script/clean-includes: added duplicate #include check

[Thomas Huth]

On 12.10.2016 20:40, Anand J wrote:
> Added script to check duplicate #include entries. This check will scan and
> print the files in which duplicate #include entries are present.
> 
> Script might output false postive entries as well. Such entries should
> not be removed. So if it finds any duplicate entries script will terminate
> with an exit status 1. Then each and every file should be checked manually
> and corrected if necessary.
> 
> Added an additional option --ignore-duphead in the clean-includes
> script to disable this check if all the duplicate #includes are
> genuine. The check in enabled by default.

Hmm, maybe it would be better to do it the other way round? Do not check
this by default since there are files that need to include a header
twice, and add a "--check-duphead" option to enable this check?

> NOTE: Removed some of the genuine duplicate entries in the code base.

Could you please split this patch into two parts? One patch that changes
the clean-includes script, and one that removes the superfluous
"#include" statements? That would help to make this patch more reviewable...

> diff --git a/accel.c b/accel.c
> index 403eb5e..b5a4210 100644
> --- a/accel.c
> +++ b/accel.c
> @@ -25,7 +25,6 @@
>  
>  #include "qemu/osdep.h"
>  #include "sysemu/accel.h"
> -#include "hw/boards.h"
>  #include "qemu-common.h"
>  #include "sysemu/arch_init.h"
>  #include "sysemu/sysemu.h"

Since the include order still matters in some files, I think it would be
better if you'd always remove the second include statement, not the
first one.

 Thomas

Re: [Qemu-devel] [PULL 00/25] target-arm queue

[Peter Maydell]

On 17 October 2016 at 19:40, Peter Maydell  wrote:
> Random mix of stuff here, nothing in particular
> very large. Includes a fix for the regression running
> Thumb userspace code.
>
> thanks
> -- PMM
>
>
> The following changes since commit 0975b8b823a888d474fa33821dfe84e6904db197:
>
>   Merge remote-tracking branch 'remotes/gkurz/tags/for-upstream' into staging 
> (2016-10-17 16:17:51 +0100)
>
> are available in the git repository at:
>
>   git://git.linaro.org/people/pmaydell/qemu-arm.git 
> tags/pull-target-arm-20161017
>
> for you to fetch changes up to 041ac05672993ff33a15f8017c0f729ca6dfad73:
>
>   hw/char/pl011: Add trace events (2016-10-17 19:32:44 +0100)
>
> 
> target-arm:
>  * target-arm: kvm: use AddressSpace-specific listener
>  * aspeed: add SMC controllers
>  * hw/arm/boot: allow using a command line specified dtb without a kernel
>  * hw/dma/pl080: Fix bad bit mask
>  * hw/intc/arm_gic_kvm: Fix build on aarch64 with some compilers
>  * hw/arm/virt: fix ACPI tables for ITS
>  * tests: add a m25p80 test
>  * tests: cleanup ptimer-test
>  * pxa2xx: Auto-assign name for i2c bus in i2c_init_bus
>  * target-arm: handle tagged addresses in A64 code
>  * target-arm: Fix masking of PC lower bits when doing exception returns
>  * target-arm: Implement dummy MDCCINT_EL1
>  * target-arm: Add trace events for the generic timers
>  * hw/intc/arm_gicv3: Fix ICC register tracepoints
>  * hw/char/pl011: Add trace events

Applied, thanks.

-- PMM

[Qemu-devel] [Bug 1631773] Re: hw/dma/pl080.c:354: possible typo ?

[T. Huth]

Thanks for reporting the issue, patch has now been included here:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=04bb79d1f519ae190a

** Changed in: qemu
   Status: New => Fix Committed

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

Title:
  hw/dma/pl080.c:354: possible typo ?

Status in QEMU:
  Fix Committed

Bug description:
  hw/dma/pl080.c:354:1: warning: V578 An odd bitwise operation detected:
  s->conf & (0x2 | 0x2). Consider verifying it.

  Source code is

 if (s->conf & (PL080_CONF_M1 | PL080_CONF_M1)) {

  Maybe better code

 if (s->conf & (PL080_CONF_M1 | PL080_CONF_M2)) {

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

[Qemu-devel] [v2] nvic: set pending status for not active interrupts

[marcin.krzeminski]

From: Marcin Krzeminski 

According to ARM DUI 0552A 4.2.10. NVIC set pending status
also for disabled interrupts. This patch adds possibility
to emulate this in Qemu.

Signed-off-by: Marcin Krzeminski 
---
Changes for v2:
- add a dedicated unction for nvic
- update complete_irq
 hw/intc/arm_gic.c | 27 +--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
index b30cc91..72e4c01 100644
--- a/hw/intc/arm_gic.c
+++ b/hw/intc/arm_gic.c
@@ -156,6 +156,21 @@ static void gic_set_irq_11mpcore(GICState *s, int irq, int 
level,
 }
 }
 
+static void gic_set_irq_nvic(GICState *s, int irq, int level,
+ int cm, int target)
+{
+if (level) {
+GIC_SET_LEVEL(irq, cm);
+if (GIC_TEST_EDGE_TRIGGER(irq) || GIC_TEST_ENABLED(irq, cm)
+|| !GIC_TEST_ACTIVE(irq, cm)) {
+DPRINTF("Set %d pending mask %x\n", irq, target);
+GIC_SET_PENDING(irq, target);
+}
+} else {
+GIC_CLEAR_LEVEL(irq, cm);
+}
+}
+
 static void gic_set_irq_generic(GICState *s, int irq, int level,
 int cm, int target)
 {
@@ -201,8 +216,10 @@ static void gic_set_irq(void *opaque, int irq, int level)
 return;
 }
 
-if (s->revision == REV_11MPCORE || s->revision == REV_NVIC) {
+if (s->revision == REV_11MPCORE) {
 gic_set_irq_11mpcore(s, irq, level, cm, target);
+} else if (s->revision == REV_NVIC) {
+gic_set_irq_nvic(s, irq, level, cm, target);
 } else {
 gic_set_irq_generic(s, irq, level, cm, target);
 }
@@ -568,7 +585,7 @@ void gic_complete_irq(GICState *s, int cpu, int irq, 
MemTxAttrs attrs)
 return; /* No active IRQ.  */
 }
 
-if (s->revision == REV_11MPCORE || s->revision == REV_NVIC) {
+if (s->revision == REV_11MPCORE) {
 /* Mark level triggered interrupts as pending if they are still
raised.  */
 if (!GIC_TEST_EDGE_TRIGGER(irq) && GIC_TEST_ENABLED(irq, cm)
@@ -576,6 +593,12 @@ void gic_complete_irq(GICState *s, int cpu, int irq, 
MemTxAttrs attrs)
 DPRINTF("Set %d pending mask %x\n", irq, cm);
 GIC_SET_PENDING(irq, cm);
 }
+} else if (s->revision == REV_NVIC) {
+if (GIC_TEST_ENABLED(irq, cm) && GIC_TEST_LEVEL(irq, cm)
+&& (GIC_TARGET(irq) & cm) != 0) {
+DPRINTF("Set nvic %d pending mask %x\n", irq, cm);
+GIC_SET_PENDING(irq, cm);
+}
 }
 
 group = gic_has_groups(s) && GIC_TEST_GROUP(irq, cm);
-- 
2.7.4

[Qemu-devel] [Bug 1452742] Re: the option for vdagent communication needed for qxl scren resizing is not documented

[T. Huth]

To be able to include your patch, you've got to send it to the qemu-
devel mailing list, with a proper Signed-off-by line. Please see http
://qemu-project.org/Contribute/SubmitAPatch#Submitting_your_Patches for
details.

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

Title:
  the option for vdagent communication needed for qxl scren resizing is
  not documented

Status in QEMU:
  New

Bug description:
  Hello,

  I tried running a guest with vdagent which is supposed to resize the
  guest screen to match client window size.

  However, a special serial port needs to be created for the vdagent to
  communicate with the client.

  This patch adds a short note to the vga qxl option.

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

[Qemu-devel] [Bug 498039] Re: No copy/paste with VNC display with Windows guest

[T. Huth]

Right, this problem should be fixed with Spice, so I'm closing this
ticket now.

** Changed in: qemu
   Status: Confirmed => Fix Released

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

Title:
  No copy/paste with VNC display with Windows guest

Status in QEMU:
  Fix Released

Bug description:
  There is no copy/paste functionality between a Windows guest and the
  VNC client.  This is a significant usability problem.

  One work-around is to run VNC inside of the guest.  But that appears
  to have more overhead than qemu's VNC display.

  Obviously, qemu's VNC display is just a display device and knows
  absolutely nothing about the Windows clipboard.  Thus, to interface
  with the guest's clipboard would require a helper app running in the
  guest that can hook into qemu.  This would probably be the best
  solution.

  There are probably not a lot of qemu developers interested in trying
  to write the helper app.  Not exactly an interesting job.  But since
  it is a significant usability problem, and many users would see this
  as a major oversight, I suggest leaving this bug open long-term as a
  hint so that some volunteer later looking for something to do might
  take pity on everyone and write this helper app.

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

[Qemu-devel] [Bug 1329956] Re: multi-core FreeBSD guest hangs after warm reboot

[T. Huth]

OK, according to the last comments, the bug has been fixed somewhere
with the last kernel or QEMU releases, so I'm closing this ticket now.

** Changed in: qemu
   Status: Incomplete => Fix Released

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

Title:
  multi-core FreeBSD guest hangs after warm reboot

Status in QEMU:
  Fix Released

Bug description:
  On some Linux KVM hosts in our environment, FreeBSD guests fail to
  reboot properly if they have more than one CPU (socket, core, and/or
  thread). They will boot fine the first time, but after issuing a
  "reboot" command via the OS the guest starts to boot but hangs during
  SMP initialization. Fully shutting down and restarting the guest works
  in all cases.

  The only meaningful difference between hosts with the problem and those 
without is the CPU. Hosts with Xeon E5-26xx v2 processors have the problem, 
including at least the "Intel(R) Xeon(R) CPU E5-2667 v2" and the "Intel(R) 
Xeon(R) CPU E5-2650 v2".
  Hosts with any other CPU, including "Intel(R) Xeon(R) CPU E5-2650 0", 
"Intel(R) Xeon(R) CPU E5-2620 0", or "AMD Opteron(TM) Processor 6274" do not 
have the problem. Note the "v2" in the names of the problematic CPUs.

  On hosts with a "v2" Xeon, I can reproduce the problem under Linux
  kernel 3.10 or 3.12 and Qemu 1.7.0 or 2.0.0.

  The problem occurs with all currently-supported versions of FreeBSD,
  including 8.4, 9.2, 10.0 and 11-CURRENT.

  On a Linux KVM host with a "v2" Xeon, this command line is adequate to
  reproduce the problem:

  /usr/bin/qemu-system-x86_64 -machine accel=kvm -name bsdtest -m 512
  -smp 2,sockets=1,cores=1,threads=2 -drive
  file=./20140613_FreeBSD_9.2-RELEASE_ufs.qcow2,if=none,id=drive0,format=qcow2
  -device virtio-blk-pci,scsi=off,drive=drive0 -vnc 0.0.0.0:0 -net none

  I have tried many variations including different models of -machine
  and -cpu for the guest with no visible difference.

  A native FreeBSD installation on a host with a "v2" Xeon does not have
  the problem, nor do a paravirtualized FreeBSD guests under bhyve (the
  BSD legacy-free hypervisor) using the same FreeBSD disk images as on
  the Linux hosts. So it seems unlikely the cause is on the FreeBSD side
  of things.

  I would greatly appreciate any feedback or developer attention to
  this. I am happy to provide additional details, test patches, etc.

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

Re: [Qemu-devel] [PATCH v3 05/13] pc: leave max apic_id_limit only in legacy cpu hotplug code

[Igor Mammedov]

On Mon, 17 Oct 2016 19:44:52 -0200
Eduardo Habkost  wrote:

> On Thu, Oct 13, 2016 at 11:52:39AM +0200, Igor Mammedov wrote:
> [...]
> > @@ -236,7 +237,11 @@ void build_legacy_cpu_hotplug_aml(Aml *ctx, 
> > MachineState *machine,
> >  /* The current AML generator can cover the APIC ID range [0..255],
> >   * inclusive, for VCPU hotplug. */
> >  QEMU_BUILD_BUG_ON(ACPI_CPU_HOTPLUG_ID_LIMIT > 256);
> > -g_assert(pcms->apic_id_limit <= ACPI_CPU_HOTPLUG_ID_LIMIT);
> > +if (pcms->apic_id_limit > ACPI_CPU_HOTPLUG_ID_LIMIT) {
> > +error_report("max_cpus is too large. APIC ID of last CPU is %u",
> > + pcms->apic_id_limit - 1);
> > +exit(1);
> > +}  
> 
> Moving the check here seems to make sense, but:
> 
> >  
> >  /* create PCI0.PRES device and its _CRS to reserve CPU hotplug MMIO */
> >  dev = aml_device("PCI0." stringify(CPU_HOTPLUG_RESOURCE_DEVICE));
> > diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> > index 93ff49c..f1c1013 100644
> > --- a/hw/i386/pc.c
> > +++ b/hw/i386/pc.c
> > @@ -778,7 +778,6 @@ static FWCfgState *bochs_bios_init(AddressSpace *as, 
> > PCMachineState *pcms)  
> 
> [Added more context below to show the code around the change]
> 
> >  numa_fw_cfg = g_new0(uint64_t, 1 + pcms->apic_id_limit + 
> > nb_numa_nodes);
> >  numa_fw_cfg[0] = cpu_to_le64(nb_numa_nodes);
> >  for (i = 0; i < max_cpus; i++) {
> >  unsigned int apic_id = x86_cpu_apic_id_from_index(i);
> > -assert(apic_id < pcms->apic_id_limit);  
> 
> If you really needed to remove this assert, that means you can
> write beyond the end of numa_fw_fg[] below. Are you sure you need
> to remove it?
> 
> >  j = numa_get_node_for_cpu(i);
> >  if (j < nb_numa_nodes) {
> >  numa_fw_cfg[apic_id + 1] = cpu_to_le64(j);  
> 
>^^^ here
Shouldn't above
  numa_fw_cfg = g_new0(uint64_t, 1 + pcms->apic_id_limit + nb_numa_nodes);
allocate sufficiently sized array?

That's aside, the assert could be kept as it doesn't get in a way
if you'd prefer it that way.

> >  }
> >  }
> > 
> > @@ -1190,12 +1189,6 @@ void pc_cpus_init(PCMachineState *pcms)
> >   * This is used for FW_CFG_MAX_CPUS. See comments on bochs_bios_init().
> >   */
> >  pcms->apic_id_limit = x86_cpu_apic_id_from_index(max_cpus - 1) + 1;
> > -if (pcms->apic_id_limit > ACPI_CPU_HOTPLUG_ID_LIMIT) {
> > -error_report("max_cpus is too large. APIC ID of last CPU is %u",
> > - pcms->apic_id_limit - 1);
> > -exit(1);
> > -}
> > -
> >  pcms->possible_cpus = g_malloc0(sizeof(CPUArchIdList) +
> >  sizeof(CPUArchId) * max_cpus);
> >  for (i = 0; i < max_cpus; i++) {
> > -- 
> > 2.7.4
> >   
> 

Re: [Qemu-devel] invtsc + migration + TSC scaling

[Dr. David Alan Gilbert]

* Radim Krčmář (rkrc...@redhat.com) wrote:
> 2016-10-17 07:47-0200, Marcelo Tosatti:
> > On Fri, Oct 14, 2016 at 06:20:31PM -0300, Eduardo Habkost wrote:
> >> I have been wondering: should we allow live migration with the
> >> invtsc flag enabled, if TSC scaling is available on the
> >> destination?
> > 
> > TSC scaling and invtsc flag, yes.
> 
> Yes, if we have well synchronized time between hosts, then we might be
> able to migrate with a TSC shift that cannot be perceived by the guest.
> 
> Unless the VM also has a migratable assigned PCI device that uses ART,
> because we have no protocol to update the setting of ART (in CPUID), so
> we should keep migration forbidden then.
> 
> >> For reference, this is what the Intel SDM says about invtsc:
> >> 
> >>   The time stamp counter in newer processors may support an
> >>   enhancement, referred to as invariant TSC. Processor’s support
> >>   for invariant TSC is indicated by CPUID.8007H:EDX[8].
> >> 
> >>   The invariant TSC will run at a constant rate in all ACPI P-,
> >>   C-. and T-states. This is the architectural behavior moving
> >>   forward. On processors with invariant TSC support, the OS may
> >>   use the TSC for wall clock timer services (instead of ACPI or
> >>   HPET timers). TSC reads are much more efficient and do not
> >>   incur the overhead associated with a ring transition or access
> >>   to a platform resource.
> >
> > Yes. The blockage happened for different reasons:
> > 
> > 1) Migration: to host with different TSC frequency.
> 
> We shouldn't have done this even now when emulating anything newer than
> Pentium 4, because those CPUs have constant TSC, which only lacks the
> guarantee that it doesn't stop in deep C-states:
> 
>   For [a list of processors we emulate]: the time-stamp counter
>   increments at a constant rate. That rate may be set by the maximum
>   core-clock to bus-clock ratio of the processor or may be set by the
>   maximum resolved frequency at which the processor is booted. The
>   maximum resolved frequency may differ from the processor base
>   frequency, see Section 18.18.2 for more detail. On certain processors,
>   the TSC frequency may not be the same as the frequency in the brand
>   string.
> 
>   The specific processor configuration determines the behavior. Constant
>   TSC behavior ensures that the duration of each clock tick is uniform
>   and supports the use of the TSC as a wall clock timer even if the
>   processor core changes frequency. This is the architectural behavior
>   moving forward.
> 
> Invariant TSC is more useful, though, so more applications would break
> when migrating to a different TSC frequency.
> 
> > 2) Savevm: It is not safe to use the TSC for wall clock timer
> > services.
> 
> With constant TSC, we could argue that a shift to deep C-state happened
> and paused TSC, which is not a good behavior, but somewhat defensible.
> 
> > By allowing savevm, you make a commitment to allow a feature
> > at the expense of not complying with the spec (specifically the "
> > the OS may use the TSC for wall clock timer services", because the
> > TSC stops relative to realtime for the duration of the savevm stop
> > window).
> 
> Yep, we should at least guesstimate the TSC to allow the guest to resume
> with as small TSC-shift as possible and check that hosts were somewhat
> synchronized with UTC (or something we choose for time).
> 
> > But since Linux guests use kvmclock and Windows guests use Hyper-V
> > enlightenment, it should be fine to disable 2).
> > 
> > There is a bug open for this, btw: 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1353073
> 
> These people should be happy with just live-migrations, so can't we just
> keep savevm forbidden?

Why is savevm so much harder? Is it just the difference in real time?
If so then I do worry about how small a difference you're hoping
to guarentee in live-migration.

Dave

> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [Qemu-devel] [PATCH v3 05/13] pc: leave max apic_id_limit only in legacy cpu hotplug code

[Igor Mammedov]

On Mon, 17 Oct 2016 19:44:52 -0200
Eduardo Habkost  wrote:

> On Thu, Oct 13, 2016 at 11:52:39AM +0200, Igor Mammedov wrote:
> [...]
> > @@ -236,7 +237,11 @@ void build_legacy_cpu_hotplug_aml(Aml *ctx, 
> > MachineState *machine,
> >  /* The current AML generator can cover the APIC ID range [0..255],
> >   * inclusive, for VCPU hotplug. */
> >  QEMU_BUILD_BUG_ON(ACPI_CPU_HOTPLUG_ID_LIMIT > 256);
> > -g_assert(pcms->apic_id_limit <= ACPI_CPU_HOTPLUG_ID_LIMIT);
> > +if (pcms->apic_id_limit > ACPI_CPU_HOTPLUG_ID_LIMIT) {
> > +error_report("max_cpus is too large. APIC ID of last CPU is %u",
> > + pcms->apic_id_limit - 1);
> > +exit(1);
> > +}  
> 
> Moving the check here seems to make sense, but:
> 
> >  
> >  /* create PCI0.PRES device and its _CRS to reserve CPU hotplug MMIO */
> >  dev = aml_device("PCI0." stringify(CPU_HOTPLUG_RESOURCE_DEVICE));
> > diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> > index 93ff49c..f1c1013 100644
> > --- a/hw/i386/pc.c
> > +++ b/hw/i386/pc.c
> > @@ -778,7 +778,6 @@ static FWCfgState *bochs_bios_init(AddressSpace *as, 
> > PCMachineState *pcms)  
> 
> [Added more context below to show the code around the change]
> 
> >  numa_fw_cfg = g_new0(uint64_t, 1 + pcms->apic_id_limit + 
> > nb_numa_nodes);
> >  numa_fw_cfg[0] = cpu_to_le64(nb_numa_nodes);
> >  for (i = 0; i < max_cpus; i++) {
> >  unsigned int apic_id = x86_cpu_apic_id_from_index(i);
> > -assert(apic_id < pcms->apic_id_limit);  
> 
> If you really needed to remove this assert, that means you can
> write beyond the end of numa_fw_fg[] below. Are you sure you need
> to remove it?
> 
> >  j = numa_get_node_for_cpu(i);
> >  if (j < nb_numa_nodes) {
> >  numa_fw_cfg[apic_id + 1] = cpu_to_le64(j);  
> 
>^^^ here
> 
> >  }
Another more radical way to deal with legacy FW_CFG_NUMA
could be to remove it altogether if machine has x2APIC cpus.
It'd be possible to do due to BIOS using QEMU provided
BIOS tables and not using/calling code for built in/legacy
ACPI tables.

Could do it as patch on top if that's sounds ok.

> >  }
> > 
> > @@ -1190,12 +1189,6 @@ void pc_cpus_init(PCMachineState *pcms)
> >   * This is used for FW_CFG_MAX_CPUS. See comments on bochs_bios_init().
> >   */
> >  pcms->apic_id_limit = x86_cpu_apic_id_from_index(max_cpus - 1) + 1;
> > -if (pcms->apic_id_limit > ACPI_CPU_HOTPLUG_ID_LIMIT) {
> > -error_report("max_cpus is too large. APIC ID of last CPU is %u",
> > - pcms->apic_id_limit - 1);
> > -exit(1);
> > -}
> > -
> >  pcms->possible_cpus = g_malloc0(sizeof(CPUArchIdList) +
> >  sizeof(CPUArchId) * max_cpus);
> >  for (i = 0; i < max_cpus; i++) {
> > -- 
> > 2.7.4
> >   
> 

[Qemu-devel] [PATCH] qapi: fix memory leak in QmpOutputVisitor

[Pino Toscano]

qmp_output_start_struct() and qmp_output_start_list() create a new
QObject (QDict, QList) and push it to the stack of the QmpOutputVisitor,
where it is saved as 'value'.  When freeing the iterator in
qmp_output_free(), these values are never freed properly.

The simple solution is to qobject_decref() them.
---
 qapi/qmp-output-visitor.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/qapi/qmp-output-visitor.c b/qapi/qmp-output-visitor.c
index 9e3b67c..eedf256 100644
--- a/qapi/qmp-output-visitor.c
+++ b/qapi/qmp-output-visitor.c
@@ -220,6 +220,7 @@ static void qmp_output_free(Visitor *v)
 while (!QSLIST_EMPTY(&qov->stack)) {
 e = QSLIST_FIRST(&qov->stack);
 QSLIST_REMOVE_HEAD(&qov->stack, node);
+qobject_decref(e->value);
 g_free(e);
 }
 
-- 
2.7.4

[Qemu-devel] [PATCH] qapi: fix memory leak in bdrv_image_info_specific_dump

[Pino Toscano]

The 'obj' result of the visitor was not properly freed, like done in
other places doing a similar job.
---
 block/qapi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/block/qapi.c b/block/qapi.c
index 6f947e3..50d3090 100644
--- a/block/qapi.c
+++ b/block/qapi.c
@@ -698,6 +698,7 @@ void bdrv_image_info_specific_dump(fprintf_function 
func_fprintf, void *f,
 assert(qobject_type(obj) == QTYPE_QDICT);
 data = qdict_get(qobject_to_qdict(obj), "data");
 dump_qobject(func_fprintf, f, 1, data);
+qobject_decref(obj);
 visit_free(v);
 }
 
-- 
2.7.4

[Qemu-devel] [PATCH v2 0/6] Start a contrib/libvhost-user

[Marc-André Lureau]

Hi

vhost-user & virtio have tricky corners and evolve regularly. There
isn't a reference code that would help you get started either. And the
backends duplicate most of the effort.

Furthermore, due to usage of ancillary data, shared memory, eventfd,
atomics, it is not so simple to implement in other languages than C
either. Having a library doing the low-level parts could eventually
help to reach other languages (this guided some decisions, such as
being able to override message handling)

I found it would help me to experiment with new usages of
libvhost-user (with other devices than network for example) if qemu
would provide such "reference" library. vhost-user-bridge was the most
complete attempt at implementing vhost-user slave in qemu, but it
lacked some abstraction and efficient handling of the virt queues.

I propose to provide such library based on virtio.c implementation and
vhost-user-bridge socket handling. It is not meant to be complete, or
solve all use cases (best efficiency, or multi-threading support are
not a goal for this first implementation). My hope is that at some
point the library would be complete and stable enough that it could
become a standalone project, that could cover most use cases. For now
it makes more sense to propose it in qemu/contrib as an internal
library where API could evolve.

Comments welcome!

v2:
- add documentation
- updated to follow latest virtio queue qemu implementation
- rename add_watch() to set_watch()
- various fixes from Felipe Franciosi

rfc->v1:
- add vu_gpa_to_va()
- fix indirect descriptors handling
- fix notification
- more error handling
- disable debugging

Marc-André Lureau (6):
  tests/vhost-user-bridge: remove false comment
  tests/vhost-user-bridge: remove unnecessary dispatcher_remove
  tests/vhost-user-bridge: indicate peer disconnected
  tests/vhost-user-bridge: do not accept more than one connection
  contrib: add libvhost-user
  tests/vhost-user-bridge: use contrib/libvhost-user

 contrib/libvhost-user/libvhost-user.c | 1499 +
 tests/vhost-user-bridge.c | 1183 +-
 Makefile  |1 +
 Makefile.objs |2 +-
 contrib/libvhost-user/Makefile.objs   |1 +
 tests/Makefile.include|2 +-
 contrib/libvhost-user/libvhost-user.h |  435 ++
 7 files changed, 2167 insertions(+), 956 deletions(-)
 create mode 100644 contrib/libvhost-user/libvhost-user.c
 create mode 100644 contrib/libvhost-user/Makefile.objs
 create mode 100644 contrib/libvhost-user/libvhost-user.h

-- 
2.10.0

[Qemu-devel] CVE-2016-5403 results in a bug

[yue]

hi, all:
    i apply this patch, 
https://git.centos.org/blob/rpms!!qemu-kvm/6078803a0db76660aef491907f795bb23ad33357/SOURCES!kvm-virtio-error-out-if-guest-exceeds-virtqueue-size.patch;jsessionid=124pfc40q9ejezgb0b5qrnv6m#L33
 . 
  but this patch always results in a bug(bug?).  a vm always exits with 
'2016-10-17T07:33:40.393592Z qemu-kvm: Virtqueue size exceeded', if you suspend 
and resume . (please refer to https://wiki.openstack.org/wiki/Kvm-Pause-Suspend 
 to see the definiton of suspend and resume in openstack). this operation is 
very commonly used in openstack. i  am not sure if this patch is elegant .


what is your opinion?


thanks


 


 

[Qemu-devel] is there a way to optimize vhost of virtio-net

[yue]

hi, jasowang:
 according to my test , the vm's network performance is just 20% of 
physical ethernet, the thread of vhost  easily eat up 100% cpu when under 
pressure.
when using multi queue(two queues) the performance goes up by 50%, but it uses 
more threads.
if we can come to a conclusion that vhost is bottomneck?  or do you have any 
idea to improve , first we do not need to care how  violent  the idea   is.




thanks


 


 

[Qemu-devel] [PATCH v2 0/6] Start a contrib/libvhost-user

[Marc-André Lureau]

Hi

vhost-user & virtio have tricky corners and evolve regularly. There
isn't a reference code that would help you get started either. And the
backends duplicate most of the effort.

Furthermore, due to usage of ancillary data, shared memory, eventfd,
atomics, it is not so simple to implement in other languages than C
either. Having a library doing the low-level parts could eventually
help to reach other languages (this guided some decisions, such as
being able to override message handling)

I found it would help me to experiment with new usages of
libvhost-user (with other devices than network for example) if qemu
would provide such "reference" library. vhost-user-bridge was the most
complete attempt at implementing vhost-user slave in qemu, but it
lacked some abstraction and efficient handling of the virt queues.

I propose to provide such library based on virtio.c implementation and
vhost-user-bridge socket handling. It is not meant to be complete, or
solve all use cases (best efficiency, or multi-threading support are
not a goal for this first implementation). My hope is that at some
point the library would be complete and stable enough that it could
become a standalone project, that could cover most use cases. For now
it makes more sense to propose it in qemu/contrib as an internal
library where API could evolve.

Comments welcome!

v2:
- add documentation
- updated to follow latest virtio queue qemu implementation
- rename add_watch() to set_watch()
- various fixes from Felipe Franciosi

rfc->v1:
- add vu_gpa_to_va()
- fix indirect descriptors handling
- fix notification
- more error handling
- disable debugging

Marc-André Lureau (6):
  tests/vhost-user-bridge: remove false comment
  tests/vhost-user-bridge: remove unnecessary dispatcher_remove
  tests/vhost-user-bridge: indicate peer disconnected
  tests/vhost-user-bridge: do not accept more than one connection
  contrib: add libvhost-user
  tests/vhost-user-bridge: use contrib/libvhost-user

 contrib/libvhost-user/libvhost-user.c | 1499 +
 tests/vhost-user-bridge.c | 1183 +-
 Makefile  |1 +
 Makefile.objs |2 +-
 contrib/libvhost-user/Makefile.objs   |1 +
 tests/Makefile.include|2 +-
 contrib/libvhost-user/libvhost-user.h |  435 ++
 7 files changed, 2167 insertions(+), 956 deletions(-)
 create mode 100644 contrib/libvhost-user/libvhost-user.c
 create mode 100644 contrib/libvhost-user/Makefile.objs
 create mode 100644 contrib/libvhost-user/libvhost-user.h

-- 
2.10.0

[Qemu-devel] [PATCH v2 5/6] contrib: add libvhost-user

[Marc-André Lureau]

Add a library to help implementing vhost-user backend (or slave).

Dealing with vhost-user as an application developper isn't so easy: you
have all the trouble with any protocol: validation, unix ancillary data,
shared memory, eventfd, logging, and on top of that you need to deal
with virtio queues, if possible efficiently.

qemu test has a nice vhost-user testing application vhost-user-bridge,
which implements most of vhost-user, and virtio.c which implements
virtqueues manipulation. Based on these two, I tried to make a simple
library, reusable for tests or development of new vhost-user scenarios.

Signed-off-by: Marc-André Lureau 
[Felipe: set used_idx copy on SET_VRING_ADDR and update shadow avail idx
 on SET_VRING_BASE]
Signed-off-by: Felipe Franciosi 
---
 contrib/libvhost-user/libvhost-user.c | 1499 +
 Makefile  |1 +
 Makefile.objs |2 +-
 contrib/libvhost-user/Makefile.objs   |1 +
 contrib/libvhost-user/libvhost-user.h |  435 ++
 5 files changed, 1937 insertions(+), 1 deletion(-)
 create mode 100644 contrib/libvhost-user/libvhost-user.c
 create mode 100644 contrib/libvhost-user/Makefile.objs
 create mode 100644 contrib/libvhost-user/libvhost-user.h

diff --git a/contrib/libvhost-user/libvhost-user.c 
b/contrib/libvhost-user/libvhost-user.c
new file mode 100644
index 000..af4faad
--- /dev/null
+++ b/contrib/libvhost-user/libvhost-user.c
@@ -0,0 +1,1499 @@
+/*
+ * Vhost User library
+ *
+ * Copyright IBM, Corp. 2007
+ * Copyright (c) 2016 Red Hat, Inc.
+ *
+ * Authors:
+ *  Anthony Liguori 
+ *  Marc-André Lureau 
+ *  Victor Kaplansky 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or
+ * later.  See the COPYING file in the top-level directory.
+ */
+
+#include 
+#include 
+#include 
+
+#include "qemu/atomic.h"
+
+#include "libvhost-user.h"
+
+#define VHOST_USER_HDR_SIZE offsetof(VhostUserMsg, payload.u64)
+
+/* The version of the protocol we support */
+#define VHOST_USER_VERSION 1
+#define LIBVHOST_USER_DEBUG 0
+
+#define DPRINT(...) \
+do {\
+if (LIBVHOST_USER_DEBUG) {  \
+fprintf(stderr, __VA_ARGS__);\
+}   \
+} while (0)
+
+static const char *
+vu_request_to_string(int req)
+{
+#define REQ(req) [req] = #req
+static const char *vu_request_str[] = {
+REQ(VHOST_USER_NONE),
+REQ(VHOST_USER_GET_FEATURES),
+REQ(VHOST_USER_SET_FEATURES),
+REQ(VHOST_USER_NONE),
+REQ(VHOST_USER_GET_FEATURES),
+REQ(VHOST_USER_SET_FEATURES),
+REQ(VHOST_USER_SET_OWNER),
+REQ(VHOST_USER_RESET_OWNER),
+REQ(VHOST_USER_SET_MEM_TABLE),
+REQ(VHOST_USER_SET_LOG_BASE),
+REQ(VHOST_USER_SET_LOG_FD),
+REQ(VHOST_USER_SET_VRING_NUM),
+REQ(VHOST_USER_SET_VRING_ADDR),
+REQ(VHOST_USER_SET_VRING_BASE),
+REQ(VHOST_USER_GET_VRING_BASE),
+REQ(VHOST_USER_SET_VRING_KICK),
+REQ(VHOST_USER_SET_VRING_CALL),
+REQ(VHOST_USER_SET_VRING_ERR),
+REQ(VHOST_USER_GET_PROTOCOL_FEATURES),
+REQ(VHOST_USER_SET_PROTOCOL_FEATURES),
+REQ(VHOST_USER_GET_QUEUE_NUM),
+REQ(VHOST_USER_SET_VRING_ENABLE),
+REQ(VHOST_USER_SEND_RARP),
+REQ(VHOST_USER_INPUT_GET_CONFIG),
+REQ(VHOST_USER_MAX),
+};
+#undef REQ
+
+if (req < VHOST_USER_MAX) {
+return vu_request_str[req];
+} else {
+return "unknown";
+}
+}
+
+static void
+vu_panic(VuDev *dev, const char *msg, ...)
+{
+char *buf = NULL;
+va_list ap;
+
+va_start(ap, msg);
+(void)vasprintf(&buf, msg, ap);
+va_end(ap);
+
+dev->broken = true;
+dev->panic(dev, buf);
+free(buf);
+
+/* FIXME: find a way to call virtio_error? */
+}
+
+/* Translate guest physical address to our virtual address.  */
+void *
+vu_gpa_to_va(VuDev *dev, uint64_t guest_addr)
+{
+int i;
+
+/* Find matching memory region.  */
+for (i = 0; i < dev->nregions; i++) {
+VuDevRegion *r = &dev->regions[i];
+
+if ((guest_addr >= r->gpa) && (guest_addr < (r->gpa + r->size))) {
+return (void *)(uintptr_t)
+guest_addr - r->gpa + r->mmap_addr + r->mmap_offset;
+}
+}
+
+return NULL;
+}
+
+/* Translate qemu virtual address to our virtual address.  */
+static void *
+qva_to_va(VuDev *dev, uint64_t qemu_addr)
+{
+int i;
+
+/* Find matching memory region.  */
+for (i = 0; i < dev->nregions; i++) {
+VuDevRegion *r = &dev->regions[i];
+
+if ((qemu_addr >= r->qva) && (qemu_addr < (r->qva + r->size))) {
+return (void *)(uintptr_t)
+qemu_addr - r->qva + r->mmap_addr + r->mmap_offset;
+}
+}
+
+return NULL;
+}
+
+static void
+vmsg_close_fds(VhostUserMsg *vmsg)
+{
+int i;
+
+for (i = 0

[Qemu-devel] [PATCH v2 1/6] tests/vhost-user-bridge: remove false comment

[Marc-André Lureau]

dispatcher_remove() is in use.

Signed-off-by: Marc-André Lureau 
---
 tests/vhost-user-bridge.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/tests/vhost-user-bridge.c b/tests/vhost-user-bridge.c
index 775e031..e91279b 100644
--- a/tests/vhost-user-bridge.c
+++ b/tests/vhost-user-bridge.c
@@ -101,8 +101,6 @@ dispatcher_add(Dispatcher *dispr, int sock, void *ctx, 
CallbackFunc cb)
 return 0;
 }
 
-/* dispatcher_remove() is not currently in use but may be useful
- * in the future. */
 static int
 dispatcher_remove(Dispatcher *dispr, int sock)
 {
-- 
2.10.0

[Qemu-devel] [PATCH v2 3/6] tests/vhost-user-bridge: indicate peer disconnected

[Marc-André Lureau]

Signed-off-by: Marc-André Lureau 
---
 tests/vhost-user-bridge.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tests/vhost-user-bridge.c b/tests/vhost-user-bridge.c
index 19b0e94..97e45d8 100644
--- a/tests/vhost-user-bridge.c
+++ b/tests/vhost-user-bridge.c
@@ -385,7 +385,6 @@ vubr_message_read(int conn_fd, VhostUserMsg *vmsg)
 rc = recvmsg(conn_fd, &msg, 0);
 
 if (rc == 0) {
-vubr_die("recvmsg");
 fprintf(stderr, "Peer disconnected.\n");
 exit(1);
 }
-- 
2.10.0

[Qemu-devel] [PATCH v2 2/6] tests/vhost-user-bridge: remove unnecessary dispatcher_remove

[Marc-André Lureau]

The call fd is not watched

Signed-off-by: Marc-André Lureau 
---
 tests/vhost-user-bridge.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/tests/vhost-user-bridge.c b/tests/vhost-user-bridge.c
index e91279b..19b0e94 100644
--- a/tests/vhost-user-bridge.c
+++ b/tests/vhost-user-bridge.c
@@ -979,7 +979,6 @@ vubr_get_vring_base_exec(VubrDev *dev, VhostUserMsg *vmsg)
 
 if (dev->vq[index].call_fd != -1) {
 close(dev->vq[index].call_fd);
-dispatcher_remove(&dev->dispatcher, dev->vq[index].call_fd);
 dev->vq[index].call_fd = -1;
 }
 if (dev->vq[index].kick_fd != -1) {
@@ -1043,7 +1042,6 @@ vubr_set_vring_call_exec(VubrDev *dev, VhostUserMsg *vmsg)
 
 if (dev->vq[index].call_fd != -1) {
 close(dev->vq[index].call_fd);
-dispatcher_remove(&dev->dispatcher, dev->vq[index].call_fd);
 }
 dev->vq[index].call_fd = vmsg->fds[0];
 DPRINT("Got call_fd: %d for vq: %d\n", vmsg->fds[0], index);
-- 
2.10.0

[Qemu-devel] [PATCH v2 6/6] tests/vhost-user-bridge: use contrib/libvhost-user

[Marc-André Lureau]

Use the libvhost-user library.

This ended up being a rather large patch that cannot be easily splitted,
due to massive code move and API changes.

Signed-off-by: Marc-André Lureau 
---
 tests/vhost-user-bridge.c | 1177 +
 tests/Makefile.include|2 +-
 2 files changed, 229 insertions(+), 950 deletions(-)

diff --git a/tests/vhost-user-bridge.c b/tests/vhost-user-bridge.c
index 5b618f6..8618c20 100644
--- a/tests/vhost-user-bridge.c
+++ b/tests/vhost-user-bridge.c
@@ -30,17 +30,9 @@
 #define _FILE_OFFSET_BITS 64
 
 #include "qemu/osdep.h"
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "qemu/atomic.h"
+#include "qemu/iov.h"
 #include "standard-headers/linux/virtio_net.h"
-#include "standard-headers/linux/virtio_ring.h"
+#include "contrib/libvhost-user/libvhost-user.h"
 
 #define VHOST_USER_BRIDGE_DEBUG 1
 
@@ -64,6 +56,17 @@ typedef struct Dispatcher {
 Event events[FD_SETSIZE];
 } Dispatcher;
 
+typedef struct VubrDev {
+VuDev vudev;
+Dispatcher dispatcher;
+int backend_udp_sock;
+struct sockaddr_in backend_udp_dest;
+int hdrlen;
+int sock;
+int ready;
+int quit;
+} VubrDev;
+
 static void
 vubr_die(const char *s)
 {
@@ -155,1036 +158,313 @@ dispatcher_wait(Dispatcher *dispr, uint32_t timeout)
 return 0;
 }
 
-typedef struct VubrVirtq {
-int call_fd;
-int kick_fd;
-uint32_t size;
-uint16_t last_avail_index;
-uint16_t last_used_index;
-struct vring_desc *desc;
-struct vring_avail *avail;
-struct vring_used *used;
-uint64_t log_guest_addr;
-int enable;
-} VubrVirtq;
-
-/* Based on qemu/hw/virtio/vhost-user.c */
-
-#define VHOST_MEMORY_MAX_NREGIONS8
-#define VHOST_USER_F_PROTOCOL_FEATURES 30
-/* v1.0 compliant. */
-#define VIRTIO_F_VERSION_1 32
-
-#define VHOST_LOG_PAGE 4096
-
-enum VhostUserProtocolFeature {
-VHOST_USER_PROTOCOL_F_MQ = 0,
-VHOST_USER_PROTOCOL_F_LOG_SHMFD = 1,
-VHOST_USER_PROTOCOL_F_RARP = 2,
-
-VHOST_USER_PROTOCOL_F_MAX
-};
-
-#define VHOST_USER_PROTOCOL_FEATURE_MASK ((1 << VHOST_USER_PROTOCOL_F_MAX) - 1)
-
-typedef enum VhostUserRequest {
-VHOST_USER_NONE = 0,
-VHOST_USER_GET_FEATURES = 1,
-VHOST_USER_SET_FEATURES = 2,
-VHOST_USER_SET_OWNER = 3,
-VHOST_USER_RESET_OWNER = 4,
-VHOST_USER_SET_MEM_TABLE = 5,
-VHOST_USER_SET_LOG_BASE = 6,
-VHOST_USER_SET_LOG_FD = 7,
-VHOST_USER_SET_VRING_NUM = 8,
-VHOST_USER_SET_VRING_ADDR = 9,
-VHOST_USER_SET_VRING_BASE = 10,
-VHOST_USER_GET_VRING_BASE = 11,
-VHOST_USER_SET_VRING_KICK = 12,
-VHOST_USER_SET_VRING_CALL = 13,
-VHOST_USER_SET_VRING_ERR = 14,
-VHOST_USER_GET_PROTOCOL_FEATURES = 15,
-VHOST_USER_SET_PROTOCOL_FEATURES = 16,
-VHOST_USER_GET_QUEUE_NUM = 17,
-VHOST_USER_SET_VRING_ENABLE = 18,
-VHOST_USER_SEND_RARP = 19,
-VHOST_USER_MAX
-} VhostUserRequest;
-
-typedef struct VhostUserMemoryRegion {
-uint64_t guest_phys_addr;
-uint64_t memory_size;
-uint64_t userspace_addr;
-uint64_t mmap_offset;
-} VhostUserMemoryRegion;
-
-typedef struct VhostUserMemory {
-uint32_t nregions;
-uint32_t padding;
-VhostUserMemoryRegion regions[VHOST_MEMORY_MAX_NREGIONS];
-} VhostUserMemory;
-
-typedef struct VhostUserLog {
-uint64_t mmap_size;
-uint64_t mmap_offset;
-} VhostUserLog;
-
-typedef struct VhostUserMsg {
-VhostUserRequest request;
-
-#define VHOST_USER_VERSION_MASK (0x3)
-#define VHOST_USER_REPLY_MASK   (0x1<<2)
-uint32_t flags;
-uint32_t size; /* the following payload size */
-union {
-#define VHOST_USER_VRING_IDX_MASK   (0xff)
-#define VHOST_USER_VRING_NOFD_MASK  (0x1<<8)
-uint64_t u64;
-struct vhost_vring_state state;
-struct vhost_vring_addr addr;
-VhostUserMemory memory;
-VhostUserLog log;
-} payload;
-int fds[VHOST_MEMORY_MAX_NREGIONS];
-int fd_num;
-} QEMU_PACKED VhostUserMsg;
-
-#define VHOST_USER_HDR_SIZE offsetof(VhostUserMsg, payload.u64)
-
-/* The version of the protocol we support */
-#define VHOST_USER_VERSION(0x1)
-
-#define MAX_NR_VIRTQUEUE (8)
-
-typedef struct VubrDevRegion {
-/* Guest Physical address. */
-uint64_t gpa;
-/* Memory region size. */
-uint64_t size;
-/* QEMU virtual address (userspace). */
-uint64_t qva;
-/* Starting offset in our mmaped space. */
-uint64_t mmap_offset;
-/* Start address of mmaped space. */
-uint64_t mmap_addr;
-} VubrDevRegion;
-
-typedef struct VubrDev {
-int sock;
-Dispatcher dispatcher;
-uint32_t nregions;
-VubrDevRegion regions[VHOST_MEMORY_MAX_NREGIONS];
-VubrVirtq vq[MAX_NR_VIRTQUEUE];
-int log_call_fd;
-uint64_t log_size;
-uint8_t *log_table;
-int backend_udp_sock;
-struct sockaddr_in backend_udp_dest;
-int ready;
-uint64_t features;
-int hdrlen;
-} VubrDev;
-
-static const char *vubr_request_str[] = {
-[VHOST_USER_NO

[Qemu-devel] [PATCH v2 4/6] tests/vhost-user-bridge: do not accept more than one connection

[Marc-André Lureau]

Signed-off-by: Marc-André Lureau 
---
 tests/vhost-user-bridge.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/vhost-user-bridge.c b/tests/vhost-user-bridge.c
index 97e45d8..5b618f6 100644
--- a/tests/vhost-user-bridge.c
+++ b/tests/vhost-user-bridge.c
@@ -1200,6 +1200,7 @@ vubr_accept_cb(int sock, void *ctx)
 }
 DPRINT("Got connection from remote peer on sock %d\n", conn_fd);
 dispatcher_add(&dev->dispatcher, conn_fd, ctx, vubr_receive_cb);
+dispatcher_remove(&dev->dispatcher, sock);
 }
 
 static VubrDev *
-- 
2.10.0

Re: [Qemu-devel] [PATCH v14 13/21] qdict: allow qdict_crumple to accept compound types as values

[Kevin Wolf]

Am 17.10.2016 um 16:50 hat Markus Armbruster geschrieben:
> Kevin Wolf  writes:
> 
> > Am 13.10.2016 um 14:35 hat Markus Armbruster geschrieben:
> >> Cc: Kevin for discussion of QemuOpts dotted key convention
> >> 
> >> "Daniel P. Berrange"  writes:
> >> 
> >> > Currently qdict_crumple requires a totally flat QDict as its
> >> > input. i.e. all values in the QDict must be scalar types.
> >> >
> >> > In order to have backwards compatibility with the OptsVisitor,
> >> > qemu_opt_to_qdict() has a new mode where it may return a QList
> >> > for values in the QDict, if there was a repeated key. We thus
> >> > need to allow compound types to appear as values in the input
> >> > dict given to qdict_crumple().
> >> >
> >> > To avoid confusion, we sanity check that the user has not mixed
> >> > the old and new syntax at the same time. e.g. these are allowed
> >> >
> >> >foo=hello,foo=world,foo=wibble
> >> >foo.0=hello,foo.1=world,foo.2=wibble
> >> >
> >> > but this is forbidden
> >> >
> >> >foo=hello,foo=world,foo.2=wibble
> >> 
> >> I understand the need for foo.bar=val.  It makes it possible to specify
> >> nested dictionaries with QemuOpts.
> >> 
> >> The case for foo.0=val is less clear.  QemuOpts already supports lists,
> >> by repeating keys.  Why do we need a second, wordier way to specify
> >> them?
> >
> > Probably primarily because someone didn't realise this when introducing
> > the dotted syntax.
> 
> Can't even blame "someone" for that; it's an obscure, underdocumented
> feature of an interface that's collapsing under its load of obscure,
> underdocumented features.
> 
> On the other hand, that's not exactly a state that allows for *more*
> obscure features.

I don't really think we're introducing more obscure features here, but
rather trying to implement a single, and rather straightforward, way as
the standard.

Dotted syntax for hierarchy has actually plenty of precedence in qemu if
you look a bit closer (the block layer, -global, -device foo,help, even
the bus names you mentioned below are really just flattened lists), so
we're only making things more consistent.

> >Also because flat QDicts can't represent this.
> 
> Explain?

Repeated options are parsed into QLists. If you keep it at that without
flattening you have at least a QDict that contains a QList that contains
simple types. This is not flat any more.

Of course, you could argue that flat QDicts are the wrong data structure
in the first place and instead of flatting everything we should have
done the equivalent of qdict_crumple from the beginning, but they were
the natural extension of what was already there and happened to work
good enough, so this is what we're currently using.

> > But even if I realised that QemuOpts support this syntax, I think we
> > would still have to use the dotted syntax because it's explicit about
> > the index and we need that because the list can contains dicts.
> >
> > Compare this:
> >
> > driver=quorum,
> > child.0.driver=file,child.0.filename=disk1.img,
> > child.1.driver=host_device,child.1.filename=/dev/sdb,
> > child.2.driver=nbd,child.2.host=localhost
> >
> > And this:
> >
> > driver=quorum,
> > child.driver=file,child.filename=disk1.img,
> > child.driver=host_device,child.filename=/dev/sdb,
> > child.driver=nbd,child.host=localhost
> 
> Aside: both are about equally illegible, to be honest.

Not sure about equally, but let's agree on "both are illegible".

> > For starters, can we really trust the order in QemuOpts so that the
> > right driver and filename are associated with each other?
> 
> The order is trustworthy, but...
> 
> > We would also have code to associate the third child.driver with the
> > first child.host (because file and host_device don't have a host
> > property). And this isn't even touching optional arguments yet. Would
> > you really want to implement or review this?
> 
> ... you're right, doing lists by repeating keys breaks down when
> combined with the dotted key convention's use of repetition to do
> structured values.
> 
> Permit me to digress.
> 
> QemuOpts wasn't designed for list-values keys.  Doing lists by
> repetition was clever.
> 
> QemuOpts wasn't designed for structured values.  Doing structured values
> by a dotted key convention plus repetition was clever.
> 
> And there's the problem: too much cleverness, not enough "this is being
> pushed way beyond its design limits, time to replace it".
> 
> For me, a replacement should do structured values by providing suitable
> *value* syntax instead of hacking it into the keys:
> 
> { "driver": "quorum",
>   "child": [ { "driver": "file", "filename": "disk1.img" },
>  { "driver": "host_device", "filename=/dev/sdb" },
>  { "driver": "nbd", "host": "localhost" } ] }
> 
> Note how the structure is obvious.  It isn't with dotted keys, not even
> if you order them sensibly (which users inevitably won't).
> 
> Also not that th

Re: [Qemu-devel] [PULL 00/21] x86 queue, 2016-10-17

[Peter Maydell]

On 17 October 2016 at 18:51, Eduardo Habkost  wrote:
> The following changes since commit 0975b8b823a888d474fa33821dfe84e6904db197:
>
>   Merge remote-tracking branch 'remotes/gkurz/tags/for-upstream' into staging 
> (2016-10-17 16:17:51 +0100)
>
> are available in the git repository at:
>
>   git://github.com/ehabkost/qemu.git tags/x86-pull-request
>
> for you to fetch changes up to 46c032f3afcc05a0123914609f1003906ba63fda:
>
>   target-i386: Don't use cpu->migratable when filtering features (2016-10-17 
> 15:50:57 -0200)
>
> 
> x86 queue, 2016-10-17
>
> 
>

Applied, thanks.

-- PMM

Re: [Qemu-devel] [PATCH v4 0/3] iotests: Fix test 162

[Kevin Wolf]

Am 17.10.2016 um 19:07 hat Max Reitz geschrieben:
> On 28.09.2016 22:46, Max Reitz wrote:
> > 162 is potentially racy and makes some invalid assumptions about what
> > should happen when connecting to a non-existing domain name. This series
> > fixes both issues.
> > 
> > 
> > v4:
> > - Added documentation for the new --fork option [Kevin]
> > 
> > 
> > git-backport-diff against v3:
> > 
> > Key:
> > [] : patches are identical
> > [] : number of functional differences between upstream/downstream
> > patch
> > [down] : patch is downstream-only
> > The flags [FC] indicate (F)unctional and (C)ontextual differences,
> > respectively
> > 
> > 001/3:[0004] [FC] 'qemu-nbd: Add --fork option'
> > 002/3:[] [--] 'iotests: Remove raciness from 162'
> > 003/3:[] [--] 'iotests: Do not rely on unavailable domains in 162'
> > 
> > 
> > Max Reitz (3):
> >   qemu-nbd: Add --fork option
> >   iotests: Remove raciness from 162
> >   iotests: Do not rely on unavailable domains in 162
> > 
> >  qemu-nbd.c | 17 -
> >  qemu-nbd.texi  |  2 ++
> >  tests/qemu-iotests/162 | 22 --
> >  tests/qemu-iotests/162.out |  2 +-
> >  4 files changed, 35 insertions(+), 8 deletions(-)
> 
> Ping

I expected that Sascha would review this as he had comments on earlier
versions?

Kevin


pgpexffGj2zKW.pgp
Description: PGP signature

Re: [Qemu-devel] CVE-2016-5403 results in a bug

[Stefan Hajnoczi]

On Tue, Oct 18, 2016 at 10:24 AM, yue  wrote:
> i apply this patch, 
> https://git.centos.org/blob/rpms!!qemu-kvm/6078803a0db76660aef491907f795bb23ad33357/SOURCES!kvm-virtio-error-out-if-guest-exceeds-virtqueue-size.patch;jsessionid=124pfc40q9ejezgb0b5qrnv6m#L33
>  .
>   but this patch always results in a bug(bug?).  a vm always exits with 
> '2016-10-17T07:33:40.393592Z qemu-kvm: Virtqueue size exceeded', if you 
> suspend and resume . (please refer to 
> https://wiki.openstack.org/wiki/Kvm-Pause-Suspend  to see the definiton of 
> suspend and resume in openstack). this operation is very commonly used in 
> openstack. i  am not sure if this patch is elegant .

Try these patches:
bccdef6b1a204db0f41ffb6e24ce373e4d7890d4..58a83c61496eeb0d31571a07a51bc19,
4b7f91ed0270a371e1933efa21ba600b6da23ab9

Re: [Qemu-devel] [PATCH] qapi: fix memory leak in bdrv_image_info_specific_dump

[Kevin Wolf]

Am 18.10.2016 um 11:18 hat Pino Toscano geschrieben:
> The 'obj' result of the visitor was not properly freed, like done in
> other places doing a similar job.
> ---
>  block/qapi.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/block/qapi.c b/block/qapi.c
> index 6f947e3..50d3090 100644
> --- a/block/qapi.c
> +++ b/block/qapi.c
> @@ -698,6 +698,7 @@ void bdrv_image_info_specific_dump(fprintf_function 
> func_fprintf, void *f,
>  assert(qobject_type(obj) == QTYPE_QDICT);
>  data = qdict_get(qobject_to_qdict(obj), "data");
>  dump_qobject(func_fprintf, f, 1, data);
> +qobject_decref(obj);
>  visit_free(v);
>  }

The change looks good, but without a Signed-off-by line I can't accept
the patch: http://wiki.qemu.org/Contribute/SubmitAPatch

Kevin

[Qemu-devel] [PATCH] char: cadence: check divider against baud rate

[P J P]

From: Prasad J Pandit 

The Cadence UART device emulator calculates speed by dividing the
baud rate by a divider. If this divider was to be zero or if baud
rate was to be lesser than the divider, it could lead to a divide
by zero error. Add check to avoid it.

Reported-by: Huawei PSIRT 
Signed-off-by: Prasad J Pandit 
---
 hw/char/cadence_uart.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/char/cadence_uart.c b/hw/char/cadence_uart.c
index e3bc52f..b18dd7f 100644
--- a/hw/char/cadence_uart.c
+++ b/hw/char/cadence_uart.c
@@ -170,6 +170,10 @@ static void uart_parameters_setup(CadenceUARTState *s)
 baud_rate = (s->r[R_MR] & UART_MR_CLKS) ?
 UART_INPUT_CLK / 8 : UART_INPUT_CLK;
 
+if (!s->r[R_BRGR] || !(s->r[R_BDIV] + 1)
+|| baud_rate < (s->r[R_BRGR] * (s->r[R_BDIV] + 1))) {
+return;
+}
 ssp.speed = baud_rate / (s->r[R_BRGR] * (s->r[R_BDIV] + 1));
 packet_size = 1;
 
-- 
2.7.4

Re: [Qemu-devel] [Qemu-arm] [PATCH] char: cadence: check divider against baud rate

[Peter Maydell]

On 18 October 2016 at 10:47, P J P  wrote:
> From: Prasad J Pandit 
>
> The Cadence UART device emulator calculates speed by dividing the
> baud rate by a divider. If this divider was to be zero or if baud
> rate was to be lesser than the divider, it could lead to a divide
> by zero error. Add check to avoid it.
>
> Reported-by: Huawei PSIRT 
> Signed-off-by: Prasad J Pandit 
> ---
>  hw/char/cadence_uart.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/hw/char/cadence_uart.c b/hw/char/cadence_uart.c
> index e3bc52f..b18dd7f 100644
> --- a/hw/char/cadence_uart.c
> +++ b/hw/char/cadence_uart.c
> @@ -170,6 +170,10 @@ static void uart_parameters_setup(CadenceUARTState *s)
>  baud_rate = (s->r[R_MR] & UART_MR_CLKS) ?
>  UART_INPUT_CLK / 8 : UART_INPUT_CLK;
>
> +if (!s->r[R_BRGR] || !(s->r[R_BDIV] + 1)
> +|| baud_rate < (s->r[R_BRGR] * (s->r[R_BDIV] + 1))) {
> +return;
> +}
>  ssp.speed = baud_rate / (s->r[R_BRGR] * (s->r[R_BDIV] + 1));
>  packet_size = 1;

It seems really unlikely that early return here is the correct thing, since
it will result in our not correctly setting a bunch of the other
stuff done later in this function that's unrelated to baud rate.
What does the datasheet for this UART specify for this situation?

thanks
-- PMM

Re: [Qemu-devel] qemu master tests/vmstate prints "Failed to load simple/primitive:b_1" etc

[Dr. David Alan Gilbert]

* Markus Armbruster (arm...@redhat.com) wrote:
> Paolo Bonzini  writes:
> 
> > On 17/10/2016 21:15, Dr. David Alan Gilbert wrote:
> >> * Peter Maydell (peter.mayd...@linaro.org) wrote:
> >>> On 17 October 2016 at 19:51, Dr. David Alan Gilbert  
> >>> wrote:
>  * Peter Maydell (peter.mayd...@linaro.org) wrote:
> > I've just noticed that qemu master running 'make check' prints
> >   GTESTER tests/test-vmstate
> > Failed to load simple/primitive:b_1
> > Failed to load simple/primitive:i64_2
> > Failed to load simple/primitive:i32_1
> > Failed to load simple/primitive:i32_1
> >
> > but the test doesn't fail.
> >
> > Can we either (a) silence this output if it's spurious or (b) have
> > it cause the test to fail if it's real (and fix the cause of the
> > failure ;-)), please?
> 
>  The test (has always) tried loading truncated versions of the migration
>  stream and made sure that it receives an error from vmstate_load_state.
> 
>  However I just added an error so we can see which field fails to load
>  in a migration where we just used to get a 'migration has failed with 
>  -22'
> 
>  Is there a way to silence error_report's that's already in use in tests?
> >>>
> >>> We have some nasty hacks (like check for 'qtest_enabled()' before
> >>> calling error_report()) but we don't have anything in the
> >>> tree today that's a more coherent approach to the "test
> >>> deliberately provoked this error" problem.
> 
> I guess the "more coherent approach" would be some way to run a piece of
> code with error reporting suppressed.
> 
> For unit tests, a need to supress error reporting indicates the code
> under test should perhaps error_setg() instead of error_report().
> Unlikely to completely eliminate the need to suppress error reporting,
> though.
> 
> >> Errors go to either the current monitor (if it's non-qmp) or
> >> stderr; so could we create a dummy monitor to eat the errors
> >> and make it current around that part?
> >
> > I guess you could reimplement the functions of stubs/mon-printf.c and
> > stubs/mon-is-qmp.c.
> 
> qemu-error.c does all its output via error_vprintf():
> 
> void error_vprintf(const char *fmt, va_list ap)
> {
> if (cur_mon && !monitor_cur_is_qmp()) {
> monitor_vprintf(cur_mon, fmt, ap);
> } else {
> vfprintf(stderr, fmt, ap);
> }
> }
> 
> Thus, custom monitor_cur_is_qmp() and monitor_vprintf() let you capture
> its output.
> 
> Using (or rather abusing) this to suppress error reporting for an entire
> program would be easy enough.  But I doubt it's a convenient way to
> suppress more narrowly.
> 
> I figure a monitor connected to a "null" chardev would work better
> there.  If we need that anyway, using it for the "entire program" case
> as well is probably easiest.

I've not quite figured it out but we're linked against the stubs/ monitor
code rather than the real monitor code; and the stubs monitor_vprintf discards
and the stubs monitor_cur_is_qmp() always returns false, so to silence things
we just have to make cur_mon non-NULL.
Unfortunately cur_mon is of type Monitor * and Monitor isn't defined publicly,
so we can't know it's size.  The following evil hack does silence things
for anyone desperate, but I do need to find a neater way; perhaps the right
thing is just to link against monitor and create a dummy "null" chardev as you
say.

Dave

diff --git a/tests/test-vmstate.c b/tests/test-vmstate.c
index d8da26f..c39d3dc 100644
--- a/tests/test-vmstate.c
+++ b/tests/test-vmstate.c
@@ -27,6 +27,7 @@
 #include "qemu-common.h"
 #include "migration/migration.h"
 #include "migration/vmstate.h"
+#include "monitor/monitor.h"
 #include "qemu/coroutine.h"
 #include "io/channel-file.h"
 
@@ -134,6 +135,11 @@ static int load_vmstate(const VMStateDescription *desc,
 {
 /* We test with zero size */
 obj_copy(obj_clone, obj);
+/* NASTY HACK! Silence error_report - relies on the fact we're using the
+ * stubs code rather than the real monitor.  As long as cur_mon is
+ * non-null error_report won't print.
+ */
+cur_mon = g_malloc(1);
 FAILURE(load_vmstate_one(desc, obj, version, wire, 0));
 
 /* Stream ends with QEMU_EOF, so we need at least 3 bytes to be
@@ -154,6 +160,9 @@ static int load_vmstate(const VMStateDescription *desc,
 FAILURE(load_vmstate_one(desc, obj, version, wire + (size/2), size/2));
 
 }
+/* Unsilence error-report - we shouldn't get any errors here */
+g_free(cur_mon);
+cur_mon = NULL;
 obj_copy(obj, obj_clone);
 return load_vmstate_one(desc, obj, version, wire, size);
 }

--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [Qemu-devel] chardev's and fd's in monitors

[Daniel P. Berrange]

On Wed, Oct 12, 2016 at 08:15:02PM +0100, Dr. David Alan Gilbert wrote:
> Hi,
>   I had a look at a couple of readline like libraries;
> editline and linenoise.  A difficulty with using them is that
> they both want fd's or FILE*'s; editline takes either but
> from a brief look I think it's expecting to extract the fd.
> That makes them tricky to integrate into qemu, where
> the chardev's hide a whole bunch of non-fd things; in particular
> tls, mux, ringbuffers etc.
> 
> If we could get away with just a FILE* then we could use fopencookie,
> but that's GNU only.
> 
> Is there any sane way of shepherding all chardev's into having an
> fd?

The entire chardev abstraction model exists precisely because we cannot
make all chardevs look like a single fd. Even those which are fd based
may have separate FDs for input and output.

IMHO the only viable approach would be to enhance linenoise/editline to
not assume use of fd* or FILE * abstractions.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

Re: [Qemu-devel] chardev's and fd's in monitors

[Daniel P. Berrange]

On Wed, Oct 12, 2016 at 08:15:02PM +0100, Dr. David Alan Gilbert wrote:
> Hi,
>   I had a look at a couple of readline like libraries;
> editline and linenoise.  A difficulty with using them is that
> they both want fd's or FILE*'s; editline takes either but
> from a brief look I think it's expecting to extract the fd.
> That makes them tricky to integrate into qemu, where
> the chardev's hide a whole bunch of non-fd things; in particular
> tls, mux, ringbuffers etc.
> 
> If we could get away with just a FILE* then we could use fopencookie,
> but that's GNU only.
> 
> Is there any sane way of shepherding all chardev's into having an
> fd?
> 
> Once you had those then you could also use them in a separate thread.

BTW, what is the actual thread issue you are facing ? Chardevs at least
ought to be usable from a separate thread, as long as each distinct
chardev object instance was only used from one thread at a time ?

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

Re: [Qemu-devel] [virtio-dev] RE: [PATCH v7 09/12] virtio-crypto: add data queue processing handler

[Stefan Hajnoczi]

On Mon, Oct 17, 2016 at 06:29:42AM +, Gonglei (Arei) wrote:
> 
> > -Original Message-
> > From: Stefan Hajnoczi [mailto:stefa...@gmail.com]
> > Sent: Sunday, October 16, 2016 9:23 PM
> > Subject: Re: [Qemu-devel] [PATCH v7 09/12] virtio-crypto: add data queue
> > processing handler
> > 
> > On Thu, Oct 13, 2016 at 03:12:03PM +0800, Gonglei wrote:
> > > Introduces VirtIOCryptoReq structure to store
> > > crypto request so that we can support sync and async
> > > crypto operation in the future.
> > 
> > What do you mean by "sync and async" operations?
> > 
> Synchronous and asynchronous.

I understand the words but:

1. The virtio interface is always asynchronous because request
   submission and completion on the virtqueue are separate steps (kick
   and irq).  The guest always thinks the operation is asynchronous.

2. If you implement operations synchronously inside QEMU then monitor
   and other QEMU threads could be blocked.  Also you will not be able
   to take advantage of parallel requests to the hardware crypto
   accelerator!

So I think it makes sense to implement everything asynchronously.


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 15/18] block: only call aio_poll on the current thread's AioContext

[Stefan Hajnoczi]

On Mon, Oct 17, 2016 at 10:04:59AM +0200, Paolo Bonzini wrote:
> 
> 
> On 16/10/2016 18:40, Stefan Hajnoczi wrote:
> > >  void bdrv_wakeup(BlockDriverState *bs)
> > >  {
> > > +if (bs->wakeup) {
> > > +aio_bh_schedule_oneshot(qemu_get_aio_context(), dummy_bh_cb, 
> > > NULL);
> > > +}
> > >  }
> > 
> > Why use a dummy BH instead of aio_notify()?
> 
> Originally I used aio_bh_schedule_oneshot() because aio_notify() is not
> enough for aio_poll() to return true.  It's also true that I am not
> using anymore the result of aio_poll, though.
> 
> Since this is not a fast path and it's not very much stressed by
> qemu-iotests, I think it's better if we can move towards making
> aio_notify() more or less an internal detail.  If you prefer
> aio_notify(), however, I can look into that as well.

I was just wondering if there is a reason that I missed.

Stefan


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH v2 3/4] sockets: add AF_VSOCK support

[Stefan Hajnoczi]

On Mon, Oct 17, 2016 at 09:25:46AM -0500, Eric Blake wrote:
> On 10/16/2016 08:35 AM, Stefan Hajnoczi wrote:
> 
> >>> +
> >>> +if (sscanf(str, "%32[^:]:%32[^,]%n", cid, port, &n) != 2) {
> >>
> >> This says stop at the first comma after the colon...
> >>
> >>> +error_setg(errp, "error parsing address '%s'", str);
> >>> +return NULL;
> >>> +}
> >>> +if (str[n] != '\0') {
> >>> +error_setg(errp, "trailing characters in address '%s'", str);
> >>
> >> ...but this rejects a trailing comma.  Is a trailing comma possible base
> >> on how QemuOpts work? If so, do you need to handle it here?
> > 
> > Actually I just wanted to grab characters up until the end of string.
> > It wasn't clear from the sscanf(3) man page what the best way to do that
> > was, so I kept the comma which is also used in tcp addresses (because
> > they support additional comma-separated options).
> 
> %32s instead of %32[^,] should grab up to all 32 remaining characters in
> the string; your %n trick then ensures there is no garbage.  I guess
> it's still a question of whether we want to always treat a comma as
> trailing garbage.

No comma options are currently accepted.  Treating comma as garbage
seems okay.

Mike: Please change %32[^,] to %32s when merging.  Thanks!

Stefan


signature.asc
Description: PGP signature

[Qemu-devel] [PATCH v3 1/4] fdc: Add a floppy qbus

[Kevin Wolf]

This adds a qbus to the floppy controller that should contain the floppy
drives eventually. At the moment it just exists and is empty.

Signed-off-by: Kevin Wolf 
Reviewed-by: John Snow 
---
 hw/block/fdc.c | 40 +++-
 1 file changed, 35 insertions(+), 5 deletions(-)

diff --git a/hw/block/fdc.c b/hw/block/fdc.c
index b79873a..a3afb62 100644
--- a/hw/block/fdc.c
+++ b/hw/block/fdc.c
@@ -52,6 +52,33 @@
 }   \
 } while (0)
 
+
+//
+/* qdev floppy bus  */
+
+#define TYPE_FLOPPY_BUS "Floppy"
+#define FLOPPY_BUS(obj) OBJECT_CHECK(FloppyBus, (obj), TYPE_FLOPPY_BUS)
+
+typedef struct FDCtrl FDCtrl;
+
+typedef struct FloppyBus {
+BusState bus;
+FDCtrl *fdc;
+} FloppyBus;
+
+static const TypeInfo floppy_bus_info = {
+.name = TYPE_FLOPPY_BUS,
+.parent = TYPE_BUS,
+.instance_size = sizeof(FloppyBus),
+};
+
+static void floppy_bus_create(FDCtrl *fdc, FloppyBus *bus, DeviceState *dev)
+{
+qbus_create_inplace(bus, sizeof(FloppyBus), TYPE_FLOPPY_BUS, dev, NULL);
+bus->fdc = fdc;
+}
+
+
 //
 /* Floppy drive emulation   */
 
@@ -148,8 +175,6 @@ static FDriveSize drive_size(FloppyDriveType drive)
 #define FD_SECTOR_SC   2   /* Sector size code */
 #define FD_RESET_SENSEI_COUNT  4   /* Number of sense interrupts on RESET */
 
-typedef struct FDCtrl FDCtrl;
-
 /* Floppy disk drive emulation */
 typedef enum FDiskFlags {
 FDISK_DBL_SIDES  = 0x01,
@@ -684,6 +709,7 @@ struct FDCtrl {
 /* Power down config (also with status regB access mode */
 uint8_t pwrd;
 /* Floppy drives */
+FloppyBus bus;
 uint8_t num_floppies;
 FDrive drives[MAX_FD];
 int reset_sensei;
@@ -2442,7 +2468,8 @@ void sun4m_fdctrl_init(qemu_irq irq, hwaddr io_base,
 *fdc_tc = qdev_get_gpio_in(dev, 0);
 }
 
-static void fdctrl_realize_common(FDCtrl *fdctrl, Error **errp)
+static void fdctrl_realize_common(DeviceState *dev, FDCtrl *fdctrl,
+  Error **errp)
 {
 int i, j;
 static int command_tables_inited = 0;
@@ -2480,6 +2507,8 @@ static void fdctrl_realize_common(FDCtrl *fdctrl, Error 
**errp)
 k->register_channel(fdctrl->dma, fdctrl->dma_chann,
 &fdctrl_transfer_handler, fdctrl);
 }
+
+floppy_bus_create(fdctrl, &fdctrl->bus, dev);
 fdctrl_connect_drives(fdctrl, errp);
 }
 
@@ -2508,7 +2537,7 @@ static void isabus_fdc_realize(DeviceState *dev, Error 
**errp)
 }
 
 qdev_set_legacy_instance_id(dev, isa->iobase, 2);
-fdctrl_realize_common(fdctrl, &err);
+fdctrl_realize_common(dev, fdctrl, &err);
 if (err != NULL) {
 error_propagate(errp, err);
 return;
@@ -2559,7 +2588,7 @@ static void sysbus_fdc_common_realize(DeviceState *dev, 
Error **errp)
 FDCtrlSysBus *sys = SYSBUS_FDC(dev);
 FDCtrl *fdctrl = &sys->state;
 
-fdctrl_realize_common(fdctrl, errp);
+fdctrl_realize_common(dev, fdctrl, errp);
 }
 
 FloppyDriveType isa_fdc_get_drive_type(ISADevice *fdc, int i)
@@ -2744,6 +2773,7 @@ static void fdc_register_types(void)
 type_register_static(&sysbus_fdc_type_info);
 type_register_static(&sysbus_fdc_info);
 type_register_static(&sun4m_fdc_info);
+type_register_static(&floppy_bus_info);
 }
 
 type_init(fdc_register_types)
-- 
1.8.3.1

[Qemu-devel] [PATCH v3 2/4] fdc: Add a floppy drive qdev

[Kevin Wolf]

Floppy controllers automatically create two floppy drive devices in qdev
now. (They always created two drives, but managed them only internally.)

Signed-off-by: Kevin Wolf 
Reviewed-by: John Snow 
---
 hw/block/fdc.c | 151 +
 1 file changed, 120 insertions(+), 31 deletions(-)

diff --git a/hw/block/fdc.c b/hw/block/fdc.c
index a3afb62..5aa8e52 100644
--- a/hw/block/fdc.c
+++ b/hw/block/fdc.c
@@ -60,6 +60,8 @@
 #define FLOPPY_BUS(obj) OBJECT_CHECK(FloppyBus, (obj), TYPE_FLOPPY_BUS)
 
 typedef struct FDCtrl FDCtrl;
+typedef struct FDrive FDrive;
+static FDrive *get_drv(FDCtrl *fdctrl, int unit);
 
 typedef struct FloppyBus {
 BusState bus;
@@ -180,7 +182,7 @@ typedef enum FDiskFlags {
 FDISK_DBL_SIDES  = 0x01,
 } FDiskFlags;
 
-typedef struct FDrive {
+struct FDrive {
 FDCtrl *fdctrl;
 BlockBackend *blk;
 /* Drive status */
@@ -201,7 +203,7 @@ typedef struct FDrive {
 uint8_t media_rate;   /* Data rate of medium*/
 
 bool media_validated; /* Have we validated the media? */
-} FDrive;
+};
 
 
 static FloppyDriveType get_fallback_drive_type(FDrive *drv);
@@ -466,6 +468,100 @@ static void fd_revalidate(FDrive *drv)
 }
 }
 
+static void fd_change_cb(void *opaque, bool load)
+{
+FDrive *drive = opaque;
+
+drive->media_changed = 1;
+drive->media_validated = false;
+fd_revalidate(drive);
+}
+
+static const BlockDevOps fd_block_ops = {
+.change_media_cb = fd_change_cb,
+};
+
+
+#define TYPE_FLOPPY_DRIVE "floppy"
+#define FLOPPY_DRIVE(obj) \
+ OBJECT_CHECK(FloppyDrive, (obj), TYPE_FLOPPY_DRIVE)
+
+typedef struct FloppyDrive {
+DeviceState qdev;
+uint32_tunit;
+} FloppyDrive;
+
+static Property floppy_drive_properties[] = {
+DEFINE_PROP_UINT32("unit", FloppyDrive, unit, -1),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static int floppy_drive_init(DeviceState *qdev)
+{
+FloppyDrive *dev = FLOPPY_DRIVE(qdev);
+FloppyBus *bus = DO_UPCAST(FloppyBus, bus, dev->qdev.parent_bus);
+FDrive *drive;
+
+if (dev->unit == -1) {
+for (dev->unit = 0; dev->unit < MAX_FD; dev->unit++) {
+drive = get_drv(bus->fdc, dev->unit);
+if (!drive->blk) {
+break;
+}
+}
+}
+
+if (dev->unit >= MAX_FD) {
+error_report("Can't create floppy unit %d, bus supports only %d units",
+ dev->unit, MAX_FD);
+return -1;
+}
+
+/* TODO Check whether unit is in use */
+
+drive = get_drv(bus->fdc, dev->unit);
+
+if (drive->blk) {
+if (blk_get_on_error(drive->blk, 0) != BLOCKDEV_ON_ERROR_ENOSPC) {
+error_report("fdc doesn't support drive option werror");
+return -1;
+}
+if (blk_get_on_error(drive->blk, 1) != BLOCKDEV_ON_ERROR_REPORT) {
+error_report("fdc doesn't support drive option rerror");
+return -1;
+}
+} else {
+/* Anonymous BlockBackend for an empty drive */
+drive->blk = blk_new();
+}
+
+fd_init(drive);
+if (drive->blk) {
+blk_set_dev_ops(drive->blk, &fd_block_ops, drive);
+pick_drive_type(drive);
+}
+fd_revalidate(drive);
+
+return 0;
+}
+
+static void floppy_drive_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *k = DEVICE_CLASS(klass);
+k->init = floppy_drive_init;
+set_bit(DEVICE_CATEGORY_STORAGE, k->categories);
+k->bus_type = TYPE_FLOPPY_BUS;
+k->props = floppy_drive_properties;
+k->desc = "virtual floppy drive";
+}
+
+static const TypeInfo floppy_drive_info = {
+.name = TYPE_FLOPPY_DRIVE,
+.parent = TYPE_DEVICE,
+.instance_size = sizeof(FloppyDrive),
+.class_init = floppy_drive_class_init,
+};
+
 //
 /* Intel 82078 floppy disk controller emulation  */
 
@@ -1185,9 +1281,9 @@ static inline FDrive *drv3(FDCtrl *fdctrl)
 }
 #endif
 
-static FDrive *get_cur_drv(FDCtrl *fdctrl)
+static FDrive *get_drv(FDCtrl *fdctrl, int unit)
 {
-switch (fdctrl->cur_drv) {
+switch (unit) {
 case 0: return drv0(fdctrl);
 case 1: return drv1(fdctrl);
 #if MAX_FD == 4
@@ -1198,6 +1294,11 @@ static FDrive *get_cur_drv(FDCtrl *fdctrl)
 }
 }
 
+static FDrive *get_cur_drv(FDCtrl *fdctrl)
+{
+return get_drv(fdctrl, fdctrl->cur_drv);
+}
+
 /* Status A register : 0x00 (read-only) */
 static uint32_t fdctrl_read_statusA(FDCtrl *fdctrl)
 {
@@ -2357,46 +2458,33 @@ static void fdctrl_result_timer(void *opaque)
 }
 }
 
-static void fdctrl_change_cb(void *opaque, bool load)
-{
-FDrive *drive = opaque;
-
-drive->media_changed = 1;
-drive->media_validated = false;
-fd_revalidate(drive);
-}
-
-static const BlockDevOps fdctrl_block_ops = {
-.change_media_cb = fdctrl_change_cb,
-};
-
 /* Init functions */
 static void fdctrl_connect_drives(FDCtrl *fdctrl, Error **errp)
 {
 unsigned int i;
 FDrive *drive;

[Qemu-devel] [PATCH v3 0/4] fdc: Use separate qdev device for drives

[Kevin Wolf]

We have been complaining for a long time about how the floppy controller and
floppy drives are combined in a single qdev device and how this makes the
device awkward to work with because it behaves different from all other block
devices.

The latest reason to complain was when I noticed that using qdev device names
in QMP commands (e.g. for media change) doesn't really work when only the
controller is a qdev device, but the drives aren't.

So I decided to have a go at it, and this is the result.

It doesn't actually change any of the inner workings of the floppy controller,
but it wires things up differently on the qdev layer so that a floppy
controller now exposes a bus on which the floppy drives sit. This results in a
structure that is similar to IDE where the actual drive state is still in the
controller and the qdev device basically just contains the qdev properties -
not pretty, but quite workable.

The commit message of patch 3 explains how to use it. In short, there is a
'-device floppy' now and it does what you would expect if you ever used ide-cd.

The other problem is old command lines, especially those using things like
'-global isa-fdc,driveA=...'. In order to keep them working, we need to forward
the property to an internally created floppy drive device. This is a bit like
usb-storage, which we know is ugly, but works well enough in practice. The good
news here is that in contrast to usb-storage, the floppy controller only does
the forwarding for legacy configurations; as soon as you start using '-device
floppy', it doesn't happen any more.

So as you may have expected, this conversion doesn't result in a perfect
device, but I think it's definitely an improvement over the old state. I hope
you like it despite the warts. :-)

v3:
- Fixed omissons in the conversion sysbus-fdc and the Sun one. Nice, combining
  floppy controllers and weird platforms in a single series. [John]

v2:
- Added patch 4 (qemu-iotests case for floppy config on the command line)
- Patch 2: Create a floppy device only if a BlockBackend exists instead of
  always creating two of them
- Patch 2: Initialise drive->fdctrl even if no drive is attached, it is
  accessed anyway during migration
- Patch 3: Keep 'type' qdev property and FDrive->drive in sync
- Patch 3: Removed if with condition that is always true

Kevin Wolf (4):
  fdc: Add a floppy qbus
  fdc: Add a floppy drive qdev
  fdc: Move qdev properties to FloppyDrive
  qemu-iotests: Test creating floppy drives

 hw/block/fdc.c |  271 --
 tests/qemu-iotests/172 |  242 +
 tests/qemu-iotests/172.out | 1205 
 tests/qemu-iotests/group   |1 +
 vl.c   |1 +
 5 files changed, 1672 insertions(+), 48 deletions(-)
 create mode 100755 tests/qemu-iotests/172
 create mode 100644 tests/qemu-iotests/172.out

-- 
1.8.3.1

[Qemu-devel] [PATCH v3 3/4] fdc: Move qdev properties to FloppyDrive

[Kevin Wolf]

This makes the FloppyDrive qdev object actually useful: Now that it has
all properties that don't belong to the controller, you can actually
use '-device floppy' and get a working result.

Command line semantics is consistent with CD-ROM drives: By default you
get a single empty floppy drive. You can override it with -drive and
using the same index, but if you use -drive to add a floppy to a
different index, you get both of them. However, as soon as you use any
'-device floppy', even to a different slot, the default drive is
disabled.

Using '-device floppy' without specifying the unit will choose the first
free slot on the controller.

Signed-off-by: Kevin Wolf 
---
 hw/block/fdc.c | 120 ++---
 vl.c   |   1 +
 2 files changed, 89 insertions(+), 32 deletions(-)

diff --git a/hw/block/fdc.c b/hw/block/fdc.c
index 5aa8e52..537b996 100644
--- a/hw/block/fdc.c
+++ b/hw/block/fdc.c
@@ -35,6 +35,7 @@
 #include "qemu/timer.h"
 #include "hw/isa/isa.h"
 #include "hw/sysbus.h"
+#include "hw/block/block.h"
 #include "sysemu/block-backend.h"
 #include "sysemu/blockdev.h"
 #include "sysemu/sysemu.h"
@@ -487,12 +488,18 @@ static const BlockDevOps fd_block_ops = {
  OBJECT_CHECK(FloppyDrive, (obj), TYPE_FLOPPY_DRIVE)
 
 typedef struct FloppyDrive {
-DeviceState qdev;
-uint32_tunit;
+DeviceState qdev;
+uint32_tunit;
+BlockConf   conf;
+FloppyDriveType type;
 } FloppyDrive;
 
 static Property floppy_drive_properties[] = {
 DEFINE_PROP_UINT32("unit", FloppyDrive, unit, -1),
+DEFINE_BLOCK_PROPERTIES(FloppyDrive, conf),
+DEFINE_PROP_DEFAULT("drive-type", FloppyDrive, type,
+FLOPPY_DRIVE_TYPE_AUTO, qdev_prop_fdc_drive_type,
+FloppyDriveType),
 DEFINE_PROP_END_OF_LIST(),
 };
 
@@ -501,6 +508,7 @@ static int floppy_drive_init(DeviceState *qdev)
 FloppyDrive *dev = FLOPPY_DRIVE(qdev);
 FloppyBus *bus = DO_UPCAST(FloppyBus, bus, dev->qdev.parent_bus);
 FDrive *drive;
+int ret;
 
 if (dev->unit == -1) {
 for (dev->unit = 0; dev->unit < MAX_FD; dev->unit++) {
@@ -517,29 +525,57 @@ static int floppy_drive_init(DeviceState *qdev)
 return -1;
 }
 
-/* TODO Check whether unit is in use */
-
 drive = get_drv(bus->fdc, dev->unit);
-
 if (drive->blk) {
-if (blk_get_on_error(drive->blk, 0) != BLOCKDEV_ON_ERROR_ENOSPC) {
-error_report("fdc doesn't support drive option werror");
-return -1;
-}
-if (blk_get_on_error(drive->blk, 1) != BLOCKDEV_ON_ERROR_REPORT) {
-error_report("fdc doesn't support drive option rerror");
-return -1;
-}
-} else {
+error_report("Floppy unit %d is in use", dev->unit);
+return -1;
+}
+
+if (!dev->conf.blk) {
 /* Anonymous BlockBackend for an empty drive */
-drive->blk = blk_new();
+dev->conf.blk = blk_new();
+ret = blk_attach_dev(dev->conf.blk, qdev);
+assert(ret == 0);
 }
 
-fd_init(drive);
-if (drive->blk) {
-blk_set_dev_ops(drive->blk, &fd_block_ops, drive);
-pick_drive_type(drive);
+blkconf_blocksizes(&dev->conf);
+if (dev->conf.logical_block_size != 512 ||
+dev->conf.physical_block_size != 512)
+{
+error_report("Physical and logical block size must be 512 for floppy");
+return -1;
+}
+
+/* rerror/werror aren't supported by fdc and therefore not even registered
+ * with qdev. So set the defaults manually before they are used in
+ * blkconf_apply_backend_options(). */
+dev->conf.rerror = BLOCKDEV_ON_ERROR_AUTO;
+dev->conf.werror = BLOCKDEV_ON_ERROR_AUTO;
+blkconf_apply_backend_options(&dev->conf);
+
+/* 'enospc' is the default for -drive, 'report' is what blk_new() gives us
+ * for empty drives. */
+if (blk_get_on_error(dev->conf.blk, 0) != BLOCKDEV_ON_ERROR_ENOSPC &&
+blk_get_on_error(dev->conf.blk, 0) != BLOCKDEV_ON_ERROR_REPORT) {
+error_report("fdc doesn't support drive option werror");
+return -1;
 }
+if (blk_get_on_error(dev->conf.blk, 1) != BLOCKDEV_ON_ERROR_REPORT) {
+error_report("fdc doesn't support drive option rerror");
+return -1;
+}
+
+drive->blk = dev->conf.blk;
+drive->fdctrl = bus->fdc;
+
+fd_init(drive);
+blk_set_dev_ops(drive->blk, &fd_block_ops, drive);
+
+/* Keep 'type' qdev property and FDrive->drive in sync */
+drive->drive = dev->type;
+pick_drive_type(drive);
+dev->type = drive->drive;
+
 fd_revalidate(drive);
 
 return 0;
@@ -808,6 +844,10 @@ struct FDCtrl {
 FloppyBus bus;
 uint8_t num_floppies;
 FDrive drives[MAX_FD];
+struct {
+BlockBackend *blk;
+FloppyDriveType type;
+} qdev_for_drives[MAX_FD];
 int reset_sensei;
 uint32_t check_media_rate;
 FloppyDriveType fallback; /* type=auto

[Qemu-devel] [PATCH v3 4/4] qemu-iotests: Test creating floppy drives

[Kevin Wolf]

This tests the different supported methods to create floppy drives and
how they interact.

Signed-off-by: Kevin Wolf 
---
 tests/qemu-iotests/172 |  242 +
 tests/qemu-iotests/172.out | 1205 
 tests/qemu-iotests/group   |1 +
 3 files changed, 1448 insertions(+)
 create mode 100755 tests/qemu-iotests/172
 create mode 100644 tests/qemu-iotests/172.out

diff --git a/tests/qemu-iotests/172 b/tests/qemu-iotests/172
new file mode 100755
index 000..8bb6443
--- /dev/null
+++ b/tests/qemu-iotests/172
@@ -0,0 +1,242 @@
+#!/bin/bash
+#
+# Test floppy configuration
+#
+# Copyright (C) 2016 Red Hat, Inc.
+#
+# 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.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+#
+
+# creator
+owner=kw...@redhat.com
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+here=`pwd`
+status=1   # failure is the default!
+
+_cleanup()
+{
+   _cleanup_test_img
+}
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+
+_supported_fmt qcow2
+_supported_proto file
+_supported_os Linux
+
+if [ "$QEMU_DEFAULT_MACHINE" != "pc" ]; then
+_notrun "Requires a PC machine"
+fi
+
+function do_run_qemu()
+{
+(
+if ! test -t 0; then
+while read cmd; do
+echo $cmd
+done
+fi
+echo quit
+) | $QEMU -nographic -monitor stdio -serial none "$@"
+echo
+}
+
+function check_floppy_qtree()
+{
+echo
+echo Testing: "$@" | _filter_testdir
+
+# QEMU_OPTIONS contains -nodefaults, we don't want that here because the
+# defaults are part of what should be checked here
+echo "info qtree" |
+QEMU_OPTIONS="" do_run_qemu "$@" | _filter_win32 |
+grep -zo '[[:cntrl:]]\( *\)dev: isa-fdc.*\([[:cntrl:]]\1 .*\)*[[:cntrl:]] 
*dev:'
+}
+
+function check_cache_mode()
+{
+echo "info block none0" |
+QEMU_OPTIONS="" do_run_qemu -drive if=none,file="$TEST_IMG" "$@" |
+_filter_win32 | grep "Cache mode"
+}
+
+
+size=720k
+
+_make_test_img $size
+
+# Default drive semantics:
+#
+# By default you get a single empty floppy drive. You can override it with
+# -drive and using the same index, but if you use -drive to add a floppy to a
+# different index, you get both of them. However, as soon as you use any
+# '-device floppy', even to a different slot, the default drive is disabled.
+
+echo
+echo
+echo === Default ===
+
+check_floppy_qtree
+
+echo
+echo
+echo === Using -fda/-fdb options ===
+
+check_floppy_qtree -fda "$TEST_IMG"
+check_floppy_qtree -fdb "$TEST_IMG"
+check_floppy_qtree -fda "$TEST_IMG" -fdb "$TEST_IMG"
+
+
+echo
+echo
+echo === Using -drive options ===
+
+check_floppy_qtree -drive if=floppy,file="$TEST_IMG"
+check_floppy_qtree -drive if=floppy,file="$TEST_IMG",index=1
+check_floppy_qtree -drive if=floppy,file="$TEST_IMG" -drive 
if=floppy,file="$TEST_IMG",index=1
+
+echo
+echo
+echo === Using -drive if=none and -global ===
+
+check_floppy_qtree -drive if=none,file="$TEST_IMG" -global isa-fdc.driveA=none0
+check_floppy_qtree -drive if=none,file="$TEST_IMG" -global isa-fdc.driveB=none0
+check_floppy_qtree -drive if=none,file="$TEST_IMG" -drive 
if=none,file="$TEST_IMG" \
+   -global isa-fdc.driveA=none0 -global isa-fdc.driveB=none1
+
+echo
+echo
+echo === Using -drive if=none and -device ===
+
+check_floppy_qtree -drive if=none,file="$TEST_IMG" -device floppy,drive=none0
+check_floppy_qtree -drive if=none,file="$TEST_IMG" -device 
floppy,drive=none0,unit=1
+check_floppy_qtree -drive if=none,file="$TEST_IMG" -drive 
if=none,file="$TEST_IMG" \
+   -device floppy,drive=none0 -device floppy,drive=none1,unit=1
+
+echo
+echo
+echo === Mixing -fdX and -global ===
+
+# Working
+check_floppy_qtree -fda "$TEST_IMG" -drive if=none,file="$TEST_IMG" -global 
isa-fdc.driveB=none0
+check_floppy_qtree -fdb "$TEST_IMG" -drive if=none,file="$TEST_IMG" -global 
isa-fdc.driveA=none0
+
+# Conflicting (-fdX wins)
+check_floppy_qtree -fda "$TEST_IMG" -drive if=none,file="$TEST_IMG" -global 
isa-fdc.driveA=none0
+check_floppy_qtree -fdb "$TEST_IMG" -drive if=none,file="$TEST_IMG" -global 
isa-fdc.driveB=none0
+
+echo
+echo
+echo === Mixing -fdX and -device ===
+
+# Working
+check_floppy_qtree -fda "$TEST_IMG" -drive if=none,file="$TEST_IMG" -device 
floppy,drive=none0
+check_floppy_qtree -fda "$TEST_IMG" -drive if=none,file="$TEST

Re: [Qemu-devel] [PATCH v3 05/13] pc: leave max apic_id_limit only in legacy cpu hotplug code

[Eduardo Habkost]

On Tue, Oct 18, 2016 at 11:02:54AM +0200, Igor Mammedov wrote:
> On Mon, 17 Oct 2016 19:44:52 -0200
> Eduardo Habkost  wrote:
> 
> > On Thu, Oct 13, 2016 at 11:52:39AM +0200, Igor Mammedov wrote:
> > [...]
> > > @@ -236,7 +237,11 @@ void build_legacy_cpu_hotplug_aml(Aml *ctx, 
> > > MachineState *machine,
> > >  /* The current AML generator can cover the APIC ID range [0..255],
> > >   * inclusive, for VCPU hotplug. */
> > >  QEMU_BUILD_BUG_ON(ACPI_CPU_HOTPLUG_ID_LIMIT > 256);
> > > -g_assert(pcms->apic_id_limit <= ACPI_CPU_HOTPLUG_ID_LIMIT);
> > > +if (pcms->apic_id_limit > ACPI_CPU_HOTPLUG_ID_LIMIT) {
> > > +error_report("max_cpus is too large. APIC ID of last CPU is %u",
> > > + pcms->apic_id_limit - 1);
> > > +exit(1);
> > > +}  
> > 
> > Moving the check here seems to make sense, but:
> > 
> > >  
> > >  /* create PCI0.PRES device and its _CRS to reserve CPU hotplug MMIO 
> > > */
> > >  dev = aml_device("PCI0." stringify(CPU_HOTPLUG_RESOURCE_DEVICE));
> > > diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> > > index 93ff49c..f1c1013 100644
> > > --- a/hw/i386/pc.c
> > > +++ b/hw/i386/pc.c
> > > @@ -778,7 +778,6 @@ static FWCfgState *bochs_bios_init(AddressSpace *as, 
> > > PCMachineState *pcms)  
> > 
> > [Added more context below to show the code around the change]
> > 
> > >  numa_fw_cfg = g_new0(uint64_t, 1 + pcms->apic_id_limit + 
> > > nb_numa_nodes);
> > >  numa_fw_cfg[0] = cpu_to_le64(nb_numa_nodes);
> > >  for (i = 0; i < max_cpus; i++) {
> > >  unsigned int apic_id = x86_cpu_apic_id_from_index(i);
> > > -assert(apic_id < pcms->apic_id_limit);  
> > 
> > If you really needed to remove this assert, that means you can
> > write beyond the end of numa_fw_fg[] below. Are you sure you need
> > to remove it?
> > 
> > >  j = numa_get_node_for_cpu(i);
> > >  if (j < nb_numa_nodes) {
> > >  numa_fw_cfg[apic_id + 1] = cpu_to_le64(j);  
> > 
> >^^^ here
> Shouldn't above
>   numa_fw_cfg = g_new0(uint64_t, 1 + pcms->apic_id_limit + nb_numa_nodes);
> allocate sufficiently sized array?

I believe it should, but that would mean the assert() is still
valid.

> 
> That's aside, the assert could be kept as it doesn't get in a way
> if you'd prefer it that way.

Yes, please. The assert() removal seems unnecessary (and
confusing, because it made me believe that the condition was not
going to be valid anymore).

-- 
Eduardo

[Qemu-devel] [PATCH 1/2] script/clean-includes: added duplicate #include check

[Anand J]

Added script to check duplicate #include entries. This check will scan
and print the files in which duplicate #include entries are present.

Script might output false positive entries as well. Such entries should
not be removed. So if it finds any duplicate entries script will
terminate with an exit status 1. Then each and every file should be
checked manually and corrected if necessary.

In order to enable the check use --check-duphead option with
script/clean-includes.

Signed-off-by: Anand J 
---
 scripts/clean-includes | 50 +-
 1 file changed, 37 insertions(+), 13 deletions(-)

diff --git a/scripts/clean-includes b/scripts/clean-includes
index 4412a55..76dd0e4 100755
--- a/scripts/clean-includes
+++ b/scripts/clean-includes
@@ -14,15 +14,18 @@
 # the top-level directory.
 
 # Usage:
-#   clean-includes [--git subjectprefix] file ...
+#   clean-includes [--git subjectprefix] [--check-duphead] file ...
 # or
-#   clean-includes [--git subjectprefix] --all
+#   clean-includes [--git subjectprefix] [--check-duphead] --all
 #
 # If the --git subjectprefix option is given, then after making
 # the changes to the files this script will create a git commit
 # with the subject line "subjectprefix: Clean up includes"
 # and a boilerplate commit message.
 #
+# If --check-duphead option is used, then check for duplicate
+# header files will be enabled.
+#
 # Using --all will cause clean-includes to run on the whole source
 # tree (excluding certain directories which are known not to need
 # handling).
@@ -45,23 +48,36 @@
 
 
 GIT=no
+DUPHEAD=no
 
 # Extended regular expression defining files to ignore when using --all
 XDIRREGEX='^(tests/tcg|tests/multiboot|pc-bios|disas/libvixl)'
 
-if [ $# -ne 0 ] && [ "$1" = "--git" ]; then
-if [ $# -eq 1 ]; then
-echo "--git option requires an argument"
-exit 1
-fi
-GITSUBJ="$2"
-GIT=yes
-shift
-shift
-fi
+while true
+do
+case $1 in
+"--git")
+ if [ $# -eq 1 ]; then
+ echo "--git option requires an argument"
+ exit 1
+ fi
+ GITSUBJ="$2"
+ GIT=yes
+ shift
+ shift
+ ;;
+"--check-duphead")
+DUPHEAD=yes
+shift
+;;
+*)
+break
+;;
+   esac
+done
 
 if [ $# -eq 0 ]; then
-echo "Usage: clean-includes [--git subjectprefix] [--all | foo.c ...]"
+echo "Usage: clean-includes [--git subjectprefix] [--check-duphead] [--all 
| foo.c ...]"
 echo "(modifies the files in place)"
 exit 1
 fi
@@ -154,6 +170,14 @@ for f in "$@"; do
 
 done
 
+if [ "$DUPHEAD" = "yes" ]; then
+grep "^#include" $@ | sort | uniq -c | awk '{if ($1 > 1) print $0}'
+if [ $? -eq 0 ]; then
+echo "Found duplicate header file includes. Please check the above 
files manually."
+exit 1
+fi
+fi
+
 if [ "$GIT" = "yes" ]; then
 git add -- "$@"
 git commit --signoff -F - <

[Qemu-devel] [PATCH 2/2] clean-up: removed duplicate #includes

[Anand J]

Some files contain multiple #includes of the same header file.
Removed most of those unnecessary duplicate entries using
scripts/clean-includes.

Signed-off-by: Anand J 
---
 accel.c | 1 -
 cputlb.c| 1 -
 gdbstub.c   | 1 -
 hw/i386/acpi-build.c| 1 -
 hw/microblaze/boot.c| 1 -
 hw/mips/mips_malta.c| 1 -
 hw/nvram/fw_cfg.c   | 1 -
 hw/pci-bridge/pci_expander_bridge.c | 1 -
 hw/ppc/ppc405_boards.c  | 1 -
 hw/ppc/spapr.c  | 1 -
 hw/timer/grlib_gptimer.c| 1 -
 hw/tpm/tpm_tis.c| 1 -
 hw/unicore32/puv3.c | 1 -
 hw/usb/dev-mtp.c| 1 -
 include/hw/i386/pc.h| 1 -
 monitor.c   | 2 --
 qemu-io-cmds.c  | 1 -
 qmp.c   | 1 -
 target-i386/machine.c   | 3 ---
 target-mips/machine.c   | 1 -
 target-ppc/machine.c| 1 -
 target-ppc/mem_helper.c | 1 -
 target-sparc/machine.c  | 3 ---
 target-xtensa/translate.c   | 1 -
 tests/crypto-tls-x509-helpers.h | 3 ---
 tests/vhost-user-test.c | 2 --
 util/oslib-posix.c  | 1 -
 vl.c| 1 -
 28 files changed, 36 deletions(-)

diff --git a/accel.c b/accel.c
index 403eb5e..664bb88 100644
--- a/accel.c
+++ b/accel.c
@@ -33,7 +33,6 @@
 #include "sysemu/qtest.h"
 #include "hw/xen/xen.h"
 #include "qom/object.h"
-#include "hw/boards.h"
 
 int tcg_tb_size;
 static bool tcg_allowed = true;
diff --git a/cputlb.c b/cputlb.c
index 3c99c34..6a7208f 100644
--- a/cputlb.c
+++ b/cputlb.c
@@ -28,7 +28,6 @@
 
 #include "exec/memory-internal.h"
 #include "exec/ram_addr.h"
-#include "exec/exec-all.h"
 #include "tcg/tcg.h"
 #include "qemu/error-report.h"
 #include "exec/log.h"
diff --git a/gdbstub.c b/gdbstub.c
index ecea8c4..67eb028 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -31,7 +31,6 @@
 
 #define MAX_PACKET_LENGTH 4096
 
-#include "cpu.h"
 #include "qemu/sockets.h"
 #include "sysemu/kvm.h"
 #include "exec/semihost.h"
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index e999654..2b49f58 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -53,7 +53,6 @@
 #include "hw/pci/pci_bus.h"
 #include "hw/pci-host/q35.h"
 #include "hw/i386/x86-iommu.h"
-#include "hw/timer/hpet.h"
 
 #include "hw/acpi/aml-build.h"
 
diff --git a/hw/microblaze/boot.c b/hw/microblaze/boot.c
index 9eebb1a..1834d22 100644
--- a/hw/microblaze/boot.c
+++ b/hw/microblaze/boot.c
@@ -30,7 +30,6 @@
 #include "qemu/option.h"
 #include "qemu/config-file.h"
 #include "qemu/error-report.h"
-#include "qemu-common.h"
 #include "sysemu/device_tree.h"
 #include "sysemu/sysemu.h"
 #include "hw/loader.h"
diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
index e90857e..61aa8eb 100644
--- a/hw/mips/mips_malta.c
+++ b/hw/mips/mips_malta.c
@@ -47,7 +47,6 @@
 #include "elf.h"
 #include "hw/timer/mc146818rtc.h"
 #include "hw/timer/i8254.h"
-#include "sysemu/block-backend.h"
 #include "sysemu/blockdev.h"
 #include "exec/address-spaces.h"
 #include "hw/sysbus.h" /* SysBusDevice */
diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index 92aa563..1f0c3e9 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -29,7 +29,6 @@
 #include "hw/isa/isa.h"
 #include "hw/nvram/fw_cfg.h"
 #include "hw/sysbus.h"
-#include "hw/boards.h"
 #include "trace.h"
 #include "qemu/error-report.h"
 #include "qemu/config-file.h"
diff --git a/hw/pci-bridge/pci_expander_bridge.c 
b/hw/pci-bridge/pci_expander_bridge.c
index 1cc598f..6ac187f 100644
--- a/hw/pci-bridge/pci_expander_bridge.c
+++ b/hw/pci-bridge/pci_expander_bridge.c
@@ -15,7 +15,6 @@
 #include "hw/pci/pci.h"
 #include "hw/pci/pci_bus.h"
 #include "hw/pci/pci_host.h"
-#include "hw/pci/pci_bus.h"
 #include "hw/pci/pci_bridge.h"
 #include "hw/i386/pc.h"
 #include "qemu/range.h"
diff --git a/hw/ppc/ppc405_boards.c b/hw/ppc/ppc405_boards.c
index 4b2f07a..d01798f 100644
--- a/hw/ppc/ppc405_boards.c
+++ b/hw/ppc/ppc405_boards.c
@@ -37,7 +37,6 @@
 #include "qemu/log.h"
 #include "qemu/error-report.h"
 #include "hw/loader.h"
-#include "sysemu/block-backend.h"
 #include "sysemu/blockdev.h"
 #include "exec/address-spaces.h"
 
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index ddb7438..2491287 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -37,7 +37,6 @@
 #include "sysemu/block-backend.h"
 #include "sysemu/cpus.h"
 #include "sysemu/kvm.h"
-#include "sysemu/device_tree.h"
 #include "kvm_ppc.h"
 #include "migration/migration.h"
 #include "mmu-hash64.h"
diff --git a/hw/timer/grlib_gptimer.c b/hw/timer/grlib_gptimer.c
index 712d1ae..4ed96e9 100644
--- a/hw/timer/grlib_gptimer.c
+++ b/hw/timer/grlib_gptimer.c
@@ -26,7 +26,6 @@
 #include "hw/sysbus.h"
 #include "qemu/timer.h"
 #include "hw/ptimer.h"
-#include "qemu/timer.h"
 #include "qemu

Re: [Qemu-devel] [PATCH] qapi: fix memory leak in bdrv_image_info_specific_dump

[Pino Toscano]

On Tuesday, 18 October 2016 11:44:26 CEST Kevin Wolf wrote:
> Am 18.10.2016 um 11:18 hat Pino Toscano geschrieben:
> > The 'obj' result of the visitor was not properly freed, like done in
> > other places doing a similar job.
> > ---
> >  block/qapi.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/block/qapi.c b/block/qapi.c
> > index 6f947e3..50d3090 100644
> > --- a/block/qapi.c
> > +++ b/block/qapi.c
> > @@ -698,6 +698,7 @@ void bdrv_image_info_specific_dump(fprintf_function 
> > func_fprintf, void *f,
> >  assert(qobject_type(obj) == QTYPE_QDICT);
> >  data = qdict_get(qobject_to_qdict(obj), "data");
> >  dump_qobject(func_fprintf, f, 1, data);
> > +qobject_decref(obj);
> >  visit_free(v);
> >  }
> 
> The change looks good, but without a Signed-off-by line I can't accept
> the patch: http://wiki.qemu.org/Contribute/SubmitAPatch

D'oh, sorry -- apparently I didn't send the right version... v2 coming.

Thanks,
-- 
Pino Toscano

signature.asc
Description: This is a digitally signed message part.

Re: [Qemu-devel] [PATCH v3 05/13] pc: leave max apic_id_limit only in legacy cpu hotplug code

[Eduardo Habkost]

On Tue, Oct 18, 2016 at 11:12:04AM +0200, Igor Mammedov wrote:
> On Mon, 17 Oct 2016 19:44:52 -0200
> Eduardo Habkost  wrote:
> 
> > On Thu, Oct 13, 2016 at 11:52:39AM +0200, Igor Mammedov wrote:
> > [...]
> > > @@ -236,7 +237,11 @@ void build_legacy_cpu_hotplug_aml(Aml *ctx, 
> > > MachineState *machine,
> > >  /* The current AML generator can cover the APIC ID range [0..255],
> > >   * inclusive, for VCPU hotplug. */
> > >  QEMU_BUILD_BUG_ON(ACPI_CPU_HOTPLUG_ID_LIMIT > 256);
> > > -g_assert(pcms->apic_id_limit <= ACPI_CPU_HOTPLUG_ID_LIMIT);
> > > +if (pcms->apic_id_limit > ACPI_CPU_HOTPLUG_ID_LIMIT) {
> > > +error_report("max_cpus is too large. APIC ID of last CPU is %u",
> > > + pcms->apic_id_limit - 1);
> > > +exit(1);
> > > +}  
> > 
> > Moving the check here seems to make sense, but:
> > 
> > >  
> > >  /* create PCI0.PRES device and its _CRS to reserve CPU hotplug MMIO 
> > > */
> > >  dev = aml_device("PCI0." stringify(CPU_HOTPLUG_RESOURCE_DEVICE));
> > > diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> > > index 93ff49c..f1c1013 100644
> > > --- a/hw/i386/pc.c
> > > +++ b/hw/i386/pc.c
> > > @@ -778,7 +778,6 @@ static FWCfgState *bochs_bios_init(AddressSpace *as, 
> > > PCMachineState *pcms)  
> > 
> > [Added more context below to show the code around the change]
> > 
> > >  numa_fw_cfg = g_new0(uint64_t, 1 + pcms->apic_id_limit + 
> > > nb_numa_nodes);
> > >  numa_fw_cfg[0] = cpu_to_le64(nb_numa_nodes);
> > >  for (i = 0; i < max_cpus; i++) {
> > >  unsigned int apic_id = x86_cpu_apic_id_from_index(i);
> > > -assert(apic_id < pcms->apic_id_limit);  
> > 
> > If you really needed to remove this assert, that means you can
> > write beyond the end of numa_fw_fg[] below. Are you sure you need
> > to remove it?
> > 
> > >  j = numa_get_node_for_cpu(i);
> > >  if (j < nb_numa_nodes) {
> > >  numa_fw_cfg[apic_id + 1] = cpu_to_le64(j);  
> > 
> >^^^ here
> > 
> > >  }
> Another more radical way to deal with legacy FW_CFG_NUMA
> could be to remove it altogether if machine has x2APIC cpus.
> It'd be possible to do due to BIOS using QEMU provided
> BIOS tables and not using/calling code for built in/legacy
> ACPI tables.
> 
> Could do it as patch on top if that's sounds ok.

I don't mind either way. Initializing the fields even if they are
not going to be used seems harmless, but if you believe skipping
it would make things simpler, go ahead.

In this case, what would happen if x2apic CPUs are available but
the BIOS is too old?

-- 
Eduardo

[Qemu-devel] [PATCH v2] qapi: fix memory leak in QmpOutputVisitor

[Pino Toscano]

qmp_output_start_struct() and qmp_output_start_list() create a new
QObject (QDict, QList) and push it to the stack of the QmpOutputVisitor,
where it is saved as 'value'.  When freeing the iterator in
qmp_output_free(), these values are never freed properly.

The simple solution is to qobject_decref() them.

Signed-off-by: Pino Toscano 
---

Changes in v2:
- added Signed-off-by

 qapi/qmp-output-visitor.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/qapi/qmp-output-visitor.c b/qapi/qmp-output-visitor.c
index 9e3b67c..eedf256 100644
--- a/qapi/qmp-output-visitor.c
+++ b/qapi/qmp-output-visitor.c
@@ -220,6 +220,7 @@ static void qmp_output_free(Visitor *v)
 while (!QSLIST_EMPTY(&qov->stack)) {
 e = QSLIST_FIRST(&qov->stack);
 QSLIST_REMOVE_HEAD(&qov->stack, node);
+qobject_decref(e->value);
 g_free(e);
 }
 
-- 
2.7.4

Re: [Qemu-devel] [PULL 0/5] machine + memory backend queue, 2016-10-17

[Peter Maydell]

On 17 October 2016 at 18:55, Eduardo Habkost  wrote:
> The following changes since commit 0975b8b823a888d474fa33821dfe84e6904db197:
>
>   Merge remote-tracking branch 'remotes/gkurz/tags/for-upstream' into staging 
> (2016-10-17 16:17:51 +0100)
>
> are available in the git repository at:
>
>   git://github.com/ehabkost/qemu.git tags/machine-pull-request
>
> for you to fetch changes up to 026ac483c70850c82fad849de656204b16f8415e:
>
>   hostmem-file: Register TYPE_MEMORY_BACKEND_FILE properties as class 
> properties (2016-10-17 15:48:40 -0200)
>
> 
> machine + memory backend queue, 2016-10-17
>
> 

Applied, thanks.

-- PMM

Re: [Qemu-devel] [PATCH v3 09/13] pc: kvm_apic: pass APIC ID depending on xAPIC/x2APIC mode

[Eduardo Habkost]

On Tue, Oct 18, 2016 at 09:17:48AM +0200, Igor Mammedov wrote:
> On Mon, 17 Oct 2016 19:51:12 -0200
> Eduardo Habkost  wrote:
> 
> > On Thu, Oct 13, 2016 at 11:52:43AM +0200, Igor Mammedov wrote:
> > > Signed-off-by: Igor Mammedov 
> > > ---
> > > v4:
> > >  - drop kvm_has_x2apic_api() and reuse kvm_enable_x2apic() instead
> > > ---
> > >  hw/i386/kvm/apic.c | 12 ++--
> > >  1 file changed, 10 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/hw/i386/kvm/apic.c b/hw/i386/kvm/apic.c
> > > index be55102..9a7dd03 100644
> > > --- a/hw/i386/kvm/apic.c
> > > +++ b/hw/i386/kvm/apic.c
> > > @@ -34,7 +34,11 @@ static void kvm_put_apic_state(APICCommonState *s, 
> > > struct kvm_lapic_state *kapic
> > >  int i;
> > >  
> > >  memset(kapic, 0, sizeof(*kapic));
> > > -kvm_apic_set_reg(kapic, 0x2, s->id << 24);
> > > +if (kvm_enable_x2apic() && s->apicbase & MSR_IA32_APICBASE_EXTD) {  
> > 
> > This is going to enable x2apic unconditionally (not just check if
> > x2apic was enabled). Is this really what you want to do?
> Fixed,
>  v4 is in reply to the same note from Radim

Oops, didn't notice v4 was already there. Sorry for the noise.

-- 
Eduardo

[Qemu-devel] [PATCH v2] qapi: fix memory leak in bdrv_image_info_specific_dump

[Pino Toscano]

The 'obj' result of the visitor was not properly freed, like done in
other places doing a similar job.

Signed-off-by: Pino Toscano 
---

Changes in v2:
- added Signed-off-by

 block/qapi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/block/qapi.c b/block/qapi.c
index 6f947e3..50d3090 100644
--- a/block/qapi.c
+++ b/block/qapi.c
@@ -698,6 +698,7 @@ void bdrv_image_info_specific_dump(fprintf_function 
func_fprintf, void *f,
 assert(qobject_type(obj) == QTYPE_QDICT);
 data = qdict_get(qobject_to_qdict(obj), "data");
 dump_qobject(func_fprintf, f, 1, data);
+qobject_decref(obj);
 visit_free(v);
 }
 
-- 
2.7.4

Re: [Qemu-devel] [very-WIP 3/4] slirp: VMStatify sbuf

[Halil Pasic]

On 10/17/2016 09:06 PM, Dr. David Alan Gilbert wrote:
>> OK, memory was allocated at #2
>> > It is a bit confusing though (for a novice like me) that we have a non 
>> > ALLOC VBUFFER
>> > whose pointer is NULL after post_load.
> I don't think this pointer can be NULL; the sbreserve at #2 causes it to be
> allocated.
> But yes, it's a shame I can't use VMS_ALLOC here, but the sbreserve is not
> a trivial allocation function.

Sorry my fault, wanted to say pre_load and not post_load. The assumption
that backing memory is allocated either during device realization or in the
pre_load of the parent or in vmstate_base_addr seemed a reasonable one
(prior to the extra possibilities introduced by the patches of Jianjun).

> 
>> > Now if I imagine the original stream were written in the following 
>> > sequence:
>> > vbuffer_length (sb_datalen), vbuffer_data (sb_data), offsets (sb_wptr, 
>> > sb_rptr)
>> > which seems completely valid to me then the context would not be sufficient
>> > to compute sb_wptr and sb_rptr because the lifetime of vbuffer_data and
>> > the tmp do not overlap.
> If that was the case you could still do it pretty easily.
> You'd have to add the sb_datalen and sb_data fields to the temporary
> and then move the VMSTATE_VBUFFER_UINT32 into the tmp so it would operate
> on the copied fields.
> 

That basically means you expand the area affected by the tmp handling
so that you have all the info you need to do the computation/transformation
before the temporary is freed, right? Then the worst it can get is that you 
need to
transform the first field and for that you need the last field.

>> > I aware it's a trade-off between how long the temporary data lives and
>> > how complicated the dependencies get. Or am I getting something wrong?
> No, I think that's right.  The other option I thought of was a macro
> to allocate a temporary and then another to free it and then someway
> to tell macros in between that they should operate on the temporary
> rather than the main pointer; but then you'd have to be VERY careful
> to not allow yourself to access a temporary that's been freed.
> This structure means you can't make that mistake.
> 

I have a couple of crazy half ideas of myself, I just do not feel
very comfortable sharing them, because right now I do not have the
capacity to explore them properly. Besides I don't know the code-base
well enough to say if this reasoning has some practical relevance
or is it 'rather academic'. Nevertheless I did not want to keep
the opinion to myself that this thing with the dependencies can
get rather convoluted under circumstances.


Cheers,
Halil

> Dave
> 
>> > 
>> > Cheers,
>> > Halil
>> > 
 > >> +VMSTATE_END_OF_LIST()
 > >> +}
 > >> +};
>> > [..]
>> > 

Re: [Qemu-devel] [Qemu-block] block/nfs: Fine grained runtime options in nfs

[Peter Lieven]

Am 17.10.2016 um 21:34 schrieb Ashijeet Acharya:

On Tue, Oct 18, 2016 at 12:59 AM, Eric Blake  wrote:

On 10/17/2016 01:00 PM, Ashijeet Acharya wrote:


One more relatively easy question though, will we include @port as an
option in runtime_opts while converting NFS to use several
runtime_opts? The reason I ask this because the uri syntax for NFS in
QEMU looks like this:

nfs:[?param=value[¶m2=value2[&...]]]

It's actually nfs://[:port]/...

so the URI syntax already supports port.

But the commit message which added support for NFS had the uri which I
mentioned above and the code for NFS does not make use of 'port'
anywhere either, which is why I am a bit confused.


Hi Aschijeet,

don't worry there is no port number when connecting to an NFS server.
The portmapper always listens on port 111. So theoretically we could
specifiy a port in the URL but it is ignored.

BR,
Peter

Re: [Qemu-devel] [PATCH 00/15] optimize Qemu RSS usage

[Peter Lieven]

Am 12.10.2016 um 23:18 schrieb Michael R. Hines:

Peter,

Greetings from DigitalOcean. We're experiencing the same symptoms without this 
patch.
We have, collectively, many gigabytes of un-planned-for RSS being used 
per-hypervisor
that we would like to get rid of =).

Without explicitly trying this patch (will do that ASAP), we immediately 
noticed that the
192MB mentioned immediately melts away (Yay) when we disabled the coroutine 
thread pool explicitly,
with another ~100MB in additional stack usage that would likely also go away if 
we
applied the entirety of your patch.

Is there any chance you have revisited this or have a timeline for it?


Hi Michael,

the current master already includes some of the patches of this original 
series. There are still some changes left, but
what works for me is the current master +

diff --git a/util/qemu-coroutine.c b/util/qemu-coroutine.c
index 5816702..3eaef68 100644
--- a/util/qemu-coroutine.c
+++ b/util/qemu-coroutine.c
@@ -25,8 +25,6 @@ enum {
 };

 /** Free list to speed up creation */
-static QSLIST_HEAD(, Coroutine) release_pool = QSLIST_HEAD_INITIALIZER(pool);
-static unsigned int release_pool_size;
 static __thread QSLIST_HEAD(, Coroutine) alloc_pool = 
QSLIST_HEAD_INITIALIZER(pool);
 static __thread unsigned int alloc_pool_size;
 static __thread Notifier coroutine_pool_cleanup_notifier;
@@ -49,20 +47,10 @@ Coroutine *qemu_coroutine_create(CoroutineEntry *entry)
 if (CONFIG_COROUTINE_POOL) {
 co = QSLIST_FIRST(&alloc_pool);
 if (!co) {
-if (release_pool_size > POOL_BATCH_SIZE) {
-/* Slow path; a good place to register the destructor, too.  */
-if (!coroutine_pool_cleanup_notifier.notify) {
-coroutine_pool_cleanup_notifier.notify = 
coroutine_pool_cleanup;
- qemu_thread_atexit_add(&coroutine_pool_cleanup_notifier);
-}
-
-/* This is not exact; there could be a little skew between
- * release_pool_size and the actual size of release_pool.  But
- * it is just a heuristic, it does not need to be perfect.
- */
-alloc_pool_size = atomic_xchg(&release_pool_size, 0);
-QSLIST_MOVE_ATOMIC(&alloc_pool, &release_pool);
-co = QSLIST_FIRST(&alloc_pool);
+/* Slow path; a good place to register the destructor, too.  */
+if (!coroutine_pool_cleanup_notifier.notify) {
+coroutine_pool_cleanup_notifier.notify = 
coroutine_pool_cleanup;
+ qemu_thread_atexit_add(&coroutine_pool_cleanup_notifier);
 }
 }
 if (co) {
@@ -85,11 +73,6 @@ static void coroutine_delete(Coroutine *co)
 co->caller = NULL;

 if (CONFIG_COROUTINE_POOL) {
-if (release_pool_size < POOL_BATCH_SIZE * 2) {
-QSLIST_INSERT_HEAD_ATOMIC(&release_pool, co, pool_next);
-atomic_inc(&release_pool_size);
-return;
-}
 if (alloc_pool_size < POOL_BATCH_SIZE) {
 QSLIST_INSERT_HEAD(&alloc_pool, co, pool_next);
 alloc_pool_size++;

+ invoking qemu with the following environemnet variable set:

MALLOC_MMAP_THRESHOLD_=32768 qemu-system-x86_64 

The last one makes glibc automatically using mmap when the malloced memory 
exceeds 32kByte.

Hope this helps,
Peter

Re: [Qemu-devel] [PATCH v3 2/3] exec: rename cpu_exec_init() as cpu_exec_realizefn()

[Igor Mammedov]

On Mon, 17 Oct 2016 17:20:22 -0200
Eduardo Habkost  wrote:

> On Sat, Oct 15, 2016 at 12:52:48AM +0200, Laurent Vivier wrote:
> > Modify all CPUs to call it from XXX_cpu_realizefn() function.
> > 
> > Remove all the cannot_destroy_with_object_finalize_yet as
> > unsafe references have been moved to cpu_exec_realizefn().
> > (tested with QOM command provided by commit 4c315c27)
> > 
> > for arm:
> > 
> > Setting of cpu->mp_affinity is moved from arm_cpu_initfn()
> > to arm_cpu_realizefn() as setting of cpu_index is now done
> > in cpu_exec_realizefn().
> > 
> > Signed-off-by: Laurent Vivier   
> [...]
> > diff --git a/target-arm/cpu.c b/target-arm/cpu.c
> > index 1b9540e..364a45d 100644
> > --- a/target-arm/cpu.c
> > +++ b/target-arm/cpu.c
> > @@ -441,22 +441,11 @@ static void arm_cpu_initfn(Object *obj)
> >  CPUState *cs = CPU(obj);
> >  ARMCPU *cpu = ARM_CPU(obj);
> >  static bool inited;
> > -uint32_t Aff1, Aff0;
> >  
> >  cs->env_ptr = &cpu->env;
> > -cpu_exec_init(cs, &error_abort);
> >  cpu->cp_regs = g_hash_table_new_full(g_int_hash, g_int_equal,
> >   g_free, g_free);
> >  
> > -/* This cpu-id-to-MPIDR affinity is used only for TCG; KVM will 
> > override it.
> > - * We don't support setting cluster ID ([16..23]) (known as Aff2
> > - * in later ARM ARM versions), or any of the higher affinity level 
> > fields,
> > - * so these bits always RAZ.
> > - */
> > -Aff1 = cs->cpu_index / ARM_CPUS_PER_CLUSTER;
> > -Aff0 = cs->cpu_index % ARM_CPUS_PER_CLUSTER;
> > -cpu->mp_affinity = (Aff1 << ARM_AFF1_SHIFT) | Aff0;
> > -
> >  #ifndef CONFIG_USER_ONLY
> >  /* Our inbound IRQ and FIQ lines */
> >  if (kvm_enabled()) {  
> [...]
> > @@ -631,6 +628,15 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
> > **errp)
> >  set_feature(env, ARM_FEATURE_THUMB_DSP);
> >  }
> >  
> > +/* This cpu-id-to-MPIDR affinity is used only for TCG; KVM will 
> > override it.
> > + * We don't support setting cluster ID ([16..23]) (known as Aff2
> > + * in later ARM ARM versions), or any of the higher affinity level 
> > fields,
> > + * so these bits always RAZ.
> > + */
> > +Aff1 = cs->cpu_index / ARM_CPUS_PER_CLUSTER;
> > +Aff0 = cs->cpu_index % ARM_CPUS_PER_CLUSTER;
> > +cpu->mp_affinity = (Aff1 << ARM_AFF1_SHIFT) | Aff0;
> > +  
>
> This will override any value set in the "mp-affinity" property,
> The mp-affinity property can be set by the user in the
> command-line, and it is also set by machvirt_init() in
> hw/arm/virt.c.
> 
> Considering that each CPU is supposed to have a different value,
> I doubt there are existing use cases for mp-affinity being set
> directly by the user.
> 
> I suggest having a "cluster-size" property, instead of
> "mp-affinity". This way the mp_affinity field can be calculated
> on realize, based on the configured cluster-size.
CCing Drew as he knows more about MPIDR stuff more.

> 
> >  if (cpu->reset_hivecs) {
> >  cpu->reset_sctlr |= (1 << 13);
> >  }  
> [...]
> 

[Qemu-devel] [PATCH 7/8] tests: Use qpci_mem{read, write} in ivshmem-test

[David Gibson]

ivshmem implements a block of shared memory in a PCI BAR.  Currently our
test case accesses this using qtest_mem{read,write}.  However, deducing
the correct addresses for these requires making assumptions about the
internel format returned by qpci_iomap(), along with some ugly casts.

This patch changes the test to use the new qpci_mem{read,write} interfaces
which is neater.

Signed-off-by: David Gibson 
---
 tests/ivshmem-test.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/tests/ivshmem-test.c b/tests/ivshmem-test.c
index f36bfe7..97a887e 100644
--- a/tests/ivshmem-test.c
+++ b/tests/ivshmem-test.c
@@ -169,7 +169,7 @@ static void test_ivshmem_single(void)
 for (i = 0; i < G_N_ELEMENTS(data); i++) {
 data[i] = i;
 }
-qtest_memwrite(s->qtest, (uintptr_t)s->mem_base, data, sizeof(data));
+qpci_memwrite(s->dev, s->mem_base, data, sizeof(data));
 
 /* verify write */
 for (i = 0; i < G_N_ELEMENTS(data); i++) {
@@ -178,7 +178,7 @@ static void test_ivshmem_single(void)
 
 /* read it back and verify read */
 memset(data, 0, sizeof(data));
-qtest_memread(s->qtest, (uintptr_t)s->mem_base, data, sizeof(data));
+qpci_memread(s->dev, s->mem_base, data, sizeof(data));
 for (i = 0; i < G_N_ELEMENTS(data); i++) {
 g_assert_cmpuint(data[i], ==, i);
 }
@@ -201,29 +201,29 @@ static void test_ivshmem_pair(void)
 
 /* host write, guest 1 & 2 read */
 memset(tmpshmem, 0x42, TMPSHMSIZE);
-qtest_memread(s1->qtest, (uintptr_t)s1->mem_base, data, TMPSHMSIZE);
+qpci_memread(s1->dev, s1->mem_base, data, TMPSHMSIZE);
 for (i = 0; i < TMPSHMSIZE; i++) {
 g_assert_cmpuint(data[i], ==, 0x42);
 }
-qtest_memread(s2->qtest, (uintptr_t)s2->mem_base, data, TMPSHMSIZE);
+qpci_memread(s2->dev, s2->mem_base, data, TMPSHMSIZE);
 for (i = 0; i < TMPSHMSIZE; i++) {
 g_assert_cmpuint(data[i], ==, 0x42);
 }
 
 /* guest 1 write, guest 2 read */
 memset(data, 0x43, TMPSHMSIZE);
-qtest_memwrite(s1->qtest, (uintptr_t)s1->mem_base, data, TMPSHMSIZE);
+qpci_memwrite(s1->dev, s1->mem_base, data, TMPSHMSIZE);
 memset(data, 0, TMPSHMSIZE);
-qtest_memread(s2->qtest, (uintptr_t)s2->mem_base, data, TMPSHMSIZE);
+qpci_memread(s2->dev, s2->mem_base, data, TMPSHMSIZE);
 for (i = 0; i < TMPSHMSIZE; i++) {
 g_assert_cmpuint(data[i], ==, 0x43);
 }
 
 /* guest 2 write, guest 1 read */
 memset(data, 0x44, TMPSHMSIZE);
-qtest_memwrite(s2->qtest, (uintptr_t)s2->mem_base, data, TMPSHMSIZE);
+qpci_memwrite(s2->dev, s2->mem_base, data, TMPSHMSIZE);
 memset(data, 0, TMPSHMSIZE);
-qtest_memread(s1->qtest, (uintptr_t)s2->mem_base, data, TMPSHMSIZE);
+qpci_memread(s1->dev, s2->mem_base, data, TMPSHMSIZE);
 for (i = 0; i < TMPSHMSIZE; i++) {
 g_assert_cmpuint(data[i], ==, 0x44);
 }
-- 
2.7.4

[Qemu-devel] [PATCH 6/8] libqos: Implement mmio accessors in terms of mem{read, write}

[David Gibson]

In the libqos PCI code we now have accessors both for registers (byte
significance preserving) and for streaming data (byte address order
preserving).  These exist in both the interface for qtest drivers and in
the machine specific backends.

However, the register-style accessors aren't actually necessary in the
backend.  They can be implemented in terms of the byte address order
preserving accessors by the libqos wrappers.  This works because PCI is
always little endian.

This does assume that the back end byte address order preserving accessors
will perform the equivalent of a single bus transaction for short lengths.
This is the case, and in fact they currently end up using the same
cpu_physical_memory_rw() implementation within the qtest accelerator.

Signed-off-by: David Gibson 
---
 tests/libqos/pci-pc.c| 38 --
 tests/libqos/pci-spapr.c | 44 
 tests/libqos/pci.c   | 20 ++--
 tests/libqos/pci.h   |  8 
 4 files changed, 14 insertions(+), 96 deletions(-)

diff --git a/tests/libqos/pci-pc.c b/tests/libqos/pci-pc.c
index 0e95772..e8b885a 100644
--- a/tests/libqos/pci-pc.c
+++ b/tests/libqos/pci-pc.c
@@ -40,61 +40,31 @@ static uint8_t qpci_pc_pio_readb(QPCIBus *bus, uint32_t 
addr)
 return inb(addr);
 }
 
-static uint8_t qpci_pc_mmio_readb(QPCIBus *bus, uint32_t addr)
-{
-return readb(addr);
-}
-
 static void qpci_pc_pio_writeb(QPCIBus *bus, uint32_t addr, uint8_t val)
 {
 outb(addr, val);
 }
 
-static void qpci_pc_mmio_writeb(QPCIBus *bus, uint32_t addr, uint8_t val)
-{
-writeb(addr, val);
-}
-
 static uint16_t qpci_pc_pio_readw(QPCIBus *bus, uint32_t addr)
 {
 return inw(addr);
 }
 
-static uint16_t qpci_pc_mmio_readw(QPCIBus *bus, uint32_t addr)
-{
-return readw(addr);
-}
-
 static void qpci_pc_pio_writew(QPCIBus *bus, uint32_t addr, uint16_t val)
 {
 outw(addr, val);
 }
 
-static void qpci_pc_mmio_writew(QPCIBus *bus, uint32_t addr, uint16_t val)
-{
-writew(addr, val);
-}
-
 static uint32_t qpci_pc_pio_readl(QPCIBus *bus, uint32_t addr)
 {
 return inl(addr);
 }
 
-static uint32_t qpci_pc_mmio_readl(QPCIBus *bus, uint32_t addr)
-{
-return readl(addr);
-}
-
 static void qpci_pc_pio_writel(QPCIBus *bus, uint32_t addr, uint32_t val)
 {
 outl(addr, val);
 }
 
-static void qpci_pc_mmio_writel(QPCIBus *bus, uint32_t addr, uint32_t val)
-{
-writel(addr, val);
-}
-
 static void qpci_pc_memread(QPCIBus *bus, uint32_t addr, void *buf, size_t len)
 {
 memread(addr, buf, len);
@@ -156,14 +126,6 @@ QPCIBus *qpci_init_pc(QGuestAllocator *alloc)
 ret->bus.pio_writew = qpci_pc_pio_writew;
 ret->bus.pio_writel = qpci_pc_pio_writel;
 
-ret->bus.mmio_readb = qpci_pc_mmio_readb;
-ret->bus.mmio_readw = qpci_pc_mmio_readw;
-ret->bus.mmio_readl = qpci_pc_mmio_readl;
-
-ret->bus.mmio_writeb = qpci_pc_mmio_writeb;
-ret->bus.mmio_writew = qpci_pc_mmio_writew;
-ret->bus.mmio_writel = qpci_pc_mmio_writel;
-
 ret->bus.memread = qpci_pc_memread;
 ret->bus.memwrite = qpci_pc_memwrite;
 
diff --git a/tests/libqos/pci-spapr.c b/tests/libqos/pci-spapr.c
index b4c4b81..dc89b25 100644
--- a/tests/libqos/pci-spapr.c
+++ b/tests/libqos/pci-spapr.c
@@ -56,72 +56,36 @@ static uint8_t qpci_spapr_pio_readb(QPCIBus *bus, uint32_t 
addr)
 return readb(s->pio_cpu_base + addr);
 }
 
-static uint8_t qpci_spapr_mmio32_readb(QPCIBus *bus, uint32_t addr)
-{
-QPCIBusSPAPR *s = container_of(bus, QPCIBusSPAPR, bus);
-return readb(s->mmio32_cpu_base + addr);
-}
-
 static void qpci_spapr_pio_writeb(QPCIBus *bus, uint32_t addr, uint8_t val)
 {
 QPCIBusSPAPR *s = container_of(bus, QPCIBusSPAPR, bus);
 writeb(s->pio_cpu_base + addr, val);
 }
 
-static void qpci_spapr_mmio32_writeb(QPCIBus *bus, uint32_t addr, uint8_t val)
-{
-QPCIBusSPAPR *s = container_of(bus, QPCIBusSPAPR, bus);
-writeb(s->mmio32_cpu_base + addr, val);
-}
-
 static uint16_t qpci_spapr_pio_readw(QPCIBus *bus, uint32_t addr)
 {
 QPCIBusSPAPR *s = container_of(bus, QPCIBusSPAPR, bus);
 return bswap16(readw(s->pio_cpu_base + addr));
 }
 
-static uint16_t qpci_spapr_mmio32_readw(QPCIBus *bus, uint32_t addr)
-{
-QPCIBusSPAPR *s = container_of(bus, QPCIBusSPAPR, bus);
-return bswap16(readw(s->mmio32_cpu_base + addr));
-}
-
 static void qpci_spapr_pio_writew(QPCIBus *bus, uint32_t addr, uint16_t val)
 {
 QPCIBusSPAPR *s = container_of(bus, QPCIBusSPAPR, bus);
 writew(s->pio_cpu_base + addr, bswap16(val));
 }
 
-static void qpci_spapr_mmio32_writew(QPCIBus *bus, uint32_t addr, uint16_t val)
-{
-QPCIBusSPAPR *s = container_of(bus, QPCIBusSPAPR, bus);
-writew(s->mmio32_cpu_base + addr, bswap16(val));
-}
-
 static uint32_t qpci_spapr_pio_readl(QPCIBus *bus, uint32_t addr)
 {
 QPCIBusSPAPR *s = container_of(bus, QPCIBusSPAPR, bus);
 return bswap32(readl(s->pio_cpu_base + addr));
 }
 
-static uint32_t qpci_spapr_mmio32_readl(QPCIBus 

[Qemu-devel] [PATCH 0/8] Cleanups to qtest PCI handling

[David Gibson]

This series contains a number of cleanups to the libqos code for
accessing PCI devices, and to tests which use it.

The general aim is to improve the consistency of semantics across
functions, and reduce the amount of intimate knowledge of the libqos
PCI layer needed by tests.

This should make it easier to write PCI tests which will be portable
to different guest machines with different PCI host bridge
arrangements.

David Gibson (8):
  libqos: Give qvirtio_config_read*() consistent semantics
  libqos: Handle PCI IO de-multiplexing in common code
  libqos: Move BAR assignment to common code
  tests: Better handle legacy IO addresses in tco-test
  libqos: Add streaming accessors for PCI MMIO
  libqos: Implement mmio accessors in terms of mem{read,write}
  tests: Use qpci_mem{read,write} in ivshmem-test
  libqos: Change PCI accessors to take opaque BAR handle

 tests/ahci-test.c  |   4 +-
 tests/e1000e-test.c|   7 +-
 tests/ide-test.c   |  23 +++---
 tests/ivshmem-test.c   |  28 
 tests/libqos/ahci.c|   3 +-
 tests/libqos/ahci.h|   6 +-
 tests/libqos/pci-pc.c  | 170 +---
 tests/libqos/pci-spapr.c   | 172 ++---
 tests/libqos/pci.c | 168 ++-
 tests/libqos/pci.h |  60 ++--
 tests/libqos/usb.c |   6 +-
 tests/libqos/usb.h |   2 +-
 tests/libqos/virtio-mmio.c |  16 ++---
 tests/libqos/virtio-pci.c  | 117 --
 tests/libqos/virtio-pci.h  |   2 +-
 tests/rtl8139-test.c   |  10 ++-
 tests/tco-test.c   |  87 +++
 tests/usb-hcd-ehci-test.c  |   5 +-
 tests/virtio-9p-test.c |   9 +--
 tests/virtio-blk-test.c|  51 +++---
 tests/virtio-scsi-test.c   |   5 +-
 21 files changed, 418 insertions(+), 533 deletions(-)

-- 
2.7.4

[Qemu-devel] [PATCH 1/8] libqos: Give qvirtio_config_read*() consistent semantics

[David Gibson]

The 'addr' parameter to qvirtio_config_read*() doesn't have a consistent
meaning: when using the virtio-pci versions, it's a full PCI space address,
but for virtio-mmio, it's an offset from the device's base mmio address.

This means that the callers need to do different things to calculate the
addresses in the two cases, which rather defeats the purpose of function
pointer backends.

All the current users of these functions are using them to retrieve
variables from the device specific portion of the virtio config space.
So, this patch alters the semantics to always be an offset into that
device specific config area.

Signed-off-by: David Gibson 
---
 tests/libqos/virtio-mmio.c | 16 +++
 tests/libqos/virtio-pci.c  | 22 
 tests/virtio-9p-test.c |  9 ++--
 tests/virtio-blk-test.c| 51 ++
 tests/virtio-scsi-test.c   |  5 +
 5 files changed, 35 insertions(+), 68 deletions(-)

diff --git a/tests/libqos/virtio-mmio.c b/tests/libqos/virtio-mmio.c
index 0cab38f..b0b74dc 100644
--- a/tests/libqos/virtio-mmio.c
+++ b/tests/libqos/virtio-mmio.c
@@ -15,28 +15,28 @@
 #include "libqos/malloc-generic.h"
 #include "standard-headers/linux/virtio_ring.h"
 
-static uint8_t qvirtio_mmio_config_readb(QVirtioDevice *d, uint64_t addr)
+static uint8_t qvirtio_mmio_config_readb(QVirtioDevice *d, uint64_t off)
 {
 QVirtioMMIODevice *dev = (QVirtioMMIODevice *)d;
-return readb(dev->addr + addr);
+return readb(dev->addr + QVIRTIO_MMIO_DEVICE_SPECIFIC + off);
 }
 
-static uint16_t qvirtio_mmio_config_readw(QVirtioDevice *d, uint64_t addr)
+static uint16_t qvirtio_mmio_config_readw(QVirtioDevice *d, uint64_t off)
 {
 QVirtioMMIODevice *dev = (QVirtioMMIODevice *)d;
-return readw(dev->addr + addr);
+return readw(dev->addr + QVIRTIO_MMIO_DEVICE_SPECIFIC + off);
 }
 
-static uint32_t qvirtio_mmio_config_readl(QVirtioDevice *d, uint64_t addr)
+static uint32_t qvirtio_mmio_config_readl(QVirtioDevice *d, uint64_t off)
 {
 QVirtioMMIODevice *dev = (QVirtioMMIODevice *)d;
-return readl(dev->addr + addr);
+return readl(dev->addr + QVIRTIO_MMIO_DEVICE_SPECIFIC + off);
 }
 
-static uint64_t qvirtio_mmio_config_readq(QVirtioDevice *d, uint64_t addr)
+static uint64_t qvirtio_mmio_config_readq(QVirtioDevice *d, uint64_t off)
 {
 QVirtioMMIODevice *dev = (QVirtioMMIODevice *)d;
-return readq(dev->addr + addr);
+return readq(dev->addr + QVIRTIO_MMIO_DEVICE_SPECIFIC + off);
 }
 
 static uint32_t qvirtio_mmio_get_features(QVirtioDevice *d)
diff --git a/tests/libqos/virtio-pci.c b/tests/libqos/virtio-pci.c
index 6e005c1..8037724 100644
--- a/tests/libqos/virtio-pci.c
+++ b/tests/libqos/virtio-pci.c
@@ -62,39 +62,43 @@ static void qvirtio_pci_assign_device(QVirtioDevice *d, 
void *data)
 *vpcidev = (QVirtioPCIDevice *)d;
 }
 
-static uint8_t qvirtio_pci_config_readb(QVirtioDevice *d, uint64_t addr)
+static uint8_t qvirtio_pci_config_readb(QVirtioDevice *d, uint64_t off)
 {
 QVirtioPCIDevice *dev = (QVirtioPCIDevice *)d;
-return qpci_io_readb(dev->pdev, (void *)(uintptr_t)addr);
+void *base = dev->addr + VIRTIO_PCI_CONFIG_OFF(dev->pdev->msix_enabled);
+return qpci_io_readb(dev->pdev, base + off);
 }
 
-static uint16_t qvirtio_pci_config_readw(QVirtioDevice *d, uint64_t addr)
+static uint16_t qvirtio_pci_config_readw(QVirtioDevice *d, uint64_t off)
 {
 QVirtioPCIDevice *dev = (QVirtioPCIDevice *)d;
-return qpci_io_readw(dev->pdev, (void *)(uintptr_t)addr);
+void *base = dev->addr + VIRTIO_PCI_CONFIG_OFF(dev->pdev->msix_enabled);
+return qpci_io_readw(dev->pdev, base + off);
 }
 
-static uint32_t qvirtio_pci_config_readl(QVirtioDevice *d, uint64_t addr)
+static uint32_t qvirtio_pci_config_readl(QVirtioDevice *d, uint64_t off)
 {
 QVirtioPCIDevice *dev = (QVirtioPCIDevice *)d;
-return qpci_io_readl(dev->pdev, (void *)(uintptr_t)addr);
+void *base = dev->addr + VIRTIO_PCI_CONFIG_OFF(dev->pdev->msix_enabled);
+return qpci_io_readl(dev->pdev, base + off);
 }
 
-static uint64_t qvirtio_pci_config_readq(QVirtioDevice *d, uint64_t addr)
+static uint64_t qvirtio_pci_config_readq(QVirtioDevice *d, uint64_t off)
 {
 QVirtioPCIDevice *dev = (QVirtioPCIDevice *)d;
 int i;
 uint64_t u64 = 0;
+void *base = dev->addr + VIRTIO_PCI_CONFIG_OFF(dev->pdev->msix_enabled);
 
 if (target_big_endian()) {
 for (i = 0; i < 8; ++i) {
 u64 |= (uint64_t)qpci_io_readb(dev->pdev,
-(void *)(uintptr_t)addr + i) << (7 - i) * 8;
+   base + off + i) << (7 - i) * 8;
 }
 } else {
 for (i = 0; i < 8; ++i) {
 u64 |= (uint64_t)qpci_io_readb(dev->pdev,
-(void *)(uintptr_t)addr + i) << i * 8;
+   base + off + i) << i * 8;
 }
 }
 
diff --git a/tests/virtio-9p-test.c b/tests/virtio-9p-test.c

[Qemu-devel] [PATCH 8/8] libqos: Change PCI accessors to take opaque BAR handle

[David Gibson]

The usual use model for the libqos PCI functions is to map a specific PCI
BAR using qpci_iomap() then pass the returned token into IO accessor
functions.  This, and the fact that iomap() returns a (void *) which
actually contains a PCI space address, kind of suggests that the return
value from iomap is supposed to be an opaque token.

..except that the callers expect to be able to add offsets to it.  Which
also assumes the compiler will support pointer arithmetic on a (void *),
and treat it as working with byte offsets.

To clarify this situation change iomap() and the IO accessors to take
a definitely opaque BAR handle (enforced with a wrapper struct) along with
an offset within the BAR.  This changes both the functions and all the
callers.

A few notes:
* Asserts that iomap() returns non-NULL are removed in some places;
iomap() already asserts if it can't map the BAR
* In ide-test.c we change explicit outb() etc. calls to matching
qpci_io_writeb() calls.  That makes the test more portable, and removes
assumptions that the test case shouldn't be making about how iomap()'s
return value is formatted internally.

Signed-off-by: David Gibson 

# Conflicts:
#   tests/libqos/virtio-pci.c
---
 tests/ahci-test.c |   4 +-
 tests/e1000e-test.c   |   7 ++-
 tests/ide-test.c  |  23 +
 tests/ivshmem-test.c  |  28 +--
 tests/libqos/ahci.c   |   3 +-
 tests/libqos/ahci.h   |   6 +--
 tests/libqos/pci.c| 125 +-
 tests/libqos/pci.h|  39 +--
 tests/libqos/usb.c|   6 +--
 tests/libqos/usb.h|   2 +-
 tests/libqos/virtio-pci.c | 113 +
 tests/libqos/virtio-pci.h |   2 +-
 tests/rtl8139-test.c  |  10 ++--
 tests/usb-hcd-ehci-test.c |   5 +-
 14 files changed, 186 insertions(+), 187 deletions(-)

diff --git a/tests/ahci-test.c b/tests/ahci-test.c
index 9c0adce..4358631 100644
--- a/tests/ahci-test.c
+++ b/tests/ahci-test.c
@@ -90,12 +90,12 @@ static void verify_state(AHCIQState *ahci)
 g_assert_cmphex(ahci_fingerprint, ==, ahci->fingerprint);
 
 /* If we haven't initialized, this is as much as can be validated. */
-if (!ahci->hba_base) {
+if (!ahci->hba_bar.addr) {
 return;
 }
 
 hba_base = (uint64_t)qpci_config_readl(ahci->dev, PCI_BASE_ADDRESS_5);
-hba_stored = (uint64_t)(uintptr_t)ahci->hba_base;
+hba_stored = ahci->hba_bar.addr;
 g_assert_cmphex(hba_base, ==, hba_stored);
 
 g_assert_cmphex(ahci_rreg(ahci, AHCI_CAP), ==, ahci->cap);
diff --git a/tests/e1000e-test.c b/tests/e1000e-test.c
index 3979b20..8c42ca9 100644
--- a/tests/e1000e-test.c
+++ b/tests/e1000e-test.c
@@ -87,7 +87,7 @@
 
 typedef struct e1000e_device {
 QPCIDevice *pci_dev;
-void *mac_regs;
+QPCIBar mac_regs;
 
 uint64_t tx_ring;
 uint64_t rx_ring;
@@ -119,12 +119,12 @@ static QPCIDevice *e1000e_device_find(QPCIBus *bus)
 
 static void e1000e_macreg_write(e1000e_device *d, uint32_t reg, uint32_t val)
 {
-qpci_io_writel(d->pci_dev, d->mac_regs + reg, val);
+qpci_io_writel(d->pci_dev, d->mac_regs, reg, val);
 }
 
 static uint32_t e1000e_macreg_read(e1000e_device *d, uint32_t reg)
 {
-return qpci_io_readl(d->pci_dev, d->mac_regs + reg);
+return qpci_io_readl(d->pci_dev, d->mac_regs, reg);
 }
 
 static void e1000e_device_init(QPCIBus *bus, e1000e_device *d)
@@ -138,7 +138,6 @@ static void e1000e_device_init(QPCIBus *bus, e1000e_device 
*d)
 
 /* Map BAR0 (mac registers) */
 d->mac_regs = qpci_iomap(d->pci_dev, 0, NULL);
-g_assert_nonnull(d->mac_regs);
 
 /* Reset the device */
 val = e1000e_macreg_read(d, E1000E_CTRL);
diff --git a/tests/ide-test.c b/tests/ide-test.c
index a8a4081..dc08536 100644
--- a/tests/ide-test.c
+++ b/tests/ide-test.c
@@ -137,7 +137,7 @@ static void ide_test_quit(void)
 qtest_end();
 }
 
-static QPCIDevice *get_pci_device(uint16_t *bmdma_base)
+static QPCIDevice *get_pci_device(QPCIBar *bmdma_bar)
 {
 QPCIDevice *dev;
 uint16_t vendor_id, device_id;
@@ -156,7 +156,7 @@ static QPCIDevice *get_pci_device(uint16_t *bmdma_base)
 g_assert(device_id == PCI_DEVICE_ID_INTEL_82371SB_1);
 
 /* Map bmdma BAR */
-*bmdma_base = (uint16_t)(uintptr_t) qpci_iomap(dev, 4, NULL);
+*bmdma_bar = qpci_iomap(dev, 4, NULL);
 
 qpci_device_enable(dev);
 
@@ -182,14 +182,14 @@ static int send_dma_request(int cmd, uint64_t sector, int 
nb_sectors,
 void(*post_exec)(uint64_t sector, int nb_sectors))
 {
 QPCIDevice *dev;
-uint16_t bmdma_base;
+QPCIBar bmdma_bar;
 uintptr_t guest_prdt;
 size_t len;
 bool from_dev;
 uint8_t status;
 int flags;
 
-dev = get_pci_device(&bmdma_base);
+dev = get_pci_device(&bmdma_bar);
 
 flags = cmd & ~0xff;
 cmd &= 0xff;
@@ -217,14 +217,14 @@ static int send_dma_request(int cmd, uint64_t sector, int 
nb_sectors,
 outb(IDE_BASE + reg_devi

[Qemu-devel] [PATCH 5/8] libqos: Add streaming accessors for PCI MMIO

[David Gibson]

Currently PCI memory (aka MMIO) space is accessed via a set of readb/writeb
style accessors.  This is what we want for accessing discrete registers of
a certain size.  However, there are a few cases where we instead need a
"bag of bytes" style streaming interface to PCI MMIO space.  This can be
either for streaming data style registers or when there's actual memory
rather than registers in PCI space, for example frame buffers or ivshmem.

This patch adds backend callbacks, and libqos wrappers for this type of
byte address order preserving accesses.

Signed-off-by: David Gibson 
---
 tests/libqos/pci-pc.c| 14 ++
 tests/libqos/pci-spapr.c | 17 +
 tests/libqos/pci.c   | 16 
 tests/libqos/pci.h   |  6 ++
 4 files changed, 53 insertions(+)

diff --git a/tests/libqos/pci-pc.c b/tests/libqos/pci-pc.c
index b087d13..0e95772 100644
--- a/tests/libqos/pci-pc.c
+++ b/tests/libqos/pci-pc.c
@@ -95,6 +95,17 @@ static void qpci_pc_mmio_writel(QPCIBus *bus, uint32_t addr, 
uint32_t val)
 writel(addr, val);
 }
 
+static void qpci_pc_memread(QPCIBus *bus, uint32_t addr, void *buf, size_t len)
+{
+memread(addr, buf, len);
+}
+
+static void qpci_pc_memwrite(QPCIBus *bus, uint32_t addr,
+ const void *buf, size_t len)
+{
+memwrite(addr, buf, len);
+}
+
 static uint8_t qpci_pc_config_readb(QPCIBus *bus, int devfn, uint8_t offset)
 {
 outl(0xcf8, (1U << 31) | (devfn << 8) | offset);
@@ -153,6 +164,9 @@ QPCIBus *qpci_init_pc(QGuestAllocator *alloc)
 ret->bus.mmio_writew = qpci_pc_mmio_writew;
 ret->bus.mmio_writel = qpci_pc_mmio_writel;
 
+ret->bus.memread = qpci_pc_memread;
+ret->bus.memwrite = qpci_pc_memwrite;
+
 ret->bus.config_readb = qpci_pc_config_readb;
 ret->bus.config_readw = qpci_pc_config_readw;
 ret->bus.config_readl = qpci_pc_config_readl;
diff --git a/tests/libqos/pci-spapr.c b/tests/libqos/pci-spapr.c
index 9a18d8a..b4c4b81 100644
--- a/tests/libqos/pci-spapr.c
+++ b/tests/libqos/pci-spapr.c
@@ -122,6 +122,20 @@ static void qpci_spapr_mmio32_writel(QPCIBus *bus, 
uint32_t addr, uint32_t val)
 writel(s->mmio32_cpu_base + addr, bswap32(val));
 }
 
+static void qpci_spapr_memread(QPCIBus *bus, uint32_t addr,
+   void *buf, size_t len)
+{
+QPCIBusSPAPR *s = container_of(bus, QPCIBusSPAPR, bus);
+memread(s->mmio32_cpu_base + addr, buf, len);
+}
+
+static void qpci_spapr_memwrite(QPCIBus *bus, uint32_t addr,
+const void *buf, size_t len)
+{
+QPCIBusSPAPR *s = container_of(bus, QPCIBusSPAPR, bus);
+memwrite(s->mmio32_cpu_base + addr, buf, len);
+}
+
 static uint8_t qpci_spapr_config_readb(QPCIBus *bus, int devfn, uint8_t offset)
 {
 QPCIBusSPAPR *s = container_of(bus, QPCIBusSPAPR, bus);
@@ -196,6 +210,9 @@ QPCIBus *qpci_init_spapr(QGuestAllocator *alloc)
 ret->bus.mmio_writew = qpci_spapr_mmio32_writew;
 ret->bus.mmio_writel = qpci_spapr_mmio32_writel;
 
+ret->bus.memread = qpci_spapr_memread;
+ret->bus.memwrite = qpci_spapr_memwrite;
+
 ret->bus.config_readb = qpci_spapr_config_readb;
 ret->bus.config_readw = qpci_spapr_config_readw;
 ret->bus.config_readl = qpci_spapr_config_readl;
diff --git a/tests/libqos/pci.c b/tests/libqos/pci.c
index bf1c532..1e242f9 100644
--- a/tests/libqos/pci.c
+++ b/tests/libqos/pci.c
@@ -289,6 +289,22 @@ void qpci_io_writel(QPCIDevice *dev, void *data, uint32_t 
value)
 }
 }
 
+void qpci_memread(QPCIDevice *dev, void *data, void *buf, size_t len)
+{
+uintptr_t addr = (uintptr_t)data;
+
+g_assert(addr >= QPCI_PIO_LIMIT);
+dev->bus->memread(dev->bus, addr, buf, len);
+}
+
+void qpci_memwrite(QPCIDevice *dev, void *data, const void *buf, size_t len)
+{
+uintptr_t addr = (uintptr_t)data;
+
+g_assert(addr >= QPCI_PIO_LIMIT);
+dev->bus->memwrite(dev->bus, addr, buf, len);
+}
+
 void *qpci_iomap(QPCIDevice *dev, int barno, uint64_t *sizeptr)
 {
 QPCIBus *bus = dev->bus;
diff --git a/tests/libqos/pci.h b/tests/libqos/pci.h
index f6f916d..2fa5b4f 100644
--- a/tests/libqos/pci.h
+++ b/tests/libqos/pci.h
@@ -39,6 +39,9 @@ struct QPCIBus {
 void (*mmio_writew)(QPCIBus *bus, uint32_t addr, uint16_t value);
 void (*mmio_writel)(QPCIBus *bus, uint32_t addr, uint32_t value);
 
+void (*memread)(QPCIBus *bus, uint32_t addr, void *buf, size_t len);
+void (*memwrite)(QPCIBus *bus, uint32_t addr, const void *buf, size_t len);
+
 uint8_t (*config_readb)(QPCIBus *bus, int devfn, uint8_t offset);
 uint16_t (*config_readw)(QPCIBus *bus, int devfn, uint8_t offset);
 uint32_t (*config_readl)(QPCIBus *bus, int devfn, uint8_t offset);
@@ -92,6 +95,9 @@ void qpci_io_writeb(QPCIDevice *dev, void *data, uint8_t 
value);
 void qpci_io_writew(QPCIDevice *dev, void *data, uint16_t value);
 void qpci_io_writel(QPCIDevice *dev, void *data, uint32_t value);
 
+void qpci_memread(QPCIDevice *bus, void *data, void *buf, size_t len);

[Qemu-devel] [PATCH 3/8] libqos: Move BAR assignment to common code

[David Gibson]

The PCI backends in libqos each supply an iomap() and iounmap() function
which is used to set up a specified PCI BAR.  But PCI BAR allocation takes
place entirely within PCI space, so doesn't really need per-backend
versions.  For example, Linux includes generic BAR allocation code used on
platforms where that isn't done by firmware.

This patch merges the BAR allocation from the two existing backends into a
single simplified copy.  The back ends just need to set up some parameters
describing the window of PCI IO and PCI memory addresses which are
available for allocation.  Like both the existing versions the new one uses
a simple bump allocator.

Note that (again like the existing versions) this doesn't really handle
64-bit memory BARs properly.  It is actually used for such a BAR by the
ivshmem test, and apparently the 32-bit MMIO BAR logic is close enough to
work, as long as the BAR isn't too big.  Fixing that to properly handle
64-bit BAR allocation is a problem for another time.

Signed-off-by: David Gibson 
---
 tests/libqos/pci-pc.c| 79 ++
 tests/libqos/pci-spapr.c | 81 ++--
 tests/libqos/pci.c   | 56 +++--
 tests/libqos/pci.h   |  7 ++---
 4 files changed, 63 insertions(+), 160 deletions(-)

diff --git a/tests/libqos/pci-pc.c b/tests/libqos/pci-pc.c
index 51dff8a..b087d13 100644
--- a/tests/libqos/pci-pc.c
+++ b/tests/libqos/pci-pc.c
@@ -17,7 +17,6 @@
 #include "hw/pci/pci_regs.h"
 
 #include "qemu-common.h"
-#include "qemu/host-utils.h"
 
 
 #define ACPI_PCIHP_ADDR 0xae00
@@ -132,71 +131,6 @@ static void qpci_pc_config_writel(QPCIBus *bus, int devfn, 
uint8_t offset, uint3
 outl(0xcfc, value);
 }
 
-static void *qpci_pc_iomap(QPCIBus *bus, QPCIDevice *dev, int barno, uint64_t 
*sizeptr)
-{
-QPCIBusPC *s = container_of(bus, QPCIBusPC, bus);
-static const int bar_reg_map[] = {
-PCI_BASE_ADDRESS_0, PCI_BASE_ADDRESS_1, PCI_BASE_ADDRESS_2,
-PCI_BASE_ADDRESS_3, PCI_BASE_ADDRESS_4, PCI_BASE_ADDRESS_5,
-};
-int bar_reg;
-uint32_t addr;
-uint64_t size;
-uint32_t io_type;
-
-g_assert(barno >= 0 && barno <= 5);
-bar_reg = bar_reg_map[barno];
-
-qpci_config_writel(dev, bar_reg, 0x);
-addr = qpci_config_readl(dev, bar_reg);
-
-io_type = addr & PCI_BASE_ADDRESS_SPACE;
-if (io_type == PCI_BASE_ADDRESS_SPACE_IO) {
-addr &= PCI_BASE_ADDRESS_IO_MASK;
-} else {
-addr &= PCI_BASE_ADDRESS_MEM_MASK;
-}
-
-size = (1ULL << ctzl(addr));
-if (size == 0) {
-return NULL;
-}
-if (sizeptr) {
-*sizeptr = size;
-}
-
-if (io_type == PCI_BASE_ADDRESS_SPACE_IO) {
-uint16_t loc;
-
-g_assert(QEMU_ALIGN_UP(s->pci_iohole_alloc, size) + size
- <= s->pci_iohole_size);
-s->pci_iohole_alloc = QEMU_ALIGN_UP(s->pci_iohole_alloc, size);
-loc = s->pci_iohole_start + s->pci_iohole_alloc;
-s->pci_iohole_alloc += size;
-
-qpci_config_writel(dev, bar_reg, loc | PCI_BASE_ADDRESS_SPACE_IO);
-
-return (void *)(intptr_t)loc;
-} else {
-uint64_t loc;
-
-g_assert(QEMU_ALIGN_UP(s->pci_hole_alloc, size) + size
- <= s->pci_hole_size);
-s->pci_hole_alloc = QEMU_ALIGN_UP(s->pci_hole_alloc, size);
-loc = s->pci_hole_start + s->pci_hole_alloc;
-s->pci_hole_alloc += size;
-
-qpci_config_writel(dev, bar_reg, loc);
-
-return (void *)(intptr_t)loc;
-}
-}
-
-static void qpci_pc_iounmap(QPCIBus *bus, void *data)
-{
-/* FIXME */
-}
-
 QPCIBus *qpci_init_pc(QGuestAllocator *alloc)
 {
 QPCIBusPC *ret;
@@ -227,16 +161,9 @@ QPCIBus *qpci_init_pc(QGuestAllocator *alloc)
 ret->bus.config_writew = qpci_pc_config_writew;
 ret->bus.config_writel = qpci_pc_config_writel;
 
-ret->bus.iomap = qpci_pc_iomap;
-ret->bus.iounmap = qpci_pc_iounmap;
-
-ret->pci_hole_start = 0xE000;
-ret->pci_hole_size = 0x2000;
-ret->pci_hole_alloc = 0;
-
-ret->pci_iohole_start = 0xc000;
-ret->pci_iohole_size = 0x4000;
-ret->pci_iohole_alloc = 0;
+ret->bus.pio_alloc_ptr = 0xc000;
+ret->bus.mmio_alloc_ptr = 0xE000;
+ret->bus.mmio_limit = 0x1ULL;
 
 return &ret->bus;
 }
diff --git a/tests/libqos/pci-spapr.c b/tests/libqos/pci-spapr.c
index 2d26a94..9a18d8a 100644
--- a/tests/libqos/pci-spapr.c
+++ b/tests/libqos/pci-spapr.c
@@ -167,72 +167,6 @@ static void qpci_spapr_config_writel(QPCIBus *bus, int 
devfn, uint8_t offset,
 qrtas_ibm_write_pci_config(s->alloc, s->buid, config_addr, 4, value);
 }
 
-static void *qpci_spapr_iomap(QPCIBus *bus, QPCIDevice *dev, int barno,
-  uint64_t *sizeptr)
-{
-QPCIBusSPAPR *s = container_of(bus, QPCIBusSPAPR, bus);
-static const int bar_reg_map[] = {
-PCI_BASE_ADDRESS_0, PCI_BASE_ADDRESS_1, PCI_BASE_ADDRESS_2,
- 

[Qemu-devel] [PATCH 2/8] libqos: Handle PCI IO de-multiplexing in common code

[David Gibson]

The PCI IO space (aka PIO, aka legacy IO) and PCI memory space (aka MMIO)
are distinct address spaces by the PCI spec (although parts of one might be
aliased to parts of the other in some cases).

However, qpci_io_read*() and qpci_io_write*() can perform accesses to
either space depending on parameter.  That's convenient for test case
drivers, since there are a fair few devices which can be controlled via
either a PIO or MMIO BAR but with an otherwise identical driver.

This is implemented by having addresses below 64kiB treated as PIO, and
those above treated as MMIO.  This works because low addresses in memory
space are generally reserved for DMA rather than MMIO.

At the moment, this demultiplexing must be handled by each PCI backend
(pc and spapr, so far).  There's no real reason for this - the current
encoding is likely to work for all platforms, and even if it doesn't we
can still use a more complex common encoding since the value returned from
iomap are semi-opaque.

This patch moves the demultiplexing into the common part of the libqos PCI
code, with the backends having simpler, separate accessors for PIO and
MMIO space.  This also means we have a way of explicitly accessing either
space if it's necessary for some special case.

Signed-off-by: David Gibson 
---
 tests/libqos/pci-pc.c| 107 --
 tests/libqos/pci-spapr.c | 118 +--
 tests/libqos/pci.c   |  49 +---
 tests/libqos/pci.h   |  22 ++---
 4 files changed, 170 insertions(+), 126 deletions(-)

diff --git a/tests/libqos/pci-pc.c b/tests/libqos/pci-pc.c
index 9600ed6..51dff8a 100644
--- a/tests/libqos/pci-pc.c
+++ b/tests/libqos/pci-pc.c
@@ -36,79 +36,64 @@ typedef struct QPCIBusPC
 uint16_t pci_iohole_alloc;
 } QPCIBusPC;
 
-static uint8_t qpci_pc_io_readb(QPCIBus *bus, void *addr)
+static uint8_t qpci_pc_pio_readb(QPCIBus *bus, uint32_t addr)
 {
-uintptr_t port = (uintptr_t)addr;
-uint8_t value;
-
-if (port < 0x1) {
-value = inb(port);
-} else {
-value = readb(port);
-}
-
-return value;
+return inb(addr);
 }
 
-static uint16_t qpci_pc_io_readw(QPCIBus *bus, void *addr)
+static uint8_t qpci_pc_mmio_readb(QPCIBus *bus, uint32_t addr)
 {
-uintptr_t port = (uintptr_t)addr;
-uint16_t value;
-
-if (port < 0x1) {
-value = inw(port);
-} else {
-value = readw(port);
-}
+return readb(addr);
+}
 
-return value;
+static void qpci_pc_pio_writeb(QPCIBus *bus, uint32_t addr, uint8_t val)
+{
+outb(addr, val);
 }
 
-static uint32_t qpci_pc_io_readl(QPCIBus *bus, void *addr)
+static void qpci_pc_mmio_writeb(QPCIBus *bus, uint32_t addr, uint8_t val)
 {
-uintptr_t port = (uintptr_t)addr;
-uint32_t value;
+writeb(addr, val);
+}
 
-if (port < 0x1) {
-value = inl(port);
-} else {
-value = readl(port);
-}
+static uint16_t qpci_pc_pio_readw(QPCIBus *bus, uint32_t addr)
+{
+return inw(addr);
+}
 
-return value;
+static uint16_t qpci_pc_mmio_readw(QPCIBus *bus, uint32_t addr)
+{
+return readw(addr);
 }
 
-static void qpci_pc_io_writeb(QPCIBus *bus, void *addr, uint8_t value)
+static void qpci_pc_pio_writew(QPCIBus *bus, uint32_t addr, uint16_t val)
 {
-uintptr_t port = (uintptr_t)addr;
+outw(addr, val);
+}
 
-if (port < 0x1) {
-outb(port, value);
-} else {
-writeb(port, value);
-}
+static void qpci_pc_mmio_writew(QPCIBus *bus, uint32_t addr, uint16_t val)
+{
+writew(addr, val);
 }
 
-static void qpci_pc_io_writew(QPCIBus *bus, void *addr, uint16_t value)
+static uint32_t qpci_pc_pio_readl(QPCIBus *bus, uint32_t addr)
 {
-uintptr_t port = (uintptr_t)addr;
+return inl(addr);
+}
 
-if (port < 0x1) {
-outw(port, value);
-} else {
-writew(port, value);
-}
+static uint32_t qpci_pc_mmio_readl(QPCIBus *bus, uint32_t addr)
+{
+return readl(addr);
 }
 
-static void qpci_pc_io_writel(QPCIBus *bus, void *addr, uint32_t value)
+static void qpci_pc_pio_writel(QPCIBus *bus, uint32_t addr, uint32_t val)
 {
-uintptr_t port = (uintptr_t)addr;
+outl(addr, val);
+}
 
-if (port < 0x1) {
-outl(port, value);
-} else {
-writel(port, value);
-}
+static void qpci_pc_mmio_writel(QPCIBus *bus, uint32_t addr, uint32_t val)
+{
+writel(addr, val);
 }
 
 static uint8_t qpci_pc_config_readb(QPCIBus *bus, int devfn, uint8_t offset)
@@ -218,13 +203,21 @@ QPCIBus *qpci_init_pc(QGuestAllocator *alloc)
 
 ret = g_malloc(sizeof(*ret));
 
-ret->bus.io_readb = qpci_pc_io_readb;
-ret->bus.io_readw = qpci_pc_io_readw;
-ret->bus.io_readl = qpci_pc_io_readl;
+ret->bus.pio_readb = qpci_pc_pio_readb;
+ret->bus.pio_readw = qpci_pc_pio_readw;
+ret->bus.pio_readl = qpci_pc_pio_readl;
+
+ret->bus.pio_writeb = qpci_pc_pio_writeb;
+ret->bus.pio_writew = qpci_pc_pio_writew;
+ret->bus.p

[Qemu-devel] [PATCH 4/8] tests: Better handle legacy IO addresses in tco-test

[David Gibson]

tco_test uses the libqos PCI code to access the device.  This makes perfect
sense for the PCI config space accesses.  However for IO, rather than the
usual PCI approach of mapping a PCI BAR, then accessing that, it instead
uses the legacy approach of fixed, known addresses in PCI IO space.

That doesn't work very well with the qpci_io_{read,write} functions because
we never use qpci_iomap() and so have to make assumptions about the
internal encoding of the address tokens iomap() returns.

This patch avoids that, by directly using the bus's pio_{read,write}
callbacks, which are defined to take addresses within the PCI IO space.

Signed-off-by: David Gibson 
---
 tests/tco-test.c | 87 
 1 file changed, 44 insertions(+), 43 deletions(-)

diff --git a/tests/tco-test.c b/tests/tco-test.c
index 0d201b1..e668630 100644
--- a/tests/tco-test.c
+++ b/tests/tco-test.c
@@ -40,13 +40,13 @@ enum {
 typedef struct {
 const char *args;
 bool noreboot;
+QPCIBus *bus;
 QPCIDevice *dev;
-void *tco_io_base;
+uint16_t tco_io_base;
 } TestData;
 
 static void test_init(TestData *d)
 {
-QPCIBus *bus;
 QTestState *qs;
 char *s;
 
@@ -57,8 +57,8 @@ static void test_init(TestData *d)
 qtest_irq_intercept_in(qs, "ioapic");
 g_free(s);
 
-bus = qpci_init_pc(NULL);
-d->dev = qpci_device_find(bus, QPCI_DEVFN(0x1f, 0x00));
+d->bus = qpci_init_pc(NULL);
+d->dev = qpci_device_find(d->bus, QPCI_DEVFN(0x1f, 0x00));
 g_assert(d->dev != NULL);
 
 qpci_device_enable(d->dev);
@@ -70,42 +70,42 @@ static void test_init(TestData *d)
 /* set Root Complex BAR */
 qpci_config_writel(d->dev, ICH9_LPC_RCBA, RCBA_BASE_ADDR | 0x1);
 
-d->tco_io_base = (void *)((uintptr_t)PM_IO_BASE_ADDR + 0x60);
+d->tco_io_base = PM_IO_BASE_ADDR + 0x60;
 }
 
 static void stop_tco(const TestData *d)
 {
 uint32_t val;
 
-val = qpci_io_readw(d->dev, d->tco_io_base + TCO1_CNT);
+val = d->bus->pio_readw(d->bus, d->tco_io_base + TCO1_CNT);
 val |= TCO_TMR_HLT;
-qpci_io_writew(d->dev, d->tco_io_base + TCO1_CNT, val);
+d->bus->pio_writew(d->bus, d->tco_io_base + TCO1_CNT, val);
 }
 
 static void start_tco(const TestData *d)
 {
 uint32_t val;
 
-val = qpci_io_readw(d->dev, d->tco_io_base + TCO1_CNT);
+val = d->bus->pio_readw(d->bus, d->tco_io_base + TCO1_CNT);
 val &= ~TCO_TMR_HLT;
-qpci_io_writew(d->dev, d->tco_io_base + TCO1_CNT, val);
+d->bus->pio_writew(d->bus, d->tco_io_base + TCO1_CNT, val);
 }
 
 static void load_tco(const TestData *d)
 {
-qpci_io_writew(d->dev, d->tco_io_base + TCO_RLD, 4);
+d->bus->pio_writew(d->bus, d->tco_io_base + TCO_RLD, 4);
 }
 
 static void set_tco_timeout(const TestData *d, uint16_t ticks)
 {
-qpci_io_writew(d->dev, d->tco_io_base + TCO_TMR, ticks);
+d->bus->pio_writew(d->bus, d->tco_io_base + TCO_TMR, ticks);
 }
 
 static void clear_tco_status(const TestData *d)
 {
-qpci_io_writew(d->dev, d->tco_io_base + TCO1_STS, 0x0008);
-qpci_io_writew(d->dev, d->tco_io_base + TCO2_STS, 0x0002);
-qpci_io_writew(d->dev, d->tco_io_base + TCO2_STS, 0x0004);
+d->bus->pio_writew(d->bus, d->tco_io_base + TCO1_STS, 0x0008);
+d->bus->pio_writew(d->bus, d->tco_io_base + TCO2_STS, 0x0002);
+d->bus->pio_writew(d->bus, d->tco_io_base + TCO2_STS, 0x0004);
 }
 
 static void reset_on_second_timeout(bool enable)
@@ -128,25 +128,25 @@ static void test_tco_defaults(void)
 d.args = NULL;
 d.noreboot = true;
 test_init(&d);
-g_assert_cmpint(qpci_io_readw(d.dev, d.tco_io_base + TCO_RLD), ==,
+g_assert_cmpint(d.bus->pio_readw(d.bus, d.tco_io_base + TCO_RLD), ==,
 TCO_RLD_DEFAULT);
 /* TCO_DAT_IN & TCO_DAT_OUT */
-g_assert_cmpint(qpci_io_readw(d.dev, d.tco_io_base + TCO_DAT_IN), ==,
+g_assert_cmpint(d.bus->pio_readw(d.bus, d.tco_io_base + TCO_DAT_IN), ==,
 (TCO_DAT_OUT_DEFAULT << 8) | TCO_DAT_IN_DEFAULT);
 /* TCO1_STS & TCO2_STS */
-g_assert_cmpint(qpci_io_readl(d.dev, d.tco_io_base + TCO1_STS), ==,
+g_assert_cmpint(d.bus->pio_readl(d.bus, d.tco_io_base + TCO1_STS), ==,
 (TCO2_STS_DEFAULT << 16) | TCO1_STS_DEFAULT);
 /* TCO1_CNT & TCO2_CNT */
-g_assert_cmpint(qpci_io_readl(d.dev, d.tco_io_base + TCO1_CNT), ==,
+g_assert_cmpint(d.bus->pio_readl(d.bus, d.tco_io_base + TCO1_CNT), ==,
 (TCO2_CNT_DEFAULT << 16) | TCO1_CNT_DEFAULT);
 /* TCO_MESSAGE1 & TCO_MESSAGE2 */
-g_assert_cmpint(qpci_io_readw(d.dev, d.tco_io_base + TCO_MESSAGE1), ==,
+g_assert_cmpint(d.bus->pio_readw(d.bus, d.tco_io_base + TCO_MESSAGE1), ==,
 (TCO_MESSAGE2_DEFAULT << 8) | TCO_MESSAGE1_DEFAULT);
-g_assert_cmpint(qpci_io_readb(d.dev, d.tco_io_base + TCO_WDCNT), ==,
+g_assert_cmpint(d.bus->pio_readb(d.bus, d.tco_io_base + TCO_WDCNT), ==,
 TCO_WDCNT_DEFAULT);
-g_assert_cmpint(qpci_io_readb(d.dev, d.

[Qemu-devel] [PATCH 0/4] remove unused VMSTateField.start

[Halil Pasic]

The member VMStateField.start was solely used to implement the partial
data migration for VBUFFER data (basically provide migration for a
sub-buffer). However the implementation of this feature is broken, but
this goes unnoticed since the feature is not used at all.

So what the series does is first add some tests for VBUFFER, then add a
test which proves that the VMS_ALLOC and used together with .start != 0
is broken.  Then we immediately revert this last patch since we are
going to drop it instead of fixing it.  Lastly simplify things by
dropping VMStateField.start altogether.

An additional benefit is that .start can be re introduced to be used for
linked structures as proposed by Jianjun in "[QEMU PATCH v6 2/2]
migration: migrate QTAILQ".

Guenther Hutzl (1):
  tests/test-vmstate.c: Add vBuffer test

Halil Pasic (3):
  tests/test-vmstate.c: prove VMStateField.start broken
  Revert "tests/test-vmstate.c: prove VMStateField.start broken"
  migration: drop unused VMStateField.start

 hw/char/exynos4210_uart.c   |   2 +-
 hw/display/g364fb.c |   2 +-
 hw/dma/pl330.c  |   8 +--
 hw/intc/exynos4210_gic.c|   2 +-
 hw/ipmi/isa_ipmi_bt.c   |   4 +-
 hw/ipmi/isa_ipmi_kcs.c  |   4 +-
 hw/net/vmxnet3.c|   2 +-
 hw/nvram/mac_nvram.c|   2 +-
 hw/nvram/spapr_nvram.c  |   2 +-
 hw/sd/sdhci.c   |   2 +-
 hw/timer/m48t59.c   |   2 +-
 include/migration/vmstate.h |  20 +++-
 migration/savevm.c  |   2 +-
 migration/vmstate.c |   4 +-
 target-s390x/machine.c  |   2 +-
 tests/test-vmstate.c| 115 +++-
 util/fifo8.c|   2 +-
 17 files changed, 141 insertions(+), 36 deletions(-)

-- 
2.8.4

[Qemu-devel] [PATCH 3/4] Revert "tests/test-vmstate.c: prove VMStateField.start broken"

[Halil Pasic]

This reverts the effect of the previous patch in the series as
a preparation for getting rid of VMStateField.start.

Signed-off-by: Halil Pasic 
Reviewed-by: Guenther Hutzl 
---
 tests/test-vmstate.c | 48 
 1 file changed, 48 deletions(-)

diff --git a/tests/test-vmstate.c b/tests/test-vmstate.c
index a2ef4a8..4ea64b7 100644
--- a/tests/test-vmstate.c
+++ b/tests/test-vmstate.c
@@ -588,53 +588,6 @@ static void test_complex_vbuffer(void)
 #undef FIELD_EQUAL
 #undef BUFFER_EQUAL
 
-typedef struct {
-uint32_t vbuff_size;
-uint8_t *vbuff;
-uint64_t stuff;
-} TestVBufStart;
-
-static const VMStateDescription vmstate_vbuff_alloc_start = {
-.name = "test/vbuff_alloc_start",
-.version_id = 1,
-.minimum_version_id = 1,
-.fields = (VMStateField[]) {
-VMSTATE_UINT64(stuff, TestVBufStart),
-VMSTATE_UINT32(vbuff_size, TestVBufStart),
-VMSTATE_VBUFFER_ALLOC_UINT32(vbuff, TestVBufStart, 1, 0, 1, 
vbuff_size),
-VMSTATE_END_OF_LIST()
-}
-
-};
-
-static void load_vmstate_one_obj(const VMStateDescription *vmsd, void *obj,
-int version_id)
-{
-QEMUFile *fload = open_test_file(false);
-
-SUCCESS(vmstate_load_state(fload, vmsd, obj, version_id));
-qemu_fclose(fload);
-}
-
-static void test_vbuff_alloc_start(void)
-{
-uint8_t my_vbuff1[] = {0, 1, 2, 3};
-uint8_t my_vbuff2[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
-TestVBufStart sample = {
-.stuff = 1,
-.vbuff_size = 3,
-.vbuff = my_vbuff1,
-};
-TestVBufStart load_obj = {
-.vbuff = my_vbuff2,
-};
-
-save_vmstate(&vmstate_vbuff_alloc_start, &sample);
-load_vmstate_one_obj(&vmstate_vbuff_alloc_start, &load_obj, 1);
-g_assert_cmpint(load_obj.stuff, ==, 0);
-g_assert_cmpint((uint64_t) load_obj.vbuff, !=, (uint64_t) my_vbuff2);
-}
-
 int main(int argc, char **argv)
 {
 temp_fd = mkstemp(temp_file);
@@ -650,7 +603,6 @@ int main(int argc, char **argv)
 g_test_add_func("/vmstate/field_exists/save/noskip", test_save_noskip);
 g_test_add_func("/vmstate/field_exists/save/skip", test_save_skip);
 g_test_add_func("/vmstate/complex/vbuffer", test_complex_vbuffer);
-g_test_add_func("/vmstate/vbuff/alloc_start", test_vbuff_alloc_start);
 g_test_run();
 close(temp_fd);
 unlink(temp_file);
-- 
2.8.4

[Qemu-devel] [PATCH 4/4] migration: drop unused VMStateField.start

[Halil Pasic]

The member VMStateField.start was solely used to implement the partial
data migration for VBUFFER data (basically provide migration for a
sub-buffer). However the implementation of this feature seems broken to
me, but this goes unnoticed since the feature is not used at all.
Instead of fixing it lets try simplify things by dropping it.

Signed-off-by: Halil Pasic 
Reviewed-by: Guenther Hutzl 
---
 hw/char/exynos4210_uart.c   |  2 +-
 hw/display/g364fb.c |  2 +-
 hw/dma/pl330.c  |  8 
 hw/intc/exynos4210_gic.c|  2 +-
 hw/ipmi/isa_ipmi_bt.c   |  4 ++--
 hw/ipmi/isa_ipmi_kcs.c  |  4 ++--
 hw/net/vmxnet3.c|  2 +-
 hw/nvram/mac_nvram.c|  2 +-
 hw/nvram/spapr_nvram.c  |  2 +-
 hw/sd/sdhci.c   |  2 +-
 hw/timer/m48t59.c   |  2 +-
 include/migration/vmstate.h | 20 ++--
 migration/savevm.c  |  2 +-
 migration/vmstate.c |  4 ++--
 target-s390x/machine.c  |  2 +-
 tests/test-vmstate.c|  4 ++--
 util/fifo8.c|  2 +-
 17 files changed, 29 insertions(+), 37 deletions(-)

diff --git a/hw/char/exynos4210_uart.c b/hw/char/exynos4210_uart.c
index 1107578..7b1b4b1 100644
--- a/hw/char/exynos4210_uart.c
+++ b/hw/char/exynos4210_uart.c
@@ -565,7 +565,7 @@ static const VMStateDescription 
vmstate_exynos4210_uart_fifo = {
 .fields = (VMStateField[]) {
 VMSTATE_UINT32(sp, Exynos4210UartFIFO),
 VMSTATE_UINT32(rp, Exynos4210UartFIFO),
-VMSTATE_VBUFFER_UINT32(data, Exynos4210UartFIFO, 1, NULL, 0, size),
+VMSTATE_VBUFFER_UINT32(data, Exynos4210UartFIFO, 1, NULL, size),
 VMSTATE_END_OF_LIST()
 }
 };
diff --git a/hw/display/g364fb.c b/hw/display/g364fb.c
index 70ef2c7..8cdc205 100644
--- a/hw/display/g364fb.c
+++ b/hw/display/g364fb.c
@@ -464,7 +464,7 @@ static const VMStateDescription vmstate_g364fb = {
 .minimum_version_id = 1,
 .post_load = g364fb_post_load,
 .fields = (VMStateField[]) {
-VMSTATE_VBUFFER_UINT32(vram, G364State, 1, NULL, 0, vram_size),
+VMSTATE_VBUFFER_UINT32(vram, G364State, 1, NULL, vram_size),
 VMSTATE_BUFFER_UNSAFE(color_palette, G364State, 0, 256 * 3),
 VMSTATE_BUFFER_UNSAFE(cursor_palette, G364State, 0, 9),
 VMSTATE_UINT16_ARRAY(cursor, G364State, 512),
diff --git a/hw/dma/pl330.c b/hw/dma/pl330.c
index c0bd9fe..32cf839 100644
--- a/hw/dma/pl330.c
+++ b/hw/dma/pl330.c
@@ -173,8 +173,8 @@ static const VMStateDescription vmstate_pl330_fifo = {
 .version_id = 1,
 .minimum_version_id = 1,
 .fields = (VMStateField[]) {
-VMSTATE_VBUFFER_UINT32(buf, PL330Fifo, 1, NULL, 0, buf_size),
-VMSTATE_VBUFFER_UINT32(tag, PL330Fifo, 1, NULL, 0, buf_size),
+VMSTATE_VBUFFER_UINT32(buf, PL330Fifo, 1, NULL, buf_size),
+VMSTATE_VBUFFER_UINT32(tag, PL330Fifo, 1, NULL, buf_size),
 VMSTATE_UINT32(head, PL330Fifo),
 VMSTATE_UINT32(num, PL330Fifo),
 VMSTATE_UINT32(buf_size, PL330Fifo),
@@ -282,8 +282,8 @@ static const VMStateDescription vmstate_pl330 = {
 VMSTATE_STRUCT(manager, PL330State, 0, vmstate_pl330_chan, PL330Chan),
 VMSTATE_STRUCT_VARRAY_UINT32(chan, PL330State, num_chnls, 0,
  vmstate_pl330_chan, PL330Chan),
-VMSTATE_VBUFFER_UINT32(lo_seqn, PL330State, 1, NULL, 0, num_chnls),
-VMSTATE_VBUFFER_UINT32(hi_seqn, PL330State, 1, NULL, 0, num_chnls),
+VMSTATE_VBUFFER_UINT32(lo_seqn, PL330State, 1, NULL, num_chnls),
+VMSTATE_VBUFFER_UINT32(hi_seqn, PL330State, 1, NULL, num_chnls),
 VMSTATE_STRUCT(fifo, PL330State, 0, vmstate_pl330_fifo, PL330Fifo),
 VMSTATE_STRUCT(read_queue, PL330State, 0, vmstate_pl330_queue,
PL330Queue),
diff --git a/hw/intc/exynos4210_gic.c b/hw/intc/exynos4210_gic.c
index fd7a8f3..2a55817 100644
--- a/hw/intc/exynos4210_gic.c
+++ b/hw/intc/exynos4210_gic.c
@@ -393,7 +393,7 @@ static const VMStateDescription vmstate_exynos4210_irq_gate 
= {
 .version_id = 2,
 .minimum_version_id = 2,
 .fields = (VMStateField[]) {
-VMSTATE_VBUFFER_UINT32(level, Exynos4210IRQGateState, 1, NULL, 0, 
n_in),
+VMSTATE_VBUFFER_UINT32(level, Exynos4210IRQGateState, 1, NULL, n_in),
 VMSTATE_END_OF_LIST()
 }
 };
diff --git a/hw/ipmi/isa_ipmi_bt.c b/hw/ipmi/isa_ipmi_bt.c
index f036617..6c10ef7 100644
--- a/hw/ipmi/isa_ipmi_bt.c
+++ b/hw/ipmi/isa_ipmi_bt.c
@@ -471,9 +471,9 @@ static const VMStateDescription vmstate_ISAIPMIBTDevice = {
 VMSTATE_BOOL(bt.use_irq, ISAIPMIBTDevice),
 VMSTATE_BOOL(bt.irqs_enabled, ISAIPMIBTDevice),
 VMSTATE_UINT32(bt.outpos, ISAIPMIBTDevice),
-VMSTATE_VBUFFER_UINT32(bt.outmsg, ISAIPMIBTDevice, 1, NULL, 0,
+VMSTATE_VBUFFER_UINT32(bt.outmsg, ISAIPMIBTDevice, 1, NULL,
bt.outlen),
-VMSTATE_VBUFFER_UINT32(bt.inmsg, ISAIPMIBTDevice, 1, NULL, 0,
+VMSTATE_VBUFFER_UINT32(b

[Qemu-devel] [PATCH 1/4] tests/test-vmstate.c: Add vBuffer test

[Halil Pasic]

From: Guenther Hutzl 

The unit test test-vmstate.c is missing tests for some of the complex
vmstate macros. This patch adds a new test for VMSTATE_VBUFFER
and VMSTATE_VBUFFER_ALLOC_UINT32. The added test does not cover
start != 0 because it's broken and unused so our intention is to
remove start altogether.

Signed-off-by: Guenther Hutzl 
Signed-off-by: Halil Pasic 
---

A proof for the brokenness of start is provided in a separate patch
so it can be easily reverted or not picked (thus we separate what is
intended to stay, and what is intended to go away).
---
 tests/test-vmstate.c | 114 +++
 1 file changed, 114 insertions(+)

diff --git a/tests/test-vmstate.c b/tests/test-vmstate.c
index d8da26f..9a57aa0 100644
--- a/tests/test-vmstate.c
+++ b/tests/test-vmstate.c
@@ -475,6 +475,119 @@ static void test_load_skip(void)
 qemu_fclose(loading);
 }
 
+/* vBuffer tests */
+#define BUF_SIZE 10
+
+typedef struct TestVBuffer {
+uint8_t  u8_1;
+int32_t  buffer_size;
+uint8_t  *vBuffer_1;
+uint32_t buffer_alloc_size;
+uint8_t  *vBuffer_alloc_1;
+uint8_t  u8_2;
+} TestVBuffer;
+
+/* buffers padded with 0xFE at the end to easier detect overflow */
+uint8_t buf1[BUF_SIZE + 1] = { 1,  2,  3,  4,  5,  6,  7,  8,  9,  0, 0xfe};
+uint8_t buf2[BUF_SIZE + 1] = { 1,  2,  3,  4,  5,  6,  7,  8,  9,  0, 0xfe};
+
+TestVBuffer obj_vbuffer = {
+.u8_1 = 100,
+.buffer_size = BUF_SIZE,
+.vBuffer_1 = buf1,
+.buffer_alloc_size = BUF_SIZE,
+.vBuffer_alloc_1 = buf2,
+.u8_2 = 200,
+};
+
+static const VMStateDescription vmstate_vbuffer = {
+.name = "complex/vbuffer",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT8(u8_1, TestVBuffer),
+VMSTATE_VBUFFER(vBuffer_1, TestVBuffer, 1, NULL, 0,
+buffer_size),
+VMSTATE_VBUFFER_ALLOC_UINT32(vBuffer_alloc_1, TestVBuffer, 1, NULL, 0,
+buffer_alloc_size),
+VMSTATE_UINT8(u8_2, TestVBuffer),
+VMSTATE_END_OF_LIST()
+}
+};
+
+uint8_t wire_vbuffer[] = {
+/* u8_1 */0x64,
+/* vBuffer_1 */   0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09,
+  0x00,
+/* vBuffer_alloc_1 */ 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09,
+  0x00,
+/* u8_2 */0xc8,
+QEMU_VM_EOF, /* just to ensure we won't get EOF reported prematurely */
+};
+
+static void obj_vbuffer_copy(void *target, void *source)
+{
+/* this proc copies all struct TestVBuffer entries from source to target
+   except the vBuffer pointers which should already point to the correct
+   locations. The buffer contents are also copied */
+TestVBuffer *s = (TestVBuffer *)source;
+TestVBuffer *t = (TestVBuffer *)target;
+
+t->u8_1 = s->u8_1;
+t->u8_2 = s->u8_2;
+t->buffer_size = s->buffer_size;
+t->buffer_alloc_size = s->buffer_alloc_size;
+if (t->vBuffer_1 && s->vBuffer_1) {
+memcpy(t->vBuffer_1, s->vBuffer_1, BUF_SIZE);
+}
+if (t->vBuffer_alloc_1 && s->vBuffer_alloc_1) {
+memcpy(t->vBuffer_alloc_1, s->vBuffer_alloc_1, BUF_SIZE);
+}
+}
+
+static void test_complex_vbuffer(void)
+{
+uint8_t buffer[BUF_SIZE];
+uint8_t buffer_clone[BUF_SIZE];
+TestVBuffer obj = {
+.u8_1 = 0,
+.buffer_size = BUF_SIZE,
+.vBuffer_1 = buffer,
+.buffer_alloc_size = BUF_SIZE,
+.vBuffer_alloc_1 = NULL,
+.u8_2 = 0,
+};
+TestVBuffer obj_clone = {
+.u8_1 = 0,
+.buffer_size = BUF_SIZE,
+.vBuffer_1 = buffer_clone,
+.buffer_alloc_size = BUF_SIZE,
+.vBuffer_alloc_1 = NULL,
+.u8_2 = 0,
+};
+
+memset(buffer, 0, BUF_SIZE);
+memset(buffer_clone, 0, BUF_SIZE);
+
+save_vmstate(&vmstate_vbuffer, &obj_vbuffer);
+
+compare_vmstate(wire_vbuffer, sizeof(wire_vbuffer));
+
+SUCCESS(load_vmstate(&vmstate_vbuffer, &obj, &obj_clone,
+ obj_vbuffer_copy, 1, wire_vbuffer,
+ sizeof(wire_vbuffer)));
+
+#define FIELD_EQUAL(name)  g_assert_cmpint(obj.name, ==, obj_vbuffer.name)
+#define BUFFER_EQUAL(name) SUCCESS(memcmp(obj.name, obj_vbuffer.name, 
BUF_SIZE))
+
+FIELD_EQUAL(u8_1);
+BUFFER_EQUAL(vBuffer_1);
+BUFFER_EQUAL(vBuffer_alloc_1);
+FIELD_EQUAL(u8_2);
+}
+#undef FIELD_EQUAL
+#undef BUFFER_EQUAL
+
 int main(int argc, char **argv)
 {
 temp_fd = mkstemp(temp_file);
@@ -489,6 +602,7 @@ int main(int argc, char **argv)
 g_test_add_func("/vmstate/field_exists/load/skip", test_load_skip);
 g_test_add_func("/vmstate/field_exists/save/noskip", test_save_noskip);
 g_test_add_func("/vmstate/field_exists/save/skip", test_save_skip);
+g_test_add_func("/vmstate/complex/vbuffer", test_complex_vbuffer);
 g_test_run();
 
 close(temp_fd);
-- 
2.8.4

Re: [Qemu-devel] [PATCH v3 06/13] pc: apic_common: extend APIC ID property to 32bit

[Eduardo Habkost]

On Thu, Oct 13, 2016 at 11:52:40AM +0200, Igor Mammedov wrote:
> ACPI ID is 32 bit wide on CPUs with x2APIC support.
> Extend 'id' property to support it.
> 
> Signed-off-by: Igor Mammedov 
> ---
> v3:
>keep original behaviour where 'id' is readonly after
>object is realized (pbonzini)
> ---
[...]
> diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c
> index 8d01c9c..30f2af0 100644
> --- a/hw/intc/apic_common.c
> +++ b/hw/intc/apic_common.c
> @@ -428,7 +429,6 @@ static const VMStateDescription vmstate_apic_common = {
>  };
>  
>  static Property apic_properties_common[] = {
> -DEFINE_PROP_UINT8("id", APICCommonState, id, -1),
>  DEFINE_PROP_UINT8("version", APICCommonState, version, 0x14),
>  DEFINE_PROP_BIT("vapic", APICCommonState, vapic_control, 
> VAPIC_ENABLE_BIT,
>  true),
> @@ -437,6 +437,49 @@ static Property apic_properties_common[] = {
>  DEFINE_PROP_END_OF_LIST(),
>  };
>  
> +static void apic_common_get_id(Object *obj, Visitor *v, const char *name,
> +   void *opaque, Error **errp)
> +{
> +APICCommonState *s = APIC_COMMON(obj);
> +int64_t value;
> +
> +value = s->apicbase & MSR_IA32_APICBASE_EXTD ? s->initial_apic_id : 
> s->id;
> +visit_type_int(v, name, &value, errp);
> +}

Who exactly is going to read this property and require this logic
to be in the property getter?

Do we really need to expose this to the outside as a magic
property that changes depending on hardware state? Returning
initial_apic_id sounds much simpler.

> +
> +static void apic_common_set_id(Object *obj, Visitor *v, const char *name,
> +   void *opaque, Error **errp)
> +{
> +APICCommonState *s = APIC_COMMON(obj);
> +DeviceState *dev = DEVICE(obj);
> +Error *local_err = NULL;
> +int64_t value;
> +
> +if (dev->realized) {
> +qdev_prop_set_after_realize(dev, name, errp);
> +return;
> +}
> +
> +visit_type_int(v, name, &value, &local_err);
> +if (local_err) {
> +error_propagate(errp, local_err);
> +return;
> +}
> +
> +s->initial_apic_id = value;
> +s->id = (uint8_t)value;

Do we really need to change s->id here too? Won't it be set
automatically to initial_apic_id on reset?

I'm asking this because making it read/write only initial_apic_id
would make it easier to eventually convert the property to a
field-based getter/setter API (maybe even keep it using the
static property system).

Or, even better: do we really need a writeable property named
"id" at all? Is there any valid use case for the user to set it
directly? We could make the code that creates the APIC set
apic->initial_apic_id directly (or use a clearer
"initial-apic-id" property name).

> +}
> +
> +static void apic_common_initfn(Object *obj)
> +{
> +APICCommonState *s = APIC_COMMON(obj);
> +
> +s->id = s->initial_apic_id = -1;
> +object_property_add(obj, "id", "int",
> +apic_common_get_id,
> +apic_common_set_id, NULL, NULL, NULL);

If you are going to add new properties, please register them
using object_class_property_add*().

> +}
> +
>  static void apic_common_class_init(ObjectClass *klass, void *data)
>  {
>  DeviceClass *dc = DEVICE_CLASS(klass);
> @@ -456,6 +499,7 @@ static const TypeInfo apic_common_type = {
>  .name = TYPE_APIC_COMMON,
>  .parent = TYPE_DEVICE,
>  .instance_size = sizeof(APICCommonState),
> +.instance_init = apic_common_initfn,
>  .class_size = sizeof(APICCommonClass),
>  .class_init = apic_common_class_init,
>  .abstract = true,
> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
> index 13505ab..b4b4342 100644
> --- a/target-i386/cpu.c
> +++ b/target-i386/cpu.c
> @@ -2872,7 +2872,7 @@ static void x86_cpu_apic_create(X86CPU *cpu, Error 
> **errp)
>OBJECT(cpu->apic_state), &error_abort);
>  object_unref(OBJECT(cpu->apic_state));
>  
> -qdev_prop_set_uint8(cpu->apic_state, "id", cpu->apic_id);
> +qdev_prop_set_uint32(cpu->apic_state, "id", cpu->apic_id);
>  /* TODO: convert to link<> */
>  apic = APIC_COMMON(cpu->apic_state);
>  apic->cpu = cpu;
> -- 
> 2.7.4
> 

-- 
Eduardo

Re: [Qemu-devel] [PATCH qemu] sysemu: support up to 1024 vCPUs

[Igor Mammedov]

On Tue, 11 Oct 2016 09:19:10 +1100
Alexey Kardashevskiy  wrote:

> Ping, anyone?
I have a similar patch
http://patchwork.ozlabs.org/patch/681709/
which bumps limit to 288 and does a little bit more
so it wouldn't affect current users.

After that's merged, I plan to get rid of this limit and
make that part of numa parsing code dynamic so that it
wouldn't impose such limit/any limits on target code.

> 
> 
> On 04/10/16 11:33, Alexey Kardashevskiy wrote:
> > From: Greg Kurz 
> > 
> > Some systems can already provide more than 255 hardware threads.
> > 
> > Bumping the QEMU limit to 1024 seems reasonable:
> > - it has no visible overhead in top;
> > - the limit itself has no effect on hot paths.
> > 
> > Signed-off-by: Greg Kurz 
> > Signed-off-by: Alexey Kardashevskiy 
> > ---
> >  include/sysemu/sysemu.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
> > index ef2c50b..2ec0bd8 100644
> > --- a/include/sysemu/sysemu.h
> > +++ b/include/sysemu/sysemu.h
> > @@ -173,7 +173,7 @@ extern int mem_prealloc;
> >   *
> >   * Note that cpu->get_arch_id() may be larger than MAX_CPUMASK_BITS.
> >   */
> > -#define MAX_CPUMASK_BITS 255
> > +#define MAX_CPUMASK_BITS 1024
> >  
> >  #define MAX_OPTION_ROMS 16
> >  typedef struct QEMUOptionRom {
> >   
> 
> 

Re: [Qemu-devel] [PATCH v14 13/21] qdict: allow qdict_crumple to accept compound types as values

[Markus Armbruster]

Eric Blake  writes:

> On 10/17/2016 09:50 AM, Markus Armbruster wrote:
>>> But even if I realised that QemuOpts support this syntax, I think we
>>> would still have to use the dotted syntax because it's explicit about
>>> the index and we need that because the list can contains dicts.
>>>
>>> Compare this:
>>>
>>> driver=quorum,
>>> child.0.driver=file,child.0.filename=disk1.img,
>>> child.1.driver=host_device,child.1.filename=/dev/sdb,
>>> child.2.driver=nbd,child.2.host=localhost
>>>
>>> And this:
>>>
>>> driver=quorum,
>>> child.driver=file,child.filename=disk1.img,
>>> child.driver=host_device,child.filename=/dev/sdb,
>>> child.driver=nbd,child.host=localhost
>> 
>> Aside: both are about equally illegible, to be honest.
>
>> Permit me to digress.
>> 
>> QemuOpts wasn't designed for list-values keys.  Doing lists by
>> repetition was clever.
>> 
>> QemuOpts wasn't designed for structured values.  Doing structured values
>> by a dotted key convention plus repetition was clever.
>> 
>> And there's the problem: too much cleverness, not enough "this is being
>> pushed way beyond its design limits, time to replace it".
>> 
>> For me, a replacement should do structured values by providing suitable
>> *value* syntax instead of hacking it into the keys:
>> 
>> { "driver": "quorum",
>>   "child": [ { "driver": "file", "filename": "disk1.img" },
>>  { "driver": "host_device", "filename=/dev/sdb" },
>>  { "driver": "nbd", "host": "localhost" } ] }
>
> Possible hack solution:
>
> QemuOpts already special-cases id=.  What if we ALSO make it
> special-case a leading json=?  Shown here with shell quoting, the above
> example of creating a Quorum -drive argument could then be:
>
> -drive json='
> { "driver": "quorum",
>   "child": [ { "driver": "file", "filename": "disk1.img" },
>  { "driver": "host_device", "filename=/dev/sdb" },
>  { "driver": "nbd", "host": "localhost" } ] }
> '
>
> As far as I know, we don't have 'json' as any existing QemuOpts key (do
> we? A full audit may be better than my quick git grep '"json"').  Thus,
> if QemuOpts sees a leading json=, it hands off the rest of the string to
> the same parser as we use for QMP, where we no longer have to escape
> commas (even nicer than the drive hack where we support
> filename=json:{...} but have to double up all commas to make it through
> the QemuOpts layer).  Encountering json= as anything other than the
> first option would be an error, and you would be unable to combine a
> json= option with any other old-style option.  In other words, the use
> of leading json= would be the switch for whether to do old-style parsing
> or to use a saner syntax for everything else that needs structure, on a
> per-argument basis.

Slight variation: omit the 'json=' and recognize the '{':

-drive '{ "driver": "quorum",
  "child": [ { "driver": "file", "filename": "disk1.img" },
 { "driver": "host_device", "filename=/dev/sdb" },
 { "driver": "nbd", "host": "localhost" } ] }'

As always when extending haphazardly defined syntax, the question to ask
is whether this makes the syntax (more) ambiguous.

So what is the option argument syntax now?  The abstract syntax is
simple enough: "list of (key, value) pairs".  For the concrete syntax,
we need to study opts_do_parse().

Each iteration of its loop accepts an abstract (key, value).  It first
looks for the leftmost '=' and ','.  Cases:

1. There is no '=', or it is to the right of the leftmost ','.  In other
words, this (key, value) can only be key with an implied value or a
value with an implied key.

1a. If this is the first iteration, and we accept an implied key, this
is a value for the implied key.  We consume everything up to the first
non-escaped ','.  This may be more than the leftmost ',' we found above.
The consumed string with escapes processed is the value.

1b. Else, this is a key with an implied value.  We consume everything up
to the leftmost ',' (no escaping here).

1b1. If the consumed string starts with "no", the key is everything after
the "no" and the value is "off".

1b2. Else the key is the string and the value is "on".

2. This is a key and a value.  We first consume everything up to the
leftmost '=' (no escaping here).  The consumed string is the key.  We
then consume '='.  Finally, we consume everything up to the first
non-escaped ','The consumed string with escapes processed is the value.

Thus, the option argument starts either with a key (case 1b1, 2), "no"
(case 1b2) or a value (case 1a).

Adding JSON object syntax (which always starts with '{') is ambiguous
when a key can start with '{' (case 1b1, 2) or when a value can (case
1a).

Keys starting with '{' are basically foolish.  Let's outlaw them by
adopting QAPI's name rules.

Values starting with '{' are possible.  The implied keys I can remember
don't have such values, th

[Qemu-devel] [PATCH 2/4] tests/test-vmstate.c: prove VMStateField.start broken

[Halil Pasic]

The handling of VMStateField.start is currently quite broken if
VMS_ALLOC is present (that is for VMSTATE_VBUFFER_ALLOC_UINT32) but
fortunately also quite underutilized -- nobody is using .start != 0.

Let's prove with this patch that it's really broken (as a first
step towards fixing things up).

Signed-off-by: Halil Pasic 
Reviewed-by: Guenther Hutzl 
---

The idea is to remove .start support and this patch should
be reverted, as soon this happens, or even better just
dropped. If however dropping the support for .start encounters
resistance, this patch should prove useful in an unexpected
way.
---
 tests/test-vmstate.c | 49 -
 1 file changed, 48 insertions(+), 1 deletion(-)

diff --git a/tests/test-vmstate.c b/tests/test-vmstate.c
index 9a57aa0..a2ef4a8 100644
--- a/tests/test-vmstate.c
+++ b/tests/test-vmstate.c
@@ -588,6 +588,53 @@ static void test_complex_vbuffer(void)
 #undef FIELD_EQUAL
 #undef BUFFER_EQUAL
 
+typedef struct {
+uint32_t vbuff_size;
+uint8_t *vbuff;
+uint64_t stuff;
+} TestVBufStart;
+
+static const VMStateDescription vmstate_vbuff_alloc_start = {
+.name = "test/vbuff_alloc_start",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT64(stuff, TestVBufStart),
+VMSTATE_UINT32(vbuff_size, TestVBufStart),
+VMSTATE_VBUFFER_ALLOC_UINT32(vbuff, TestVBufStart, 1, 0, 1, 
vbuff_size),
+VMSTATE_END_OF_LIST()
+}
+
+};
+
+static void load_vmstate_one_obj(const VMStateDescription *vmsd, void *obj,
+int version_id)
+{
+QEMUFile *fload = open_test_file(false);
+
+SUCCESS(vmstate_load_state(fload, vmsd, obj, version_id));
+qemu_fclose(fload);
+}
+
+static void test_vbuff_alloc_start(void)
+{
+uint8_t my_vbuff1[] = {0, 1, 2, 3};
+uint8_t my_vbuff2[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
+TestVBufStart sample = {
+.stuff = 1,
+.vbuff_size = 3,
+.vbuff = my_vbuff1,
+};
+TestVBufStart load_obj = {
+.vbuff = my_vbuff2,
+};
+
+save_vmstate(&vmstate_vbuff_alloc_start, &sample);
+load_vmstate_one_obj(&vmstate_vbuff_alloc_start, &load_obj, 1);
+g_assert_cmpint(load_obj.stuff, ==, 0);
+g_assert_cmpint((uint64_t) load_obj.vbuff, !=, (uint64_t) my_vbuff2);
+}
+
 int main(int argc, char **argv)
 {
 temp_fd = mkstemp(temp_file);
@@ -603,8 +650,8 @@ int main(int argc, char **argv)
 g_test_add_func("/vmstate/field_exists/save/noskip", test_save_noskip);
 g_test_add_func("/vmstate/field_exists/save/skip", test_save_skip);
 g_test_add_func("/vmstate/complex/vbuffer", test_complex_vbuffer);
+g_test_add_func("/vmstate/vbuff/alloc_start", test_vbuff_alloc_start);
 g_test_run();
-
 close(temp_fd);
 unlink(temp_file);
 
-- 
2.8.4

Re: [Qemu-devel] [PATCH] qapi: fix memory leak in QmpOutputVisitor

[Eric Blake]

On 10/18/2016 04:17 AM, Pino Toscano wrote:
> qmp_output_start_struct() and qmp_output_start_list() create a new
> QObject (QDict, QList) and push it to the stack of the QmpOutputVisitor,
> where it is saved as 'value'.  When freeing the iterator in
> qmp_output_free(), these values are never freed properly.

Do any of the tests (perhaps run under valgrind) show this leak? If not,
maybe we should enhance their coverage.

> 
> The simple solution is to qobject_decref() them.
> ---
>  qapi/qmp-output-visitor.c | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Eric Blake 

> 
> diff --git a/qapi/qmp-output-visitor.c b/qapi/qmp-output-visitor.c
> index 9e3b67c..eedf256 100644
> --- a/qapi/qmp-output-visitor.c
> +++ b/qapi/qmp-output-visitor.c
> @@ -220,6 +220,7 @@ static void qmp_output_free(Visitor *v)
>  while (!QSLIST_EMPTY(&qov->stack)) {
>  e = QSLIST_FIRST(&qov->stack);
>  QSLIST_REMOVE_HEAD(&qov->stack, node);
> +qobject_decref(e->value);
>  g_free(e);
>  }
>  
> 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2] qapi: fix memory leak in bdrv_image_info_specific_dump

[Eric Blake]

On 10/18/2016 05:37 AM, Pino Toscano wrote:
> The 'obj' result of the visitor was not properly freed, like done in
> other places doing a similar job.
> 
> Signed-off-by: Pino Toscano 
> ---

Reviewed-by: Eric Blake 

> 
> Changes in v2:
> - added Signed-off-by
> 
>  block/qapi.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/block/qapi.c b/block/qapi.c
> index 6f947e3..50d3090 100644
> --- a/block/qapi.c
> +++ b/block/qapi.c
> @@ -698,6 +698,7 @@ void bdrv_image_info_specific_dump(fprintf_function 
> func_fprintf, void *f,
>  assert(qobject_type(obj) == QTYPE_QDICT);
>  data = qdict_get(qobject_to_qdict(obj), "data");
>  dump_qobject(func_fprintf, f, 1, data);
> +qobject_decref(obj);
>  visit_free(v);
>  }
>  
> 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2] qapi: fix memory leak in bdrv_image_info_specific_dump

[Kevin Wolf]

Am 18.10.2016 um 12:37 hat Pino Toscano geschrieben:
> The 'obj' result of the visitor was not properly freed, like done in
> other places doing a similar job.
> 
> Signed-off-by: Pino Toscano 

Thanks, applied to my block branch.

Kevin

Re: [Qemu-devel] [PATCH] qapi: fix memory leak in QmpOutputVisitor

[Eric Blake]

On 10/18/2016 06:13 AM, Eric Blake wrote:
> On 10/18/2016 04:17 AM, Pino Toscano wrote:
>> qmp_output_start_struct() and qmp_output_start_list() create a new
>> QObject (QDict, QList) and push it to the stack of the QmpOutputVisitor,
>> where it is saved as 'value'.  When freeing the iterator in
>> qmp_output_free(), these values are never freed properly.
> 
> Do any of the tests (perhaps run under valgrind) show this leak? If not,
> maybe we should enhance their coverage.
> 
>>
>> The simple solution is to qobject_decref() them.
>> ---
>>  qapi/qmp-output-visitor.c | 1 +
>>  1 file changed, 1 insertion(+)
> 
> Reviewed-by: Eric Blake 

except this should be done against v2, where you had S-o-B :)

> 
>>
>> diff --git a/qapi/qmp-output-visitor.c b/qapi/qmp-output-visitor.c
>> index 9e3b67c..eedf256 100644
>> --- a/qapi/qmp-output-visitor.c
>> +++ b/qapi/qmp-output-visitor.c
>> @@ -220,6 +220,7 @@ static void qmp_output_free(Visitor *v)
>>  while (!QSLIST_EMPTY(&qov->stack)) {
>>  e = QSLIST_FIRST(&qov->stack);
>>  QSLIST_REMOVE_HEAD(&qov->stack, node);
>> +qobject_decref(e->value);
>>  g_free(e);
>>  }
>>  
>>
> 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH] qapi: fix memory leak in QmpOutputVisitor

[Pino Toscano]

On Tuesday, 18 October 2016 06:13:30 CEST Eric Blake wrote:
> On 10/18/2016 04:17 AM, Pino Toscano wrote:
> > qmp_output_start_struct() and qmp_output_start_list() create a new
> > QObject (QDict, QList) and push it to the stack of the QmpOutputVisitor,
> > where it is saved as 'value'.  When freeing the iterator in
> > qmp_output_free(), these values are never freed properly.
> 
> Do any of the tests (perhaps run under valgrind) show this leak? If not,
> maybe we should enhance their coverage.

Running a simple `qemu-img info file.qcow2` under valgrind was enough
for me to show the leak.

In this case, another simple fix is needed to fully fix the leak:
http://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg04023.html
(Yes, I just saw your ACK on this, Eric, just leaving it here for
reference.)

> > 
> > The simple solution is to qobject_decref() them.
> > ---
> >  qapi/qmp-output-visitor.c | 1 +
> >  1 file changed, 1 insertion(+)
> 
> Reviewed-by: Eric Blake 
> 
> > 
> > diff --git a/qapi/qmp-output-visitor.c b/qapi/qmp-output-visitor.c
> > index 9e3b67c..eedf256 100644
> > --- a/qapi/qmp-output-visitor.c
> > +++ b/qapi/qmp-output-visitor.c
> > @@ -220,6 +220,7 @@ static void qmp_output_free(Visitor *v)
> >  while (!QSLIST_EMPTY(&qov->stack)) {
> >  e = QSLIST_FIRST(&qov->stack);
> >  QSLIST_REMOVE_HEAD(&qov->stack, node);
> > +qobject_decref(e->value);
> >  g_free(e);
> >  }
> >  
> > 
> 
> 


-- 
Pino Toscano

signature.asc
Description: This is a digitally signed message part.

Re: [Qemu-devel] [PATCH 0/4] remove unused VMSTateField.start

[no-reply]

Hi,

Your series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: 20161018105724.26520-1-pa...@linux.vnet.ibm.com
Subject: [Qemu-devel] [PATCH 0/4] remove unused VMSTateField.start

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git show --no-patch --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 - [tag update]  
patchew/1476782267-2602-1-git-send-email-ptosc...@redhat.com -> 
patchew/1476782267-2602-1-git-send-email-ptosc...@redhat.com
 - [tag update]  
patchew/1476787062-27376-1-git-send-email-ptosc...@redhat.com -> 
patchew/1476787062-27376-1-git-send-email-ptosc...@redhat.com
Switched to a new branch 'test'
f8c250a migration: drop unused VMStateField.start
908def4 Revert "tests/test-vmstate.c: prove VMStateField.start broken"
10612d0 tests/test-vmstate.c: prove VMStateField.start broken
138f40f tests/test-vmstate.c: Add vBuffer test

=== OUTPUT BEGIN ===
Checking PATCH 1/4: tests/test-vmstate.c: Add vBuffer test...
Checking PATCH 2/4: tests/test-vmstate.c: prove VMStateField.start broken...
Checking PATCH 3/4: Revert "tests/test-vmstate.c: prove VMStateField.start 
broken"...
Checking PATCH 4/4: migration: drop unused VMStateField.start...
ERROR: line over 90 characters
#195: FILE: include/migration/vmstate.h:572:
+#define VMSTATE_VBUFFER_MULTIPLY(_field, _state, _version, _test, _field_size, 
_multiply) { \

WARNING: line over 80 characters
#231: FILE: include/migration/vmstate.h:603:
+#define VMSTATE_VBUFFER_ALLOC_UINT32(_field, _state, _version, _test, 
_field_size) { \

total: 1 errors, 1 warnings, 223 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@freelists.org

Re: [Qemu-devel] [PATCH v4 13/13] pc: require IRQ remapping and EIM if there could be x2APIC CPUs

[Eduardo Habkost]

On Fri, Oct 14, 2016 at 01:25:35PM +0200, Igor Mammedov wrote:
> it would prevent starting guest with incorrect configs
> where interrupts couldn't be delivered to CPUs with
> APIC IDs > 255.
> 
> Signed-off-by: Igor Mammedov 
> Reviewed-by: Radim Krčmář 
> ---
> v4:
>  - s/254/255/ in commit message (Radim)
> ---
>  hw/i386/pc.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 40eb43b..f7070e0 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -68,6 +68,7 @@
>  #include "qapi-visit.h"
>  #include "qom/cpu.h"
>  #include "hw/nmi.h"
> +#include "hw/i386/intel_iommu.h"
>  
>  /* debug PC/ISA interrupts */
>  //#define DEBUG_IRQ
> @@ -1264,6 +1265,18 @@ void pc_machine_done(Notifier *notifier, void *data)
>  sizeof(pcms->boot_cpus_le));
>  }
>  }
> +
> +if (pcms->apic_id_limit > 255) {
> +IntelIOMMUState *iommu = INTEL_IOMMU_DEVICE(x86_iommu_get_default());
> +
> +if (!iommu || !iommu->x86_iommu.intr_supported ||
> +iommu->intr_eim != ON_OFF_AUTO_ON) {
> +error_report("current -smp configuration requires "
> + "Extended Interrupt Mode enabled. "
> + "IOMMU should have eim=on option set");

Suggestion for a follow-up patch:

* Error message explaining how to set eim=on if the iommu is
  available
* Error message explaining how to make sure the iommu is created,
  in case it was not even created.

-- 
Eduardo

Re: [Qemu-devel] chardev's and fd's in monitors

[Dr. David Alan Gilbert]

* Daniel P. Berrange (berra...@redhat.com) wrote:
> On Wed, Oct 12, 2016 at 08:15:02PM +0100, Dr. David Alan Gilbert wrote:
> > Hi,
> >   I had a look at a couple of readline like libraries;
> > editline and linenoise.  A difficulty with using them is that
> > they both want fd's or FILE*'s; editline takes either but
> > from a brief look I think it's expecting to extract the fd.
> > That makes them tricky to integrate into qemu, where
> > the chardev's hide a whole bunch of non-fd things; in particular
> > tls, mux, ringbuffers etc.
> > 
> > If we could get away with just a FILE* then we could use fopencookie,
> > but that's GNU only.
> > 
> > Is there any sane way of shepherding all chardev's into having an
> > fd?
> 
> The entire chardev abstraction model exists precisely because we cannot
> make all chardevs look like a single fd. Even those which are fd based
> may have separate FDs for input and output.

Note that editline takes separate in/out streams, but it does want those streams
to be FILE*'s.

> IMHO the only viable approach would be to enhance linenoise/editline to
> not assume use of fd* or FILE * abstractions.

I think if it came to that then we'd probably end up sticking with what we
had for a very long time; I'd assume it would take a long time before
any mods we made to the libraries would come around to be generally useful.

> BTW, what is the actual thread issue you are facing ? Chardevs at least
> ought to be usable from a separate thread, as long as each distinct
> chardev object instance was only used from one thread at a time ?

Marc-André pointed that out; I hadn't realised they were thread safe.
But what are the rules? You say 'only used from one thread at a time' -
what happens if we have a mux and the different streams to the mux come
from different threads?

My actual thoughts for threads came from a few sides:
  a) Maybe I could have a shim thread that fed the editline fd from a chardev
  b) I'd eventually like multiple monitor threads.

Dave

> Regards,
> Daniel
> -- 
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o- http://virt-manager.org :|
> |: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [Qemu-devel] [PULL 00/19] VFIO updates 2016-10-17

[Peter Maydell]

On 17 October 2016 at 20:51, Alex Williamson  wrote:
> The following changes since commit 0975b8b823a888d474fa33821dfe84e6904db197:
>
>   Merge remote-tracking branch 'remotes/gkurz/tags/for-upstream' into staging 
> (2016-10-17 16:17:51 +0100)
>
> are available in the git repository at:
>
>
>   git://github.com/awilliam/qemu-vfio.git tags/vfio-updates-20161017.0
>
> for you to fetch changes up to 893bfc3cc893ed36cedc364e99cf483e9b08c294:
>
>   vfio: fix duplicate function call (2016-10-17 10:58:03 -0600)
>
> 
> VFIO updates 2016-10-17
>
>  - Convert to realize & improve error reporting (Eric Auger)
>  - RTL quirk bug fix (Thorsten Kohfeldt)
>  - Skip duplicate pre/post reset (Cao jin)
>

Applied, thanks.

-- PMM

[Qemu-devel] [PATCH v4 05/13] pc: leave max apic_id_limit only in legacy cpu hotplug code

[Igor Mammedov]

that's enough to make old code that depends on it
to prevent QEMU starting with more than 255 CPUs.

Signed-off-by: Igor Mammedov 
---
v4:
  - keep assert() as it doesn't affect x2APIC cpus (Eduardo)
---
 hw/acpi/cpu_hotplug.c | 7 ++-
 hw/i386/pc.c  | 6 --
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/hw/acpi/cpu_hotplug.c b/hw/acpi/cpu_hotplug.c
index c2ab9b8..f15a240 100644
--- a/hw/acpi/cpu_hotplug.c
+++ b/hw/acpi/cpu_hotplug.c
@@ -15,6 +15,7 @@
 #include "qapi/error.h"
 #include "qom/cpu.h"
 #include "hw/i386/pc.h"
+#include "qemu/error-report.h"
 
 #define CPU_EJECT_METHOD "CPEJ"
 #define CPU_MAT_METHOD "CPMA"
@@ -236,7 +237,11 @@ void build_legacy_cpu_hotplug_aml(Aml *ctx, MachineState 
*machine,
 /* The current AML generator can cover the APIC ID range [0..255],
  * inclusive, for VCPU hotplug. */
 QEMU_BUILD_BUG_ON(ACPI_CPU_HOTPLUG_ID_LIMIT > 256);
-g_assert(pcms->apic_id_limit <= ACPI_CPU_HOTPLUG_ID_LIMIT);
+if (pcms->apic_id_limit > ACPI_CPU_HOTPLUG_ID_LIMIT) {
+error_report("max_cpus is too large. APIC ID of last CPU is %u",
+ pcms->apic_id_limit - 1);
+exit(1);
+}
 
 /* create PCI0.PRES device and its _CRS to reserve CPU hotplug MMIO */
 dev = aml_device("PCI0." stringify(CPU_HOTPLUG_RESOURCE_DEVICE));
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 93ff49c..2045525 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1190,12 +1190,6 @@ void pc_cpus_init(PCMachineState *pcms)
  * This is used for FW_CFG_MAX_CPUS. See comments on bochs_bios_init().
  */
 pcms->apic_id_limit = x86_cpu_apic_id_from_index(max_cpus - 1) + 1;
-if (pcms->apic_id_limit > ACPI_CPU_HOTPLUG_ID_LIMIT) {
-error_report("max_cpus is too large. APIC ID of last CPU is %u",
- pcms->apic_id_limit - 1);
-exit(1);
-}
-
 pcms->possible_cpus = g_malloc0(sizeof(CPUArchIdList) +
 sizeof(CPUArchId) * max_cpus);
 for (i = 0; i < max_cpus; i++) {
-- 
2.7.4

Re: [Qemu-devel] chardev's and fd's in monitors

[Marc-André Lureau]

Hi

On Tue, Oct 18, 2016 at 2:32 PM Dr. David Alan Gilbert 
wrote:

> * Daniel P. Berrange (berra...@redhat.com) wrote:
> > On Wed, Oct 12, 2016 at 08:15:02PM +0100, Dr. David Alan Gilbert wrote:
> > > Hi,
> > >   I had a look at a couple of readline like libraries;
> > > editline and linenoise.  A difficulty with using them is that
> > > they both want fd's or FILE*'s; editline takes either but
> > > from a brief look I think it's expecting to extract the fd.
> > > That makes them tricky to integrate into qemu, where
> > > the chardev's hide a whole bunch of non-fd things; in particular
> > > tls, mux, ringbuffers etc.
> > >
> > > If we could get away with just a FILE* then we could use fopencookie,
> > > but that's GNU only.
> > >
> > > Is there any sane way of shepherding all chardev's into having an
> > > fd?
> >
> > The entire chardev abstraction model exists precisely because we cannot
> > make all chardevs look like a single fd. Even those which are fd based
> > may have separate FDs for input and output.
>
> Note that editline takes separate in/out streams, but it does want those
> streams
> to be FILE*'s.
>

glibc can have custom streams iirc:
https://www.gnu.org/software/libc/manual/html_node/Custom-Streams.html#Custom-Streams

I haven't looked in details if that would solve it.


> > IMHO the only viable approach would be to enhance linenoise/editline to
> > not assume use of fd* or FILE * abstractions.
>
> I think if it came to that then we'd probably end up sticking with what we
> had for a very long time; I'd assume it would take a long time before
> any mods we made to the libraries would come around to be generally useful.
>
> > BTW, what is the actual thread issue you are facing ? Chardevs at least
> > ought to be usable from a separate thread, as long as each distinct
> > chardev object instance was only used from one thread at a time ?
>
> Marc-André pointed that out; I hadn't realised they were thread safe.
> But what are the rules? You say 'only used from one thread at a time' -
> what happens if we have a mux and the different streams to the mux come
> from different threads?
>
> My actual thoughts for threads came from a few sides:
>   a) Maybe I could have a shim thread that fed the editline fd from a
> chardev
>   b) I'd eventually like multiple monitor threads.
>
> Dave
>
> > Regards,
> > Daniel
> > --
> > |: http://berrange.com  -o-
> http://www.flickr.com/photos/dberrange/ :|
> > |: http://libvirt.org  -o-
> http://virt-manager.org :|
> > |: http://entangle-photo.org   -o-
> http://search.cpan.org/~danberr/ :|
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
>
> --
Marc-André Lureau

Re: [Qemu-devel] chardev's and fd's in monitors

[Marc-André Lureau]

Hi

On Tue, Oct 18, 2016 at 2:41 PM Marc-André Lureau <
marcandre.lur...@gmail.com> wrote:

> Hi
>
> On Tue, Oct 18, 2016 at 2:32 PM Dr. David Alan Gilbert <
> dgilb...@redhat.com> wrote:
>
> * Daniel P. Berrange (berra...@redhat.com) wrote:
> > On Wed, Oct 12, 2016 at 08:15:02PM +0100, Dr. David Alan Gilbert wrote:
> > > Hi,
> > >   I had a look at a couple of readline like libraries;
> > > editline and linenoise.  A difficulty with using them is that
> > > they both want fd's or FILE*'s; editline takes either but
> > > from a brief look I think it's expecting to extract the fd.
> > > That makes them tricky to integrate into qemu, where
> > > the chardev's hide a whole bunch of non-fd things; in particular
> > > tls, mux, ringbuffers etc.
> > >
> > > If we could get away with just a FILE* then we could use fopencookie,
> > > but that's GNU only.
> > >
> > > Is there any sane way of shepherding all chardev's into having an
> > > fd?
> >
> > The entire chardev abstraction model exists precisely because we cannot
> > make all chardevs look like a single fd. Even those which are fd based
> > may have separate FDs for input and output.
>
> Note that editline takes separate in/out streams, but it does want those
> streams
> to be FILE*'s.
>
>
> glibc can have custom streams iirc:
>
> https://www.gnu.org/software/libc/manual/html_node/Custom-Streams.html#Custom-Streams
>
> I haven't looked in details if that would solve it.
>

Sorry, just noticed you mentionned it already (didn't realize it was called
fopencookie)


> > IMHO the only viable approach would be to enhance linenoise/editline to
> > not assume use of fd* or FILE * abstractions.
>
> I think if it came to that then we'd probably end up sticking with what we
> had for a very long time; I'd assume it would take a long time before
> any mods we made to the libraries would come around to be generally useful.
>
> > BTW, what is the actual thread issue you are facing ? Chardevs at least
> > ought to be usable from a separate thread, as long as each distinct
> > chardev object instance was only used from one thread at a time ?
>
> Marc-André pointed that out; I hadn't realised they were thread safe.
> But what are the rules? You say 'only used from one thread at a time' -
> what happens if we have a mux and the different streams to the mux come
> from different threads?
>
> My actual thoughts for threads came from a few sides:
>   a) Maybe I could have a shim thread that fed the editline fd from a
> chardev
>   b) I'd eventually like multiple monitor threads.
>
> Dave
>
> > Regards,
> > Daniel
> > --
> > |: http://berrange.com  -o-
> http://www.flickr.com/photos/dberrange/ :|
> > |: http://libvirt.org  -o-
> http://virt-manager.org :|
> > |: http://entangle-photo.org   -o-
> http://search.cpan.org/~danberr/ :|
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
>
> --
> Marc-André Lureau
>
-- 
Marc-André Lureau

Re: [Qemu-devel] [PATCH v2] Add 'offset' and 'size' options

[Kevin Wolf]

Am 18.10.2016 um 00:25 hat Tomáš Golembiovský geschrieben:
> This is a follow-up to the patch:
> [PATCH] raw-posix: add 'offset' and 'size' options
> 
> The main changes are:
>  -  options were moved from 'file' driver into 'raw' driver as suggested
>  -  added support for writing, reopen and truncate when possible
> 
> If I forgot to address somebody's comments feel free to raise them again,
> please.
> 
> Some general notes to the code:
> 
> 1)  The size is rounded *down* to the 512 byte boundary. It's not that
> the raw driver really cares about this, but if we don't do it then 
> bdrv_getlength() will do that instead of us. The problem is that
> bdrv_getlength() does round *up* and this can lead to reads/writes
> outside the specified 'size'.

I think it might be better to just check whether offset/size are
correctly aligned and error out if they aren't.

Then once we made the necessary changes to allow byte alignment (I think
what prevents it is mostly bs->total_sectors, right?) we can allow that
in the raw format driver, which will only make previously failing
options work rather than changing the behaviour of already working
configurations (we can't do the latter without a very good justification
because of compatibility).

> 2)  We don't provide '.bdrv_get_allocated_file_size' function. As a
> result the information about allocated disk size reports size of the
> whole file. This is, rather confusingly, larger than the provided
> 'size'. But I don't think this matters much. Note that we don't have
> any easy way how to get the correct information here apart from
> checking all the block with bdrv_co_get_block_status() (as suggested
> by Kevin Wolf).
> 
> 3)  No options for raw_create(). The 'size' and 'offset' options were
> added only to open/reopen. In my opinion there is no real reason for
> them there. AFAIK you cannot create embeded QCOW2/VMDK/etc. image
> that way anyway.

These two things are fine with me.

Kevin

[Qemu-devel] [PATCH] xilinx: fix buffer overflow on realize

[Marc-André Lureau]

ASAN complains about buffer overflow when running:
aarch64-softmmu/qemu-system-aarch64 -machine xilinx-zynq-a9

==476==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60235e38 
at pc 0x00f75253 bp 0x7ffc597e0ec0 sp 0x7ffc597e0eb0
READ of size 8 at 0x60235e38 thread T0
#0 0xf75252 in xilinx_spips_realize hw/ssi/xilinx_spips.c:623
#1 0xb9ef6c in device_set_realized hw/core/qdev.c:918
#2 0x129ae01 in property_set_bool qom/object.c:1854
#3 0x1296e70 in object_property_set qom/object.c:1088
#4 0x129dd1b in object_property_set_qobject qom/qom-qobject.c:27
#5 0x1297168 in object_property_set_bool qom/object.c:1157
#6 0xb9aeac in qdev_init_nofail hw/core/qdev.c:358
#7 0x78a5bf in zynq_init_spi_flashes 
/home/elmarco/src/qemu/hw/arm/xilinx_zynq.c:125
#8 0x78af60 in zynq_init /home/elmarco/src/qemu/hw/arm/xilinx_zynq.c:238
#9 0x998eac in main /home/elmarco/src/qemu/vl.c:4534
#10 0x7f96ed692730 in __libc_start_main (/lib64/libc.so.6+0x20730)
#11 0x41d0a8 in _start 
(/home/elmarco/src/qemu/aarch64-softmmu/qemu-system-aarch64+0x41d0a8)

0x60235e38 is located 0 bytes to the right of 8-byte region 
[0x60235e30,0x60235e38)
allocated by thread T0 here:
#0 0x7f970b014e60 in malloc (/lib64/libasan.so.3+0xc6e60)
#1 0x7f96f15b0e18 in g_malloc (/lib64/libglib-2.0.so.0+0x4ee18)
#2 0xb9ef6c in device_set_realized hw/core/qdev.c:918
#3 0x129ae01 in property_set_bool qom/object.c:1854
#4 0x1296e70 in object_property_set qom/object.c:1088
#5 0x129dd1b in object_property_set_qobject qom/qom-qobject.c:27
#6 0x1297168 in object_property_set_bool qom/object.c:1157
#7 0xb9aeac in qdev_init_nofail hw/core/qdev.c:358
#8 0x78a5bf in zynq_init_spi_flashes 
/home/elmarco/src/qemu/hw/arm/xilinx_zynq.c:125
#9 0x78af60 in zynq_init /home/elmarco/src/qemu/hw/arm/xilinx_zynq.c:238
#10 0x998eac in main /home/elmarco/src/qemu/vl.c:4534
#11 0x7f96ed692730 in __libc_start_main (/lib64/libc.so.6+0x20730)

s->spi is allocated with the size of num_busses which may be 1 (by
default).

It looks like ssi_auto_connect_slaves() connects all devices children to
a s->spi bus. Since there can be only one parent bus, remove the second call.

Signed-off-by: Marc-André Lureau 
---
 hw/ssi/xilinx_spips.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/ssi/xilinx_spips.c b/hw/ssi/xilinx_spips.c
index e2b77dc..ab7fa6f 100644
--- a/hw/ssi/xilinx_spips.c
+++ b/hw/ssi/xilinx_spips.c
@@ -620,7 +620,7 @@ static void xilinx_spips_realize(DeviceState *dev, Error 
**errp)
 
 s->cs_lines = g_new0(qemu_irq, s->num_cs * s->num_busses);
 ssi_auto_connect_slaves(DEVICE(s), s->cs_lines, s->spi[0]);
-ssi_auto_connect_slaves(DEVICE(s), s->cs_lines, s->spi[1]);
+
 sysbus_init_irq(sbd, &s->irq);
 for (i = 0; i < s->num_cs * s->num_busses; ++i) {
 sysbus_init_irq(sbd, &s->cs_lines[i]);
-- 
2.10.0

Re: [Qemu-devel] [PATCH qemu] sysemu: support up to 1024 vCPUs

[Greg Kurz]

On Tue, 18 Oct 2016 13:00:07 +0200
Igor Mammedov  wrote:

> On Tue, 11 Oct 2016 09:19:10 +1100
> Alexey Kardashevskiy  wrote:
> 
> > Ping, anyone?  
> I have a similar patch
> http://patchwork.ozlabs.org/patch/681709/
> which bumps limit to 288 and does a little bit more
> so it wouldn't affect current users.
> 

Heh the bumping to 1024 was kinda arbitrary but 288 would be an
improvement anyway. FYI, only Alpine class servers would benefit
from that since they have 320 threads, even if they're not officially
supported to run a KVM based hypervisor (biggest supported model is
Tuleta with 192 threads).

BTW, the afore mentioned patch keeps the current 255 limit for
pseries machine types. I guess David's answer means that the
hw/ppc/spapr.c hunk can be safely dropped.

> After that's merged, I plan to get rid of this limit and
> make that part of numa parsing code dynamic so that it
> wouldn't impose such limit/any limits on target code.
> 
> > 
> > 
> > On 04/10/16 11:33, Alexey Kardashevskiy wrote:  
> > > From: Greg Kurz 
> > > 
> > > Some systems can already provide more than 255 hardware threads.
> > > 
> > > Bumping the QEMU limit to 1024 seems reasonable:
> > > - it has no visible overhead in top;
> > > - the limit itself has no effect on hot paths.
> > > 
> > > Signed-off-by: Greg Kurz 
> > > Signed-off-by: Alexey Kardashevskiy 
> > > ---
> > >  include/sysemu/sysemu.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
> > > index ef2c50b..2ec0bd8 100644
> > > --- a/include/sysemu/sysemu.h
> > > +++ b/include/sysemu/sysemu.h
> > > @@ -173,7 +173,7 @@ extern int mem_prealloc;
> > >   *
> > >   * Note that cpu->get_arch_id() may be larger than MAX_CPUMASK_BITS.
> > >   */
> > > -#define MAX_CPUMASK_BITS 255
> > > +#define MAX_CPUMASK_BITS 1024
> > >  
> > >  #define MAX_OPTION_ROMS 16
> > >  typedef struct QEMUOptionRom {
> > > 
> > 
> >   
> 

Re: [Qemu-devel] [PATCH 0/8] Cleanups to qtest PCI handling

[Laurent Vivier]

On 18/10/2016 12:52, David Gibson wrote:
> This series contains a number of cleanups to the libqos code for
> accessing PCI devices, and to tests which use it.
> 
> The general aim is to improve the consistency of semantics across
> functions, and reduce the amount of intimate knowledge of the libqos
> PCI layer needed by tests.
> 
> This should make it easier to write PCI tests which will be portable
> to different guest machines with different PCI host bridge
> arrangements.
> 
> David Gibson (8):
>   libqos: Give qvirtio_config_read*() consistent semantics
>   libqos: Handle PCI IO de-multiplexing in common code
>   libqos: Move BAR assignment to common code
>   tests: Better handle legacy IO addresses in tco-test
>   libqos: Add streaming accessors for PCI MMIO
>   libqos: Implement mmio accessors in terms of mem{read,write}
>   tests: Use qpci_mem{read,write} in ivshmem-test
>   libqos: Change PCI accessors to take opaque BAR handle
> 
>  tests/ahci-test.c  |   4 +-
>  tests/e1000e-test.c|   7 +-
>  tests/ide-test.c   |  23 +++---
>  tests/ivshmem-test.c   |  28 
>  tests/libqos/ahci.c|   3 +-
>  tests/libqos/ahci.h|   6 +-
>  tests/libqos/pci-pc.c  | 170 +---
>  tests/libqos/pci-spapr.c   | 172 
> ++---
>  tests/libqos/pci.c | 168 ++-
>  tests/libqos/pci.h |  60 ++--
>  tests/libqos/usb.c |   6 +-
>  tests/libqos/usb.h |   2 +-
>  tests/libqos/virtio-mmio.c |  16 ++---
>  tests/libqos/virtio-pci.c  | 117 --
>  tests/libqos/virtio-pci.h  |   2 +-
>  tests/rtl8139-test.c   |  10 ++-
>  tests/tco-test.c   |  87 +++
>  tests/usb-hcd-ehci-test.c  |   5 +-
>  tests/virtio-9p-test.c |   9 +--
>  tests/virtio-blk-test.c|  51 +++---
>  tests/virtio-scsi-test.c   |   5 +-
>  21 files changed, 418 insertions(+), 533 deletions(-)
> 

This series conflicts with series "tests: enable virtio tests on SPAPR".

Which one will you apply first?

Thanks,
Laurent