Re: [Qemu-devel] [PATCH] e1000: add the ability to select among several specific types of e1000, plus some pointers to documentations and details.

2014-02-25 Thread Andreas Färber
Hi,

Am 24.02.2014 20:08, schrieb Romain Dolbeau:
> Hello,
> 
> This patch adds this ability to select a specific variant of
> the e1000 virtual ethernet from the command-line. Previously
> only a single device was available, selected at compile time.
> This helps for guests with limited hardware support, as with
> this patch not all guests are required to use the same device.
> 
> So for instance to use the emulated 82545EM in OSX[1], a user
> would add e.g. the options:
> 
> "-netdev user,id=mynet0 -device 82545EM,netdev=mynet0"
> 
> Note that the value 'e1000' is retained to mean "whatever
> is the compiled-in default", as previously.
> 
> There's also some comments to help future developers to
> identify relevant informations in the documentations.
> There's also a couple of fixed values for constants
> (didn't match the current driver).
> 
> Known cosmetic issues:
> 1) Some lines are long than 80 characters to avoid breaking
> down URLs and titles.
> 2) One of the array initializer generates the error:
> 
> ERROR: space prohibited before open square bracket '['
> #107: FILE: hw/net/e1000.c:256:
> +[PHY_ID1] = 0x141,  [PHY_ID2] = 0xc20,
> 
> Despite being formatted exactly like the surrounding lines
> (minus the tabs, another source of error in checkpatch.pl).
> 
> No maintainer CC:, because I couldn't find a maintainer for
> hw/net/e1000 or hw/net/*.

CC'ing Stefan as maintainer.

> 
> Cordially,
> 
> Romain Dolbeau

When you send a "PATCH" please send it in a form we can actually commit,
without letter-style text. That can go into a cover letter 0/1 or below
--- line.

> 
> [1] See 
> for details
> 
> Signed-off-by: Romain Dolbeau 
> ---
>  hw/net/e1000.c  |  195 
> +++
>  hw/net/e1000_regs.h |   65 +++--
>  hw/pci/pci.c|6 ++
>  3 files changed, 215 insertions(+), 51 deletions(-)
> 
> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> index 8387443..9073c1a 100644
> --- a/hw/net/e1000.c
> +++ b/hw/net/e1000.c
> @@ -1,8 +1,10 @@
>  /*
>   * QEMU e1000 emulation
>   *
> - * Software developer's manual:
> - * http://download.intel.com/design/network/manuals/8254x_GBe_SDM.pdf
> + * Software developer's manual (PCI, PCI-X):
> + * 
> + * Software developer's manual (PCIe):
> + * 
> 
>   *
>   * Nir Peleg, Tutis Systems Ltd. for Qumranet Inc.
>   * Copyright (c) 2008 Qumranet
> @@ -10,6 +12,8 @@
>   * Copyright (c) 2007 Dan Aloni
>   * Copyright (c) 2004 Antony T Curtis
>   *
> + * Additional modifications (c) 2014 Romain Dolbeau
> + *
>   * This library is free software; you can redistribute it and/or
>   * modify it under the terms of the GNU Lesser General Public
>   * License as published by the Free Software Foundation; either
> @@ -69,10 +73,11 @@ static int debugflags = DBGBIT(TXERR) | DBGBIT(GENERAL);
>  
>  /*
>   * HW models:
> - *  E1000_DEV_ID_82540EM works with Windows and Linux
> - *  E1000_DEV_ID_82573L OK with windoze and Linux 2.6.22,
> - *   appears to perform better than 82540EM, but breaks with Linux 2.6.18
> + *  E1000_DEV_ID_82540EM works with Windows and Linux, and is the default
>   *  E1000_DEV_ID_82544GC_COPPER appears to work; not well tested
> + *  E1000_DEV_ID_82545EM_COPPER appears to work with OSX 10.9[.1]
> + *  It seems those 3 are mostly identical anyway, so picking one
> + *  over the others is a matter of guest support.
>   *  Others never tested
>   */
>  enum { E1000_DEVID = E1000_DEV_ID_82540EM };
> @@ -81,10 +86,22 @@ enum { E1000_DEVID = E1000_DEV_ID_82540EM };
>   * May need to specify additional MAC-to-PHY entries --
>   * Intel's Windows driver refuses to initialize unless they match
>   */
> -enum {
> -PHY_ID2_INIT = E1000_DEVID == E1000_DEV_ID_82573L ?  0xcc2 :
> -   E1000_DEVID == E1000_DEV_ID_82544GC_COPPER ?  0xc30 :
> -   /* default to E1000_DEV_ID_82540EM */ 0xc20
> +/* PHY_ID1:
> + * Most 8254x uses 0x141, but 82541xx and 82547GI/EI uses 0x2a8,
> + * and so do the 631xESB/632xESB, 82571EB/82572EI.
> + * The 82573E/82573V/82573L and 82563EB/82564EB also uses 0x141.
> + *  page 
> 250
> + * 
> 
>  page 305
> + */
> +const uint16_t PHY_ID1_INIT[][2] = {
> +  { E1000_DEV_ID_80003ES2LAN_COPPER_DPT, 0x2a8 },
> +  { -1, 0x141 } /* default for 82540EM and many others */
> +};
> +const uint16_t PHY_ID2_INIT[][2] = {
> +  { E1000_DEV_ID_82573L, 0xcc2 },
> +  { E1000_DEV_ID_82544GC_COPPER, 0xc30 },
> +  { -1, 0xc20 } /* default for 82540EM and many others ; this is one
> +   is a lo

Re: [Qemu-devel] Question

2014-02-25 Thread Andreas Färber
Am 25.02.2014 07:54, schrieb Atlas Khan:
> Plz someone guide me that how I can add new virtual hardware in QEMU? I
> tried t get help from already made hardware but it gives me no
> idea...Plz someone guide me and tell me detailed process.

Please don't post the same question again and again. Instead, reply to
your previous post if you don't get an answer - usually that means that
you provided insufficient information on what you tried and read.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



Re: [Qemu-devel] [PATCH 3/4] exynos4210: Set reset-cbar property of Cortex-A9 CPUs

2014-02-25 Thread Peter Crosthwaite
On Tue, Feb 25, 2014 at 6:24 AM, Peter Maydell  wrote:
> Set the reset-cbar property of the Exynos4210 SoC's Cortex-A9
> CPUs, so that Linux doesn't misrecognize them as a broken
> uniprocessor SoC.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Peter Crosthwaite 

But a couple of random notes below ...

> ---
>  hw/arm/exynos4210.c | 23 ---
>  1 file changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/hw/arm/exynos4210.c b/hw/arm/exynos4210.c
> index 9f137e9..a6f481a 100644
> --- a/hw/arm/exynos4210.c
> +++ b/hw/arm/exynos4210.c
> @@ -143,11 +143,28 @@ Exynos4210State *exynos4210_init(MemoryRegion 
> *system_mem,
>  unsigned long mem_size;
>  DeviceState *dev;
>  SysBusDevice *busdev;
> +ObjectClass *cpu_oc;
> +
> +cpu_oc = cpu_class_by_name(TYPE_ARM_CPU, "cortex-a9");
> +if (!cpu_oc) {
> +fprintf(stderr, "Unable to find CPU definition\n");
> +exit(1);
> +}

Now that this code is ignoring use -cpu I wonder if this should be
promoted to an assertion. The only way this can fail is if someone
rips A9 out of QEMU (or some other nasty fatal condition).

>
>  for (n = 0; n < EXYNOS4210_NCPUS; n++) {
> -s->cpu[n] = cpu_arm_init("cortex-a9");
> -if (!s->cpu[n]) {
> -fprintf(stderr, "Unable to find CPU %d definition\n", n);
> +Object *cpuobj = object_new(object_class_get_name(cpu_oc));
> +Error *err = NULL;
> +
> +s->cpu[n] = ARM_CPU(cpuobj);
> +object_property_set_int(cpuobj, EXYNOS4210_SMP_PRIVATE_BASE_ADDR,
> +"reset-cbar", &err);
> +if (err) {
> +error_report("%s", error_get_pretty(err));
> +exit(1);
> +}

And this may even be convertible to error_abort as theres no user
accessible way to make this fail.

Regards,
Peter

> +object_property_set_bool(cpuobj, true, "realized", &err);
> +if (err) {
> +error_report("%s", error_get_pretty(err));
>  exit(1);
>  }
>  }
> --
> 1.8.5
>
>



Re: [Qemu-devel] [PATCH 6/9] w32: Add and use intermediate include file for windows.h

2014-02-25 Thread Paolo Bonzini

Il 25/02/2014 00:00, Stefan Weil ha scritto:

Ah, thanks for explaining. I'll use the suggested name in an updated
series. But you are aware that qga/ already includes sysemu/os-posix.h
and sysemu/os-win32.h indirectly? Should those two files also be in
include/qemu?


No, but perhaps part of it should be moved to qemu/osdep.h?

Paolo



Re: [Qemu-devel] Add a new hardware

2014-02-25 Thread Andreas Färber
Am 21.02.2014 10:34, schrieb atlas khan:
> I am working on project in which we have add support of a board in
> QEMU. We have to add some virtual devices in QEMU. The question which
> I want to ask that what should I do to add virtual device. And after
> adding that device in \hw in which file I have to make changes so that
> program access that hardware when it need it. Because the device which
> I have to add is the device which is already available, but in our
> board, this device has different architecture, so we want our program
> to access that file which we have made for our board instead of file
> which is already available in QEMU

Your question sounds slightly confused.

Either you want to add a new device, then place it in the appropriate
subdirectory of hw/ and add it to Makefile.objs - common-obj-y preferably.

Or you want to enable a device that already exists there to another
softmmu target, then you need to edit default-configs/*-softmmu.mak.

Otherwise, what does the architecture have to do with the device and why
would you want to replace some file?

All of this would've been much easier to answer had you actually
mentioned which file you are talking about and which board/architecture
you are working on! Attaching a patch of what you already have (or short
of that posting a link to your public repository) would also help to
spot what you're missing.

Cheers,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



Re: [Qemu-devel] [PATCH 0/9] w32: Reduce dependency on Windows API

2014-02-25 Thread Paolo Bonzini

Il 25/02/2014 06:32, Stefan Weil ha scritto:

Am 23.02.2014 18:02, schrieb Stefan Weil:

Today, most .o files depend on windows.h when QEMU is built with MinGW or
MinGW-w64 (32 and 64 bit builds). These patches reduce the number of such
files from more than 1800 to less than 180. They also allow removing some
hacks which were needed because of conflicts with windows.h. A nasty
compiler warning is fixed, too.

The modifications were tested with MinGW (32 bit native) and MinGW-w64
(32 and 64 bit cross).

Regards
Stefan W.

[PATCH 1/9] util/iov: Use qemu/sockets.h instead of conditional code
[PATCH 2/9] exec: Remove unneeded include files
[PATCH 3/9] qemu-img: Remove unneeded include files
[PATCH 4/9] qga: Remove unneeded include file
[PATCH 5/9] vl: Remove unneeded include file
[PATCH 6/9] w32: Add and use intermediate include file for windows.h
[PATCH 7/9] w32: Move inline function from header file to C source
[PATCH 8/9] w32: Reduce dependencies in sysemu/os-win32.h
[PATCH 9/9] w32: Replace Windows specific data types in common



This patch series needs at least one more iteration with a v2.

Patches 1-5 can be applied independently of the rest and are trivial, so
maybe they can be applied by qemu-trivial, or I can send a pull request
for only those patches as soon as they were reviewed. That would reduce
the size of my v2 patch set.


Patches 1-5 are

Reviewed-by: Paolo Bonzini 

Thanks for all the effort you put in janitorial work, it's as thankless 
as it's useful!


Paolo




Re: [Qemu-devel] [PATCH 2/3] target-i386: Fix SSE status flag corruption

2014-02-25 Thread Paolo Bonzini

Il 25/02/2014 08:30, Richard Henderson ha scritto:

When we restore the mxcsr register with FXRSTOR, or set it with gdb,
we need to update the various SSE status flags in CPUX86State

Reported-by: Richard Purdie 
Signed-off-by: Richard Henderson 
---
Differs from Purdie's patch primarily in fixing gdb too.  And that
required exporting update_sse_status.  Which suggested that the name
and interface be changed to match the norm.


r~
---
 target-i386/cpu.h|  3 +++
 target-i386/fpu_helper.c | 15 ---
 target-i386/gdbstub.c|  2 +-
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 1b94f0f..5d3f143 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -1259,6 +1259,9 @@ static inline void cpu_load_efer(CPUX86State *env, 
uint64_t val)
 }
 }

+/* fpu_helper.c */
+void cpu_set_mxcsr(CPUX86State *env, uint32_t val);
+
 /* svm_helper.c */
 void cpu_svm_check_intercept_param(CPUX86State *env1, uint32_t type,
uint64_t param);
diff --git a/target-i386/fpu_helper.c b/target-i386/fpu_helper.c
index c0427fe..de7ba76 100644
--- a/target-i386/fpu_helper.c
+++ b/target-i386/fpu_helper.c
@@ -1179,7 +1179,7 @@ void helper_fxrstor(CPUX86State *env, target_ulong ptr, 
int data64)

 if (env->cr[4] & CR4_OSFXSR_MASK) {
 /* XXX: finish it */
-env->mxcsr = cpu_ldl_data(env, ptr + 0x18);
+cpu_set_mxcsr(env, cpu_ldl_data(env, ptr + 0x18));
 /* cpu_ldl_data(env, ptr + 0x1c); */
 if (env->hflags & HF_CS64_MASK) {
 nb_xmm_regs = 16;
@@ -1229,12 +1229,14 @@ floatx80 cpu_set_fp80(uint64_t mant, uint16_t upper)
 #define SSE_RC_CHOP 0x6000
 #define SSE_FZ  0x8000

-static void update_sse_status(CPUX86State *env)
+void cpu_set_mxcsr(CPUX86State *env, uint32_t mxcsr)
 {
 int rnd_type;

+env->mxcsr = mxcsr;
+
 /* set rounding mode */
-switch (env->mxcsr & SSE_RC_MASK) {
+switch (mxcsr & SSE_RC_MASK) {
 default:
 case SSE_RC_NEAR:
 rnd_type = float_round_nearest_even;
@@ -1252,16 +1254,15 @@ static void update_sse_status(CPUX86State *env)
 set_float_rounding_mode(rnd_type, &env->sse_status);

 /* set denormals are zero */
-set_flush_inputs_to_zero((env->mxcsr & SSE_DAZ) ? 1 : 0, &env->sse_status);
+set_flush_inputs_to_zero((mxcsr & SSE_DAZ) ? 1 : 0, &env->sse_status);

 /* set flush to zero */
-set_flush_to_zero((env->mxcsr & SSE_FZ) ? 1 : 0, &env->fp_status);
+set_flush_to_zero((mxcsr & SSE_FZ) ? 1 : 0, &env->fp_status);
 }

 void helper_ldmxcsr(CPUX86State *env, uint32_t val)
 {
-env->mxcsr = val;
-update_sse_status(env);
+cpu_set_mxcsr(env, val);
 }

 void helper_enter_mmx(CPUX86State *env)
diff --git a/target-i386/gdbstub.c b/target-i386/gdbstub.c
index 15bebef..d34e535 100644
--- a/target-i386/gdbstub.c
+++ b/target-i386/gdbstub.c
@@ -222,7 +222,7 @@ int x86_cpu_gdb_write_register(CPUState *cs, uint8_t 
*mem_buf, int n)
 return 4;

 case IDX_MXCSR_REG:
-env->mxcsr = ldl_p(mem_buf);
+cpu_set_mxcsr(env, ldl_p(mem_buf));
 return 4;
 }
 }



Reviewed-by: Paolo Bonzini 



Re: [Qemu-devel] [PATCH 4/4] virt: Set reset-cbar on CPUs

2014-02-25 Thread Peter Crosthwaite
On Tue, Feb 25, 2014 at 6:24 AM, Peter Maydell  wrote:
> Set the reset-cbar property on CPUs used by the virt board,
> if they have it. This isn't necessary for correct functioning
> under Linux (since the A9 isn't a valid CPU for the virt board),
> but it is the correct behaviour.
>
> Signed-off-by: Peter Maydell 
> ---
>  hw/arm/virt.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 517f2fe..b418b77 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -379,6 +379,7 @@ static void machvirt_init(QEMUMachineInitArgs *args)
>  for (n = 0; n < smp_cpus; n++) {
>  ObjectClass *oc = cpu_class_by_name(TYPE_ARM_CPU, cpu_model);
>  Object *cpuobj;
> +Error *err = NULL;
>
>  if (!oc) {
>  fprintf(stderr, "Unable to find CPU definition\n");
> @@ -390,6 +391,16 @@ static void machvirt_init(QEMUMachineInitArgs *args)
>  if (n > 0) {
>  object_property_set_bool(cpuobj, true, "start-powered-off", 
> NULL);
>  }
> +
> +if (object_property_find(cpuobj, "reset-cbar", NULL)) {
> +object_property_set_int(cpuobj, 
> vbi->memmap[VIRT_CPUPERIPHS].base,
> +"reset-cbar", &err);
> +if (err) {
> +error_report("%s", error_get_pretty(err));
> +exit(1);
> +}

If the property exists (as enforced by the if), and you cant set it,
its probably a fatal and candidate for error_abort.

Regards,
Peter

> +}
> +
>  object_property_set_bool(cpuobj, true, "realized", NULL);
>  }
>  fdt_add_cpu_nodes(vbi);
> --
> 1.8.5
>
>



Re: [Qemu-devel] QOM vs QAPI for QMP APIs

2014-02-25 Thread Markus Armbruster
Eric Blake  writes:

> On 02/24/2014 01:29 AM, Markus Armbruster wrote:
>
>>>
>>> The other burden is documenting what QOM paths to be queried, and
>>> knowing where to find that documentation.  That is, it's another layer
>>> of complexity, but it's also a more powerful expression.
>>>
>>> I'm comparing this situation somewhat to libvirt's 'virsh
>>> qemu-monitor-command' vs. other libvirt commands.  qemu-monitor-command
>>> is a more powerful interface (via libvirt, you can issue ANY qmp
>>> command), and is therefore great for development for testing something
>>> that libvirt has not yet supported; but not so nice to the end user
>>> (it's use is explicitly unsupported).  What happens is that as people
>>> say "I had to use qemu-monitor-command to do task A", it is a hint to
>>> libvirt development to say "oh, we need to add an API to make task A
>>> easier to do".
>>>
>>> Thus, having qom-find-objects-by-class is a good idea, even if it is
>>> more awkward to use than a dedicated qmp command.  But meanwhile, we
>>> should watch what common patterns it gets used for, and add dedicated
>>> QMP commands for those patterns.  It's much faster to get a chunk of
>>> information in one QMP call already formatted into desired structs than
>>> it is to make a series of QMP calls to learn about the lower-level qom
>>> model one piece at a time.
>> 
>> You didn't spell out the ABI promises here.  Do you argue for providing
>> QOM interfaces as unstable low-level interfaces?
>
> Haven't we already done that in the past?  For example, object-add
> currently takes an unspecified dictionary of options, where you would
> have to consult QOM documentation to learn what makes sense to send.

My question isn't about where the command details are documented, or
even whether they are documented.  It's about ABI promises, or lack
thereof.  The general promise for QMP is we treat it as stable ABI.  If
we add QMP commands to examine and manipulate QOM, doesn't that move all
of QOM under the QMP ABI promise, unless we explicitly excempt it?



Re: [Qemu-devel] [PATCH 2/4] realview-pbx-a9: Set reset-cbar property for CPUs

2014-02-25 Thread Peter Crosthwaite
On Tue, Feb 25, 2014 at 6:24 AM, Peter Maydell  wrote:
> If the CPU is a Cortex-A9 then we should set its reset-cbar property
> so that the guest can read the correct PERIPHBASE/CBAR register value;
> newer versions of the Linux kernel (as of commit bc41b8724 in 3.12)
> will otherwise assume the CPU is a buggy single core A9 SoC. The
> realview-pbx-a9 is the only one of the cluster of boards in realview.c
> which works with the Cortex-A9 (ie which gets an a9mpcore_priv device);
> make sure it also has reset-cbar set correctly.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Peter Crosthwaite 

> ---
>  hw/arm/realview.c | 39 +--
>  1 file changed, 29 insertions(+), 10 deletions(-)
>
> diff --git a/hw/arm/realview.c b/hw/arm/realview.c
> index 6ef7646..7e04e50 100644
> --- a/hw/arm/realview.c
> +++ b/hw/arm/realview.c
> @@ -18,6 +18,7 @@
>  #include "hw/i2c/i2c.h"
>  #include "sysemu/blockdev.h"
>  #include "exec/address-spaces.h"
> +#include "qemu/error-report.h"
>
>  #define SMP_BOOT_ADDR 0xe000
>  #define SMP_BOOTREG_ADDR 0x1030
> @@ -49,6 +50,7 @@ static void realview_init(QEMUMachineInitArgs *args,
>  {
>  ARMCPU *cpu = NULL;
>  CPUARMState *env;
> +ObjectClass *cpu_oc;
>  MemoryRegion *sysmem = get_system_memory();
>  MemoryRegion *ram_lo = g_new(MemoryRegion, 1);
>  MemoryRegion *ram_hi = g_new(MemoryRegion, 1);
> @@ -70,12 +72,14 @@ static void realview_init(QEMUMachineInitArgs *args,
>  uint32_t sys_id;
>  ram_addr_t low_ram_size;
>  ram_addr_t ram_size = args->ram_size;
> +hwaddr periphbase = 0;
>
>  switch (board_type) {
>  case BOARD_EB:
>  break;
>  case BOARD_EB_MPCORE:
>  is_mpcore = 1;
> +periphbase = 0x1010;
>  break;
>  case BOARD_PB_A8:
>  is_pb = 1;
> @@ -83,16 +87,37 @@ static void realview_init(QEMUMachineInitArgs *args,
>  case BOARD_PBX_A9:
>  is_mpcore = 1;
>  is_pb = 1;
> +periphbase = 0x1f00;
>  break;
>  }
> +
> +cpu_oc = cpu_class_by_name(TYPE_ARM_CPU, args->cpu_model);
> +if (!cpu_oc) {
> +fprintf(stderr, "Unable to find CPU definition\n");
> +exit(1);
> +}
> +
>  for (n = 0; n < smp_cpus; n++) {
> -cpu = cpu_arm_init(args->cpu_model);
> -if (!cpu) {
> -fprintf(stderr, "Unable to find CPU definition\n");
> +Object *cpuobj = object_new(object_class_get_name(cpu_oc));
> +Error *err = NULL;
> +
> +if (is_pb && is_mpcore) {
> +object_property_set_int(cpuobj, periphbase, "reset-cbar", &err);
> +if (err) {
> +error_report("%s", error_get_pretty(err));
> +exit(1);
> +}
> +}
> +
> +object_property_set_bool(cpuobj, true, "realized", &err);
> +if (err) {
> +error_report("%s", error_get_pretty(err));
>  exit(1);
>  }
> -cpu_irq[n] = qdev_get_gpio_in(DEVICE(cpu), ARM_CPU_IRQ);
> +
> +cpu_irq[n] = qdev_get_gpio_in(DEVICE(cpuobj), ARM_CPU_IRQ);
>  }
> +cpu = ARM_CPU(first_cpu);
>  env = &cpu->env;
>  if (arm_feature(env, ARM_FEATURE_V7)) {
>  if (is_mpcore) {
> @@ -141,16 +166,10 @@ static void realview_init(QEMUMachineInitArgs *args,
>  sysbus_mmio_map(SYS_BUS_DEVICE(sysctl), 0, 0x1000);
>
>  if (is_mpcore) {
> -hwaddr periphbase;
>  dev = qdev_create(NULL, is_pb ? "a9mpcore_priv": "realview_mpcore");
>  qdev_prop_set_uint32(dev, "num-cpu", smp_cpus);
>  qdev_init_nofail(dev);
>  busdev = SYS_BUS_DEVICE(dev);
> -if (is_pb) {
> -periphbase = 0x1f00;
> -} else {
> -periphbase = 0x1010;
> -}
>  sysbus_mmio_map(busdev, 0, periphbase);
>  for (n = 0; n < smp_cpus; n++) {
>  sysbus_connect_irq(busdev, n, cpu_irq[n]);
> --
> 1.8.5
>
>



Re: [Qemu-devel] QOM vs QAPI for QMP APIs

2014-02-25 Thread Andreas Färber
Am 25.02.2014 09:25, schrieb Markus Armbruster:
> Eric Blake  writes:
> 
>> On 02/24/2014 01:29 AM, Markus Armbruster wrote:
>>

 The other burden is documenting what QOM paths to be queried, and
 knowing where to find that documentation.  That is, it's another layer
 of complexity, but it's also a more powerful expression.

 I'm comparing this situation somewhat to libvirt's 'virsh
 qemu-monitor-command' vs. other libvirt commands.  qemu-monitor-command
 is a more powerful interface (via libvirt, you can issue ANY qmp
 command), and is therefore great for development for testing something
 that libvirt has not yet supported; but not so nice to the end user
 (it's use is explicitly unsupported).  What happens is that as people
 say "I had to use qemu-monitor-command to do task A", it is a hint to
 libvirt development to say "oh, we need to add an API to make task A
 easier to do".

 Thus, having qom-find-objects-by-class is a good idea, even if it is
 more awkward to use than a dedicated qmp command.  But meanwhile, we
 should watch what common patterns it gets used for, and add dedicated
 QMP commands for those patterns.  It's much faster to get a chunk of
 information in one QMP call already formatted into desired structs than
 it is to make a series of QMP calls to learn about the lower-level qom
 model one piece at a time.
>>>
>>> You didn't spell out the ABI promises here.  Do you argue for providing
>>> QOM interfaces as unstable low-level interfaces?
>>
>> Haven't we already done that in the past?  For example, object-add
>> currently takes an unspecified dictionary of options, where you would
>> have to consult QOM documentation to learn what makes sense to send.
> 
> My question isn't about where the command details are documented, or
> even whether they are documented.  It's about ABI promises, or lack
> thereof.  The general promise for QMP is we treat it as stable ABI.  If
> we add QMP commands to examine and manipulate QOM, doesn't that move all
> of QOM under the QMP ABI promise, unless we explicitly excempt it?

Anthony has clearly stated and I have been repeating that QOM follows
strict ABI stability rules for its properties, and that therefore
applies to what some of you still call "qdev" as well. Therefore my
nagging to get underscores vs. dashes right for new properties and
questioning attempted type changes without changing the property name.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



Re: [Qemu-devel] QOM vs QAPI for QMP APIs

2014-02-25 Thread Paolo Bonzini

Il 25/02/2014 09:25, Markus Armbruster ha scritto:

> Haven't we already done that in the past?  For example, object-add
> currently takes an unspecified dictionary of options, where you would
> have to consult QOM documentation to learn what makes sense to send.

My question isn't about where the command details are documented, or
even whether they are documented.  It's about ABI promises, or lack
thereof.  The general promise for QMP is we treat it as stable ABI.  If
we add QMP commands to examine and manipulate QOM, doesn't that move all
of QOM under the QMP ABI promise, unless we explicitly excempt it?


We did already exempt it, in general.  QOM is not declared stable.

However, there are parts (-object, and in 2.0 object_add/object-add) 
that are part of the QEMU API/ABI.  Now that we have a way to restrict 
which classes will be compatible (only classes that are UserCreatable 
can be created and thus will require backwards compatibility), we need 
to document those closses.


Paolo



Re: [Qemu-devel] [PATCH] configure: Make C++ test work with --enable-werror

2014-02-25 Thread Andreas Färber
Am 24.02.2014 20:08, schrieb Peter Maydell:
> gcc's C++ compiler complains about being passed some -W options
> which make sense for C but not for C++. This means we mustn't try
> a C++ compile with QEMU_CFLAGS, but only with a filtered version
> that removes the offending options. This filtering was already being
> done for uses of C++ in the build itself, but was omitted for the
> "does C++ work?" configure test. This only showed up when doing
> builds which explicitly enabled -Werror with --enable-werror,
> because the "do the compilers work" tests were mistakenly placed
> above the "default werror based on whether compiling from git" code.
> Further, when the test did fail configure would plunge on regardless
> of the error since we were running do_cc in a subshell. Fix this
> complex of errors:
> 
> 1. Move the default-werror code up so that there are no invocations
> of compile_object and friends between it and the point where we
> set $werror explicitly based on the --enable-werror command line
> option.
> 
> 2. Provide a mechanism for filtering QEMU_CFLAGS to create
> QEMU_CXXFLAGS, and use it for the test we run here.
> 
> 3. Provide a do_cxx function to run a test with the C++ compiler
> rather than doing cute tricks with subshells and do_cc.
> 
> Signed-off-by: Peter Maydell 

Tested-by: Andreas Färber 

Thanks,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



Re: [Qemu-devel] [PATCH v3 22/31] target-arm: A64: Implement MSR (immediate) instructions

2014-02-25 Thread Peter Crosthwaite
On Sun, Feb 16, 2014 at 2:07 AM, Peter Maydell  wrote:
> Implement the MSR (immediate) instructions, which can update the
> PSTATE SP and DAIF fields.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Peter Crosthwaite 

> ---
>  target-arm/helper.h|  2 ++
>  target-arm/op_helper.c | 25 +
>  target-arm/translate-a64.c | 25 -
>  3 files changed, 51 insertions(+), 1 deletion(-)
>
> diff --git a/target-arm/helper.h b/target-arm/helper.h
> index 19bd620..4a063c1 100644
> --- a/target-arm/helper.h
> +++ b/target-arm/helper.h
> @@ -63,6 +63,8 @@ DEF_HELPER_2(get_cp_reg, i32, env, ptr)
>  DEF_HELPER_3(set_cp_reg64, void, env, ptr, i64)
>  DEF_HELPER_2(get_cp_reg64, i64, env, ptr)
>
> +DEF_HELPER_3(msr_i_pstate, void, env, i32, i32)
> +
>  DEF_HELPER_2(get_r13_banked, i32, env, i32)
>  DEF_HELPER_3(set_r13_banked, void, env, i32, i32)
>
> diff --git a/target-arm/op_helper.c b/target-arm/op_helper.c
> index eb0fccd..7d06d2f 100644
> --- a/target-arm/op_helper.c
> +++ b/target-arm/op_helper.c
> @@ -319,6 +319,31 @@ uint64_t HELPER(get_cp_reg64)(CPUARMState *env, void 
> *rip)
>  return ri->readfn(env, ri);
>  }
>
> +void HELPER(msr_i_pstate)(CPUARMState *env, uint32_t op, uint32_t imm)
> +{
> +/* MSR_i to update PSTATE. This is OK from EL0 only if UMA is set.
> + * Note that SPSel is never OK from EL0; we rely on handle_msr_i()
> + * to catch that case at translate time.
> + */
> +if (arm_current_pl(env) == 0 && !(env->cp15.c1_sys & SCTLR_UMA)) {
> +raise_exception(env, EXCP_UDEF);
> +}
> +
> +switch (op) {
> +case 0x05: /* SPSel */
> +env->pstate = deposit32(env->pstate, 0, 1, imm);
> +break;
> +case 0x1e: /* DAIFSet */
> +env->daif |= (imm << 6) & PSTATE_DAIF;
> +break;
> +case 0x1f: /* DAIFClear */
> +env->daif &= ~((imm << 6) & PSTATE_DAIF);
> +break;
> +default:
> +g_assert_not_reached();
> +}
> +}
> +
>  /* ??? Flag setting arithmetic is awkward because we need to do comparisons.
> The only way to do that in TCG is a conditional branch, which clobbers
> all our temporaries.  For now implement these as helper functions.  */
> diff --git a/target-arm/translate-a64.c b/target-arm/translate-a64.c
> index 948470f..1054e38 100644
> --- a/target-arm/translate-a64.c
> +++ b/target-arm/translate-a64.c
> @@ -1113,7 +1113,30 @@ static void handle_sync(DisasContext *s, uint32_t insn,
>  static void handle_msr_i(DisasContext *s, uint32_t insn,
>   unsigned int op1, unsigned int op2, unsigned int 
> crm)
>  {
> -unsupported_encoding(s, insn);
> +int op = op1 << 3 | op2;
> +switch (op) {
> +case 0x05: /* SPSel */
> +if (s->current_pl == 0) {
> +unallocated_encoding(s);
> +return;
> +}
> +/* fall through */
> +case 0x1e: /* DAIFSet */
> +case 0x1f: /* DAIFClear */
> +{
> +TCGv_i32 tcg_imm = tcg_const_i32(crm);
> +TCGv_i32 tcg_op = tcg_const_i32(op);
> +gen_a64_set_pc_im(s->pc - 4);
> +gen_helper_msr_i_pstate(cpu_env, tcg_op, tcg_imm);
> +tcg_temp_free_i32(tcg_imm);
> +tcg_temp_free_i32(tcg_op);
> +s->is_jmp = DISAS_UPDATE;
> +break;
> +}
> +default:
> +unallocated_encoding(s);
> +return;
> +}
>  }
>
>  static void gen_get_nzcv(TCGv_i64 tcg_rt)
> --
> 1.8.5
>
>



Re: [Qemu-devel] QOM vs QAPI for QMP APIs

2014-02-25 Thread Andreas Färber
Am 25.02.2014 09:30, schrieb Paolo Bonzini:
> Il 25/02/2014 09:25, Markus Armbruster ha scritto:
>>> > Haven't we already done that in the past?  For example, object-add
>>> > currently takes an unspecified dictionary of options, where you would
>>> > have to consult QOM documentation to learn what makes sense to send.
>> My question isn't about where the command details are documented, or
>> even whether they are documented.  It's about ABI promises, or lack
>> thereof.  The general promise for QMP is we treat it as stable ABI.  If
>> we add QMP commands to examine and manipulate QOM, doesn't that move all
>> of QOM under the QMP ABI promise, unless we explicitly excempt it?
> 
> We did already exempt it, in general.  QOM is not declared stable.

Negative, QOM is stable in that properties may not change their type
incompatibly. Properties may be dropped/renamed, since that is
discoverable via qom-list, so it is less stable than the command line
interface.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



Re: [Qemu-devel] [PATCH v3 23/31] target-arm: Implement AArch64 view of CPACR

2014-02-25 Thread Peter Crosthwaite
On Sun, Feb 16, 2014 at 2:07 AM, Peter Maydell  wrote:
> Implement the AArch64 view of the CPACR. The AArch64
> CPACR is defined to have a lot of RES0 bits, but since
> the architecture defines that RES0 bits may be implemented
> as reads-as-written and we know that a v8 CPU will have
> no registered coprocessors for cp0..cp13 we can safely
> implement the whole register this way.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Peter Crosthwaite 

> ---
>  target-arm/cpu.h| 2 +-
>  target-arm/helper.c | 3 ++-
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/target-arm/cpu.h b/target-arm/cpu.h
> index 571b033..1f6f65d 100644
> --- a/target-arm/cpu.h
> +++ b/target-arm/cpu.h
> @@ -172,7 +172,7 @@ typedef struct CPUARMState {
>  uint32_t c0_cpuid;
>  uint64_t c0_cssel; /* Cache size selection.  */
>  uint64_t c1_sys; /* System control register.  */
> -uint32_t c1_coproc; /* Coprocessor access register.  */
> +uint64_t c1_coproc; /* Coprocessor access register.  */
>  uint32_t c1_xscaleauxcr; /* XScale auxiliary control register.  */
>  uint32_t c1_scr; /* secure config register.  */
>  uint64_t ttbr0_el1; /* MMU translation table base 0. */
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index c50ca5a..d35cc73 100644
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -458,7 +458,8 @@ static const ARMCPRegInfo v6_cp_reginfo[] = {
>   */
>  { .name = "WFAR", .cp = 15, .crn = 6, .crm = 0, .opc1 = 0, .opc2 = 1,
>.access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0, },
> -{ .name = "CPACR", .cp = 15, .crn = 1, .crm = 0, .opc1 = 0, .opc2 = 2,
> +{ .name = "CPACR", .state = ARM_CP_STATE_BOTH, .opc0 = 3,
> +  .crn = 1, .crm = 0, .opc1 = 0, .opc2 = 2,
>.access = PL1_RW, .fieldoffset = offsetof(CPUARMState, cp15.c1_coproc),
>.resetvalue = 0, .writefn = cpacr_write },
>  REGINFO_SENTINEL
> --
> 1.8.5
>
>



Re: [Qemu-devel] [PATCH v3 24/31] target-arm: Add utility function for checking AA32/64 state of an EL

2014-02-25 Thread Peter Crosthwaite
On Sun, Feb 16, 2014 at 2:07 AM, Peter Maydell  wrote:
> There are various situations where we need to behave differently
> depending on whether a given exception level is in AArch64 or
> AArch32 state. The state of the current exception level is stored
> in env->aarch64, but there's no equivalent guest-visible architected
> state bits for the status of the exception levels "above" the
> current one which may still affect execution. At the moment we
> only support EL1 (ie no EL2 or EL3) and insist that AArch64
> capable CPUs run with EL1 in AArch64 state, but these may change
> in the future, so abstract out the "what state is this?" check
> into a utility function which can be enhanced later if necessary.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Peter Crosthwaite 

> ---
>  target-arm/cpu.h | 16 
>  1 file changed, 16 insertions(+)
>
> diff --git a/target-arm/cpu.h b/target-arm/cpu.h
> index 1f6f65d..f530333 100644
> --- a/target-arm/cpu.h
> +++ b/target-arm/cpu.h
> @@ -633,6 +633,22 @@ static inline int arm_feature(CPUARMState *env, int 
> feature)
>  return (env->features & (1ULL << feature)) != 0;
>  }
>
> +/* Return true if the specified exception level is running in AArch64 state. 
> */
> +static inline bool arm_el_is_aa64(CPUARMState *env, int el)
> +{
> +/* We don't currently support EL2 or EL3, and this isn't valid for EL0
> + * (if we're in EL0, is_a64() is what you want, and if we're not in EL0
> + * then the state of EL0 isn't well defined.)
> + */
> +assert(el == 1);
> +/* AArch64-capable CPUs always run with EL1 in AArch64 mode. This
> + * is a QEMU-imposed simplification which we may wish to change later.
> + * If we in future support EL2 and/or EL3, then the state of lower
> + * exception levels is controlled by the HCR.RW and SCR.RW bits.
> + */
> +return arm_feature(env, ARM_FEATURE_AARCH64);
> +}
> +
>  void arm_cpu_list(FILE *f, fprintf_function cpu_fprintf);
>
>  /* Interface between CPU and Interrupt controller.  */
> --
> 1.8.5
>
>



Re: [Qemu-devel] [PATCH 9/9] w32: Replace Windows specific data types in common header files

2014-02-25 Thread Andreas Färber
Am 25.02.2014 00:07, schrieb Stefan Weil:
> Am 24.02.2014 14:07, schrieb Andreas Färber:
>> Am 23.02.2014 18:02, schrieb Stefan Weil:
>>> These header files are used by most QEMU source files. If they
>>> depend on windows.h, all those source files do so, too.
>>>
> [...]
>>
>> First of all, why was I not CC'ed on this change?
>> File is listed under "CPU" subsystem in MAINTAINERS.
>>
>> Patches not getting sufficient review is one risk, causing merge
>> conflicts another. People should be aware of changes you make in their
>> files, even if "just" Windows-related.
> 
> Sorry, I simply missed your name in the lengthy output from
> get_maintainer.pl.
> 
>> I had moved the field unchanged from another header, I believe. I don't
>> think this is a good change (assuming the Windows API is still using
>> this type and not void*), especially since it's #ifdef'ed anyway.
> 
> Please see my mail to Kevin (which will be sent in a moment).

My opinion still stands. You can easily add "typedef void * HANDLE;" to
qemu-typedefs.h or osdep.h to retain telling type names, in this case
explaining why the variable is called "hThread" - h for "HANDLE".

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation

2014-02-25 Thread Alex Bennée

Dann Frazier  writes:

> On Mon, Feb 17, 2014 at 6:40 AM, Alex Bennée  wrote:
>> Hi,
>
> Thanks to all involved for your work here!
>
>> After a solid few months of work the QEMU master branch [1] has now reached
>> instruction feature parity with the suse-1.6 [6] tree that a lot of people
>> have been using to build various aarch64 binaries. In addition to the

>>
>> I've tested against the following aarch64 rootfs:
>> * SUSE [2]
>> * Debian [3]
>> * Ubuntu Saucy [4]
>
> fyi, I've been doing my testing with Ubuntu Trusty.

Good stuff, I shall see if I can set one up. Is the package coverage
between trusty and saucy much different? I noticed for example I
couldn't find zile and various build-deps for llvm.


>>
>> Feedback I'm interested in
>> ==
>>
>> * Any instruction failure (please include the log line with the
>>   unsupported message)
>> * Any aarch64 specific failures (i.e. not generic QEMU threading flakeiness).
>
> I'm not sure if this qualifies as generic QEMU threading flakiness or not. 
> I've
> found a couple conditions that causes master to core dump fairly
> reliably, while the aarch64-1.6 branch seems to consistently work
> fine.
>
>  1) dh_fixperms is a script that commonly runs at the end of a package build.
>  Its basically doing a `find | xargs chmod`.
>  2) debootstrap --second-stage
>  This is used to configure an arm64 chroot that was built using
>  debootstrap on a non-native host. It is basically invoking a bunch of
>  shell scripts (postinst, etc). When it blows up, the stack consistently
>  looks like this:
>
> Core was generated by `/usr/bin/qemu-aarch64-static /bin/sh -e
> /debootstrap/debootstrap --second-stage'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x60058e55 in memcpy (__len=8, __src=0x7fff62ae34e0,
> __dest=0x400082c330) at
> /usr/include/x86_64-linux-gnu/bits/string3.h:51
> 51  return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
> (gdb) bt
> #0  0x60058e55 in memcpy (__len=8, __src=0x7fff62ae34e0,
> __dest=0x400082c330) at
> /usr/include/x86_64-linux-gnu/bits/string3.h:51
> #1  stq_p (v=274886476624, ptr=0x400082c330) at
> /mnt/qemu.upstream/include/qemu/bswap.h:280
> #2  stq_le_p (v=274886476624, ptr=0x400082c330) at
> /mnt/qemu.upstream/include/qemu/bswap.h:315
> #3  target_setup_sigframe (set=0x7fff62ae3530, env=0x62d9c678,
> sf=0x400082b0d0) at /mnt/qemu.upstream/linux-user/signal.c:1167
> #4  target_setup_frame (usig=usig@entry=17, ka=ka@entry=0x604ec1e0
> , info=info@entry=0x0, set=set@entry=0x7fff62ae3530,
> env=env@entry=0x62d9c678)
> at /mnt/qemu.upstream/linux-user/signal.c:1286
> #5  0x60059f46 in setup_frame (env=0x62d9c678,
> set=0x7fff62ae3530, ka=0x604ec1e0 , sig=17) at
> /mnt/qemu.upstream/linux-user/signal.c:1322
> #6  process_pending_signals (cpu_env=cpu_env@entry=0x62d9c678) at
> /mnt/qemu.upstream/linux-user/signal.c:5747
> #7  0x60056e60 in cpu_loop (env=env@entry=0x62d9c678) at
> /mnt/qemu.upstream/linux-user/main.c:1082
> #8  0x60005079 in main (argc=, argv= out>, envp=) at
> /mnt/qemu.upstream/linux-user/main.c:4374
>
> There are some pretty large differences between these trees with
> respect to signal syscalls - is that the likely culprit?

Quite likely. We explicitly concentrated on the arch64 specific
instruction emulation leaving more generic patches to flow in from SUSE
as they matured.

I guess it's time to go through the remaining patches and see what's 
up-streamable.

Alex/Michael,

Are any of these patches in flight now?

Cheers,

--
Alex Bennée
QEMU/KVM Hacker for Linaro





Re: [Qemu-devel] [PATCH 0/9] w32: Reduce dependency on Windows API

2014-02-25 Thread Andreas Färber
Am 25.02.2014 09:20, schrieb Paolo Bonzini:
> Il 25/02/2014 06:32, Stefan Weil ha scritto:
>> Am 23.02.2014 18:02, schrieb Stefan Weil:
>>> Today, most .o files depend on windows.h when QEMU is built with
>>> MinGW or
>>> MinGW-w64 (32 and 64 bit builds). These patches reduce the number of
>>> such
>>> files from more than 1800 to less than 180. They also allow removing
>>> some
>>> hacks which were needed because of conflicts with windows.h. A nasty
>>> compiler warning is fixed, too.
>>>
>>> The modifications were tested with MinGW (32 bit native) and MinGW-w64
>>> (32 and 64 bit cross).
>>>
>>> Regards
>>> Stefan W.
>>>
>>> [PATCH 1/9] util/iov: Use qemu/sockets.h instead of conditional code
>>> [PATCH 2/9] exec: Remove unneeded include files
>>> [PATCH 3/9] qemu-img: Remove unneeded include files
>>> [PATCH 4/9] qga: Remove unneeded include file
>>> [PATCH 5/9] vl: Remove unneeded include file
>>> [PATCH 6/9] w32: Add and use intermediate include file for windows.h
>>> [PATCH 7/9] w32: Move inline function from header file to C source
>>> [PATCH 8/9] w32: Reduce dependencies in sysemu/os-win32.h
>>> [PATCH 9/9] w32: Replace Windows specific data types in common
>>>
>>
>> This patch series needs at least one more iteration with a v2.
>>
>> Patches 1-5 can be applied independently of the rest and are trivial, so
>> maybe they can be applied by qemu-trivial, or I can send a pull request
>> for only those patches as soon as they were reviewed. That would reduce
>> the size of my v2 patch set.
> 
> Patches 1-5 are
> 
> Reviewed-by: Paolo Bonzini 

Seconded, no objections to those,

Reviewed-by: Andreas Färber 

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



Re: [Qemu-devel] [PATCH] qerror: Improve QERR_DEVICE_NOT_ACTIVE message

2014-02-25 Thread Markus Armbruster
Hani Benhabiles  writes:

> The error message as currently used is confusing as there are no "balloon" or
> "spice" devices.
>
> (qemu) balloon 1024
> balloon: Device 'balloon' has not been activated
>
> With this patch:
>
> (qemu) balloon 1024
> balloon: No balloon device has been activated
>
> Signed-off-by: Hani Benhabiles 
> Suggested-by: Markus Armbruster 
> ---
>  include/qapi/qmp/qerror.h | 2 +-
>  qmp.c | 2 --
>  2 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/include/qapi/qmp/qerror.h b/include/qapi/qmp/qerror.h
> index 73c67b7..25193c9 100644
> --- a/include/qapi/qmp/qerror.h
> +++ b/include/qapi/qmp/qerror.h
> @@ -105,7 +105,7 @@ void qerror_report_err(Error *err);
>  ERROR_CLASS_GENERIC_ERROR, "Device '%s' does not support hotplugging"
>  
>  #define QERR_DEVICE_NOT_ACTIVE \
> -ERROR_CLASS_DEVICE_NOT_ACTIVE, "Device '%s' has not been activated"
> +ERROR_CLASS_DEVICE_NOT_ACTIVE, "No %s device has been activated"
>  
>  #define QERR_DEVICE_NOT_ENCRYPTED \
>  ERROR_CLASS_GENERIC_ERROR, "Device '%s' is not encrypted"
> diff --git a/qmp.c b/qmp.c
> index d0d98e7..ffddd26 100644
> --- a/qmp.c
> +++ b/qmp.c
> @@ -289,7 +289,6 @@ void qmp_set_password(const char *protocol, const char 
> *password,
>  
>  if (strcmp(protocol, "spice") == 0) {
>  if (!using_spice) {
> -/* correct one? spice isn't a device ,,, */
>  error_set(errp, QERR_DEVICE_NOT_ACTIVE, "spice");
>  return;
>  }
> @@ -337,7 +336,6 @@ void qmp_expire_password(const char *protocol, const char 
> *whenstr,
>  
>  if (strcmp(protocol, "spice") == 0) {
>  if (!using_spice) {
> -/* correct one? spice isn't a device ,,, */
>  error_set(errp, QERR_DEVICE_NOT_ACTIVE, "spice");
>  return;
>  }

The wording of the error message is still suboptimal for the
!using_spice case, but it's an improvement.  I'd leave the two comments
alone, though.  Hani, if you agree, then Luiz could perhaps merge your
patch with these two hunks dropped.

Reviewed-by: Markus Armbruster 



Re: [Qemu-devel] [PATCH 1/4] vexpress: Set reset-cbar property for CPUs

2014-02-25 Thread Peter Crosthwaite
On Tue, Feb 25, 2014 at 6:23 AM, Peter Maydell  wrote:
> Newer versions of the Linux kernel (as of commit bc41b8724 in 3.12)
> now assume that if the CPU is a Cortex-A9 and the reset value of the
> PERIPHBASE/CBAR register is zero then the CPU is a specific buggy
> single core A9 SoC, and will not try to start other cores. Since we
> now have a CPU property for the reset value of the CBAR, we can
> just fix the vexpress board model to correctly set CBAR so SMP
> works again. To avoid duplicate boilerplate code in both the A9
> and A15 daughterboard init functions, we split out the CPU and
> private memory region init to its own function.
>
> Signed-off-by: Peter Maydell 
> Reported-by: Rob Herring 

Reviewed-by: Peter Crosthwaite 

> ---
>  hw/arm/vexpress.c | 123 
> +++---
>  1 file changed, 61 insertions(+), 62 deletions(-)
>
> diff --git a/hw/arm/vexpress.c b/hw/arm/vexpress.c
> index ef1707a..67628af 100644
> --- a/hw/arm/vexpress.c
> +++ b/hw/arm/vexpress.c
> @@ -32,6 +32,7 @@
>  #include "sysemu/blockdev.h"
>  #include "hw/block/flash.h"
>  #include "sysemu/device_tree.h"
> +#include "qemu/error-report.h"
>  #include 
>
>  #define VEXPRESS_BOARD_ID 0x8e0
> @@ -173,6 +174,64 @@ struct VEDBoardInfo {
>  DBoardInitFn *init;
>  };
>
> +static void init_cpus(const char *cpu_model, const char *privdev,
> +  hwaddr periphbase, qemu_irq *pic)
> +{
> +ObjectClass *cpu_oc = cpu_class_by_name(TYPE_ARM_CPU, cpu_model);
> +DeviceState *dev;
> +SysBusDevice *busdev;
> +int n;
> +
> +if (!cpu_oc) {
> +fprintf(stderr, "Unable to find CPU definition\n");
> +exit(1);
> +}
> +
> +/* Create the actual CPUs */
> +for (n = 0; n < smp_cpus; n++) {
> +Object *cpuobj = object_new(object_class_get_name(cpu_oc));
> +Error *err = NULL;
> +
> +object_property_set_int(cpuobj, periphbase, "reset-cbar", &err);
> +if (err) {
> +error_report("%s", error_get_pretty(err));
> +exit(1);
> +}
> +object_property_set_bool(cpuobj, true, "realized", &err);
> +if (err) {
> +error_report("%s", error_get_pretty(err));
> +exit(1);
> +}
> +}
> +
> +/* Create the private peripheral devices (including the GIC);
> + * this must happen after the CPUs are created because a15mpcore_priv
> + * wires itself up to the CPU's generic_timer gpio out lines.
> + */
> +dev = qdev_create(NULL, privdev);
> +qdev_prop_set_uint32(dev, "num-cpu", smp_cpus);
> +qdev_init_nofail(dev);
> +busdev = SYS_BUS_DEVICE(dev);
> +sysbus_mmio_map(busdev, 0, periphbase);
> +
> +/* Interrupts [42:0] are from the motherboard;
> + * [47:43] are reserved; [63:48] are daughterboard
> + * peripherals. Note that some documentation numbers
> + * external interrupts starting from 32 (because there
> + * are internal interrupts 0..31).
> + */
> +for (n = 0; n < 64; n++) {
> +pic[n] = qdev_get_gpio_in(dev, n);
> +}
> +
> +/* Connect the CPUs to the GIC */
> +for (n = 0; n < smp_cpus; n++) {
> +DeviceState *cpudev = DEVICE(qemu_get_cpu(n));
> +
> +sysbus_connect_irq(busdev, n, qdev_get_gpio_in(cpudev, ARM_CPU_IRQ));
> +}
> +}
> +
>  static void a9_daughterboard_init(const VEDBoardInfo *daughterboard,
>ram_addr_t ram_size,
>const char *cpu_model,
> @@ -181,25 +240,12 @@ static void a9_daughterboard_init(const VEDBoardInfo 
> *daughterboard,
>  MemoryRegion *sysmem = get_system_memory();
>  MemoryRegion *ram = g_new(MemoryRegion, 1);
>  MemoryRegion *lowram = g_new(MemoryRegion, 1);
> -DeviceState *dev;
> -SysBusDevice *busdev;
> -int n;
> -qemu_irq cpu_irq[4];
>  ram_addr_t low_ram_size;
>
>  if (!cpu_model) {
>  cpu_model = "cortex-a9";
>  }
>
> -for (n = 0; n < smp_cpus; n++) {
> -ARMCPU *cpu = cpu_arm_init(cpu_model);
> -if (!cpu) {
> -fprintf(stderr, "Unable to find CPU definition\n");
> -exit(1);
> -}
> -cpu_irq[n] = qdev_get_gpio_in(DEVICE(cpu), ARM_CPU_IRQ);
> -}
> -
>  if (ram_size > 0x4000) {
>  /* 1GB is the maximum the address space permits */
>  fprintf(stderr, "vexpress-a9: cannot model more than 1GB RAM\n");
> @@ -221,23 +267,7 @@ static void a9_daughterboard_init(const VEDBoardInfo 
> *daughterboard,
>  memory_region_add_subregion(sysmem, 0x6000, ram);
>
>  /* 0x1e00 A9MPCore (SCU) private memory region */
> -dev = qdev_create(NULL, "a9mpcore_priv");
> -qdev_prop_set_uint32(dev, "num-cpu", smp_cpus);
> -qdev_init_nofail(dev);
> -busdev = SYS_BUS_DEVICE(dev);
> -sysbus_mmio_map(busdev, 0, 0x1e00);
> -for (n = 0; n < smp_cpus; n++) {
> -sysbus_connect_irq(busdev, n, cpu_irq[n]);
> -}
> - 

Re: [Qemu-devel] [PATCH] qerror: Improve QERR_DEVICE_NOT_ACTIVE message

2014-02-25 Thread Hani Benhabiles
On Tue, Feb 25, 2014 at 09:41:02AM +0100, Markus Armbruster wrote:
> Hani Benhabiles  writes:
> 
> > The error message as currently used is confusing as there are no "balloon" 
> > or
> > "spice" devices.
> >
> > (qemu) balloon 1024
> > balloon: Device 'balloon' has not been activated
> >
> > With this patch:
> >
> > (qemu) balloon 1024
> > balloon: No balloon device has been activated
> >
> > Signed-off-by: Hani Benhabiles 
> > Suggested-by: Markus Armbruster 
> > ---
> >  include/qapi/qmp/qerror.h | 2 +-
> >  qmp.c | 2 --
> >  2 files changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/include/qapi/qmp/qerror.h b/include/qapi/qmp/qerror.h
> > index 73c67b7..25193c9 100644
> > --- a/include/qapi/qmp/qerror.h
> > +++ b/include/qapi/qmp/qerror.h
> > @@ -105,7 +105,7 @@ void qerror_report_err(Error *err);
> >  ERROR_CLASS_GENERIC_ERROR, "Device '%s' does not support hotplugging"
> >  
> >  #define QERR_DEVICE_NOT_ACTIVE \
> > -ERROR_CLASS_DEVICE_NOT_ACTIVE, "Device '%s' has not been activated"
> > +ERROR_CLASS_DEVICE_NOT_ACTIVE, "No %s device has been activated"
> >  
> >  #define QERR_DEVICE_NOT_ENCRYPTED \
> >  ERROR_CLASS_GENERIC_ERROR, "Device '%s' is not encrypted"
> > diff --git a/qmp.c b/qmp.c
> > index d0d98e7..ffddd26 100644
> > --- a/qmp.c
> > +++ b/qmp.c
> > @@ -289,7 +289,6 @@ void qmp_set_password(const char *protocol, const char 
> > *password,
> >  
> >  if (strcmp(protocol, "spice") == 0) {
> >  if (!using_spice) {
> > -/* correct one? spice isn't a device ,,, */
> >  error_set(errp, QERR_DEVICE_NOT_ACTIVE, "spice");
> >  return;
> >  }
> > @@ -337,7 +336,6 @@ void qmp_expire_password(const char *protocol, const 
> > char *whenstr,
> >  
> >  if (strcmp(protocol, "spice") == 0) {
> >  if (!using_spice) {
> > -/* correct one? spice isn't a device ,,, */
> >  error_set(errp, QERR_DEVICE_NOT_ACTIVE, "spice");
> >  return;
> >  }
> 
> The wording of the error message is still suboptimal for the
> !using_spice case, but it's an improvement.  I'd leave the two comments
> alone, though.  Hani, if you agree, then Luiz could perhaps merge your
> patch with these two hunks dropped.
> 
> Reviewed-by: Markus Armbruster 

Sure, no problem with dropping them. Thanks for the review, Markus!





Re: [Qemu-devel] [PATCH qom-next v1 0/6] SSI QOM cleanups

2014-02-25 Thread Peter Crosthwaite
Ping!

On Wed, Feb 12, 2014 at 10:27 AM, Peter Crosthwaite
 wrote:
> Hi Andreas,
>
> Here is a mixed bag of QOM cleanups, moving us slightly closer to
> QOMification of SSI.
>
> This prepares support for some major refactoring around SSI (in
> particular some QSPI patches).
>
> Regards,
> Peter
>
>
> Peter Crosthwaite (6):
>   ssi: Convert legacy casts from SSI_SLAVE->DEVICE
>   ssi: Remove legacy SSI_BUS->BUS cast
>   misc: max111x: Create abstract max111x class
>   misc: max111x: QOM casting sweep
>   ssi: Remove SSI_SLAVE_FROM_QDEV macro
>   block/m25p80: Remove FROM_SSI_SLAVE usages
>
>  hw/arm/spitz.c   |  9 +
>  hw/block/m25p80.c|  6 +++---
>  hw/display/ads7846.c |  2 +-
>  hw/display/ssd0323.c |  4 ++--
>  hw/misc/max111x.c| 46 +-
>  hw/sd/ssi-sd.c   |  2 +-
>  hw/ssi/ssi.c |  4 ++--
>  include/hw/ssi.h |  1 -
>  8 files changed, 47 insertions(+), 27 deletions(-)
>
> --
> 1.8.5.4
>



Re: [Qemu-devel] [PATCH microblaze/ppc v2 0/8] Remove include/hw/xilinx.h

2014-02-25 Thread Peter Crosthwaite
Ping!

On Thu, Feb 13, 2014 at 9:21 AM, Peter Crosthwaite
 wrote:
> Hi Edgar,
>
> This file is written for a very old qdev style of machine description.
> Remove by inlining all usages of its functions (which is consistent with
> the modern preference that qdev_initery should be inline and not in
> cross-board helper functions).
>
> To avoid movement of magic numbers, Define macros for IRQ and memory
> maps as appropriate. This cleanup comes first, followed by the
> piecewise removal of xilinx.h.
>
> Regards,
> Peter
>
>
> Peter Crosthwaite (8):
>   microblaze/s3adsp_1800: Define macros for irq map
>   ppc/virtex_ml507: Define macros for irq/memory maps
>   microblaze/ml605: Define macros for irq/memory maps
>   xilinx: Inline usages of xilinx_intc_create()
>   xilinx: Inline usages of xilinx_timer_create()
>   xilinx: Inline usage of xilinx_ethlite_create()
>   xilinx: Inline usages of xilinx_axi*_init()
>   xilinx: Delete hw/include/xilinx.h
>
>  hw/microblaze/petalogix_ml605_mmu.c  | 55 ++-
>  hw/microblaze/petalogix_s3adsp1800_mmu.c | 35 ++---
>  hw/ppc/virtex_ml507.c| 29 +++---
>  include/hw/xilinx.h  | 90 
> 
>  4 files changed, 95 insertions(+), 114 deletions(-)
>  delete mode 100644 include/hw/xilinx.h
>
> --
> 1.8.5.4
>



Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation

2014-02-25 Thread Andreas Färber
Am 25.02.2014 09:39, schrieb Alex Bennée:
> 
> Dann Frazier  writes:
> 
>> On Mon, Feb 17, 2014 at 6:40 AM, Alex Bennée  wrote:
>>> Hi,
>>
>> Thanks to all involved for your work here!
>>
>>> After a solid few months of work the QEMU master branch [1] has now reached
>>> instruction feature parity with the suse-1.6 [6] tree that a lot of people
>>> have been using to build various aarch64 binaries. In addition to the
> 
>>>
>>> I've tested against the following aarch64 rootfs:
>>> * SUSE [2]
>>> * Debian [3]
>>> * Ubuntu Saucy [4]
>>
>> fyi, I've been doing my testing with Ubuntu Trusty.
> 
> Good stuff, I shall see if I can set one up. Is the package coverage
> between trusty and saucy much different? I noticed for example I
> couldn't find zile and various build-deps for llvm.
> 
> 
>>>
>>> Feedback I'm interested in
>>> ==
>>>
>>> * Any instruction failure (please include the log line with the
>>>   unsupported message)
>>> * Any aarch64 specific failures (i.e. not generic QEMU threading 
>>> flakeiness).
>>
>> I'm not sure if this qualifies as generic QEMU threading flakiness or not. 
>> I've
>> found a couple conditions that causes master to core dump fairly
>> reliably, while the aarch64-1.6 branch seems to consistently work
>> fine.
>>
>>  1) dh_fixperms is a script that commonly runs at the end of a package build.
>>  Its basically doing a `find | xargs chmod`.
>>  2) debootstrap --second-stage
>>  This is used to configure an arm64 chroot that was built using
>>  debootstrap on a non-native host. It is basically invoking a bunch of
>>  shell scripts (postinst, etc). When it blows up, the stack consistently
>>  looks like this:
>>
>> Core was generated by `/usr/bin/qemu-aarch64-static /bin/sh -e
>> /debootstrap/debootstrap --second-stage'.
>> Program terminated with signal SIGSEGV, Segmentation fault.
>> #0  0x60058e55 in memcpy (__len=8, __src=0x7fff62ae34e0,
>> __dest=0x400082c330) at
>> /usr/include/x86_64-linux-gnu/bits/string3.h:51
>> 51  return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
>> (gdb) bt
>> #0  0x60058e55 in memcpy (__len=8, __src=0x7fff62ae34e0,
>> __dest=0x400082c330) at
>> /usr/include/x86_64-linux-gnu/bits/string3.h:51
>> #1  stq_p (v=274886476624, ptr=0x400082c330) at
>> /mnt/qemu.upstream/include/qemu/bswap.h:280
>> #2  stq_le_p (v=274886476624, ptr=0x400082c330) at
>> /mnt/qemu.upstream/include/qemu/bswap.h:315
>> #3  target_setup_sigframe (set=0x7fff62ae3530, env=0x62d9c678,
>> sf=0x400082b0d0) at /mnt/qemu.upstream/linux-user/signal.c:1167
>> #4  target_setup_frame (usig=usig@entry=17, ka=ka@entry=0x604ec1e0
>> , info=info@entry=0x0, set=set@entry=0x7fff62ae3530,
>> env=env@entry=0x62d9c678)
>> at /mnt/qemu.upstream/linux-user/signal.c:1286
>> #5  0x60059f46 in setup_frame (env=0x62d9c678,
>> set=0x7fff62ae3530, ka=0x604ec1e0 , sig=17) at
>> /mnt/qemu.upstream/linux-user/signal.c:1322
>> #6  process_pending_signals (cpu_env=cpu_env@entry=0x62d9c678) at
>> /mnt/qemu.upstream/linux-user/signal.c:5747
>> #7  0x60056e60 in cpu_loop (env=env@entry=0x62d9c678) at
>> /mnt/qemu.upstream/linux-user/main.c:1082
>> #8  0x60005079 in main (argc=, argv=> out>, envp=) at
>> /mnt/qemu.upstream/linux-user/main.c:4374
>>
>> There are some pretty large differences between these trees with
>> respect to signal syscalls - is that the likely culprit?
> 
> Quite likely. We explicitly concentrated on the arch64 specific
> instruction emulation leaving more generic patches to flow in from SUSE
> as they matured.
> 
> I guess it's time to go through the remaining patches and see what's 
> up-streamable.
> 
> Alex/Michael,
> 
> Are any of these patches in flight now?

I don't think so, Alex seems to hate cleaning that stuff up... :P

Compare https://github.com/openSUSE/qemu/commits/opensuse-1.7 for our
general queue. We have patches adding locking to TCG, and there's a hack
pinning the CPU somewhere.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



Re: [Qemu-devel] [PATCH qom-next v1 0/6] SSI QOM cleanups

2014-02-25 Thread Andreas Färber
Am 25.02.2014 09:46, schrieb Peter Crosthwaite:
> Ping!

Looked good, didn't get to applying them yet. I did wonder though a) why
1/6 is not renaming the parent field to verify and b) whether I can swap
d vs. dev naming in one hunk there while at it.

Cheers,
Andreas

> 
> On Wed, Feb 12, 2014 at 10:27 AM, Peter Crosthwaite
>  wrote:
>> Hi Andreas,
>>
>> Here is a mixed bag of QOM cleanups, moving us slightly closer to
>> QOMification of SSI.
>>
>> This prepares support for some major refactoring around SSI (in
>> particular some QSPI patches).
>>
>> Regards,
>> Peter
>>
>>
>> Peter Crosthwaite (6):
>>   ssi: Convert legacy casts from SSI_SLAVE->DEVICE
>>   ssi: Remove legacy SSI_BUS->BUS cast
>>   misc: max111x: Create abstract max111x class
>>   misc: max111x: QOM casting sweep
>>   ssi: Remove SSI_SLAVE_FROM_QDEV macro
>>   block/m25p80: Remove FROM_SSI_SLAVE usages
>>
>>  hw/arm/spitz.c   |  9 +
>>  hw/block/m25p80.c|  6 +++---
>>  hw/display/ads7846.c |  2 +-
>>  hw/display/ssd0323.c |  4 ++--
>>  hw/misc/max111x.c| 46 +-
>>  hw/sd/ssi-sd.c   |  2 +-
>>  hw/ssi/ssi.c |  4 ++--
>>  include/hw/ssi.h |  1 -
>>  8 files changed, 47 insertions(+), 27 deletions(-)
>>
>> --
>> 1.8.5.4
>>


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



Re: [Qemu-devel] [PATCH] e1000: add the ability to select among several specific types of e1000, plus some pointers to documentations and details.

2014-02-25 Thread Romain Dolbeau
2014-02-25 9:01 GMT+01:00 Andreas Färber :

> > -#define E1000(obj) \
> > -OBJECT_CHECK(E1000State, (obj), TYPE_E1000)
> > +#define E1000(obj)  \
> > +  DO_UPCAST(E1000State, parent_obj, obj)
>
> No, don't go backwards in time please. Take a look at e.g. eepro100,
> which already registers multiple data-driven subtypes for instance. The
> key to making it work is to introduce an abstract base type matching
> E1000() macro, with original "e1000" type becoming a subtype thereof.
>

I don't understand. I did look at "eepro100.c", it does exactly the same
thing
in the init() and uninit() (where E1000() is used):
#
static int e100_nic_init(PCIDevice *pci_dev)
{
EEPRO100State *s = DO_UPCAST(EEPRO100State, dev, pci_dev);
#

> @@ -1572,6 +1572,9 @@ static const char * const pci_nic_models[] = {
> > @@ -1584,6 +1587,9 @@ static const char * const pci_nic_names[] = {
>
> I would hope that adding to these two legacy lists is not necessary for
> new types. They should be created using -device, not -net nic,model=.
>

Again I don't understand - I took inspiration from eepro100.c, and it has 3
devices in there
(i82551, i82557b, i82559er). And the model is handled by -device, as my
example
shows:
#
"-netdev user,id=mynet0 -device 82545EM,netdev=mynet0"
#

Cordially,

-- 
Romain Dolbeau


Re: [Qemu-devel] Error compiling qemu from source on Ubuntu 12.10

2014-02-25 Thread Peter Maydell
On 25 February 2014 04:15, Jobin Raju George  wrote:
> On Mon, Feb 24, 2014 at 5:54 PM, Peter Maydell 
> wrote:
>> Why not just do the git submodule command that the error message
>> from configure suggests? You don't need to manually stick the tarball
>> into the qemu tree like this.
>>
> When I did just that, it said it was not a git repository and returned this
> error:
>
> fatal: Not a git repository (or any parent up to mount point /home)
> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

This looks like you didn't get qemu by cloning it from git (maybe you got
a tarball?). That's fine but it's not what you said you did...

Anyway, what you've done will work, it's just not something we expect
people to have to do.

thanks
-- PMM



[Qemu-devel] [PATCH 1/2][RFC] qom: introduce cpu QOM hierarchy tree /machine/node/socket/core/thread/cpu.

2014-02-25 Thread Chen Fan
Signed-off-by: Chen Fan 
---
 include/qom/node.h |  66 +++
 qom/Makefile.objs  |   2 +-
 qom/node.c | 156 +
 3 files changed, 223 insertions(+), 1 deletion(-)
 create mode 100644 include/qom/node.h
 create mode 100644 qom/node.c

diff --git a/include/qom/node.h b/include/qom/node.h
new file mode 100644
index 000..6c948ec
--- /dev/null
+++ b/include/qom/node.h
@@ -0,0 +1,66 @@
+/*
+ * QEMU System Emulator
+ *
+ * Copyright (c) 2013 Fujitsu Ltd.
+ * Author: Chen Fan 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "hw/qdev-core.h"
+
+#define TYPE_NODE   "node"
+#define TYPE_SOCKET "socket"
+#define TYPE_CORE   "core"
+#define TYPE_THREAD "thread"
+
+#define NODE(obj) OBJECT_CHECK(NodeState, (obj), TYPE_NODE)
+
+#define SOCKET(obj) OBJECT_CHECK(SocketState, (obj), TYPE_SOCKET)
+
+#define CORE(obj) OBJECT_CHECK(CoreState, (obj), TYPE_CORE)
+
+#define THREAD(obj) OBJECT_CHECK(ThreadState, (obj), TYPE_THREAD)
+
+Object *object_get_thread_from_index(int64_t cpu_index);
+
+typedef struct ThreadState {
+/*< private >*/
+Object parent_obj;
+/*< public >*/
+CPUState **cpu;
+} ThreadState;
+
+typedef struct CoreState {
+/*< private >*/
+Object parent_obj;
+/*< public >*/
+} CoreState;
+
+typedef struct SocketState {
+/*< private >*/
+Object parent_obj;
+/*< public >*/
+} SocketState;
+
+typedef struct NodeState {
+/*< private >*/
+Object parent_obj;
+/*< public >*/
+} NodeState;
diff --git a/qom/Makefile.objs b/qom/Makefile.objs
index 985003b..5863919 100644
--- a/qom/Makefile.objs
+++ b/qom/Makefile.objs
@@ -1,3 +1,3 @@
 common-obj-y = object.o container.o qom-qobject.o
-common-obj-y += cpu.o
+common-obj-y += cpu.o node.o
 common-obj-y += object_interfaces.o
diff --git a/qom/node.c b/qom/node.c
new file mode 100644
index 000..a335992
--- /dev/null
+++ b/qom/node.c
@@ -0,0 +1,156 @@
+/*
+ * QEMU System Emulator
+ *
+ * Copyright (c) 2013 Fujitsu Ltd.
+ * Author: Chen Fan 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qom/object.h"
+#include "qemu/module.h"
+#include "hw/hw.h"
+#include "sysemu/cpus.h"
+#include "sysemu/sysemu.h"
+#include "qom/cpu.h"
+#include "qom/node.h"
+
+Object *object_get_thread_from_index(int64_t cpu_index)
+{
+gchar *path;
+Object *thread;
+int nodes, cpus_pre_nodes, smp_sockets;
+unsigned node_id, socket_id, core_id, thread_id;
+unsigned core_index, socket_index;
+
+nodes = nb_numa_nodes ? nb_numa_nodes : 1;
+cpus_pre_nodes = max_cpus / nodes;
+smp_sockets = cpus_pre_nodes / (smp_cores * smp_threads);
+
+core_index = cpu_index / smp_threads;
+thread_id = cpu_index % smp_threads;
+socket_index = core_index / smp_cores;
+core_id = core_index % smp_cores;
+node_id = socket_index / smp_sockets;
+socket_id = socket_

[Qemu-devel] [PATCH 2/2][RFC] cpu: link each new cpu to QOM tree /machine/node/socket/core/thread/cpu respectively.

2014-02-25 Thread Chen Fan
Signed-off-by: Chen Fan 
---
 hw/i386/pc.c | 40 
 1 file changed, 36 insertions(+), 4 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 348b15f..4e07ef9 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -57,6 +57,7 @@
 #include "hw/boards.h"
 #include "hw/pci/pci_host.h"
 #include "acpi-build.h"
+#include "qom/node.h"
 
 /* debug PC/ISA interrupts */
 //#define DEBUG_IRQ
@@ -927,11 +928,13 @@ void pc_acpi_smi_interrupt(void *opaque, int irq, int 
level)
 }
 }
 
-static X86CPU *pc_new_cpu(const char *cpu_model, int64_t apic_id,
+static X86CPU *pc_new_cpu(const char *cpu_model, int64_t id,
   DeviceState *icc_bridge, Error **errp)
 {
 X86CPU *cpu;
 Error *local_err = NULL;
+Object *thread;
+int64_t apic_id = x86_cpu_apic_id_from_index(id);
 
 cpu = cpu_x86_create(cpu_model, icc_bridge, &local_err);
 if (local_err != NULL) {
@@ -942,11 +945,17 @@ static X86CPU *pc_new_cpu(const char *cpu_model, int64_t 
apic_id,
 object_property_set_int(OBJECT(cpu), apic_id, "apic-id", &local_err);
 object_property_set_bool(OBJECT(cpu), true, "realized", &local_err);
 
+thread = object_get_thread_from_index(id);
+if (thread) {
+object_property_set_link(thread, OBJECT(cpu), "cpu", &local_err);
+}
+
 if (local_err) {
 error_propagate(errp, local_err);
 object_unref(OBJECT(cpu));
 cpu = NULL;
 }
+
 return cpu;
 }
 
@@ -976,7 +985,29 @@ void pc_hot_add_cpu(const int64_t id, Error **errp)
 
 icc_bridge = DEVICE(object_resolve_path_type("icc-bridge",
  TYPE_ICC_BRIDGE, NULL));
-pc_new_cpu(current_cpu_model, apic_id, icc_bridge, errp);
+pc_new_cpu(current_cpu_model, id, icc_bridge, errp);
+}
+
+static void qdev_cpus_init(void)
+{
+int i, nodes;
+gchar *node_name;
+Object *obj;
+
+if (nb_numa_nodes) {
+nodes = nb_numa_nodes;
+} else {
+nodes = 1;
+}
+
+for (i = 0; i < nodes; i++) {
+obj = object_new(TYPE_NODE);
+node_name = g_strdup_printf("node[%" PRIi32 "]", i);
+object_property_add_child(qdev_get_machine(),
+  node_name, obj, NULL);
+g_free(node_name);
+}
+
 }
 
 void pc_cpus_init(const char *cpu_model, DeviceState *icc_bridge)
@@ -995,9 +1026,10 @@ void pc_cpus_init(const char *cpu_model, DeviceState 
*icc_bridge)
 }
 current_cpu_model = cpu_model;
 
+qdev_cpus_init();
+
 for (i = 0; i < smp_cpus; i++) {
-cpu = pc_new_cpu(cpu_model, x86_cpu_apic_id_from_index(i),
- icc_bridge, &error);
+cpu = pc_new_cpu(cpu_model, i, icc_bridge, &error);
 if (error) {
 error_report("%s", error_get_pretty(error));
 error_free(error);
-- 
1.8.1.4




[Qemu-devel] [PATCH 0/2][RFC] prebuild cpu QOM tree /machine/node/socket/core/thread/..

2014-02-25 Thread Chen Fan
Hi,
at present, after hotplug a discontinuous cpu id on source, then done 
migration,
  on target, it will fail to add the unoccupied cpu id which was skipped at 
source,
  this cause is on target Qemu prebuild CPU with continuous cpu_index. so after
  migration, the cpu infrastructure bewteen source and target are different.
  
  I suppose we could use apic_id as instance_id which was used at registering 
vmstate
  when create cpu. on target, we prebuild the specified cpu using QOM comand 
line:
  /machine/node/socket/core/thread, then migration, we could keep the same cpu
  infrastructure on both side.

  at first, I introduce a empty QOM tree /machine/node/socket/core/thread/, 
then when
  create cpu, link each created cpu into the tree. which idea was suggested by 
Igor. thanks.
  
  TODO:
1. add cpu "path" property which used for specifying the QOM path. 
2. add -device cpu-foo.path supported.
3. then we could introduce hot-remove cpu probably.

  I don't know wether this way is right or not. pls tell me. :)

Thanks,
Chen

Chen Fan (2):
  qom: introduce cpu QOM hierarchy tree
/machine/node/socket/core/thread/cpu.
  cpu: link each new cpu to QOM tree
/machine/node/socket/core/thread/cpu respectively.

 hw/i386/pc.c   |  40 --
 include/qom/node.h |  66 +++
 qom/Makefile.objs  |   2 +-
 qom/node.c | 156 +
 4 files changed, 259 insertions(+), 5 deletions(-)
 create mode 100644 include/qom/node.h
 create mode 100644 qom/node.c

-- 
1.8.1.4




Re: [Qemu-devel] Error compiling qemu from source on Ubuntu 12.10

2014-02-25 Thread Jobin Raju George
On Tue, Feb 25, 2014 at 2:42 PM, Peter Maydell wrote:

> On 25 February 2014 04:15, Jobin Raju George  wrote:
> > On Mon, Feb 24, 2014 at 5:54 PM, Peter Maydell  >
> > wrote:
> >> Why not just do the git submodule command that the error message
> >> from configure suggests? You don't need to manually stick the tarball
> >> into the qemu tree like this.
> >>
> > When I did just that, it said it was not a git repository and returned
> this
> > error:
> >
> > fatal: Not a git repository (or any parent up to mount point /home)
> > Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not
> set).
>
> This looks like you didn't get qemu by cloning it from git (maybe you got
> a tarball?). That's fine but it's not what you said you did...
>
>
Exactly! But is there a difference if I snapshot it and clone it from the
repo?
I took a snapshot.


> Anyway, what you've done will work, it's just not something we expect
> people to have to do.
>
> thanks
> -- PMM
>



-- 

Thanks and regards,

Jobin Raju George

Final Year, Information Technology

College of Engineering Pune

Alternate e-mail: georgejr10...@coep.ac.in


Re: [Qemu-devel] [PATCH] e1000: add the ability to select among several specific types of e1000, plus some pointers to documentations and details.

2014-02-25 Thread Romain Dolbeau
2014-02-25 9:58 GMT+01:00 Romain Dolbeau :

> 2014-02-25 9:01 GMT+01:00 Andreas Färber :
>
> > @@ -1572,6 +1572,9 @@ static const char * const pci_nic_models[] = {
>> > @@ -1584,6 +1587,9 @@ static const char * const pci_nic_names[] = {
>>
>> I would hope that adding to these two legacy lists is not necessary for
>> new types. They should be created using -device, not -net nic,model=.
>>
>
> Again I don't understand - I took inspiration from eepro100.c, and it has
> 3 devices in there
> (i82551, i82557b, i82559er). And the model is handled by -device, as my
> example
> shows:
> #
> "-netdev user,id=mynet0 -device 82545EM,netdev=mynet0"
> #
>
> I was misled by the presence of "e1000" and several eepro100 variants in
this list.
Modifying it is not necessary, it works fine without it. I suppose that's
what you
meant - that it works both ways (-device or -net nic), but the second
option is not
required for new device as it's a deprecated way of doing things?

Cordially,

-- 
Romain Dolbeau


Re: [Qemu-devel] Error compiling qemu from source on Ubuntu 12.10

2014-02-25 Thread Peter Maydell
On 25 February 2014 09:19, Jobin Raju George  wrote:
> On Tue, Feb 25, 2014 at 2:42 PM, Peter Maydell 
> wrote:
>> This looks like you didn't get qemu by cloning it from git (maybe you got
>> a tarball?). That's fine but it's not what you said you did...
>>
>
> Exactly! But is there a difference if I snapshot it and clone it from the
> repo?
> I took a snapshot.

If you take a snapshot then the git submodule commands won't work.
Generally we expect people will mostly either (a) take a release tarball,
which has the submodule sources included or (b) clone from git,
in which case the advice in the error message will work.

Anyway, you've got to a working compile now, but that's why you
ran into the problems you did, I think.

thanks
-- PMM



[Qemu-devel] [PATCH v3 1/2] include/qemu/crc32c.h: Rename include guards to match filename

2014-02-25 Thread Will Newton
Signed-off-by: Will Newton 
Reviewed-by: Peter Maydell 
---
 include/qemu/crc32c.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Changes in v3:
 - None

diff --git a/include/qemu/crc32c.h b/include/qemu/crc32c.h
index 56d1c3b..dafb6a1 100644
--- a/include/qemu/crc32c.h
+++ b/include/qemu/crc32c.h
@@ -25,8 +25,8 @@
  *
  */
 
-#ifndef QEMU_CRC32_H
-#define QEMU_CRC32_H
+#ifndef QEMU_CRC32C_H
+#define QEMU_CRC32C_H
 
 #include "qemu-common.h"
 
-- 
1.8.1.4




[Qemu-devel] [PATCH v3 0/2] target-arm: Add support for AArch32 ARMv8 CRC32 instructions

2014-02-25 Thread Will Newton
This series adds support for the AArch32 CRC32 instructions added in
ARMv8.

Will Newton (2):
  include/qemu/crc32c.h: Rename include guards to match filename
  target-arm: Add support for AArch32 ARMv8 CRC32 instructions

 configure  |  2 +-
 include/qemu/crc32c.h  |  4 ++--
 target-arm/helper.c| 39 +++
 target-arm/helper.h|  3 +++
 target-arm/translate.c | 48 
 5 files changed, 93 insertions(+), 3 deletions(-)

-- 
1.8.1.4




[Qemu-devel] [PATCH v3 2/2] target-arm: Add support for AArch32 ARMv8 CRC32 instructions

2014-02-25 Thread Will Newton
Add support for AArch32 CRC32 and CRC32C instructions added in ARMv8.
The CRC32-C implementation used is the built-in qemu implementation
and The CRC-32 implementation is from zlib. This requires adding zlib
to LIBS to ensure it is linked for the linux-user binary.

Signed-off-by: Will Newton 
---
 configure  |  2 +-
 target-arm/helper.c| 39 +++
 target-arm/helper.h|  3 +++
 target-arm/translate.c | 48 
 4 files changed, 91 insertions(+), 1 deletion(-)

Changes in v3:
 - Use extract32 to get register fields from instruction

diff --git a/configure b/configure
index 4648117..822842c 100755
--- a/configure
+++ b/configure
@@ -1550,7 +1550,7 @@ EOF
 "Make sure to have the zlib libs and headers installed."
 fi
 fi
-libs_softmmu="$libs_softmmu -lz"
+LIBS="$LIBS -lz"
 
 ##
 # libseccomp check
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 5ae08c9..294cfaf 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -5,6 +5,8 @@
 #include "sysemu/arch_init.h"
 #include "sysemu/sysemu.h"
 #include "qemu/bitops.h"
+#include "qemu/crc32c.h"
+#include  /* For crc32 */
 
 #ifndef CONFIG_USER_ONLY
 static inline int get_phys_addr(CPUARMState *env, uint32_t address,
@@ -4468,3 +4470,40 @@ int arm_rmode_to_sf(int rmode)
 }
 return rmode;
 }
+
+static void crc_init_buffer(uint8_t *buf, uint32_t val, uint32_t bytes)
+{
+memset(buf, 0, 4);
+
+if (bytes == 1) {
+buf[0] = val & 0xff;
+} else if (bytes == 2) {
+buf[0] = val & 0xff;
+buf[1] = (val >> 8) & 0xff;
+} else {
+buf[0] = val & 0xff;
+buf[1] = (val >> 8) & 0xff;
+buf[2] = (val >> 16) & 0xff;
+buf[3] = (val >> 24) & 0xff;
+}
+}
+
+uint32_t HELPER(crc32)(uint32_t acc, uint32_t val, uint32_t bytes)
+{
+uint8_t buf[4];
+
+crc_init_buffer(buf, val, bytes);
+
+/* zlib crc32 converts the accumulator and output to one's complement.  */
+return crc32(acc ^ 0x, buf, bytes) ^ 0x;
+}
+
+uint32_t HELPER(crc32c)(uint32_t acc, uint32_t val, uint32_t bytes)
+{
+uint8_t buf[4];
+
+crc_init_buffer(buf, val, bytes);
+
+/* Linux crc32c converts the output to one's complement.  */
+return crc32c(acc, buf, bytes) ^ 0x;
+}
diff --git a/target-arm/helper.h b/target-arm/helper.h
index 951e6ad..fb92e53 100644
--- a/target-arm/helper.h
+++ b/target-arm/helper.h
@@ -494,6 +494,9 @@ DEF_HELPER_3(neon_qzip32, void, env, i32, i32)
 DEF_HELPER_4(crypto_aese, void, env, i32, i32, i32)
 DEF_HELPER_4(crypto_aesmc, void, env, i32, i32, i32)
 
+DEF_HELPER_3(crc32, i32, i32, i32, i32)
+DEF_HELPER_3(crc32c, i32, i32, i32, i32)
+
 #ifdef TARGET_AARCH64
 #include "helper-a64.h"
 #endif
diff --git a/target-arm/translate.c b/target-arm/translate.c
index 782aab8..8e87869 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -7541,6 +7541,32 @@ static void disas_arm_insn(CPUARMState * env, 
DisasContext *s)
 store_reg(s, 14, tmp2);
 gen_bx(s, tmp);
 break;
+case 0x4:
+{
+/* crc32/crc32c */
+uint32_t c = extract32(insn, 9, 1);
+
+/* size == 64 is UNPREDICTABLE but handle as UNDEFINED.  */
+if (op1 == 0x3) {
+goto illegal_op;
+}
+
+rn = extract32(insn, 16, 4);
+rd = extract32(insn, 12, 4);
+
+tmp = load_reg(s, rn);
+tmp2 = load_reg(s, rm);
+tmp3 = tcg_const_i32(1 << op1);
+if (c) {
+gen_helper_crc32c(tmp, tmp, tmp2, tmp3);
+} else {
+gen_helper_crc32(tmp, tmp, tmp2, tmp3);
+}
+tcg_temp_free_i32(tmp2);
+tcg_temp_free_i32(tmp3);
+store_reg(s, rd, tmp);
+break;
+}
 case 0x5: /* saturating add/subtract */
 ARCH(5TE);
 rd = (insn >> 12) & 0xf;
@@ -9125,6 +9151,28 @@ static int disas_thumb2_insn(CPUARMState *env, 
DisasContext *s, uint16_t insn_hw
 case 0x18: /* clz */
 gen_helper_clz(tmp, tmp);
 break;
+case 0x20:
+case 0x21:
+case 0x22:
+case 0x28:
+case 0x29:
+case 0x2a:
+{
+/* crc32/crc32c */
+uint32_t sz = op & 0x3;
+uint32_t c = op & 0x8;
+
+tmp2 = load_reg(s, rm);
+tmp3 = tcg_const_i32(1 << sz);
+if (c) {
+gen_helper_crc32c(tmp, tmp, tmp2, tmp3);
+} else {
+gen_helper_crc32(tmp, tmp, tmp2, tmp3);
+}
+tcg_temp_free_i32(tmp2);
+tcg_temp_free_i32(tm

Re: [Qemu-devel] QOM vs QAPI for QMP APIs

2014-02-25 Thread Kevin Wolf
Am 21.02.2014 um 15:32 hat Stefan Hajnoczi geschrieben:
> On Fri, Feb 21, 2014 at 10:16 AM, Stefan Hajnoczi  wrote:
> > Maybe I just need some convincing but it seems that QAPI is the simplest
> > and cleanest way to define external APIs.
> >
> > Disagree?  Tell me why :).
> 
> I'm replying to myself because we had an interesting discussion on
> IRC.  Thanks Paolo, Markus, and Peter!
> 
> I'm biased, but here are the points collected from the discussion:
> 
> Why QOM *should* be QEMU's external API:
>  * QOM eliminates hand-written QMP API code.  We get query-foo APIs
> for free using qom-list, qom-get, qom-set, and friends

I don't think this is valid point. We already have a QAPI code
generator. There's no reason why it couldn't automatically map things to
QOM for certain commands.

This means that you would internally use QOM in order to get rid of
hand-written code, but it would be an implementation detail and the
external API would still be as high-level as it is today.

> Why QOM should *not* be QEMU's external API:
>  * Internal objects will diverge from the external QOM objects over
> time, we'll have to maintain a backwards compatible QOM object layer
> on top of QEMU's internal objects - that defeats the whole point of
> getting APIs for free from QOM

This is a very important point. We already managed to mess up existing
QMP commands so that we're jumping through hoops to provide an old
interface, which doesn't really match the design we want to have.
Sometimes it prevents us from making changes.

With QOM, we potentially expose everything, every little detail of our
internal implementation. If we don't say that there is no (or at least
very weak) compatibility promise, then we're forever stuck with whatever
broken design we first came up with.

If QOM comes with stability requirements, I'll veto any conversion patch
of any part of the block layer to QOM.

>  * We lose the easy-to-review qapi-schema.json.  Would need new
> documentation and review tools for QOM model changes.
>  * query-foo APIs are simple to implement, not a huge win to get them via QOM
>  * QAPI is mature and well-understood, QMP is incomplete
>  * qom-list, qom-get, qom-set are too low-level, need more powerful
> APIs to save clients from elaborate back-and-forth conversations

Right, QOM is simple in the way that programming in assembly is simple.
The building blocks are really simple and easy to explain, but building
something higher level from it is hard and easy to get wrong.

Try expressing a 'transaction' QMP command with multiple newly created
snapshots and a backup job in QOM... (without creating a transaction
object that contains the current QAPI arguments as properties, because
that wouldn't really be using QOM but tunneling QMP through QOM)

External QOM interfaces have their place, especially for debugging or
trying out things before there is a proper API, but it's not as the
primary external interface.

Kevin



[Qemu-devel] [PATCH 06/17] s390x/virtio-hcall: Specification exception for illegal subcodes

2014-02-25 Thread Christian Borntraeger
From: Thomas Huth 

So far, the DIAG 500 hypervisor call was only setting -EINVAL in
R2 when a guest tried to call this function with an illegal subcode.
This patch now changes the behavior so that a specification exception
is thrown instead, since this is the common behavior of other DIAG
functions (and other CPU instructions) when being called with illegal
parameters.

Signed-off-by: Thomas Huth 
Reviewed-by: Cornelia Huck 
Signed-off-by: Christian Borntraeger 
---
 hw/s390x/s390-virtio-hcall.c | 3 ++-
 target-s390x/kvm.c   | 9 +++--
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/hw/s390x/s390-virtio-hcall.c b/hw/s390x/s390-virtio-hcall.c
index 0e328d8..c7bdc20 100644
--- a/hw/s390x/s390-virtio-hcall.c
+++ b/hw/s390x/s390-virtio-hcall.c
@@ -31,7 +31,8 @@ int s390_virtio_hypercall(CPUS390XState *env)
 if (env->regs[1] < MAX_DIAG_SUBCODES) {
 fn = s390_diag500_table[env->regs[1]];
 if (fn) {
-return fn(&env->regs[2]);
+env->regs[2] = fn(&env->regs[2]);
+return 0;
 }
 }
 
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index b93fe84..2fa374a 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -559,11 +559,16 @@ static int handle_priv(S390CPU *cpu, struct kvm_run *run,
 static int handle_hypercall(S390CPU *cpu, struct kvm_run *run)
 {
 CPUS390XState *env = &cpu->env;
+int ret;
 
 cpu_synchronize_state(CPU(cpu));
-env->regs[2] = s390_virtio_hypercall(env);
+ret = s390_virtio_hypercall(env);
+if (ret == -EINVAL) {
+enter_pgmcheck(cpu, PGM_SPECIFICATION);
+return 0;
+}
 
-return 0;
+return ret;
 }
 
 static void kvm_handle_diag_308(S390CPU *cpu, struct kvm_run *run)
-- 
1.8.4.2




[Qemu-devel] [PATCH 14/17] s390x/event-facility: exploit realize/unrealize

2014-02-25 Thread Christian Borntraeger
From: Heinz Graalfs 

init/exit functionality of abstract SCLPEvent class is now exploiting
realize/unrealize.

Signed-off-by: Heinz Graalfs 
Reviewed-by: Cornelia Huck 
Signed-off-by: Christian Borntraeger 
---
 hw/s390x/event-facility.c | 27 ++-
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/hw/s390x/event-facility.c b/hw/s390x/event-facility.c
index 5b6d5c6..0777a93 100644
--- a/hw/s390x/event-facility.c
+++ b/hw/s390x/event-facility.c
@@ -377,22 +377,31 @@ static const TypeInfo sclp_event_facility_info = {
 .class_size= sizeof(SCLPEventFacilityClass),
 };
 
-static int event_qdev_init(DeviceState *qdev)
+static void event_realize(DeviceState *qdev, Error **errp)
 {
-SCLPEvent *event = DO_UPCAST(SCLPEvent, qdev, qdev);
+SCLPEvent *event = SCLP_EVENT(qdev);
 SCLPEventClass *child = SCLP_EVENT_GET_CLASS(event);
 
-return child->init(event);
+if (child->init) {
+int rc = child->init(event);
+if (rc < 0) {
+error_setg(errp, "SCLP event initialization failed.");
+return;
+}
+}
 }
 
-static int event_qdev_exit(DeviceState *qdev)
+static void event_unrealize(DeviceState *qdev, Error **errp)
 {
-SCLPEvent *event = DO_UPCAST(SCLPEvent, qdev, qdev);
+SCLPEvent *event = SCLP_EVENT(qdev);
 SCLPEventClass *child = SCLP_EVENT_GET_CLASS(event);
 if (child->exit) {
-child->exit(event);
+int rc = child->exit(event);
+if (rc < 0) {
+error_setg(errp, "SCLP event exit failed.");
+return;
+}
 }
-return 0;
 }
 
 static void event_class_init(ObjectClass *klass, void *data)
@@ -401,8 +410,8 @@ static void event_class_init(ObjectClass *klass, void *data)
 
 dc->bus_type = TYPE_SCLP_EVENTS_BUS;
 dc->unplug = qdev_simple_unplug_cb;
-dc->init = event_qdev_init;
-dc->exit = event_qdev_exit;
+dc->realize = event_realize;
+dc->unrealize = event_unrealize;
 }
 
 static const TypeInfo sclp_event_type_info = {
-- 
1.8.4.2




[Qemu-devel] [PATCH 04/17] s390x/kvm: Fixed bad SIGP SET-ARCHITECTURE handler

2014-02-25 Thread Christian Borntraeger
From: Thomas Huth 

The SET-ARCHITECTURE handler in QEMU caused a program interruption.
This is wrong according to the "Principles of Operations" specification
(since SIGP should never cause a program interrupt) and was likely only
introduced for debugging purposes. Since we handle SET-ARCHITECTURE in
the kernel already and only dropped to user space in case of bad mode
parameters, we should just report INVALID PARAMETER in QEMU instead.

Signed-off-by: Thomas Huth 
Reviewed-by: Cornelia Huck 
Signed-off-by: Christian Borntraeger 
---
 target-s390x/kvm.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index 9430a35..b93fe84 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -676,8 +676,10 @@ static int handle_sigp(S390CPU *cpu, struct kvm_run *run, 
uint8_t ipa1)
 cc = kvm_s390_cpu_restart(target_cpu);
 break;
 case SIGP_SET_ARCH:
-/* make the caller panic */
-return -1;
+*statusreg &= 0xUL;
+*statusreg |= SIGP_STAT_INVALID_PARAMETER;
+cc = 1;   /* status stored */
+break;
 case SIGP_INITIAL_CPU_RESET:
 cc = s390_cpu_initial_reset(target_cpu);
 break;
-- 
1.8.4.2




[Qemu-devel] [PATCH 11/17] s390x/event-facility: some renaming

2014-02-25 Thread Christian Borntraeger
From: Heinz Graalfs 

Do some renaming to shorten some identifiers and to emphasize sclp.

Signed-off-by: Heinz Graalfs 
Acked-by: Cornelia Huck 
Signed-off-by: Christian Borntraeger 
---
 hw/s390x/event-facility.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/hw/s390x/event-facility.c b/hw/s390x/event-facility.c
index 1e8c99a..e0ee737 100644
--- a/hw/s390x/event-facility.c
+++ b/hw/s390x/event-facility.c
@@ -21,12 +21,12 @@
 #include "hw/s390x/sclp.h"
 #include "hw/s390x/event-facility.h"
 
-typedef struct EventTypesBus {
+typedef struct SCLPEventsBus {
 BusState qbus;
-} EventTypesBus;
+} SCLPEventsBus;
 
 struct SCLPEventFacility {
-EventTypesBus sbus;
+SCLPEventsBus sbus;
 DeviceState *qdev;
 /* guest' receive mask */
 unsigned int receive_mask;
@@ -291,7 +291,7 @@ static void sclp_events_bus_class_init(ObjectClass *klass, 
void *data)
 {
 }
 
-static const TypeInfo s390_sclp_events_bus_info = {
+static const TypeInfo sclp_events_bus_info = {
 .name = TYPE_SCLP_EVENTS_BUS,
 .parent = TYPE_BUS,
 .class_init = sclp_events_bus_class_init,
@@ -360,7 +360,7 @@ static void init_event_facility_class(ObjectClass *klass, 
void *data)
 k->init = init_event_facility;
 }
 
-static const TypeInfo s390_sclp_event_facility_info = {
+static const TypeInfo sclp_event_facility_info = {
 .name  = "s390-sclp-event-facility",
 .parent= TYPE_DEVICE_S390_SCLP,
 .instance_size = sizeof(S390SCLPDevice),
@@ -395,7 +395,7 @@ static void event_class_init(ObjectClass *klass, void *data)
 dc->exit = event_qdev_exit;
 }
 
-static const TypeInfo s390_sclp_event_type_info = {
+static const TypeInfo sclp_event_type_info = {
 .name = TYPE_SCLP_EVENT,
 .parent = TYPE_DEVICE,
 .instance_size = sizeof(SCLPEvent),
@@ -406,9 +406,9 @@ static const TypeInfo s390_sclp_event_type_info = {
 
 static void register_types(void)
 {
-type_register_static(&s390_sclp_events_bus_info);
-type_register_static(&s390_sclp_event_facility_info);
-type_register_static(&s390_sclp_event_type_info);
+type_register_static(&sclp_events_bus_info);
+type_register_static(&sclp_event_facility_info);
+type_register_static(&sclp_event_type_info);
 }
 
 type_init(register_types)
-- 
1.8.4.2




[Qemu-devel] [PATCH 13/17] s390x/event-facility: add support for live migration

2014-02-25 Thread Christian Borntraeger
From: Heinz Graalfs 

Add support for live migration using VMStateDescription.

Signed-off-by: Heinz Graalfs 
Reviewed-by: Cornelia Huck 
Signed-off-by: Christian Borntraeger 
---
 hw/s390x/event-facility.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/hw/s390x/event-facility.c b/hw/s390x/event-facility.c
index 8ad2dc4..5b6d5c6 100644
--- a/hw/s390x/event-facility.c
+++ b/hw/s390x/event-facility.c
@@ -315,6 +315,17 @@ static void command_handler(SCLPEventFacility *ef, SCCB 
*sccb, uint64_t code)
 }
 }
 
+static const VMStateDescription vmstate_event_facility = {
+.name = "vmstate-event-facility",
+.version_id = 0,
+.minimum_version_id = 0,
+.minimum_version_id_old = 0,
+.fields  = (VMStateField[]) {
+VMSTATE_UINT32(receive_mask, SCLPEventFacility),
+VMSTATE_END_OF_LIST()
+ }
+};
+
 static int init_event_facility(SCLPEventFacility *event_facility)
 {
 DeviceState *sdev = DEVICE(event_facility);
@@ -352,6 +363,7 @@ static void init_event_facility_class(ObjectClass *klass, 
void *data)
 SCLPEventFacilityClass *k = EVENT_FACILITY_CLASS(dc);
 
 dc->reset = reset_event_facility;
+dc->vmsd = &vmstate_event_facility;
 k->init = init_event_facility;
 k->command_handler = command_handler;
 k->event_pending = event_pending;
-- 
1.8.4.2




[Qemu-devel] [PATCH 16/17] s390-ccw.img: Fix sporadic errors with ccw boot image - initialize css

2014-02-25 Thread Christian Borntraeger
We have to set the cssid to 0, otherwise the stsch code will
return an operand exception without the m bit. In the same way
we should set m=0.

This case was triggered in some cases during reboot, if for some
reason the location of blk_schid.cssid contains 1 and m was 0.
Turns out that the qemu elf loader does not zero out the bss section
on reboot.

The symptom was an dump of the old kernel with several areas
overwritten. The bootloader does not register a program check
handler, so bios exception jumped back into the old kernel.

Lets just use a local struct with a designed initializer. That
will guarantee that all other subelements are initialized to 0.

Signed-off-by: Christian Borntraeger 
Reviewed-by: Cornelia Huck 
---
 pc-bios/s390-ccw/main.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/pc-bios/s390-ccw/main.c b/pc-bios/s390-ccw/main.c
index c5d5332..5c33766 100644
--- a/pc-bios/s390-ccw/main.c
+++ b/pc-bios/s390-ccw/main.c
@@ -10,7 +10,6 @@
 
 #include "s390-ccw.h"
 
-struct subchannel_id blk_schid;
 char stack[PAGE_SIZE * 8] __attribute__((__aligned__(PAGE_SIZE)));
 uint64_t boot_value;
 
@@ -23,13 +22,13 @@ void virtio_panic(const char *string)
 
 static void virtio_setup(uint64_t dev_info)
 {
+struct subchannel_id blk_schid = { .one = 1 };
 struct schib schib;
 int i;
 int r;
 bool found = false;
 bool check_devno = false;
 uint16_t dev_no = -1;
-blk_schid.one = 1;
 
 if (dev_info != -1) {
 check_devno = true;
-- 
1.8.4.2




[Qemu-devel] [PATCH 10/17] s390x/sclp: Fixed setting of condition code register

2014-02-25 Thread Christian Borntraeger
From: Thomas Huth 

In the SCLP handler function, the condition code register must
only be set if no exception occured.

Signed-off-by: Thomas Huth 
Reviewed-by: Cornelia Huck 
Signed-off-by: Christian Borntraeger 
---
 target-s390x/kvm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index e7b3b13..d3f0d4a 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -451,8 +451,9 @@ static int kvm_sclp_service_call(S390CPU *cpu, struct 
kvm_run *run,
 r = sclp_service_call(env, sccb, code);
 if (r < 0) {
 enter_pgmcheck(cpu, -r);
+} else {
+setcc(cpu, r);
 }
-setcc(cpu, r);
 
 return 0;
 }
-- 
1.8.4.2




[Qemu-devel] [PATCH 15/17] s390-ccw.img: Fix sporadic reboot hangs: Initialize next_idx

2014-02-25 Thread Christian Borntraeger
The current code does not initialize next_idx in the virtio ring.
As the ccw bios will always use guest memory at a fixed location,
this queue might != 0 after a reboot.
Lets make the initialization explicit.

Signed-off-by: Christian Borntraeger 
Reviewed-by: Cornelia Huck 
---
 pc-bios/s390-ccw/virtio.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/pc-bios/s390-ccw/virtio.c b/pc-bios/s390-ccw/virtio.c
index 4d6e48f..a46914d 100644
--- a/pc-bios/s390-ccw/virtio.c
+++ b/pc-bios/s390-ccw/virtio.c
@@ -124,6 +124,7 @@ static void vring_init(struct vring *vr, unsigned int num, 
void *p,
 vr->used->flags = VRING_USED_F_NO_NOTIFY;
 vr->used->idx = 0;
 vr->used_idx = 0;
+vr->next_idx = 0;
 
 debug_print_addr("init vr", vr);
 }
-- 
1.8.4.2




[Qemu-devel] [PATCH 03/17] s390x/async_pf: Check for apf extension and enable pfault

2014-02-25 Thread Christian Borntraeger
From: Dominik Dingel 

S390 can also use async page faults, to enhance guest scheduling.
In case of live migration we want to disable the feature and let
all pending request finish.

Signed-off-by: Dominik Dingel 
Signed-off-by: Jens Freimann 
Signed-off-by: Christian Borntraeger 
---
 hw/intc/s390_flic.c | 36 
 target-s390x/cpu.c  |  6 ++
 target-s390x/cpu.h  |  4 
 target-s390x/kvm.c  | 48 
 4 files changed, 94 insertions(+)

diff --git a/hw/intc/s390_flic.c b/hw/intc/s390_flic.c
index 1a7876d..b2ef3e3 100644
--- a/hw/intc/s390_flic.c
+++ b/hw/intc/s390_flic.c
@@ -63,6 +63,34 @@ static int flic_get_all_irqs(KVMS390FLICState *flic,
 return rc == -1 ? -errno : rc;
 }
 
+static void flic_enable_pfault(KVMS390FLICState *flic)
+{
+struct kvm_device_attr attr = {
+.group = KVM_DEV_FLIC_APF_ENABLE,
+};
+int rc;
+
+rc = ioctl(flic->fd, KVM_SET_DEVICE_ATTR, &attr);
+
+if (rc) {
+fprintf(stderr, "flic: couldn't enable pfault\n");
+}
+}
+
+static void flic_disable_wait_pfault(KVMS390FLICState *flic)
+{
+struct kvm_device_attr attr = {
+.group = KVM_DEV_FLIC_APF_DISABLE_WAIT,
+};
+int rc;
+
+rc = ioctl(flic->fd, KVM_SET_DEVICE_ATTR, &attr);
+
+if (rc) {
+fprintf(stderr, "flic: couldn't disable pfault\n");
+}
+}
+
 /** flic_enqueue_irqs - returns 0 on success
  * @buf: pointer to buffer which is passed to kernel
  * @len: length of buffer
@@ -136,6 +164,8 @@ static void kvm_flic_save(QEMUFile *f, void *opaque)
 void *buf;
 int count;
 
+flic_disable_wait_pfault((struct KVMS390FLICState *) opaque);
+
 buf = g_try_malloc0(len);
 if (!buf) {
 /* Storing FLIC_FAILED into the count field here will cause the
@@ -184,6 +214,8 @@ static int kvm_flic_load(QEMUFile *f, void *opaque, int 
version_id)
 goto out;
 }
 
+flic_enable_pfault((struct KVMS390FLICState *) opaque);
+
 count = qemu_get_be64(f);
 len = count * sizeof(struct kvm_s390_irq);
 if (count == FLIC_FAILED) {
@@ -256,10 +288,14 @@ static void kvm_s390_flic_reset(DeviceState *dev)
 return;
 }
 
+flic_disable_wait_pfault(flic);
+
 rc = ioctl(flic->fd, KVM_SET_DEVICE_ATTR, &attr);
 if (rc) {
 trace_flic_reset_failed(errno);
 }
+
+flic_enable_pfault(flic);
 }
 
 static void kvm_s390_flic_class_init(ObjectClass *oc, void *data)
diff --git a/target-s390x/cpu.c b/target-s390x/cpu.c
index ff57b80..f1319e5 100644
--- a/target-s390x/cpu.c
+++ b/target-s390x/cpu.c
@@ -83,6 +83,7 @@ static void s390_cpu_reset(CPUState *s)
 S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
 CPUS390XState *env = &cpu->env;
 
+env->pfault_token = -1UL;
 s390_del_running_cpu(cpu);
 scc->parent_reset(s);
 #if !defined(CONFIG_USER_ONLY)
@@ -105,6 +106,8 @@ static void s390_cpu_initial_reset(CPUState *s)
 /* architectured initial values for CR 0 and 14 */
 env->cregs[0] = CR0_RESET;
 env->cregs[14] = CR14_RESET;
+
+env->pfault_token = -1UL;
 }
 
 /* CPUClass:reset() */
@@ -123,6 +126,9 @@ static void s390_cpu_full_reset(CPUState *s)
 /* architectured initial values for CR 0 and 14 */
 env->cregs[0] = CR0_RESET;
 env->cregs[14] = CR14_RESET;
+
+env->pfault_token = -1UL;
+
 /* set halted to 1 to make sure we can add the cpu in
  * s390_ipl_cpu code, where CPUState::halted is set back to 0
  * after incrementing the cpu counter */
diff --git a/target-s390x/cpu.h b/target-s390x/cpu.h
index 96c2b4a..b09ff92 100644
--- a/target-s390x/cpu.h
+++ b/target-s390x/cpu.h
@@ -121,6 +121,10 @@ typedef struct CPUS390XState {
 uint64_t cputm;
 uint32_t todpr;
 
+uint64_t pfault_token;
+uint64_t pfault_compare;
+uint64_t pfault_select;
+
 CPU_COMMON
 
 /* reset does memset(0) up to here */
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index f60ccdc..9430a35 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -87,12 +87,14 @@ const KVMCapabilityInfo kvm_arch_required_capabilities[] = {
 };
 
 static int cap_sync_regs;
+static int cap_async_pf;
 
 static void *legacy_s390_alloc(size_t size);
 
 int kvm_arch_init(KVMState *s)
 {
 cap_sync_regs = kvm_check_extension(s, KVM_CAP_SYNC_REGS);
+cap_async_pf = kvm_check_extension(s, KVM_CAP_ASYNC_PF);
 if (!kvm_check_extension(s, KVM_CAP_S390_GMAP)
 || !kvm_check_extension(s, KVM_CAP_S390_COW)) {
 phys_mem_set_alloc(legacy_s390_alloc);
@@ -178,6 +180,29 @@ int kvm_arch_put_registers(CPUState *cs, int level)
 return ret;
 }
 
+if (cap_async_pf) {
+reg.id = KVM_REG_S390_PFTOKEN;
+reg.addr = (__u64)&(env->pfault_token);
+ret = kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, ®);
+if (ret < 0) {
+return ret;
+}
+
+reg.id = KVM_REG_S390_PFCOMPARE;
+reg.addr = (__u64)&(env->pfault_compare);
+ret = kvm_vcpu_ioctl

[Qemu-devel] [PATCH 08/17] s390x/sclp: Fixed the size of sccb and code parameter

2014-02-25 Thread Christian Borntraeger
From: Thomas Huth 

The pointer to the SCCB should not be limited to 32 bits only.
In contrast to this, the command word parameter is only 32 bits
(the upper 32 bits should be ignored).

Signed-off-by: Thomas Huth 
Reviewed-by: Cornelia Huck 
Signed-off-by: Christian Borntraeger 
---
 hw/s390x/sclp.c| 4 ++--
 target-s390x/cpu.h | 2 +-
 target-s390x/kvm.c | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c
index 4e0c564..6134d4f 100644
--- a/hw/s390x/sclp.c
+++ b/hw/s390x/sclp.c
@@ -89,7 +89,7 @@ static void sclp_read_cpu_info(SCCB *sccb)
 sccb->h.response_code = cpu_to_be16(SCLP_RC_NORMAL_READ_COMPLETION);
 }
 
-static void sclp_execute(SCCB *sccb, uint64_t code)
+static void sclp_execute(SCCB *sccb, uint32_t code)
 {
 S390SCLPDevice *sdev = get_event_facility();
 
@@ -107,7 +107,7 @@ static void sclp_execute(SCCB *sccb, uint64_t code)
 }
 }
 
-int sclp_service_call(uint32_t sccb, uint64_t code)
+int sclp_service_call(uint64_t sccb, uint32_t code)
 {
 int r = 0;
 SCCB work_sccb;
diff --git a/target-s390x/cpu.h b/target-s390x/cpu.h
index b09ff92..373c115 100644
--- a/target-s390x/cpu.h
+++ b/target-s390x/cpu.h
@@ -963,7 +963,7 @@ struct sysib_322 {
 void load_psw(CPUS390XState *env, uint64_t mask, uint64_t addr);
 int mmu_translate(CPUS390XState *env, target_ulong vaddr, int rw, uint64_t asc,
   target_ulong *raddr, int *flags);
-int sclp_service_call(uint32_t sccb, uint64_t code);
+int sclp_service_call(uint64_t sccb, uint32_t code);
 uint32_t calc_cc(CPUS390XState *env, uint32_t cc_op, uint64_t src, uint64_t 
dst,
  uint64_t vr);
 
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index 2fa374a..9e1083e 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -440,8 +440,8 @@ static int kvm_sclp_service_call(S390CPU *cpu, struct 
kvm_run *run,
  uint16_t ipbh0)
 {
 CPUS390XState *env = &cpu->env;
-uint32_t sccb;
-uint64_t code;
+uint64_t sccb;
+uint32_t code;
 int r = 0;
 
 cpu_synchronize_state(CPU(cpu));
-- 
1.8.4.2




[Qemu-devel] [PATCH 2/3] tests: add nbd-fault-injector.py utility

2014-02-25 Thread Stefan Hajnoczi
The nbd-fault-injector.py script is a special kind of NBD server.  It
throws away all writes and produces zeroes for reads.  Given a list of
fault injection rules, it can simulate NBD protocol errors and is useful
for testing NBD client error handling code paths.

See the patch for documentation.  This scripts is modelled after Kevin
Wolf 's blkdebug block driver.

Signed-off-by: Stefan Hajnoczi 
---
 tests/qemu-iotests/nbd-fault-injector.py | 231 +++
 1 file changed, 231 insertions(+)
 create mode 100755 tests/qemu-iotests/nbd-fault-injector.py

diff --git a/tests/qemu-iotests/nbd-fault-injector.py 
b/tests/qemu-iotests/nbd-fault-injector.py
new file mode 100755
index 000..b4011f4
--- /dev/null
+++ b/tests/qemu-iotests/nbd-fault-injector.py
@@ -0,0 +1,231 @@
+#!/usr/bin/env python
+# NBD server - fault injection utility
+#
+# Configuration file syntax:
+#   [inject-error "disconnect-neg1"]
+#   event=neg1
+#   io=readwrite
+#   when=before
+#
+# Note that Python's ConfigParser squashes together all sections with the same
+# name, so give each [inject-error] a unique name.
+#
+# inject-error options:
+#   event - name of the trigger event
+#   "neg1" - first part of negotiation struct
+#   "export" - export struct
+#   "neg2" - second part of negotiation struct
+#   "request" - NBD request struct
+#   "reply" - NBD reply struct
+#   "data" - request/reply data
+#   io- I/O direction that triggers this rule:
+#   "read", "write", or "readwrite"
+#   default: readwrite
+#   when  - when to inject the fault relative to the I/O operation
+#   "before" or "after"
+#   default: before
+#
+# Currently the only error injection action is to terminate the server process.
+# This resets the TCP connection and thus forces the client to handle
+# unexpected connection termination.
+#
+# Other error injection actions could be added in the future.
+#
+# Copyright Red Hat, Inc. 2014
+#
+# Authors:
+#   Stefan Hajnoczi 
+#
+# This work is licensed under the terms of the GNU GPL, version 2 or later.
+# See the COPYING file in the top-level directory.
+
+import sys
+import socket
+import struct
+import collections
+import ConfigParser
+
+# Protocol constants
+NBD_CMD_READ = 0
+NBD_CMD_WRITE = 1
+NBD_CMD_DISC = 2
+NBD_REQUEST_MAGIC = 0x25609513
+NBD_REPLY_MAGIC = 0x67446698
+NBD_PASSWD = 0x4e42444d41474943
+NBD_OPTS_MAGIC = 0x49484156454F5054
+NBD_OPT_EXPORT_NAME = 1 << 0
+
+# Protocol structs
+neg1_struct = struct.Struct('>QQH')
+export_tuple = collections.namedtuple('Export', 'reserved magic opt len')
+export_struct = struct.Struct('>IQII')
+neg2_struct = struct.Struct('>QH124x')
+request_tuple = collections.namedtuple('Request', 'magic type handle from_ 
len')
+request_struct = struct.Struct('>IIQQI')
+reply_struct = struct.Struct('>IIQ')
+
+def err(msg):
+sys.stderr.write(msg + '\n')
+sys.exit(1)
+
+def recvall(sock, bufsize):
+received = 0
+chunks = []
+while received < bufsize:
+chunk = sock.recv(bufsize - received)
+if len(chunk) == 0:
+raise Exception('unexpected disconnect')
+chunks.append(chunk)
+received += len(chunk)
+return ''.join(chunks)
+
+class Rule(object):
+def __init__(self, name, event, io, when):
+self.name = name
+self.event = event
+self.io = io
+self.when = when
+
+def match(self, event, io, when):
+if when != self.when:
+return False
+if event != self.event:
+return False
+if io != self.io and self.io != 'readwrite':
+return False
+return True
+
+class FaultInjectionSocket(object):
+def __init__(self, sock, rules):
+self.sock = sock
+self.rules = rules
+
+def check(self, event, io, when):
+for rule in self.rules:
+if rule.match(event, io, when):
+print 'Closing connection on rule match %s' % rule.name
+sys.exit(0)
+
+def send(self, buf, event):
+self.check(event, 'write', 'before')
+self.sock.sendall(buf)
+self.check(event, 'write', 'after')
+
+def recv(self, bufsize, event):
+self.check(event, 'read', 'before')
+data = recvall(self.sock, bufsize)
+self.check(event, 'read', 'after')
+return data
+
+def close(self):
+self.sock.close()
+
+def negotiate(conn):
+'''Negotiate export with client'''
+# Send negotiation part 1
+buf = neg1_struct.pack(NBD_PASSWD, NBD_OPTS_MAGIC, 0)
+conn.send(buf, event='neg1')
+
+# Receive export option
+buf = conn.recv(export_struct.size, event='export')
+export = export_tuple._make(export_struct.unpack(buf))
+assert export.magic == NBD_OPTS_MAGIC
+assert export.opt == NBD_OPT_EXPORT_NAME
+name = conn.recv(export.len, event='export-name')
+
+# Send negotiation part 2
+buf = neg2_struct.pack(

[Qemu-devel] [PATCH 17/17] s390-ccw.img: new binary rom to match latest fixes

2014-02-25 Thread Christian Borntraeger
Signed-off-by: Christian Borntraeger 
---
 pc-bios/s390-ccw.img | Bin 9336 -> 9336 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/pc-bios/s390-ccw.img b/pc-bios/s390-ccw.img
index 
6727f0ca39d6bf6d114974d1535cb7ad9e56355f..f6223e77c2aacfa86652d63b773dc05eca55570d
 100644
GIT binary patch
delta 1460
zcmYLJeN0{B598rap=*kQJ&?u}Igs0Y|(CEtrhk^vfveG`nf|
zQG1G)0|AjT-{nR@TC54+G%-KBC7IeZ9IiLDU=L1enL5eI)&qGZdM~>Z@|zm}mik19
zMYN89O$5EdEu=%RH9ZNSkK!+iUFt?mvas+p^L~g}-C|c%#E}wznw?OFy>5HZ>wvMm
z8`Hka10~Ly0q)#HXG7Hk0rhwoVEyVg>Qw+M+!8TLd+ik@mtL?J)G>e+8pft>2o9~BoN#Ewl^K@@5k
zO}HoPwmc1n
zf_f`Bt2*^;;^!3`Sg{lyDv1;u76Q@&mntm^*>x!DF|m3|SkKT-hu3iidmfi%BZ$0T
zFqkd9fNG9La*-}M{FbyOn(nM5Gql?IIJq?bsw@+%ems%$UX)1_OmP98D8_6QIx&3Y#hhc*4`6;6f=WFrKHh?lcxqgM#y5F%e27E}=aI+pfF)$eW
zyBASI)DTU^?yq9@D#reqN5n_D>PHMCP9Y+1Z71SY#7V?e#@2`N_NZ6`UT{kgtE@sq
z{>DB;yzrYNh;xjkteDt_Irwk_&{~g|%+pqnFD-zPx@g$ras_k3(iQ_}3;-RBB}eIb
zPaQGnJx@(x2igv7GXOle-aye&y3gw)Wwg~>PC~TTTUm_q;3hN;WDMFYKTO@&-h&T`
z3}ZQ6^p>}V1Zj3rsI(@--1>Uhq*46BKMFoP-E^*0`wtZv7?}V7

delta 1362
zcmYLIZA@EL7=BN0;TBlP?Z-;n_2U*;z`%sX1sJH{Ky0#U2+mlHKdOm_#APxi1kE!1
zKt;!N-I*DSm^9k%GBaZXnm9G&M(45wWHoG&7>y*C{V>IFmvz`p?D0Kk3!dcmdGEQ;
z`@GL{?rlDjj~ow?+PK&R
z*&+QJ0GW*{G0;`qT}%0Z^x&P*r~+8EcE+?(IFPLZ1-7Kz?3U-{{b~l@Rl)9daGs_>
zu{H?LXcIuRuK^xPm`QDnvD6SiY5@pW_Ozuc@U98KQ|oq)@V4n)37D<~bxZ}nb}vXc
z#2F{%S;R8OY5a8iAS
zh+XL|!CJ;=NwA5&SrPRGeJ^kNNXr3e!QSCT$bBqYJ`^HWS{ZE3D1b)q3`)}P>~%ZpjP!92SUFGfqUInpqeYp8473Q=^ADL%z+YJ>tR-y2^=y^%F3v+jcVa$^JKZ~>|ddjZK
z8PFBVh3B%DuiL33nf9Zl7Xs#WZsqEpU*^AsMoAso$kqih(}pY9MR$plb*Dd1lg8L&(GQ!q!j84chNMimaU5Ad7UV
z;sNp%b$i0(GHvm6mc1DP^9)yee1*R4IYukIL9$MpymjsT3m9dq+yU9n!)z289oK8|
zGx~xjkaOaR#Gm|=M{lp-%l^achiW~89buaA2FNs>^|r}*JThBZ_=K;MFxur)-MR_3
z-c|l*>iyFghyheoI*4i`x}8YBCa6zGnTJK
zd=2pmBJyrEB3?qAN6a&JdlEkm54ubv_F#?{MC5ODAx<#%FX~#B7%Sj#2`{l+0Q87I
zKvw9aKU6e^O087)yWPFzdCOf2!2MVqU@VuWtNwO!iPi_2y@R;7XOjWo$9jXY^#nZ}
z2$6a^8K@yKdLhsdMtiUT-A7BtZI+AkbDKT8aM($VbC|k<%_K_q1sisvbtv6rh{+Zg
zMoc32S?GSRl&c(*-!J~4=;`t$i)Edj3)Y~cE5U}MJoX)&iIX`?*oq}41L={+o&f1w
z=P!lRTid?<@%f?ozScKl!3d>ahO;;_QQ1y9=yK(YCDA)WeNh^%YA)e6aBWM|3B1E|
M

[Qemu-devel] [PATCH 00/17] s390x/kvm: pending patches

2014-02-25 Thread Christian Borntraeger
Anthony, Peter,

here is what I have queued for my next pull request. I will wait
until the linux header updates move from kvm/queue to kvm/next, which
should happen soon.

The patch queue is basically the combined queue of things already posted.

o https://lists.gnu.org/archive/html/qemu-devel/2014-02/msg01041.html
- two sigp patches removed which need some more work
+ some fixes for flic/pfault (use designated initializer)
+ fixed patch descriptions
+ add qemu-stable to s390x/virtio-hcall: Add range check for hypervisor call

o https://lists.gnu.org/archive/html/qemu-devel/2014-02/msg02200.html
+ style fixes
+ better patch description


Conny, maybe you can post your (on top) adapter interrupt/irqfd patch
set as well before the soft freeze? This has already seen many (internal)
test and performance cycles, so time for a last(?) round of review before
the soft freeze.

Christian


Christian Borntraeger (5):
  update linux headers to kvm/queue
  s390x/eventfacility: mask out commands
  s390-ccw.img: Fix sporadic reboot hangs: Initialize next_idx
  s390-ccw.img: Fix sporadic errors with ccw boot image - initialize css
  s390-ccw.img: new binary rom to match latest fixes

Dominik Dingel (1):
  s390x/async_pf: Check for apf extension and enable pfault

Heinz Graalfs (4):
  s390x/event-facility: some renaming
  s390x/event-facility: code restructure
  s390x/event-facility: add support for live migration
  s390x/event-facility: exploit realize/unrealize

Jens Freimann (1):
  s390x/kvm: implement floating-interrupt controller device

Thomas Huth (6):
  s390x/kvm: Fixed bad SIGP SET-ARCHITECTURE handler
  s390x/virtio-hcall: Add range check for hypervisor call
  s390x/virtio-hcall: Specification exception for illegal subcodes
  s390x/sclp: Fixed the size of sccb and code parameter
  s390x/sclp: Add missing checks to SCLP handler
  s390x/sclp: Fixed setting of condition code register

 default-configs/s390x-softmmu.mak |   1 +
 hw/intc/Makefile.objs |   1 +
 hw/intc/s390_flic.c   | 322 ++
 hw/s390x/event-facility.c |  93 ++-
 hw/s390x/s390-virtio-ccw.c|   8 +-
 hw/s390x/s390-virtio-hcall.c  |  14 +-
 hw/s390x/s390-virtio.c|   2 +
 hw/s390x/sclp.c   |  69 +++-
 include/hw/s390x/event-facility.h |  19 +++
 include/hw/s390x/s390_flic.h  |  33 
 include/hw/s390x/sclp.h   |  24 ---
 linux-headers/asm-arm/kvm.h   |  28 
 linux-headers/asm-arm64/kvm.h |  30 +++-
 linux-headers/asm-powerpc/kvm.h   |   3 +
 linux-headers/asm-s390/kvm.h  |  19 +++
 linux-headers/asm-x86/hyperv.h|  16 +-
 linux-headers/linux/kvm.h |  67 
 pc-bios/s390-ccw.img  | Bin 9336 -> 9336 bytes
 pc-bios/s390-ccw/main.c   |   3 +-
 pc-bios/s390-ccw/virtio.c |   1 +
 target-s390x/cpu.c|   6 +
 target-s390x/cpu.h|   6 +-
 target-s390x/kvm.c|  76 +++--
 target-s390x/misc_helper.c|   2 +-
 trace-events  |   5 +
 25 files changed, 712 insertions(+), 136 deletions(-)
 create mode 100644 hw/intc/s390_flic.c
 create mode 100644 include/hw/s390x/s390_flic.h

-- 
1.8.4.2




[Qemu-devel] [PATCH 05/17] s390x/virtio-hcall: Add range check for hypervisor call

2014-02-25 Thread Christian Borntraeger
From: Thomas Huth 

The handler for diag 500 did not check whether the requested function
was in the supported range, so illegal values could crash QEMU in the
worst case.

Signed-off-by: Thomas Huth 
Reviewed-by: Cornelia Huck 
Signed-off-by: Christian Borntraeger 
CC: qemu-sta...@nongnu.org
---
 hw/s390x/s390-virtio-hcall.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/hw/s390x/s390-virtio-hcall.c b/hw/s390x/s390-virtio-hcall.c
index ee62649..0e328d8 100644
--- a/hw/s390x/s390-virtio-hcall.c
+++ b/hw/s390x/s390-virtio-hcall.c
@@ -26,11 +26,14 @@ void s390_register_virtio_hypercall(uint64_t code, 
s390_virtio_fn fn)
 
 int s390_virtio_hypercall(CPUS390XState *env)
 {
-s390_virtio_fn fn = s390_diag500_table[env->regs[1]];
+s390_virtio_fn fn;
 
-if (!fn) {
-return -EINVAL;
+if (env->regs[1] < MAX_DIAG_SUBCODES) {
+fn = s390_diag500_table[env->regs[1]];
+if (fn) {
+return fn(&env->regs[2]);
+}
 }
 
-return fn(&env->regs[2]);
+return -EINVAL;
 }
-- 
1.8.4.2




[Qemu-devel] [PATCH 0/3] nbd: fix issues when connection breaks

2014-02-25 Thread Stefan Hajnoczi
The first patch ensures the nbd_receive_reply() fd handler is unregistered when
the connection to the server breaks.  This avoids high CPU consumption and
flooding error messages.

The second patch introduces an NBD server fault injection script.  Using this
fake NBD server it is possible to exercise error handling code paths in the NBD
client.

The third patch adds qemu-iotests test case 080 to verify qemu-io exits with an
error at each point where the connection can break.

Stefan Hajnoczi (3):
  nbd: close socket if connection breaks
  tests: add nbd-fault-injector.py utility
  qemu-iotests: add 080 NBD client disconnect tests

 block/nbd-client.c   |  33 +++--
 tests/qemu-iotests/080   |  91 
 tests/qemu-iotests/080.out   |  73 ++
 tests/qemu-iotests/group |   1 +
 tests/qemu-iotests/nbd-fault-injector.py | 231 +++
 5 files changed, 414 insertions(+), 15 deletions(-)
 create mode 100755 tests/qemu-iotests/080
 create mode 100644 tests/qemu-iotests/080.out
 create mode 100755 tests/qemu-iotests/nbd-fault-injector.py

-- 
1.8.5.3




[Qemu-devel] [PATCH 1/3] nbd: close socket if connection breaks

2014-02-25 Thread Stefan Hajnoczi
nbd_receive_reply() is called by the event loop whenever data is
available or the socket has been closed by the remote side.

This patch closes the socket when an error occurs to prevent the
nbd_receive_reply() handler from being called indefinitely after the
connection has failed.

Note that we were already correctly returning EIO for pending requests
but leaving the nbd_receive_reply() handler registered resulted in high
CPU consumption and a flood of error messages.

Reuse nbd_teardown_connection() to close the socket.

Reported-by: Zhifeng Cai 
Signed-off-by: Stefan Hajnoczi 
---
 block/nbd-client.c | 33 ++---
 1 file changed, 18 insertions(+), 15 deletions(-)

diff --git a/block/nbd-client.c b/block/nbd-client.c
index 0922b78..7d698cb 100644
--- a/block/nbd-client.c
+++ b/block/nbd-client.c
@@ -43,6 +43,17 @@ static void nbd_recv_coroutines_enter_all(NbdClientSession 
*s)
 }
 }
 
+static void nbd_teardown_connection(NbdClientSession *client)
+{
+/* finish any pending coroutines */
+shutdown(client->sock, 2);
+nbd_recv_coroutines_enter_all(client);
+
+qemu_aio_set_fd_handler(client->sock, NULL, NULL, NULL);
+closesocket(client->sock);
+client->sock = -1;
+}
+
 static void nbd_reply_ready(void *opaque)
 {
 NbdClientSession *s = opaque;
@@ -78,7 +89,7 @@ static void nbd_reply_ready(void *opaque)
 }
 
 fail:
-nbd_recv_coroutines_enter_all(s);
+nbd_teardown_connection(s);
 }
 
 static void nbd_restart_write(void *opaque)
@@ -324,7 +335,7 @@ int nbd_client_session_co_discard(NbdClientSession *client, 
int64_t sector_num,
 
 }
 
-static void nbd_teardown_connection(NbdClientSession *client)
+void nbd_client_session_close(NbdClientSession *client)
 {
 struct nbd_request request = {
 .type = NBD_CMD_DISC,
@@ -332,22 +343,14 @@ static void nbd_teardown_connection(NbdClientSession 
*client)
 .len = 0
 };
 
-nbd_send_request(client->sock, &request);
-
-/* finish any pending coroutines */
-shutdown(client->sock, 2);
-nbd_recv_coroutines_enter_all(client);
-
-qemu_aio_set_fd_handler(client->sock, NULL, NULL, NULL);
-closesocket(client->sock);
-client->sock = -1;
-}
-
-void nbd_client_session_close(NbdClientSession *client)
-{
 if (!client->bs) {
 return;
 }
+if (client->sock == -1) {
+return;
+}
+
+nbd_send_request(client->sock, &request);
 
 nbd_teardown_connection(client);
 client->bs = NULL;
-- 
1.8.5.3




[Qemu-devel] [PATCH 02/17] s390x/kvm: implement floating-interrupt controller device

2014-02-25 Thread Christian Borntraeger
From: Jens Freimann 

This patch implements a floating-interrupt controller device (flic)
which interacts with the s390 flic kvm_device.

Signed-off-by: Jens Freimann 
Reviewed-by: Cornelia Huck 
Signed-off-by: Christian Borntraeger 
---
 default-configs/s390x-softmmu.mak |   1 +
 hw/intc/Makefile.objs |   1 +
 hw/intc/s390_flic.c   | 286 ++
 hw/s390x/s390-virtio-ccw.c|   8 +-
 hw/s390x/s390-virtio.c|   2 +
 include/hw/s390x/s390_flic.h  |  33 +
 trace-events  |   5 +
 7 files changed, 335 insertions(+), 1 deletion(-)
 create mode 100644 hw/intc/s390_flic.c
 create mode 100644 include/hw/s390x/s390_flic.h

diff --git a/default-configs/s390x-softmmu.mak 
b/default-configs/s390x-softmmu.mak
index 81fbc68..d843dc0 100644
--- a/default-configs/s390x-softmmu.mak
+++ b/default-configs/s390x-softmmu.mak
@@ -1,2 +1,3 @@
 CONFIG_VIRTIO=y
 CONFIG_SCLPCONSOLE=y
+CONFIG_S390_FLIC=$(CONFIG_KVM)
diff --git a/hw/intc/Makefile.objs b/hw/intc/Makefile.objs
index 60eb936..c8a2318 100644
--- a/hw/intc/Makefile.objs
+++ b/hw/intc/Makefile.objs
@@ -25,3 +25,4 @@ obj-$(CONFIG_SH4) += sh_intc.o
 obj-$(CONFIG_XICS) += xics.o
 obj-$(CONFIG_XICS_KVM) += xics_kvm.o
 obj-$(CONFIG_ALLWINNER_A10_PIC) += allwinner-a10-pic.o
+obj-$(CONFIG_S390_FLIC) += s390_flic.o
diff --git a/hw/intc/s390_flic.c b/hw/intc/s390_flic.c
new file mode 100644
index 000..1a7876d
--- /dev/null
+++ b/hw/intc/s390_flic.c
@@ -0,0 +1,286 @@
+/*
+ * QEMU S390x KVM floating interrupt controller (flic)
+ *
+ * Copyright 2014 IBM Corp.
+ * Author(s): Jens Freimann 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or (at
+ * your option) any later version. See the COPYING file in the top-level
+ * directory.
+ */
+
+#include 
+#include "qemu/error-report.h"
+#include "hw/sysbus.h"
+#include "sysemu/kvm.h"
+#include "migration/qemu-file.h"
+#include "hw/s390x/s390_flic.h"
+#include "trace.h"
+
+#define FLIC_SAVE_INITIAL_SIZE getpagesize()
+#define FLIC_FAILED (-1UL)
+#define FLIC_SAVEVM_VERSION 1
+
+void s390_flic_init(void)
+{
+DeviceState *dev;
+int r;
+
+if (kvm_enabled()) {
+dev = qdev_create(NULL, "s390-flic");
+object_property_add_child(qdev_get_machine(), "s390-flic",
+OBJECT(dev), NULL);
+r = qdev_init(dev);
+if (r) {
+error_report("flic: couldn't create qdev");
+}
+}
+}
+
+/**
+ * flic_get_all_irqs - store all pending irqs in buffer
+ * @buf: pointer to buffer which is passed to kernel
+ * @len: length of buffer
+ * @flic: pointer to flic device state
+ *
+ * Returns: -ENOMEM if buffer is too small,
+ * -EINVAL if attr.group is invalid,
+ * -EFAULT if copying to userspace failed,
+ * on success return number of stored interrupts
+ */
+static int flic_get_all_irqs(KVMS390FLICState *flic,
+ void *buf, int len)
+{
+struct kvm_device_attr attr = {
+.group = KVM_DEV_FLIC_GET_ALL_IRQS,
+.addr = (uint64_t) buf,
+.attr = len,
+};
+int rc;
+
+rc = ioctl(flic->fd, KVM_GET_DEVICE_ATTR, &attr);
+
+return rc == -1 ? -errno : rc;
+}
+
+/** flic_enqueue_irqs - returns 0 on success
+ * @buf: pointer to buffer which is passed to kernel
+ * @len: length of buffer
+ * @flic: pointer to flic device state
+ *
+ * Returns: -EINVAL if attr.group is unknown
+ */
+static int flic_enqueue_irqs(void *buf, uint64_t len,
+KVMS390FLICState *flic)
+{
+int rc;
+struct kvm_device_attr attr = {
+.group = KVM_DEV_FLIC_ENQUEUE,
+.addr = (uint64_t) buf,
+.attr = len,
+};
+
+rc = ioctl(flic->fd, KVM_SET_DEVICE_ATTR, &attr);
+
+return rc ? -errno : 0;
+}
+
+/**
+ * __get_all_irqs - store all pending irqs in buffer
+ * @flic: pointer to flic device state
+ * @buf: pointer to pointer to a buffer
+ * @len: length of buffer
+ *
+ * Returns: return value of flic_get_all_irqs
+ * Note: Retry and increase buffer size until flic_get_all_irqs
+ * either returns a value >= 0 or a negative error code.
+ * -ENOMEM is an exception, which means the buffer is too small
+ * and we should try again. Other negative error codes can be
+ * -EFAULT and -EINVAL which we ignore at this point
+ */
+static int __get_all_irqs(KVMS390FLICState *flic,
+  void **buf, int len)
+{
+int r;
+
+do {
+/* returns -ENOMEM if buffer is too small and number
+ * of queued interrupts on success */
+r = flic_get_all_irqs(flic, *buf, len);
+if (r >= 0) {
+break;
+}
+len *= 2;
+*buf = g_try_realloc(*buf, len);
+if (!buf) {
+return -ENOMEM;
+}
+} while (r == -ENOMEM && len <= KVM_S390_FLIC_MAX_BUFFER);
+
+return r;
+}
+
+/**
+ * kvm_flic_save - Save pending floating interrupts
+ * @f: QEMUFile containing migration state
+ * @opaque: point

[Qemu-devel] [PATCH 12/17] s390x/event-facility: code restructure

2014-02-25 Thread Christian Borntraeger
From: Heinz Graalfs 

Code restructure in order to simplify class hierarchy
  - remove S390SCLPDevice abstract base class
and move function pointers into new SCLPEventFacilityClass
  - implement SCLPEventFacility as SysBusDevice
  - use define constants for instance creation strings

The following ascii-art shows the class structure wrt the SCLP EventFacility
before (CURRENT) and after the restructure (NEW):


CURRENT:

   "s390-sclp-events-bus"
   +-+
   |  SCLPEventsBus  |
   |-|
   |BusState qbus|
   +-+

   +-+
   |   SCLPEventFacility |  - to be replaced by new SCLPEventFacility,
   |-|which will be a SysBusDevice
   |SCLPEventsBus sbus   |
   |DeviceState *qdev|
   |unsigned int receive_mask|
   +-+

   +-+
   |   S390SCLPDeviceClass   |  - to be replaced by new SCLPEventFacilityClass
   |-|
   |DeviceClass qdev |
   |*(init)()|
   +-+

   "s390-sclp-event-facility"
 |
 instance-of
 |
 V
   "s390-sclp-device"   - this is an abstract class
   +-+
   | S390SCLPDevice   (A)|  - to be replaced by new SCLPEventFacility
   |-|
   |SysBusDevice busdev  |
   |SCLPEventFacility *ef|
   | |
   |*(sclp_command_handler)()|  - these 2 go to new SCLPEventFacilityClass
   |*(event_pending)()   |
   +-+


NEW:

   "s390-sclp-events-bus"
   +-+
   |  SCLPEventsBus  |
   |-|
   |BusState qbus|
   +-+

   +-+
   | SCLPEventFacilityClass  |
   |-|
   |DeviceClass parent_class |
   | |
   |*(init)()|
   |*(command_handler)() |
   |*(event_pending)()   |
   +-+

   "s390-sclp-event-facility"
   +-+
   |   SCLPEventFacility |
   |-|
   |SysBusDevice parent_class|
   |SCLPEventsBus sbus   |
   |unsigned int receive_mask|
   +-+

Signed-off-by: Heinz Graalfs 
Reviewed-by: Cornelia Huck 
Signed-off-by: Christian Borntraeger 
---
 hw/s390x/event-facility.c | 34 +++
 hw/s390x/sclp.c   | 58 ---
 include/hw/s390x/event-facility.h | 19 +
 include/hw/s390x/sclp.h   | 24 
 4 files changed, 47 insertions(+), 88 deletions(-)

diff --git a/hw/s390x/event-facility.c b/hw/s390x/event-facility.c
index e0ee737..8ad2dc4 100644
--- a/hw/s390x/event-facility.c
+++ b/hw/s390x/event-facility.c
@@ -26,8 +26,8 @@ typedef struct SCLPEventsBus {
 } SCLPEventsBus;
 
 struct SCLPEventFacility {
+SysBusDevice parent_obj;
 SCLPEventsBus sbus;
-DeviceState *qdev;
 /* guest' receive mask */
 unsigned int receive_mask;
 };
@@ -315,21 +315,15 @@ static void command_handler(SCLPEventFacility *ef, SCCB 
*sccb, uint64_t code)
 }
 }
 
-static int init_event_facility(S390SCLPDevice *sdev)
+static int init_event_facility(SCLPEventFacility *event_facility)
 {
-SCLPEventFacility *event_facility;
+DeviceState *sdev = DEVICE(event_facility);
 DeviceState *quiesce;
 
-event_facility = g_malloc0(sizeof(SCLPEventFacility));
-sdev->ef = event_facility;
-sdev->sclp_command_handler = command_handler;
-sdev->event_pending = event_pending;
-
-/* Spawn a new sclp-events facility */
+/* Spawn a new bus for SCLP events */
 qbus_create_inplace(&event_facility->sbus, sizeof(event_facility->sbus),
-TYPE_SCLP_EVENTS_BUS, DEVICE(sdev), NULL);
+TYPE_SCLP_EVENTS_BUS, sdev, NULL);
 event_facility->sbus.qbus.allow_hotplug = 0;
-event_facility->qdev = (DeviceState *) sdev;
 
 quiesce = qdev_create(&event_facility->sbus.qbus, "sclpquiesce");
 if (!quiesce) {
@@ -346,25 +340,29 @@ static int init_event_facility(S390SCLPDevice *sdev)
 
 static void reset_event_facility(DeviceState *dev)
 {
-S390SCLPDevice *sdev = SCLP_S390_DEVICE(dev);
+SCLPEventFacility *sdev = EVENT_FACILITY(dev);
 
-sdev->ef->receive_mask = 0;
+sdev->receive_mask = 0;
 }
 
 static void init_event_facility_class(ObjectClass *klass, void *data)
 {
-DeviceClass *dc = DEVICE_CLASS(klass);
-S390SCLPDeviceClass *k = SCLP_S390_DEVICE_CLASS(klass);
+SysBusDeviceClass *sbdc = SYS_BUS_DEVICE_CLASS(klass);
+DeviceClass *dc = DEVICE_CLASS(sbdc);
+SCLPEventFacilityClass *k = EVENT_FACILITY_CLASS(dc);
 
 dc->reset = reset_event_facility;
 k->init = init_event_facility;
+k->command_handler = command_handler;
+k

Re: [Qemu-devel] QOM vs QAPI for QMP APIs

2014-02-25 Thread Stefan Hajnoczi
On Tue, Feb 25, 2014 at 10:46 AM, Kevin Wolf  wrote:
> External QOM interfaces have their place, especially for debugging or
> trying out things before there is a proper API, but it's not as the
> primary external interface.

Yes, I agree.

Stefan



Re: [Qemu-devel] [PATCH v18 13/14] memory backend: fill memory backend ram fields

2014-02-25 Thread Hu Tao
On Wed, Feb 19, 2014 at 10:03:13AM +0100, Paolo Bonzini wrote:

<...>

> > static int
> > ram_backend_memory_init(HostMemoryBackend *backend, Error **errp)
> > {
> >+HostMemoryBackendRam *ram_backend = MEMORY_BACKEND_RAM(backend);
> >+int mode = ram_backend->policy;
> >+void *p;
> >+unsigned long maxnode;
> >+
> > if (!memory_region_size(&backend->mr)) {
> > memory_region_init_ram(&backend->mr, OBJECT(backend),
> >object_get_canonical_path(OBJECT(backend)),
> >backend->size);
> >+
> >+p = memory_region_get_ram_ptr(&backend->mr);
> >+maxnode = find_last_bit(ram_backend->host_nodes, MAX_NODES);
> >+
> >+mode |= ram_backend->relative ? MPOL_F_RELATIVE_NODES :
> >+MPOL_F_STATIC_NODES;
> >+/* This is a workaround for a long standing bug in Linux'
> >+ * mbind implementation, which cuts off the last specified
> >+ * node. To stay compatible should this bug be fixed, we
> >+ * specify one more node and zero this one out.
> >+ */
> >+if (syscall(SYS_mbind, p, backend->size, mode,
> >+ram_backend->host_nodes, maxnode + 2, 0)) {
> 
> This does not compile on non-Linux; also, does libnuma include the
> workaround?  If so, this is a hint that we should be using libnuma
> instead...

Tested with libnuma and works fine without the workaround. Will use
libnuma in v19.




Re: [Qemu-devel] [PATCH 3/3] qemu-iotests: add 080 NBD client disconnect tests

2014-02-25 Thread Kevin Wolf
Am 25.02.2014 um 11:09 hat Stefan Hajnoczi geschrieben:
> This new test case uses nbd-fault-injector.py to simulate broken TCP
> connections at each stage in the NBD protocol.  This way we can exercise
> block/nbd-client.c's socket error handling code paths.
> 
> In particular, this serves as a regression test to make sure
> nbd-client.c doesn't cause an infinite loop by leaving its
> nbd_receive_reply() fd handler registered after the connection has been
> closed.  This bug was fixed in an earlier patch.
> 
> Signed-off-by: Stefan Hajnoczi 
> ---
>  tests/qemu-iotests/080 | 91 
> ++
>  tests/qemu-iotests/080.out | 73 +
>  tests/qemu-iotests/group   |  1 +

083 is the next free one, afaik. (081 and 082 are used by the pull
request I sent on Friday, and I think 080 was reserved for some series,
but I don't remember who it was.)

Kevin



Re: [Qemu-devel] [PATCH 2/2] qtest: fix a "!chr->fd_in_tag" assertion error in qtest.

2014-02-25 Thread Gal Hammer
Hi,

After reading the code again. It make sense to leave the call to 
remove_fd_in_watch() because I changed the code so the chr_update_read_handler 
function is called only when the front end is opened.

Submitting a new version of the patch.

Gal.


- Original Message -
From: "Gal Hammer" 
To: "Paolo Bonzini" , qemu-devel@nongnu.org
Cc: "amit shah" , "peter maydell" 
, anth...@codemonkey.ws
Sent: Monday, February 24, 2014 1:44:31 PM
Subject: Re: [Qemu-devel] [PATCH 2/2] qtest: fix a "!chr->fd_in_tag" assertion 
error in qtest.

On 24/02/2014 12:32, Paolo Bonzini wrote:
> Il 24/02/2014 11:16, Gal Hammer ha scritto:
>> Replacement of the default chardev handlers now requires a call to
>> release the current handlers.
>>
>> Signed-off-by: Gal Hammer 
>> ---
>>  monitor.c | 1 +
>>  qtest.c   | 2 ++
>>  2 files changed, 3 insertions(+)
>>
>> diff --git a/monitor.c b/monitor.c
>> index de90fba..db52e7f 100644
>> --- a/monitor.c
>> +++ b/monitor.c
>> @@ -5024,6 +5024,7 @@ void monitor_init(CharDriverState *chr, int flags)
>>  if (monitor_ctrl_mode(mon)) {
>>  mon->mc = g_malloc0(sizeof(MonitorControl));
>>  /* Control mode requires special handlers */
>> +qemu_chr_add_handlers(chr, NULL, NULL, NULL, NULL);
>>  qemu_chr_add_handlers(chr, monitor_can_read,
>> monitor_control_read,
>>monitor_control_event, mon);
>>  qemu_chr_fe_set_echo(chr, true);
>> diff --git a/qtest.c b/qtest.c
>> index ae941d6..a5682ee 100644
>> --- a/qtest.c
>> +++ b/qtest.c
>> @@ -519,6 +519,8 @@ void qtest_init(const char *qtest_chrdev, const
>> char *qtest_log, Error **errp)
>>  return;
>>  }
>>
>> +/* Replace the default tcp's handlers with qtest's handlers. */
>> +qemu_chr_add_handlers(chr, NULL, NULL, NULL, NULL);
>>  qemu_chr_add_handlers(chr, qtest_can_read, qtest_read,
>> qtest_event, chr);
>>  qemu_chr_fe_set_echo(chr, true);
>>
>>
>
> Why can't qemu_chr_add_handlers call remove_fd_in_watch when handlers
> are replaced, before setting the new ones?
>
> Paolo

It used to be like that (see patch 1/2 for the change). However, I 
removed it after I saw that the function remove_fd_in_watch() is always 
called when setting all the handlers to NULL (qemu-char.c +3872) so a 
second call in every chr_update_read_handler callback seems redundant.

As far as I can tell only the qtest change the read handlers and not 
using the default ones.

 Gal.





[Qemu-devel] [PATCH V6] char: restore read callback on a reattached (hotplug) chardev

2014-02-25 Thread Gal Hammer
Fix a bug that was introduced in commit 386a5a1e. A removal of a device
set the chr handlers to NULL. However when the device is plugged back,
its read callback is not restored so data can't be transferred from the
host to the guest (e.g. via the virtio-serial port).

https://bugzilla.redhat.com/show_bug.cgi?id=1027181

Signed-off-by: Gal Hammer 

---
 qemu-char.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

V6: - replace asserts with remove_fd_in_watch to allow changing
  the char device read hanlders.

V5: - remove_fd_in_watch in fd_chr_update_read_handler as well.
- fix pty backend.

V4: - Same as V3, but this time done right.

V3: - fix a typo in comment.
- move the revision history after the "signed-off-by" tag.

V2: - do not call chr_update_read_handler on device removal.
- add asserts to verify chr_update_read_handler is not called
  with an assigned fd_in_tag to prevent fd leaks.
- update fd and udp backends' chr_update_read_handler function
  so it won't remove fd_in to prevent a double release.

diff --git a/qemu-char.c b/qemu-char.c
index 4d50838..54ed244 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -213,7 +213,7 @@ void qemu_chr_add_handlers(CharDriverState *s,
 s->chr_read = fd_read;
 s->chr_event = fd_event;
 s->handler_opaque = opaque;
-if (s->chr_update_read_handler)
+if (fe_open && s->chr_update_read_handler)
 s->chr_update_read_handler(s);
 
 if (!s->explicit_fe_open) {
@@ -1136,13 +1136,14 @@ static void pty_chr_state(CharDriverState *chr, int 
connected)
 if (!s->connected) {
 s->connected = 1;
 qemu_chr_be_generic_open(chr);
+}
+if (!chr->fd_in_tag) {
 chr->fd_in_tag = io_add_watch_poll(s->fd, pty_chr_read_poll,
pty_chr_read, chr);
 }
 }
 }
 
-
 static void pty_chr_close(struct CharDriverState *chr)
 {
 PtyCharDriver *s = chr->opaque;
@@ -2509,6 +2510,17 @@ static void tcp_chr_connect(void *opaque)
 qemu_chr_be_generic_open(chr);
 }
 
+static void tcp_chr_update_read_handler(CharDriverState *chr)
+{
+TCPCharDriver *s = chr->opaque;
+
+remove_fd_in_watch(chr);
+if (s->chan) {
+chr->fd_in_tag = io_add_watch_poll(s->chan, tcp_chr_read_poll,
+   tcp_chr_read, chr);
+}
+}
+
 #define IACSET(x,a,b,c) x[0] = a; x[1] = b; x[2] = c;
 static void tcp_chr_telnet_init(int fd)
 {
@@ -2664,6 +2676,7 @@ static CharDriverState *qemu_chr_open_socket_fd(int fd, 
bool do_nodelay,
 chr->get_msgfd = tcp_get_msgfd;
 chr->chr_add_client = tcp_chr_add_client;
 chr->chr_add_watch = tcp_chr_add_watch;
+chr->chr_update_read_handler = tcp_chr_update_read_handler;
 /* be isn't opened until we get a connection */
 chr->explicit_be_open = true;
 
-- 
1.8.5.3




Re: [Qemu-devel] [PATCH v18 13/14] memory backend: fill memory backend ram fields

2014-02-25 Thread Hu Tao
On Wed, Feb 19, 2014 at 10:36:57AM +0100, Igor Mammedov wrote:
> On Wed, 19 Feb 2014 10:03:13 +0100
> Paolo Bonzini  wrote:
> 
> >   19/02/2014 08:54, Hu Tao ha scritto:
> > > Thus makes user control how to allocate memory for ram backend.
> > >
> > > Signed-off-by: Hu Tao 
> > > ---
> > >  backends/hostmem-ram.c  | 158 
> > > 
> > >  include/sysemu/sysemu.h |   2 +
> > >  2 files changed, 160 insertions(+)
> > >
> > > diff --git a/backends/hostmem-ram.c b/backends/hostmem-ram.c
> [...]
> 
> > >  static int
> > >  ram_backend_memory_init(HostMemoryBackend *backend, Error **errp)
> > >  {
> > > +HostMemoryBackendRam *ram_backend = MEMORY_BACKEND_RAM(backend);
> > > +int mode = ram_backend->policy;
> > > +void *p;
> > > +unsigned long maxnode;
> > > +
> > >  if (!memory_region_size(&backend->mr)) {
> > >  memory_region_init_ram(&backend->mr, OBJECT(backend),
> > > 
> > > object_get_canonical_path(OBJECT(backend)),
> > > backend->size);
> > > +
> > > +p = memory_region_get_ram_ptr(&backend->mr);
> > > +maxnode = find_last_bit(ram_backend->host_nodes, MAX_NODES);
> > > +
> > > +mode |= ram_backend->relative ? MPOL_F_RELATIVE_NODES :
> > > +MPOL_F_STATIC_NODES;
> > > +/* This is a workaround for a long standing bug in Linux'
> > > + * mbind implementation, which cuts off the last specified
> > > + * node. To stay compatible should this bug be fixed, we
> > > + * specify one more node and zero this one out.
> > > + */
> > > +if (syscall(SYS_mbind, p, backend->size, mode,
> > > +ram_backend->host_nodes, maxnode + 2, 0)) {
> > 
> > This does not compile on non-Linux; also, does libnuma include the 
> > workaround?  If so, this is a hint that we should be using libnuma 
> > instead...
> > 
> > Finally, all this code should be in hostmem.c, not hostmem-ram.c, 
> > because the same policies can be applied to hugepage-backed memory.
> > 
> > Currently host_memory_backend_get_memory is calling bc->memory_init. 
> > Probably the call should be replaced by something like
> I've pushed to github updated version of memdev, where
> host_memory_backend_get_memory() is just convenience wrapper to get
> access to memdev's internal MemoryRegion.
> 
> All initialization now is done in user_creatable->complete() method
> which calls ram_backend_memory_init() so leaving it as is should be fine.

There is a problem that user_creatable_complete() is called before
adding object to "/objects" (see object_create()), which triggers a
assert failure when calling object_get_canonical_path() in
ram_backend_memory_init(). Any ideas?




[Qemu-devel] [PATCH 09/17] s390x/sclp: Add missing checks to SCLP handler

2014-02-25 Thread Christian Borntraeger
From: Thomas Huth 

If the 51 most significant bits of the SCCB address are zero or equal to
the prefix, we should throw an specification exception, too.
Also moved the check for privileged mode to sclp_service_call() to have
all program checks in one place now.

Signed-off-by: Thomas Huth 
Reviewed-by: Cornelia Huck 
Signed-off-by: Christian Borntraeger 
---
 hw/s390x/sclp.c| 9 +++--
 target-s390x/cpu.h | 2 +-
 target-s390x/kvm.c | 6 +-
 target-s390x/misc_helper.c | 2 +-
 4 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c
index 6134d4f..9880977 100644
--- a/hw/s390x/sclp.c
+++ b/hw/s390x/sclp.c
@@ -107,7 +107,7 @@ static void sclp_execute(SCCB *sccb, uint32_t code)
 }
 }
 
-int sclp_service_call(uint64_t sccb, uint32_t code)
+int sclp_service_call(CPUS390XState *env, uint64_t sccb, uint32_t code)
 {
 int r = 0;
 SCCB work_sccb;
@@ -115,11 +115,16 @@ int sclp_service_call(uint64_t sccb, uint32_t code)
 hwaddr sccb_len = sizeof(SCCB);
 
 /* first some basic checks on program checks */
+if (env->psw.mask & PSW_MASK_PSTATE) {
+r = -PGM_PRIVILEGED;
+goto out;
+}
 if (cpu_physical_memory_is_io(sccb)) {
 r = -PGM_ADDRESSING;
 goto out;
 }
-if (sccb & ~0x7ff8ul) {
+if ((sccb & ~0x1fffUL) == 0 || (sccb & ~0x1fffUL) == env->psa
+|| (sccb & ~0x7ff8UL) != 0) {
 r = -PGM_SPECIFICATION;
 goto out;
 }
diff --git a/target-s390x/cpu.h b/target-s390x/cpu.h
index 373c115..9673838 100644
--- a/target-s390x/cpu.h
+++ b/target-s390x/cpu.h
@@ -963,7 +963,7 @@ struct sysib_322 {
 void load_psw(CPUS390XState *env, uint64_t mask, uint64_t addr);
 int mmu_translate(CPUS390XState *env, target_ulong vaddr, int rw, uint64_t asc,
   target_ulong *raddr, int *flags);
-int sclp_service_call(uint64_t sccb, uint32_t code);
+int sclp_service_call(CPUS390XState *env, uint64_t sccb, uint32_t code);
 uint32_t calc_cc(CPUS390XState *env, uint32_t cc_op, uint64_t src, uint64_t 
dst,
  uint64_t vr);
 
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index 9e1083e..e7b3b13 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -445,14 +445,10 @@ static int kvm_sclp_service_call(S390CPU *cpu, struct 
kvm_run *run,
 int r = 0;
 
 cpu_synchronize_state(CPU(cpu));
-if (env->psw.mask & PSW_MASK_PSTATE) {
-enter_pgmcheck(cpu, PGM_PRIVILEGED);
-return 0;
-}
 sccb = env->regs[ipbh0 & 0xf];
 code = env->regs[(ipbh0 & 0xf0) >> 4];
 
-r = sclp_service_call(sccb, code);
+r = sclp_service_call(env, sccb, code);
 if (r < 0) {
 enter_pgmcheck(cpu, -r);
 }
diff --git a/target-s390x/misc_helper.c b/target-s390x/misc_helper.c
index 10d0425..728456f 100644
--- a/target-s390x/misc_helper.c
+++ b/target-s390x/misc_helper.c
@@ -93,7 +93,7 @@ void program_interrupt(CPUS390XState *env, uint32_t code, int 
ilen)
 /* SCLP service call */
 uint32_t HELPER(servc)(CPUS390XState *env, uint64_t r1, uint64_t r2)
 {
-int r = sclp_service_call(r1, r2);
+int r = sclp_service_call(env, r1, r2);
 if (r < 0) {
 program_interrupt(env, -r, 4);
 return 0;
-- 
1.8.4.2




[Qemu-devel] [PATCH 07/17] s390x/eventfacility: mask out commands

2014-02-25 Thread Christian Borntraeger
As a followup to commit 5f04c14a10fa7f259bc0808f35a0beda49f7821e
(s390-sclp: Define New SCLP Codes) we should mask the sclp command
not only in base sclp, but also in the event facility.

Based on an initial patch from Ralf Hoppe.

Signed-off-by: Christian Borntraeger 
---
 hw/s390x/event-facility.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/s390x/event-facility.c b/hw/s390x/event-facility.c
index a73c0b9..1e8c99a 100644
--- a/hw/s390x/event-facility.c
+++ b/hw/s390x/event-facility.c
@@ -299,7 +299,7 @@ static const TypeInfo s390_sclp_events_bus_info = {
 
 static void command_handler(SCLPEventFacility *ef, SCCB *sccb, uint64_t code)
 {
-switch (code) {
+switch (code & SCLP_CMD_CODE_MASK) {
 case SCLP_CMD_READ_EVENT_DATA:
 read_event_data(ef, sccb);
 break;
-- 
1.8.4.2




[Qemu-devel] [PULL 0/1] Lonely uq/master patch for 2014-02-24

2014-02-25 Thread Paolo Bonzini
Anthony, Peter,

The following changes since commit 7c08db30e6a43f7083a881eb07bfbc878e001e08:

  target-i386: Move KVM default-vendor hack to instance_init (2014-02-03 
17:33:55 +0100)

are available in the git repository at:
  git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master

Paolo

Alexander Graf (1):
  KVM: Use return value for error print

 kvm-all.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)




Re: [Qemu-devel] QOM vs QAPI for QMP APIs

2014-02-25 Thread Paolo Bonzini

Il 25/02/2014 11:15, Stefan Hajnoczi ha scritto:

On Tue, Feb 25, 2014 at 10:46 AM, Kevin Wolf  wrote:

> External QOM interfaces have their place, especially for debugging or
> trying out things before there is a proper API, but it's not as the
> primary external interface.

Yes, I agree.


-object is an exception to this though, isn't it?

Paolo



Re: [Qemu-devel] [PATCHv2 00/18] qemu-iotests: adjust tests to work with the NFS protocol

2014-02-25 Thread Stefan Hajnoczi
On Mon, Feb 24, 2014 at 09:21:38PM +0100, Peter Lieven wrote:
> Am 24.02.2014 13:54, schrieb Stefan Hajnoczi:
> > On Sun, Jan 05, 2014 at 06:21:50PM +0100, Peter Lieven wrote:
> >> In order to proceed with the integration of the NFS protocol driver into
> >> qemu I was asked by Stefan to add integration for NFS into the 
> >> qemu-iotests.
> >>
> >> Unfortunately, this became more complex than I had expected because most
> >> of the tests for non RAW formats only work with the file protocol because
> >> they use shell commands like cp, rm or mv which obviously don't work
> >> on nfs:// URLs.
> >>
> >> This series first changes all those tests that are not working out of the
> >> box to support only the file protocol.
> >>
> >> After the NFS protocol is introduced in Patch 2 I fix most of them
> >> to work with any protocol.
> >>
> >> After this series the qemu-iotests for NFS run through gracefully with
> >> the RAW, QCOW2 and VMDK formats.
> >>
> >> There are 3 topics open:
> >>  - test 051 fails regardless which protocol is used (I already send a msg
> >>to the list)
> >>  - test 052 should work, but it seems there is a bug in the bdrv_open
> >>logic if the BDRV_O_SNAPSHOT flag is set and the protocol is anything
> >>else than file. Maybe someone with more understanding of the whole
> >>open logic could look at this. I do not believe that its sth which
> >>has to do with the NFS driver since the test fails while opening the
> >>backing file and other backing file tests run without problems.
> >>  - other protocols like sheepdog or ssh that are allowed to use other 
> >> formats
> >>than raw should be tested. they actually can't never have run 
> >> qemu-iotests
> >>with qcow2 protocol for instance.
> >>
> >> If you want to do your tests please make sure to have
> >>[PATCHv5] block: add native support for NFS
> >>[PATCH v2] vmdk: Allow vmdk_create to work with protocol
> > Going through my email backlog.  What is the status of this series?
> The NFS driver and bare qemu-iotests support is merged. All the patches
> that try to fix the limit for protocol != file where left out because there
> was no consensus how the filename construction etc. should be handled.

Okay, it's the latter I was wondering about.  Let's leave it for now.

Stefan



Re: [Qemu-devel] [PULL 0/2] xen-140220

2014-02-25 Thread Peter Maydell
On 20 February 2014 18:12, Stefano Stabellini
 wrote:
> The following changes since commit 2ca92bb993991d6dcb8f68751aca9fc2ec2b8867:
>
>   Merge remote-tracking branch 'remotes/kraxel/tags/pull-usb-3' into staging 
> (2014-02-20 15:25:05 +)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git xen-140220
>
> for you to fetch changes up to 58da5b1e01a586eb5a52ba3eec342d6828269839:
>
>   xen_disk: fix io accounting (2014-02-20 17:57:13 +)

Applied, thanks.

-- PMM



Re: [Qemu-devel] [PATCH v2] net: Disable netmap backend when not supported

2014-02-25 Thread Stefan Hajnoczi
On Mon, Feb 24, 2014 at 10:54:43AM +0100, Vincenzo Maffione wrote:
>   I cannot see it in your net tree.

It's there now.  Sorry, I sometimes forget to push to my public repo.

Stefan



[Qemu-devel] [PATCH 01/17] update linux headers to kvm/queue

2014-02-25 Thread Christian Borntraeger
This updates the kvm headers to commit 56c103ec040b1944c8866f79aa768265c0dd2986
(KVM: x86: Fix xsave cpuid exposing bug)

Signed-off-by: Christian Borntraeger 
---
 linux-headers/asm-arm/kvm.h | 28 +
 linux-headers/asm-arm64/kvm.h   | 30 +-
 linux-headers/asm-powerpc/kvm.h |  3 ++
 linux-headers/asm-s390/kvm.h| 19 
 linux-headers/asm-x86/hyperv.h  | 16 --
 linux-headers/linux/kvm.h   | 67 +
 6 files changed, 159 insertions(+), 4 deletions(-)

diff --git a/linux-headers/asm-arm/kvm.h b/linux-headers/asm-arm/kvm.h
index c498b60..ef0c878 100644
--- a/linux-headers/asm-arm/kvm.h
+++ b/linux-headers/asm-arm/kvm.h
@@ -119,6 +119,26 @@ struct kvm_arch_memory_slot {
 #define KVM_REG_ARM_32_CRN_MASK0x7800
 #define KVM_REG_ARM_32_CRN_SHIFT   11
 
+#define ARM_CP15_REG_SHIFT_MASK(x,n) \
+   (((x) << KVM_REG_ARM_ ## n ## _SHIFT) & KVM_REG_ARM_ ## n ## _MASK)
+
+#define __ARM_CP15_REG(op1,crn,crm,op2) \
+   (KVM_REG_ARM | (15 << KVM_REG_ARM_COPROC_SHIFT) | \
+   ARM_CP15_REG_SHIFT_MASK(op1, OPC1) | \
+   ARM_CP15_REG_SHIFT_MASK(crn, 32_CRN) | \
+   ARM_CP15_REG_SHIFT_MASK(crm, CRM) | \
+   ARM_CP15_REG_SHIFT_MASK(op2, 32_OPC2))
+
+#define ARM_CP15_REG32(...) (__ARM_CP15_REG(__VA_ARGS__) | KVM_REG_SIZE_U32)
+
+#define __ARM_CP15_REG64(op1,crm) \
+   (__ARM_CP15_REG(op1, 0, crm, 0) | KVM_REG_SIZE_U64)
+#define ARM_CP15_REG64(...) __ARM_CP15_REG64(__VA_ARGS__)
+
+#define KVM_REG_ARM_TIMER_CTL  ARM_CP15_REG32(0, 14, 3, 1)
+#define KVM_REG_ARM_TIMER_CNT  ARM_CP15_REG64(1, 14) 
+#define KVM_REG_ARM_TIMER_CVAL ARM_CP15_REG64(3, 14) 
+
 /* Normal registers are mapped as coprocessor 16. */
 #define KVM_REG_ARM_CORE   (0x0010 << KVM_REG_ARM_COPROC_SHIFT)
 #define KVM_REG_ARM_CORE_REG(name) (offsetof(struct kvm_regs, name) / 4)
@@ -143,6 +163,14 @@ struct kvm_arch_memory_slot {
 #define KVM_REG_ARM_VFP_FPINST 0x1009
 #define KVM_REG_ARM_VFP_FPINST20x100A
 
+/* Device Control API: ARM VGIC */
+#define KVM_DEV_ARM_VGIC_GRP_ADDR  0
+#define KVM_DEV_ARM_VGIC_GRP_DIST_REGS 1
+#define KVM_DEV_ARM_VGIC_GRP_CPU_REGS  2
+#define   KVM_DEV_ARM_VGIC_CPUID_SHIFT 32
+#define   KVM_DEV_ARM_VGIC_CPUID_MASK  (0xffULL << 
KVM_DEV_ARM_VGIC_CPUID_SHIFT)
+#define   KVM_DEV_ARM_VGIC_OFFSET_SHIFT0
+#define   KVM_DEV_ARM_VGIC_OFFSET_MASK (0xULL << 
KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
 
 /* KVM_IRQ_LINE irq field index values */
 #define KVM_ARM_IRQ_TYPE_SHIFT 24
diff --git a/linux-headers/asm-arm64/kvm.h b/linux-headers/asm-arm64/kvm.h
index 5031f42..eaf54a3 100644
--- a/linux-headers/asm-arm64/kvm.h
+++ b/linux-headers/asm-arm64/kvm.h
@@ -55,8 +55,9 @@ struct kvm_regs {
 #define KVM_ARM_TARGET_AEM_V8  0
 #define KVM_ARM_TARGET_FOUNDATION_V8   1
 #define KVM_ARM_TARGET_CORTEX_A57  2
+#define KVM_ARM_TARGET_XGENE_POTENZA   3
 
-#define KVM_ARM_NUM_TARGETS3
+#define KVM_ARM_NUM_TARGETS4
 
 /* KVM_ARM_SET_DEVICE_ADDR ioctl id encoding */
 #define KVM_ARM_DEVICE_TYPE_SHIFT  0
@@ -129,6 +130,33 @@ struct kvm_arch_memory_slot {
 #define KVM_REG_ARM64_SYSREG_OP2_MASK  0x0007
 #define KVM_REG_ARM64_SYSREG_OP2_SHIFT 0
 
+#define ARM64_SYS_REG_SHIFT_MASK(x,n) \
+   (((x) << KVM_REG_ARM64_SYSREG_ ## n ## _SHIFT) & \
+   KVM_REG_ARM64_SYSREG_ ## n ## _MASK)
+
+#define __ARM64_SYS_REG(op0,op1,crn,crm,op2) \
+   (KVM_REG_ARM64 | KVM_REG_ARM64_SYSREG | \
+   ARM64_SYS_REG_SHIFT_MASK(op0, OP0) | \
+   ARM64_SYS_REG_SHIFT_MASK(op1, OP1) | \
+   ARM64_SYS_REG_SHIFT_MASK(crn, CRN) | \
+   ARM64_SYS_REG_SHIFT_MASK(crm, CRM) | \
+   ARM64_SYS_REG_SHIFT_MASK(op2, OP2))
+
+#define ARM64_SYS_REG(...) (__ARM64_SYS_REG(__VA_ARGS__) | KVM_REG_SIZE_U64)
+
+#define KVM_REG_ARM_TIMER_CTL  ARM64_SYS_REG(3, 3, 14, 3, 1)
+#define KVM_REG_ARM_TIMER_CNT  ARM64_SYS_REG(3, 3, 14, 3, 2)
+#define KVM_REG_ARM_TIMER_CVAL ARM64_SYS_REG(3, 3, 14, 0, 2)
+
+/* Device Control API: ARM VGIC */
+#define KVM_DEV_ARM_VGIC_GRP_ADDR  0
+#define KVM_DEV_ARM_VGIC_GRP_DIST_REGS 1
+#define KVM_DEV_ARM_VGIC_GRP_CPU_REGS  2
+#define   KVM_DEV_ARM_VGIC_CPUID_SHIFT 32
+#define   KVM_DEV_ARM_VGIC_CPUID_MASK  (0xffULL << 
KVM_DEV_ARM_VGIC_CPUID_SHIFT)
+#define   KVM_DEV_ARM_VGIC_OFFSET_SHIFT0
+#define   KVM_DEV_ARM_VGIC_OFFSET_MASK (0xULL << 
KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
+
 /* KVM_IRQ_LINE irq field index values */
 #define KVM_ARM_IRQ_TYPE_SHIFT 24
 #define KVM_ARM_IRQ_TYPE_MASK  0xff
diff --git a/linux-headers/asm-powerpc/kvm.h b/linux-headers/asm-powerpc/kvm.h
index 6836ec7..a6665be 100644
--- a/linux-headers/asm-powerpc/kvm.h
+++ b/linux-headers/asm-powerpc/kvm.h
@@ -545,6 +545,7 @@ struct kvm_get_htab_header {
 #define KVM_REG_PPC_TCSCR  (KVM_REG_PPC | KVM_REG_SIZE_U64 | 0xb1)
 #define KVM_REG_PPC_PID  

[Qemu-devel] [PATCH 3/3] qemu-iotests: add 080 NBD client disconnect tests

2014-02-25 Thread Stefan Hajnoczi
This new test case uses nbd-fault-injector.py to simulate broken TCP
connections at each stage in the NBD protocol.  This way we can exercise
block/nbd-client.c's socket error handling code paths.

In particular, this serves as a regression test to make sure
nbd-client.c doesn't cause an infinite loop by leaving its
nbd_receive_reply() fd handler registered after the connection has been
closed.  This bug was fixed in an earlier patch.

Signed-off-by: Stefan Hajnoczi 
---
 tests/qemu-iotests/080 | 91 ++
 tests/qemu-iotests/080.out | 73 +
 tests/qemu-iotests/group   |  1 +
 3 files changed, 165 insertions(+)
 create mode 100755 tests/qemu-iotests/080
 create mode 100644 tests/qemu-iotests/080.out

diff --git a/tests/qemu-iotests/080 b/tests/qemu-iotests/080
new file mode 100755
index 000..21f599b
--- /dev/null
+++ b/tests/qemu-iotests/080
@@ -0,0 +1,91 @@
+#!/bin/bash
+#
+# Test NBD client unexpected disconnect
+#
+# Copyright Red Hat, Inc. 2014
+#
+# 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=stefa...@redhat.com
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+here=`pwd`
+tmp=/tmp/$$
+status=1   # failure is the default!
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+
+_supported_fmt generic
+_supported_proto nbd
+_supported_os Linux
+
+# Pick a TCP port based on our pid.  This way multiple instances of this test
+# can run in parallel without conflicting.
+choose_tcp_port() {
+   echo $((($$ % 31744) + 1024)) # 1024 <= port < 32768
+}
+
+wait_for_tcp_port() {
+   while ! (netstat --tcp --listening --numeric | \
+grep "$1.*0.0.0.0:\*.*LISTEN") 2>&1 >/dev/null; do
+   sleep 0.1
+   done
+}
+
+filter_nbd() {
+   # nbd.c error messages contain function names and line numbers that are 
prone
+   # to change.  Message ordering depends on timing between send and 
receive
+   # callbacks sometimes, making them unreliable.
+   #
+   # Filter out the TCP port number since this changes between runs.
+   sed -e 's#^nbd.c:.*##g' \
+   -e 's#nbd:127.0.0.1:[^:]*:#nbd:127.0.0.1:PORT:#g'
+}
+
+check_disconnect() {
+   event=$1
+   when=$2
+   echo "=== Check disconnect $when $event ==="
+   echo
+
+   port=$(choose_tcp_port)
+
+   cat > "$TEST_DIR/nbd-fault-injector.conf" <&1 >/dev/null &
+   wait_for_tcp_port "127.0.0.1:$port"
+   $QEMU_IO -c "read 0 512" "nbd:127.0.0.1:$port:exportname=foo" 2>&1 | 
_filter_qemu_io | filter_nbd
+
+   echo
+}
+
+for event in neg1 "export" neg2 request reply data; do
+   for when in before after; do
+   check_disconnect "$event" "$when"
+   done
+done
+
+# success, all done
+echo "*** done"
+rm -f $seq.full
+status=0
diff --git a/tests/qemu-iotests/080.out b/tests/qemu-iotests/080.out
new file mode 100644
index 000..9fc5761
--- /dev/null
+++ b/tests/qemu-iotests/080.out
@@ -0,0 +1,73 @@
+QA output created by 080
+=== Check disconnect before neg1 ===
+
+
+qemu-io: can't open device nbd:127.0.0.1:PORT:exportname=foo: Could not open 
image: Invalid argument
+no file open, try 'help open'
+
+=== Check disconnect after neg1 ===
+
+
+qemu-io: can't open device nbd:127.0.0.1:PORT:exportname=foo: Could not open 
image: Invalid argument
+no file open, try 'help open'
+
+=== Check disconnect before export ===
+
+
+qemu-io: can't open device nbd:127.0.0.1:PORT:exportname=foo: Could not open 
image: Invalid argument
+no file open, try 'help open'
+
+=== Check disconnect after export ===
+
+
+qemu-io: can't open device nbd:127.0.0.1:PORT:exportname=foo: Could not open 
image: Invalid argument
+no file open, try 'help open'
+
+=== Check disconnect before neg2 ===
+
+
+qemu-io: can't open device nbd:127.0.0.1:PORT:exportname=foo: Could not open 
image: Invalid argument
+no file open, try 'help open'
+
+=== Check disconnect after neg2 ===
+
+
+qemu-io: can't open device nbd:127.0.0.1:PORT:exportname=foo: Could not read 
image for determining its format: Input/output error
+no file open, try 'help open'
+
+=== Check disconnect before request ===
+
+
+qemu-io: can't open device nbd:127.0.0.1:PORT:exportname=foo: Could not read 
image for determining its format: Input/output error
+no file open, try 'help open'
+
+=== Check disconne

Re: [Qemu-devel] [PATCH 3/3] qemu-iotests: add 080 NBD client disconnect tests

2014-02-25 Thread Stefan Hajnoczi
On Tue, Feb 25, 2014 at 11:16:16AM +0100, Kevin Wolf wrote:
> Am 25.02.2014 um 11:09 hat Stefan Hajnoczi geschrieben:
> > This new test case uses nbd-fault-injector.py to simulate broken TCP
> > connections at each stage in the NBD protocol.  This way we can exercise
> > block/nbd-client.c's socket error handling code paths.
> > 
> > In particular, this serves as a regression test to make sure
> > nbd-client.c doesn't cause an infinite loop by leaving its
> > nbd_receive_reply() fd handler registered after the connection has been
> > closed.  This bug was fixed in an earlier patch.
> > 
> > Signed-off-by: Stefan Hajnoczi 
> > ---
> >  tests/qemu-iotests/080 | 91 
> > ++
> >  tests/qemu-iotests/080.out | 73 +
> >  tests/qemu-iotests/group   |  1 +
> 
> 083 is the next free one, afaik. (081 and 082 are used by the pull
> request I sent on Friday, and I think 080 was reserved for some series,
> but I don't remember who it was.)

Thanks, will fix in v2.

Stefan



Re: [Qemu-devel] device_del id missing after blockdev-add

2014-02-25 Thread William Dauchy
On Feb24 16:34, Stefan Hajnoczi wrote:
> Also, it should probably be 'removable':true?

oh true, did not mention this was a boolean

> You forgot to give the device an ID.  Could that be the problem here?

yup I spotted that some days after and forgot to write an answer here.
that's solved the issue.
I was indeed confused with drive/id attributes.

Thanks for you answer, I thought it my issue was drowned into the ML.
-- 
William


signature.asc
Description: Digital signature


[Qemu-devel] [PULL 1/1] KVM: Use return value for error print

2014-02-25 Thread Paolo Bonzini
From: Alexander Graf 

Commit 94ccff13 introduced a more verbose failure message and retry
operations on KVM VM creation. However, it ended up using a variable
for its failure message that hasn't been initialized yet.

Fix it to use the value it meant to set.

Cc: qemu-sta...@nongnu.org
Signed-off-by: Alexander Graf 
Signed-off-by: Paolo Bonzini 
---
 kvm-all.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kvm-all.c b/kvm-all.c
index f742f8d..979a8d9 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -1427,7 +1427,7 @@ int kvm_init(void)
 } while (ret == -EINTR);
 
 if (ret < 0) {
-fprintf(stderr, "ioctl(KVM_CREATE_VM) failed: %d %s\n", -s->vmfd,
+fprintf(stderr, "ioctl(KVM_CREATE_VM) failed: %d %s\n", -ret,
 strerror(-ret));
 
 #ifdef TARGET_S390X
-- 
1.7.1




Re: [Qemu-devel] [PATCH 2/3] tests: add nbd-fault-injector.py utility

2014-02-25 Thread Nick Thomas
Hi,

On 25/02/14 10:09, Stefan Hajnoczi wrote:
> The nbd-fault-injector.py script is a special kind of NBD server.  It
> throws away all writes and produces zeroes for reads.  Given a list of
> fault injection rules, it can simulate NBD protocol errors and is useful
> for testing NBD client error handling code paths.
> 
> See the patch for documentation.  This scripts is modelled after Kevin
> Wolf 's blkdebug block driver.
> 
> Signed-off-by: Stefan Hajnoczi 
> ---
>  tests/qemu-iotests/nbd-fault-injector.py | 231 
> +++
>  1 file changed, 231 insertions(+)
>  create mode 100755 tests/qemu-iotests/nbd-fault-injector.py
> 
> diff --git a/tests/qemu-iotests/nbd-fault-injector.py 
> b/tests/qemu-iotests/nbd-fault-injector.py
> new file mode 100755
> index 000..b4011f4
> --- /dev/null
> +++ b/tests/qemu-iotests/nbd-fault-injector.py
> @@ -0,0 +1,231 @@
> +#!/usr/bin/env python
> +# NBD server - fault injection utility
> +#
> +# Configuration file syntax:
> +#   [inject-error "disconnect-neg1"]
> +#   event=neg1
> +#   io=readwrite
> +#   when=before
> +#
> +# Note that Python's ConfigParser squashes together all sections with the 
> same
> +# name, so give each [inject-error] a unique name.
> +#
> +# inject-error options:
> +#   event - name of the trigger event
> +#   "neg1" - first part of negotiation struct
> +#   "export" - export struct
> +#   "neg2" - second part of negotiation struct
> +#   "request" - NBD request struct
> +#   "reply" - NBD reply struct
> +#   "data" - request/reply data
> +#   io- I/O direction that triggers this rule:
> +#   "read", "write", or "readwrite"
> +#   default: readwrite
> +#   when  - when to inject the fault relative to the I/O operation
> +#   "before" or "after"
> +#   default: before
> +#
> +# Currently the only error injection action is to terminate the server 
> process.
> +# This resets the TCP connection and thus forces the client to handle
> +# unexpected connection termination.
> +#
> +# Other error injection actions could be added in the future.
> +#
> +# Copyright Red Hat, Inc. 2014
> +#
> +# Authors:
> +#   Stefan Hajnoczi 
> +#
> +# This work is licensed under the terms of the GNU GPL, version 2 or later.
> +# See the COPYING file in the top-level directory.
> +
> +import sys
> +import socket
> +import struct
> +import collections
> +import ConfigParser
> +
> +# Protocol constants
> +NBD_CMD_READ = 0
> +NBD_CMD_WRITE = 1
> +NBD_CMD_DISC = 2
> +NBD_REQUEST_MAGIC = 0x25609513
> +NBD_REPLY_MAGIC = 0x67446698
> +NBD_PASSWD = 0x4e42444d41474943
> +NBD_OPTS_MAGIC = 0x49484156454F5054
> +NBD_OPT_EXPORT_NAME = 1 << 0
> +
> +# Protocol structs
> +neg1_struct = struct.Struct('>QQH')
> +export_tuple = collections.namedtuple('Export', 'reserved magic opt len')
> +export_struct = struct.Struct('>IQII')
> +neg2_struct = struct.Struct('>QH124x')
> +request_tuple = collections.namedtuple('Request', 'magic type handle from_ 
> len')
> +request_struct = struct.Struct('>IIQQI')
> +reply_struct = struct.Struct('>IIQ')
> +
> +def err(msg):
> +sys.stderr.write(msg + '\n')
> +sys.exit(1)
> +
> +def recvall(sock, bufsize):
> +received = 0
> +chunks = []
> +while received < bufsize:
> +chunk = sock.recv(bufsize - received)
> +if len(chunk) == 0:
> +raise Exception('unexpected disconnect')
> +chunks.append(chunk)
> +received += len(chunk)
> +return ''.join(chunks)
> +
> +class Rule(object):
> +def __init__(self, name, event, io, when):
> +self.name = name
> +self.event = event
> +self.io = io
> +self.when = when
> +
> +def match(self, event, io, when):
> +if when != self.when:
> +return False
> +if event != self.event:
> +return False
> +if io != self.io and self.io != 'readwrite':
> +return False
> +return True
> +
> +class FaultInjectionSocket(object):
> +def __init__(self, sock, rules):
> +self.sock = sock
> +self.rules = rules
> +
> +def check(self, event, io, when):
> +for rule in self.rules:
> +if rule.match(event, io, when):
> +print 'Closing connection on rule match %s' % rule.name
> +sys.exit(0)
> +
> +def send(self, buf, event):
> +self.check(event, 'write', 'before')
> +self.sock.sendall(buf)
> +self.check(event, 'write', 'after')
> +
> +def recv(self, bufsize, event):
> +self.check(event, 'read', 'before')
> +data = recvall(self.sock, bufsize)
> +self.check(event, 'read', 'after')
> +return data

There's a class of error I recently encountered in our out-of-tree proxy
component that only shows up if a read or write is interrupted partway
through. Perhaps you could have a "during" event here that happens after
bufsize/2 bytes is written?

I've not 

[Qemu-devel] [PULL] qemu-sparc: CG3 framebuffer plus misc sun4m fixes

2014-02-25 Thread Mark Cave-Ayland
Hi Peter,

This branch contains updates for SPARC, particularly a new implementation of 
the CG3 framebuffer as
reviewed on list, plus timer/hostid fixes from Olivier. Please pull.


ATB,

Mark.


The following changes since commit c58e291591dbc1c846fa152d4792554803405ebb:

  Merge remote-tracking branch 'remotes/sstabellini/xen-140220' into staging 
(2014-02-24 16:12:55 +)

are available in the git repository at:


  http://github.com/mcayland/qemu.git qemu-sparc

for you to fetch changes up to c9bf3ff47b8ce424979aa99fafa6b7197d9b6c5f:

  sun4m: Add Sun CG3 framebuffer initialisation function (2014-02-24 20:11:26 
+)


Mark Cave-Ayland (4):
  sun4m: Set HostID in NVRAM
  sun4m: fix slavio timer RUN/STOP bit
  sun4m: Add Sun CG3 framebuffer and corresponding OpenBIOS FCode ROM
  sun4m: Add Sun CG3 framebuffer initialisation function

 Makefile |2 +-
 default-configs/sparc-softmmu.mak|1 +
 hw/display/Makefile.objs |1 +
 hw/display/cg3.c |  384 ++
 hw/sparc/sun4m.c |   62 -
 hw/timer/slavio_timer.c  |   25 +-
 include/hw/nvram/openbios_firmware_abi.h |2 +
 include/sysemu/sysemu.h  |1 +
 pc-bios/QEMU,cgthree.bin |  Bin 0 -> 850 bytes
 pc-bios/README   |4 +-
 vl.c |   24 ++
 11 files changed, 485 insertions(+), 21 deletions(-)
 create mode 100644 hw/display/cg3.c
 create mode 100644 pc-bios/QEMU,cgthree.bin



Re: [Qemu-devel] [PULL 00/54] Block patches

2014-02-25 Thread Peter Maydell
On 21 February 2014 22:11, Kevin Wolf  wrote:
> The following changes since commit 3e890c77cf038d8c2de66ed7996fe77a6f94787c:
>
>   Merge remote-tracking branch 
> 'remotes/stefanha/tags/qtest-monitor-process-pull-request' into staging 
> (2014-02-21 14:54:05 +)
>
> are available in the git repository at:
>
>
>   git://repo.or.cz/qemu/kevin.git tags/for-upstream
>
> for you to fetch changes up to 6141f3bd6904df7cf9519c6444a14a608b9874c4:
>
>   iotests: Mixed quorum child device specifications (2014-02-21 22:40:19 
> +0100)

Applied, thanks.

-- PMM



Re: [Qemu-devel] [PATCH] monitor: Fix 'mouse_button': do not move mouse

2014-02-25 Thread Eugene Shatokhin

Hi,

On 07/03/2013 08:08 PM, Andreas Färber wrote:

Am 03.07.2013 14:50, schrieb Eugene Shatokhin:

If absolute positions are used, 'mouse_button' command moved mouse
pointer to (0, 0) before generating a mouse button event. The event was
therefore generated at incorrect position.

This problem is now fixed.

Signed-off-by: Eugene Shatokhin 


This patch has been rejected before. I had suggested a different
solution but that was not fully accepted either and I haven't respun yet:
http://lists.nongnu.org/archive/html/qemu-devel/2013-06/msg02506.html



Any news on this issue? I have just checked qemu 1.7.0 - the problem 
still exists there.


Regards,
Eugene

--
Eugene Shatokhin, ROSA
www.rosalab.com



Re: [Qemu-devel] [PULL] xtensa queue 2014-02-24

2014-02-25 Thread Peter Maydell
On 24 February 2014 01:01, Max Filippov  wrote:
> Hi Anthony, Peter,
>
> please pull my current xtensa tree.
>
> The following changes since commit 105a060188dc6fdd4551571a966514d1a5f6815a:
>
>   Merge remote-tracking branch 
> 'remotes/pmaydell/tags/pull-target-arm-20140220' into staging (2014-02-21 
> 15:04:58 +)
>
> are available in the git repository at:
>
>   git://github.com/OSLL/qemu-xtensa.git tags/20140224-xtensa
>
> for you to fetch changes up to 604e1f9cd0602e92ba49a27dd3a46db3d29f882e:
>
>   target-xtensa: provide HW confg ID registers (2014-02-24 04:47:02 +0400)
>
> 
> Xtensa fixes and improvements queue 2014-02-24:
> - add support for ML605 and KC705 FPGA boards;
> - flush opencores_eth queue when new RX descriptor is available;
> - add basic checks to cache opcodes;
> - make core configuration available to tests;
> - implement HW config ID special registers.
>

Applied, thanks.

-- PMM



Re: [Qemu-devel] [PATCH] monitor: Fix 'mouse_button': do not move mouse

2014-02-25 Thread Gerd Hoffmann
On Di, 2014-02-25 at 16:21 +0400, Eugene Shatokhin wrote:
> Hi,
> 
> On 07/03/2013 08:08 PM, Andreas Färber wrote:
> > Am 03.07.2013 14:50, schrieb Eugene Shatokhin:
> >> If absolute positions are used, 'mouse_button' command moved mouse
> >> pointer to (0, 0) before generating a mouse button event. The event was
> >> therefore generated at incorrect position.
> >>
> >> This problem is now fixed.
> >>
> >> Signed-off-by: Eugene Shatokhin 
> >
> > This patch has been rejected before. I had suggested a different
> > solution but that was not fully accepted either and I haven't respun yet:
> > http://lists.nongnu.org/archive/html/qemu-devel/2013-06/msg02506.html
> >
> 
> Any news on this issue? I have just checked qemu 1.7.0 - the problem 
> still exists there.

I have an outstanding pull request for a input layer rewrite:

http://www.kraxel.org/cgit/qemu/tag/?id=pull-input-2

Once it is merged it should be easy to fix as you can simply generate
mouse button events without having to care about the position at all.

cheers,
  Gerd





Re: [Qemu-devel] [PULL 0/6] qemu-ga: various fixes, and serial support for w32

2014-02-25 Thread Peter Maydell
On 24 February 2014 01:21, Michael Roth  wrote:
> Hello,
>
> Please pull the following patches for qemu-ga, which include a number of
> fixes applicable for the upcoming 1.7.1 release, and support for
> communicating with a Windows guest over a serial port.
>
> The following changes since commit 105a060188dc6fdd4551571a966514d1a5f6815a:
>
>   Merge remote-tracking branch 
> 'remotes/pmaydell/tags/pull-target-arm-20140220' into staging (2014-02-21 
> 15:04:58 +)
>
> are available in the git repository at:
>
>
>   git://github.com/mdroth/qemu.git qga-pull-2014-02-24
>
> for you to fetch changes up to bd7e859c65cafee7d63bd8650b09bab36673a7a1:
>
>   qemu-ga: isa-serial support on Windows (2014-02-23 19:07:59 -0600)


Applied, thanks.

-- PMM



[Qemu-devel] Some line of codes in a file that I cant understand

2014-02-25 Thread Atlas Khan
I am watching i8259.c in \hw folder in QEMU. here is something like this


static const VMStateDescription vmstate_pic = {
.name = "i8259",
.version_id = 1,
.minimum_version_id = 1,
.minimum_version_id_old = 1,
.fields = (VMStateField[]) {
VMSTATE_UINT8(last_irr, PicState),
VMSTATE_UINT8(irr, PicState),
VMSTATE_UINT8(imr, PicState),
VMSTATE_UINT8(isr, PicState),
VMSTATE_UINT8(priority_add, PicState),
VMSTATE_UINT8(irq_base, PicSthisate),
VMSTATE_UINT8(read_reg_select, PicState),
VMSTATE_UINT8(poll, PicState),
VMSTATE_UINT8(special_mask, PicState),
VMSTATE_UINT8(init_state, PicState),
VMSTATE_UINT8(auto_eoi, PicState),
VMSTATE_UINT8(rotate_on_auto_eoi, PicState),
VMSTATE_UINT8(special_fully_nested_mode, PicState),
VMSTATE_UINT8(init4, PicState),
VMSTATE_UINT8(single_mode, PicState),
VMSTATE_UINT8(elcr, PicState),
VMSTATE_END_OF_LIST()
}
};

here what does this dot shows and what is this VMSTATE_UINT8 function?


Re: [Qemu-devel] [PATCH 0/4] target-ppc: htab fixes (V2)

2014-02-25 Thread Alexander Graf
Greg Kurz wrote:
> On Mon, 17 Feb 2014 14:22:14 +0100
> Greg Kurz  wrote:
>   
>> Hi,
>>
>> This is a new tentative for the patches 2/5 to 5/5 from the "target-ppc:
>> Add support for dumping guest memory using qemu gdb server" patchset:
>>
>> https://lists.nongnu.org/archive/html/qemu-ppc/2014-01/msg00380.html
>>
>> All patches have been rebased on the current ppc-next head (72c798d7dccc).
>>
>> To ensure proper bisectability, the following was verified for each
>> individual patch:
>> •- 32 and 64 bit build of ppc-softmmu and ppc64-softmmu (fedora 19 ppc64)
>> •- 64 bit pseries guest with KVM on a POWER7 host (fedora 19 ppc64)
>> •- 64 bit pseries guest with 64 bit TCG on a x86_64 host (fedora 19 ppc64)
>> •- 64 bit pseries guest with 32 bit TCG on a x86_64 host (fedora 19 ppc64)
>> •- 32 bit mac99 guest with 64 bit TCG on a x86_64 host (wheezy ppc)
>> •- 32 bit mac99 guest with 32 bit TCG on a x86_64 host (wheezy ppc)
>>
>> Alex,
>>
>> This should address all the requirements you expressed in your last mail.
>> Please tell me if something is missing.
>> 
>
> Alex,
>
> I have added the 32 bit build with KVM enabled to catch the remaining build
> breaks:
>
> target-ppc/kvm.c: In function 'kvmppc_hash64_read_pteg':
> target-ppc/kvm.c:1977:12: error: cast from pointer to integer of different 
> size
>  [-Werror=pointer-to-int-cast]
> target-ppc/kvm.c: In function 'kvmppc_hash64_free_pteg':
> target-ppc/kvm.c:1990:82: error: cast to pointer from integer of different 
> size
>  [-Werror=int-to-pointer-cast]
>
> I have folded the fix into patch 2/4.
>
> I have also fixed the SoB mess, and rebased on the current ppc-next.
>
> Hope this time, it is okay ! :)
>   

Thanks, applied to ppc-next.


Alex




[Qemu-devel] [PULL 00/11] Net patches

2014-02-25 Thread Stefan Hajnoczi
The following changes since commit c58e291591dbc1c846fa152d4792554803405ebb:

  Merge remote-tracking branch 'remotes/sstabellini/xen-140220' into staging 
(2014-02-24 16:12:55 +)

are available in the git repository at:


  git://github.com/stefanha/qemu.git tags/net-pull-request

for you to fetch changes up to ad37bb3b000963b36b5c30f5a4239cfbc4fe8725:

  virtio-net: use qemu_get_queue() where possible (2014-02-25 14:31:05 +0100)


Net patches


Max Filippov (1):
  opencores_eth: flush queue whenever can_receive can go from false to true

Stefan Hajnoczi (3):
  net: remove implicit peer from offload API
  vhost_net: use offload API instead of bypassing it
  virtio-net: use qemu_get_queue() where possible

Vincenzo Maffione (7):
  net: change vnet-hdr TAP prototypes
  net: extend NetClientInfo for offloading
  net: TAP uses NetClientInfo offloading callbacks
  net: virtio-net and vmxnet3 use offloading API
  net: make tap offloading callbacks static
  net: add offloading support to netmap backend
  net: Disable netmap backend when not supported

 configure  |  10 +++-
 hw/net/opencores_eth.c |  33 -
 hw/net/vhost_net.c |   6 +--
 hw/net/virtio-net.c|  16 +++
 hw/net/vmxnet3.c   |  22 -
 include/net/net.h  |  19 
 include/net/tap.h  |   6 ---
 net/net.c  |  55 ++
 net/netmap.c   | 123 -
 net/tap-win32.c|  92 +++-
 net/tap.c  |  20 +---
 11 files changed, 275 insertions(+), 127 deletions(-)

-- 
1.8.5.3




[Qemu-devel] [PULL 01/11] opencores_eth: flush queue whenever can_receive can go from false to true

2014-02-25 Thread Stefan Hajnoczi
From: Max Filippov 

The following registers control whether MAC can receive frames:
- MODER.RXEN bit that enables/disables receiver;
- TX_BD_NUM register that specifies number of RX descriptors.
Notify QEMU networking core when the MAC is ready to receive frames.
Discard frame and raise BUSY interrupt when the frame arrives but the
current RX descriptor is not empty.

Signed-off-by: Max Filippov 
Reviewed-by: Paolo Bonzini 
Signed-off-by: Stefan Hajnoczi 
---
 hw/net/opencores_eth.c | 33 +++--
 1 file changed, 31 insertions(+), 2 deletions(-)

diff --git a/hw/net/opencores_eth.c b/hw/net/opencores_eth.c
index 4118d54..4a44304 100644
--- a/hw/net/opencores_eth.c
+++ b/hw/net/opencores_eth.c
@@ -169,6 +169,7 @@ enum {
 };
 
 enum {
+INT_SOURCE_BUSY = 0x10,
 INT_SOURCE_RXB = 0x4,
 INT_SOURCE_TXB = 0x1,
 };
@@ -351,8 +352,7 @@ static int open_eth_can_receive(NetClientState *nc)
 OpenEthState *s = qemu_get_nic_opaque(nc);
 
 return GET_REGBIT(s, MODER, RXEN) &&
-(s->regs[TX_BD_NUM] < 0x80) &&
-(rx_desc(s)->len_flags & RXD_E);
+(s->regs[TX_BD_NUM] < 0x80);
 }
 
 static ssize_t open_eth_receive(NetClientState *nc,
@@ -402,6 +402,12 @@ static ssize_t open_eth_receive(NetClientState *nc,
 desc *desc = rx_desc(s);
 size_t copy_size = GET_REGBIT(s, MODER, HUGEN) ? 65536 : maxfl;
 
+if (!(desc->len_flags & RXD_E)) {
+open_eth_int_source_write(s,
+s->regs[INT_SOURCE] | INT_SOURCE_BUSY);
+return size;
+}
+
 desc->len_flags &= ~(RXD_CF | RXD_M | RXD_OR |
 RXD_IS | RXD_DN | RXD_TL | RXD_SF | RXD_CRC | RXD_LC);
 
@@ -551,6 +557,15 @@ static uint64_t open_eth_reg_read(void *opaque,
 return v;
 }
 
+static void open_eth_notify_can_receive(OpenEthState *s)
+{
+NetClientState *nc = qemu_get_queue(s->nic);
+
+if (open_eth_can_receive(nc)) {
+qemu_flush_queued_packets(nc);
+}
+}
+
 static void open_eth_ro(OpenEthState *s, uint32_t val)
 {
 }
@@ -567,6 +582,7 @@ static void open_eth_moder_host_write(OpenEthState *s, 
uint32_t val)
 
 if (set & MODER_RXEN) {
 s->rx_desc = s->regs[TX_BD_NUM];
+open_eth_notify_can_receive(s);
 }
 if (set & MODER_TXEN) {
 s->tx_desc = 0;
@@ -592,6 +608,18 @@ static void open_eth_int_mask_host_write(OpenEthState *s, 
uint32_t val)
 s->regs[INT_SOURCE] & s->regs[INT_MASK]);
 }
 
+static void open_eth_tx_bd_num_host_write(OpenEthState *s, uint32_t val)
+{
+if (val < 0x80) {
+bool enable = s->regs[TX_BD_NUM] == 0x80;
+
+s->regs[TX_BD_NUM] = val;
+if (enable) {
+open_eth_notify_can_receive(s);
+}
+}
+}
+
 static void open_eth_mii_command_host_write(OpenEthState *s, uint32_t val)
 {
 unsigned fiad = GET_REGFIELD(s, MIIADDRESS, FIAD);
@@ -630,6 +658,7 @@ static void open_eth_reg_write(void *opaque,
 [MODER] = open_eth_moder_host_write,
 [INT_SOURCE] = open_eth_int_source_host_write,
 [INT_MASK] = open_eth_int_mask_host_write,
+[TX_BD_NUM] = open_eth_tx_bd_num_host_write,
 [MIICOMMAND] = open_eth_mii_command_host_write,
 [MIITX_DATA] = open_eth_mii_tx_host_write,
 [MIISTATUS] = open_eth_ro,
-- 
1.8.5.3




Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation

2014-02-25 Thread Michael Matz
Hi,

On Tue, 25 Feb 2014, Andreas Färber wrote:

> >> There are some pretty large differences between these trees with 
> >> respect to signal syscalls - is that the likely culprit?
> > 
> > Quite likely. We explicitly concentrated on the arch64 specific 
> > instruction emulation leaving more generic patches to flow in from 
> > SUSE as they matured.
> > 
> > I guess it's time to go through the remaining patches and see what's 
> > up-streamable.
> > 
> > Alex/Michael,
> > 
> > Are any of these patches in flight now?
> 
> I don't think so, Alex seems to hate cleaning that stuff up... :P
> 
> Compare https://github.com/openSUSE/qemu/commits/opensuse-1.7 for our
> general queue. We have patches adding locking to TCG, and there's a hack
> pinning the CPU somewhere.

The locking and pinning is all wrong (resp. overbroad).  The aarch64-1.6 
branch contains better implementations for that and some actual fixes for 
aarch64' userspace.

Somehow I don't find the time to go through our patches in linux-user and 
submit them.  The biggest road-block is that signal vs syscall handling is 
fundamentally broken in linux-user and it's unfixable without 
assembler implementations of the syscall caller.  That is also still 
broken on the suse branch where I tried various ways to fix that until 
coming to that conclusion.


Ciao,
Michael.

[Qemu-devel] [PULL 04/11] net: TAP uses NetClientInfo offloading callbacks

2014-02-25 Thread Stefan Hajnoczi
From: Vincenzo Maffione 

The TAP NetClientInfo structure is inizialized with the TAP-specific
functions that manipulates offloading features.

Signed-off-by: Vincenzo Maffione 
Signed-off-by: Stefan Hajnoczi 
---
 net/tap-win32.c | 92 ++---
 net/tap.c   |  6 
 2 files changed, 55 insertions(+), 43 deletions(-)

diff --git a/net/tap-win32.c b/net/tap-win32.c
index edf26c4..924ca55 100644
--- a/net/tap-win32.c
+++ b/net/tap-win32.c
@@ -669,11 +669,60 @@ static void tap_win32_send(void *opaque)
 }
 }
 
+bool tap_has_ufo(NetClientState *nc)
+{
+return false;
+}
+
+bool tap_has_vnet_hdr(NetClientState *nc)
+{
+return false;
+}
+
+int tap_probe_vnet_hdr_len(int fd, int len)
+{
+return 0;
+}
+
+void tap_fd_set_vnet_hdr_len(int fd, int len)
+{
+}
+
+void tap_using_vnet_hdr(NetClientState *nc, bool using_vnet_hdr)
+{
+}
+
+void tap_set_offload(NetClientState *nc, int csum, int tso4,
+ int tso6, int ecn, int ufo)
+{
+}
+
+struct vhost_net *tap_get_vhost_net(NetClientState *nc)
+{
+return NULL;
+}
+
+bool tap_has_vnet_hdr_len(NetClientState *nc, int len)
+{
+return false;
+}
+
+void tap_set_vnet_hdr_len(NetClientState *nc, int len)
+{
+abort();
+}
+
 static NetClientInfo net_tap_win32_info = {
 .type = NET_CLIENT_OPTIONS_KIND_TAP,
 .size = sizeof(TAPState),
 .receive = tap_receive,
 .cleanup = tap_cleanup,
+.has_ufo = tap_has_ufo,
+.has_vnet_hdr = tap_has_vnet_hdr,
+.has_vnet_hdr_len = tap_has_vnet_hdr_len,
+.using_vnet_hdr = tap_using_vnet_hdr,
+.set_offload = tap_set_offload,
+.set_vnet_hdr_len = tap_set_vnet_hdr_len,
 };
 
 static int tap_win32_init(NetClientState *peer, const char *model,
@@ -722,49 +771,6 @@ int net_init_tap(const NetClientOptions *opts, const char 
*name,
 return 0;
 }
 
-bool tap_has_ufo(NetClientState *nc)
-{
-return false;
-}
-
-bool tap_has_vnet_hdr(NetClientState *nc)
-{
-return false;
-}
-
-int tap_probe_vnet_hdr_len(int fd, int len)
-{
-return 0;
-}
-
-void tap_fd_set_vnet_hdr_len(int fd, int len)
-{
-}
-
-void tap_using_vnet_hdr(NetClientState *nc, bool using_vnet_hdr)
-{
-}
-
-void tap_set_offload(NetClientState *nc, int csum, int tso4,
- int tso6, int ecn, int ufo)
-{
-}
-
-struct vhost_net *tap_get_vhost_net(NetClientState *nc)
-{
-return NULL;
-}
-
-bool tap_has_vnet_hdr_len(NetClientState *nc, int len)
-{
-return false;
-}
-
-void tap_set_vnet_hdr_len(NetClientState *nc, int len)
-{
-abort();
-}
-
 int tap_enable(NetClientState *nc)
 {
 abort();
diff --git a/net/tap.c b/net/tap.c
index c805f3c..d34ec88 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -314,6 +314,12 @@ static NetClientInfo net_tap_info = {
 .receive_iov = tap_receive_iov,
 .poll = tap_poll,
 .cleanup = tap_cleanup,
+.has_ufo = tap_has_ufo,
+.has_vnet_hdr = tap_has_vnet_hdr,
+.has_vnet_hdr_len = tap_has_vnet_hdr_len,
+.using_vnet_hdr = tap_using_vnet_hdr,
+.set_offload = tap_set_offload,
+.set_vnet_hdr_len = tap_set_vnet_hdr_len,
 };
 
 static TAPState *net_tap_fd_init(NetClientState *peer,
-- 
1.8.5.3




[Qemu-devel] [PULL 07/11] net: add offloading support to netmap backend

2014-02-25 Thread Stefan Hajnoczi
From: Vincenzo Maffione 

Whit this patch, the netmap backend supports TSO/UFO/CSUM
offloadings, and accepts the virtio-net header, similarly to what
happens with TAP. The offloading callbacks in the NetClientInfo
interface have been implemented.

Signed-off-by: Vincenzo Maffione 
Signed-off-by: Stefan Hajnoczi 
---
 net/netmap.c | 68 +++-
 1 file changed, 67 insertions(+), 1 deletion(-)

diff --git a/net/netmap.c b/net/netmap.c
index 0ccc497..73f6d7a 100644
--- a/net/netmap.c
+++ b/net/netmap.c
@@ -31,6 +31,7 @@
 #include 
 
 #include "net/net.h"
+#include "net/tap.h"
 #include "clients.h"
 #include "sysemu/sysemu.h"
 #include "qemu/error-report.h"
@@ -54,6 +55,7 @@ typedef struct NetmapState {
 boolread_poll;
 boolwrite_poll;
 struct ioveciov[IOV_MAX];
+int vnet_hdr_len;  /* Current virtio-net header length. */
 } NetmapState;
 
 #define D(format, ...)  \
@@ -274,7 +276,7 @@ static ssize_t netmap_receive_iov(NetClientState *nc,
 return iov_size(iov, iovcnt);
 }
 
-i = ring->cur;
+last = i = ring->cur;
 avail = ring->avail;
 
 if (avail < iovcnt) {
@@ -394,6 +396,63 @@ static void netmap_cleanup(NetClientState *nc)
 s->me.fd = -1;
 }
 
+/* Offloading manipulation support callbacks. */
+static bool netmap_has_ufo(NetClientState *nc)
+{
+return true;
+}
+
+static bool netmap_has_vnet_hdr(NetClientState *nc)
+{
+return true;
+}
+
+static bool netmap_has_vnet_hdr_len(NetClientState *nc, int len)
+{
+return len == 0 || len == sizeof(struct virtio_net_hdr) ||
+len == sizeof(struct virtio_net_hdr_mrg_rxbuf);
+}
+
+static void netmap_using_vnet_hdr(NetClientState *nc, bool enable)
+{
+}
+
+static void netmap_set_vnet_hdr_len(NetClientState *nc, int len)
+{
+NetmapState *s = DO_UPCAST(NetmapState, nc, nc);
+int err;
+struct nmreq req;
+
+/* Issue a NETMAP_BDG_VNET_HDR command to change the virtio-net header
+ * length for the netmap adapter associated to 'me->ifname'.
+ */
+memset(&req, 0, sizeof(req));
+pstrcpy(req.nr_name, sizeof(req.nr_name), s->me.ifname);
+req.nr_version = NETMAP_API;
+req.nr_cmd = NETMAP_BDG_VNET_HDR;
+req.nr_arg1 = len;
+err = ioctl(s->me.fd, NIOCREGIF, &req);
+if (err) {
+error_report("Unable to execute NETMAP_BDG_VNET_HDR on %s: %s",
+ s->me.ifname, strerror(errno));
+} else {
+/* Keep track of the current length. */
+s->vnet_hdr_len = len;
+}
+}
+
+static void netmap_set_offload(NetClientState *nc, int csum, int tso4, int 
tso6,
+   int ecn, int ufo)
+{
+NetmapState *s = DO_UPCAST(NetmapState, nc, nc);
+
+/* Setting a virtio-net header length greater than zero automatically
+ * enables the offloadings.
+ */
+if (!s->vnet_hdr_len) {
+netmap_set_vnet_hdr_len(nc, sizeof(struct virtio_net_hdr));
+}
+}
 
 /* NetClientInfo methods */
 static NetClientInfo net_netmap_info = {
@@ -403,6 +462,12 @@ static NetClientInfo net_netmap_info = {
 .receive_iov = netmap_receive_iov,
 .poll = netmap_poll,
 .cleanup = netmap_cleanup,
+.has_ufo = netmap_has_ufo,
+.has_vnet_hdr = netmap_has_vnet_hdr,
+.has_vnet_hdr_len = netmap_has_vnet_hdr_len,
+.using_vnet_hdr = netmap_using_vnet_hdr,
+.set_offload = netmap_set_offload,
+.set_vnet_hdr_len = netmap_set_vnet_hdr_len,
 };
 
 /* The exported init function
@@ -428,6 +493,7 @@ int net_init_netmap(const NetClientOptions *opts,
 nc = qemu_new_net_client(&net_netmap_info, peer, "netmap", name);
 s = DO_UPCAST(NetmapState, nc, nc);
 s->me = me;
+s->vnet_hdr_len = 0;
 netmap_read_poll(s, true); /* Initially only poll for reads. */
 
 return 0;
-- 
1.8.5.3




[Qemu-devel] [PULL 06/11] net: make tap offloading callbacks static

2014-02-25 Thread Stefan Hajnoczi
From: Vincenzo Maffione 

Since TAP offloadings are manipulated through a new API, it's
not necessary to export them in include/net/tap.h anymore.

Signed-off-by: Vincenzo Maffione 
Signed-off-by: Stefan Hajnoczi 
---
 include/net/tap.h |  6 --
 net/tap-win32.c   | 12 ++--
 net/tap.c | 12 ++--
 3 files changed, 12 insertions(+), 18 deletions(-)

diff --git a/include/net/tap.h b/include/net/tap.h
index a3490a9..6daeb42 100644
--- a/include/net/tap.h
+++ b/include/net/tap.h
@@ -29,12 +29,6 @@
 #include "qemu-common.h"
 #include "qapi-types.h"
 
-bool tap_has_ufo(NetClientState *nc);
-bool tap_has_vnet_hdr(NetClientState *nc);
-bool tap_has_vnet_hdr_len(NetClientState *nc, int len);
-void tap_using_vnet_hdr(NetClientState *nc, bool using_vnet_hdr);
-void tap_set_offload(NetClientState *nc, int csum, int tso4, int tso6, int 
ecn, int ufo);
-void tap_set_vnet_hdr_len(NetClientState *nc, int len);
 int tap_enable(NetClientState *nc);
 int tap_disable(NetClientState *nc);
 
diff --git a/net/tap-win32.c b/net/tap-win32.c
index 924ca55..8aee611 100644
--- a/net/tap-win32.c
+++ b/net/tap-win32.c
@@ -669,12 +669,12 @@ static void tap_win32_send(void *opaque)
 }
 }
 
-bool tap_has_ufo(NetClientState *nc)
+static bool tap_has_ufo(NetClientState *nc)
 {
 return false;
 }
 
-bool tap_has_vnet_hdr(NetClientState *nc)
+static bool tap_has_vnet_hdr(NetClientState *nc)
 {
 return false;
 }
@@ -688,11 +688,11 @@ void tap_fd_set_vnet_hdr_len(int fd, int len)
 {
 }
 
-void tap_using_vnet_hdr(NetClientState *nc, bool using_vnet_hdr)
+static void tap_using_vnet_hdr(NetClientState *nc, bool using_vnet_hdr)
 {
 }
 
-void tap_set_offload(NetClientState *nc, int csum, int tso4,
+static void tap_set_offload(NetClientState *nc, int csum, int tso4,
  int tso6, int ecn, int ufo)
 {
 }
@@ -702,12 +702,12 @@ struct vhost_net *tap_get_vhost_net(NetClientState *nc)
 return NULL;
 }
 
-bool tap_has_vnet_hdr_len(NetClientState *nc, int len)
+static bool tap_has_vnet_hdr_len(NetClientState *nc, int len)
 {
 return false;
 }
 
-void tap_set_vnet_hdr_len(NetClientState *nc, int len)
+static void tap_set_vnet_hdr_len(NetClientState *nc, int len)
 {
 abort();
 }
diff --git a/net/tap.c b/net/tap.c
index d34ec88..2d5099b 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -210,7 +210,7 @@ static void tap_send(void *opaque)
 } while (size > 0 && qemu_can_send_packet(&s->nc));
 }
 
-bool tap_has_ufo(NetClientState *nc)
+static bool tap_has_ufo(NetClientState *nc)
 {
 TAPState *s = DO_UPCAST(TAPState, nc, nc);
 
@@ -219,7 +219,7 @@ bool tap_has_ufo(NetClientState *nc)
 return s->has_ufo;
 }
 
-bool tap_has_vnet_hdr(NetClientState *nc)
+static bool tap_has_vnet_hdr(NetClientState *nc)
 {
 TAPState *s = DO_UPCAST(TAPState, nc, nc);
 
@@ -228,7 +228,7 @@ bool tap_has_vnet_hdr(NetClientState *nc)
 return !!s->host_vnet_hdr_len;
 }
 
-bool tap_has_vnet_hdr_len(NetClientState *nc, int len)
+static bool tap_has_vnet_hdr_len(NetClientState *nc, int len)
 {
 TAPState *s = DO_UPCAST(TAPState, nc, nc);
 
@@ -237,7 +237,7 @@ bool tap_has_vnet_hdr_len(NetClientState *nc, int len)
 return !!tap_probe_vnet_hdr_len(s->fd, len);
 }
 
-void tap_set_vnet_hdr_len(NetClientState *nc, int len)
+static void tap_set_vnet_hdr_len(NetClientState *nc, int len)
 {
 TAPState *s = DO_UPCAST(TAPState, nc, nc);
 
@@ -249,7 +249,7 @@ void tap_set_vnet_hdr_len(NetClientState *nc, int len)
 s->host_vnet_hdr_len = len;
 }
 
-void tap_using_vnet_hdr(NetClientState *nc, bool using_vnet_hdr)
+static void tap_using_vnet_hdr(NetClientState *nc, bool using_vnet_hdr)
 {
 TAPState *s = DO_UPCAST(TAPState, nc, nc);
 
@@ -259,7 +259,7 @@ void tap_using_vnet_hdr(NetClientState *nc, bool 
using_vnet_hdr)
 s->using_vnet_hdr = using_vnet_hdr;
 }
 
-void tap_set_offload(NetClientState *nc, int csum, int tso4,
+static void tap_set_offload(NetClientState *nc, int csum, int tso4,
  int tso6, int ecn, int ufo)
 {
 TAPState *s = DO_UPCAST(TAPState, nc, nc);
-- 
1.8.5.3




[Qemu-devel] [PULL 11/11] virtio-net: use qemu_get_queue() where possible

2014-02-25 Thread Stefan Hajnoczi
qemu_get_queue() is a shorthand for qemu_get_subqueue(n->nic, 0).  Use
the shorthand where possible.

Signed-off-by: Stefan Hajnoczi 
---
 hw/net/virtio-net.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 9218a09..3c0342e 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -459,7 +459,7 @@ static uint32_t virtio_net_bad_features(VirtIODevice *vdev)
 
 static void virtio_net_apply_guest_offloads(VirtIONet *n)
 {
-qemu_set_offload(qemu_get_subqueue(n->nic, 0)->peer,
+qemu_set_offload(qemu_get_queue(n->nic)->peer,
 !!(n->curr_guest_offloads & (1ULL << VIRTIO_NET_F_GUEST_CSUM)),
 !!(n->curr_guest_offloads & (1ULL << VIRTIO_NET_F_GUEST_TSO4)),
 !!(n->curr_guest_offloads & (1ULL << VIRTIO_NET_F_GUEST_TSO6)),
-- 
1.8.5.3




[Qemu-devel] [PULL 09/11] net: remove implicit peer from offload API

2014-02-25 Thread Stefan Hajnoczi
The virtio_net offload APIs are used on the NIC's peer (i.e. the tap
device).  The API was defined to implicitly use nc->peer, saving the
caller the trouble.

This wasn't ideal because:
1. There are callers who have the peer but not the NIC.  Currently they
   are forced to bypass the API and access peer->info->... directly.
2. The rest of the net.h API uses nc, not nc->peer, so it is
   inconsistent.

This patch pushes nc->peer back up to callers.

Signed-off-by: Stefan Hajnoczi 
---
 hw/net/virtio-net.c | 12 ++--
 hw/net/vmxnet3.c| 18 +-
 include/net/net.h   | 14 +++---
 net/net.c   | 36 ++--
 4 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index cda8c75..9218a09 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -325,7 +325,7 @@ static void peer_test_vnet_hdr(VirtIONet *n)
 return;
 }
 
-n->has_vnet_hdr = qemu_peer_has_vnet_hdr(nc);
+n->has_vnet_hdr = qemu_has_vnet_hdr(nc->peer);
 }
 
 static int peer_has_vnet_hdr(VirtIONet *n)
@@ -338,7 +338,7 @@ static int peer_has_ufo(VirtIONet *n)
 if (!peer_has_vnet_hdr(n))
 return 0;
 
-n->has_ufo = qemu_peer_has_ufo(qemu_get_queue(n->nic));
+n->has_ufo = qemu_has_ufo(qemu_get_queue(n->nic)->peer);
 
 return n->has_ufo;
 }
@@ -357,8 +357,8 @@ static void virtio_net_set_mrg_rx_bufs(VirtIONet *n, int 
mergeable_rx_bufs)
 nc = qemu_get_subqueue(n->nic, i);
 
 if (peer_has_vnet_hdr(n) &&
-qemu_peer_has_vnet_hdr_len(nc, n->guest_hdr_len)) {
-qemu_peer_set_vnet_hdr_len(nc, n->guest_hdr_len);
+qemu_has_vnet_hdr_len(nc->peer, n->guest_hdr_len)) {
+qemu_set_vnet_hdr_len(nc->peer, n->guest_hdr_len);
 n->host_hdr_len = n->guest_hdr_len;
 }
 }
@@ -459,7 +459,7 @@ static uint32_t virtio_net_bad_features(VirtIODevice *vdev)
 
 static void virtio_net_apply_guest_offloads(VirtIONet *n)
 {
-qemu_peer_set_offload(qemu_get_subqueue(n->nic, 0),
+qemu_set_offload(qemu_get_subqueue(n->nic, 0)->peer,
 !!(n->curr_guest_offloads & (1ULL << VIRTIO_NET_F_GUEST_CSUM)),
 !!(n->curr_guest_offloads & (1ULL << VIRTIO_NET_F_GUEST_TSO4)),
 !!(n->curr_guest_offloads & (1ULL << VIRTIO_NET_F_GUEST_TSO6)),
@@ -1540,7 +1540,7 @@ static void virtio_net_device_realize(DeviceState *dev, 
Error **errp)
 peer_test_vnet_hdr(n);
 if (peer_has_vnet_hdr(n)) {
 for (i = 0; i < n->max_queues; i++) {
-qemu_peer_using_vnet_hdr(qemu_get_subqueue(n->nic, i), true);
+qemu_using_vnet_hdr(qemu_get_subqueue(n->nic, i)->peer, true);
 }
 n->host_hdr_len = sizeof(struct virtio_net_hdr);
 } else {
diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c
index 0524684..5be807c 100644
--- a/hw/net/vmxnet3.c
+++ b/hw/net/vmxnet3.c
@@ -1290,12 +1290,12 @@ static void vmxnet3_update_features(VMXNET3State *s)
   s->lro_supported, rxcso_supported,
   s->rx_vlan_stripping);
 if (s->peer_has_vhdr) {
-qemu_peer_set_offload(qemu_get_queue(s->nic),
-rxcso_supported,
-s->lro_supported,
-s->lro_supported,
-0,
-0);
+qemu_set_offload(qemu_get_queue(s->nic)->peer,
+ rxcso_supported,
+ s->lro_supported,
+ s->lro_supported,
+ 0,
+ 0);
 }
 }
 
@@ -1885,7 +1885,7 @@ static bool vmxnet3_peer_has_vnet_hdr(VMXNET3State *s)
 {
 NetClientState *nc = qemu_get_queue(s->nic);
 
-if (qemu_peer_has_vnet_hdr(nc)) {
+if (qemu_has_vnet_hdr(nc->peer)) {
 return true;
 }
 
@@ -1933,10 +1933,10 @@ static void vmxnet3_net_init(VMXNET3State *s)
 s->lro_supported = false;
 
 if (s->peer_has_vhdr) {
-qemu_peer_set_vnet_hdr_len(qemu_get_queue(s->nic),
+qemu_set_vnet_hdr_len(qemu_get_queue(s->nic)->peer,
 sizeof(struct virtio_net_hdr));
 
-qemu_peer_using_vnet_hdr(qemu_get_queue(s->nic), 1);
+qemu_using_vnet_hdr(qemu_get_queue(s->nic)->peer, 1);
 }
 
 qemu_format_nic_info_str(qemu_get_queue(s->nic), s->conf.macaddr.a);
diff --git a/include/net/net.h b/include/net/net.h
index 7b25394..8166345 100644
--- a/include/net/net.h
+++ b/include/net/net.h
@@ -132,13 +132,13 @@ ssize_t qemu_send_packet_async(NetClientState *nc, const 
uint8_t *buf,
 void qemu_purge_queued_packets(NetClientState *nc);
 void qemu_flush_queued_packets(NetClientState *nc);
 void qemu_format_nic_info_str(NetClientState *nc, uint8_t macaddr[6]);
-bool qemu_peer_has_ufo(NetClientState *nc);
-bool qemu_peer_has_vnet_hdr(NetClientState *nc);
-bool qemu_peer_has_vnet_hdr_len(NetClientState *nc, int len);
-void qemu_peer_using_vnet_hdr(NetClientState *nc, bool enable);
-voi

[Qemu-devel] [PATCH 1/7] timer: move QEMUTimerList functions together

2014-02-25 Thread Xuebing Wang
This patch does below:
-   Move function timerlist_has_timers() to be first QEMUTimerList function
because there is a chance that we will make it private
-   Move QEMUTimerList related functions together
-   Remove below comments for function timerlist_deadline_ns(), because:
--  There is already information in the header file include/qemu/timer.h
--  "As above" part of the information is wrong
/*
 * As above, but return -1 for no deadline, and do not cap to 2^32
 * as we know the result is always positive.
 */

Signed-off-by: Xuebing Wang 
---
 include/qemu/timer.h |   28 +++---
 qemu-timer.c |  231 +-
 2 files changed, 129 insertions(+), 130 deletions(-)

diff --git a/include/qemu/timer.h b/include/qemu/timer.h
index 7f9a074..55cd3a7 100644
--- a/include/qemu/timer.h
+++ b/include/qemu/timer.h
@@ -254,6 +254,20 @@ bool qemu_clock_run_all_timers(void);
  */
 
 /**
+ * timerlist_has_timers:
+ * @timer_list: the timer list to operate on
+ *
+ * Determine whether a timer list has active timers
+ *
+ * Note that this function should not be used when other threads also access
+ * the timer list.  The return value may be outdated by the time it is acted
+ * upon.
+ *
+ * Returns: true if the timer list has timers.
+ */
+bool timerlist_has_timers(QEMUTimerList *timer_list);
+
+/**
  * timerlist_new:
  * @type: the clock type to associate with the timerlist
  * @cb: the callback to call on notification
@@ -276,20 +290,6 @@ QEMUTimerList *timerlist_new(QEMUClockType type,
 void timerlist_free(QEMUTimerList *timer_list);
 
 /**
- * timerlist_has_timers:
- * @timer_list: the timer list to operate on
- *
- * Determine whether a timer list has active timers
- *
- * Note that this function should not be used when other threads also access
- * the timer list.  The return value may be outdated by the time it is acted
- * upon.
- *
- * Returns: true if the timer list has timers.
- */
-bool timerlist_has_timers(QEMUTimerList *timer_list);
-
-/**
  * timerlist_expired:
  * @timer_list: the timer list to operate on
  *
diff --git a/qemu-timer.c b/qemu-timer.c
index e15ce47..4929f8b 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -95,6 +95,15 @@ static bool timer_expired_ns(QEMUTimer *timer_head, int64_t 
current_time)
 return timer_head && (timer_head->expire_time <= current_time);
 }
 
+/*
+ * QEMUTimerList
+ */
+
+bool timerlist_has_timers(QEMUTimerList *timer_list)
+{
+return !!timer_list->active_timers;
+}
+
 QEMUTimerList *timerlist_new(QEMUClockType type,
  QEMUTimerListNotifyCB *cb,
  void *opaque)
@@ -122,6 +131,112 @@ void timerlist_free(QEMUTimerList *timer_list)
 g_free(timer_list);
 }
 
+bool timerlist_expired(QEMUTimerList *timer_list)
+{
+int64_t expire_time;
+
+qemu_mutex_lock(&timer_list->active_timers_lock);
+if (!timer_list->active_timers) {
+qemu_mutex_unlock(&timer_list->active_timers_lock);
+return false;
+}
+expire_time = timer_list->active_timers->expire_time;
+qemu_mutex_unlock(&timer_list->active_timers_lock);
+
+return expire_time < qemu_clock_get_ns(timer_list->clock->type);
+}
+
+int64_t timerlist_deadline_ns(QEMUTimerList *timer_list)
+{
+int64_t delta;
+int64_t expire_time;
+
+if (!timer_list->clock->enabled) {
+return -1;
+}
+
+/* The active timers list may be modified before the caller uses our return
+ * value but ->notify_cb() is called when the deadline changes.  Therefore
+ * the caller should notice the change and there is no race condition.
+ */
+qemu_mutex_lock(&timer_list->active_timers_lock);
+if (!timer_list->active_timers) {
+qemu_mutex_unlock(&timer_list->active_timers_lock);
+return -1;
+}
+expire_time = timer_list->active_timers->expire_time;
+qemu_mutex_unlock(&timer_list->active_timers_lock);
+
+delta = expire_time - qemu_clock_get_ns(timer_list->clock->type);
+
+if (delta <= 0) {
+return 0;
+}
+
+return delta;
+}
+
+QEMUClockType timerlist_get_clock(QEMUTimerList *timer_list)
+{
+return timer_list->clock->type;
+}
+
+bool timerlist_run_timers(QEMUTimerList *timer_list)
+{
+QEMUTimer *ts;
+int64_t current_time;
+bool progress = false;
+QEMUTimerCB *cb;
+void *opaque;
+
+qemu_event_reset(&timer_list->timers_done_ev);
+if (!timer_list->clock->enabled) {
+goto out;
+}
+
+current_time = qemu_clock_get_ns(timer_list->clock->type);
+for(;;) {
+qemu_mutex_lock(&timer_list->active_timers_lock);
+ts = timer_list->active_timers;
+if (!timer_expired_ns(ts, current_time)) {
+qemu_mutex_unlock(&timer_list->active_timers_lock);
+break;
+}
+
+/* remove timer from the list before calling the callback */
+timer_list->active_timers = ts->next;
+ts->next = NULL;
+ts->expire_time = -1;

Re: [Qemu-devel] [PATCH 1/2][RFC] qom: introduce cpu QOM hierarchy tree /machine/node/socket/core/thread/cpu.

2014-02-25 Thread Eric Blake
On 02/25/2014 02:07 AM, Chen Fan wrote:
> Signed-off-by: Chen Fan 
> ---
>  include/qom/node.h |  66 +++
>  qom/Makefile.objs  |   2 +-
>  qom/node.c | 156 
> +
>  3 files changed, 223 insertions(+), 1 deletion(-)
>  create mode 100644 include/qom/node.h
>  create mode 100644 qom/node.c
> 
> diff --git a/include/qom/node.h b/include/qom/node.h
> new file mode 100644
> index 000..6c948ec
> --- /dev/null
> +++ b/include/qom/node.h
> @@ -0,0 +1,66 @@
> +/*
> + * QEMU System Emulator
> + *
> + * Copyright (c) 2013 Fujitsu Ltd.

It's 2014 now.

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



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] QOM vs QAPI for QMP APIs

2014-02-25 Thread Kevin Wolf
Am 25.02.2014 um 11:47 hat Paolo Bonzini geschrieben:
> Il 25/02/2014 11:15, Stefan Hajnoczi ha scritto:
> >On Tue, Feb 25, 2014 at 10:46 AM, Kevin Wolf  wrote:
> >>> External QOM interfaces have their place, especially for debugging or
> >>> trying out things before there is a proper API, but it's not as the
> >>> primary external interface.
> >Yes, I agree.
> 
> -object is an exception to this though, isn't it?

I'd prefer if -object weren't the primary interface for anything.
We could define a few stable types that are meant to be created,
queried and manipulated using QOM, but it would blur the line.

Kevin



[Qemu-devel] [PATCH 0/7] timer: move APIs together according to their category

2014-02-25 Thread Xuebing Wang
There are 6 categories of APIs:
- QEMUClockType
- QEMUTimerList
- QEMUTimerListGroup
- QEMUTimer
- General utility functions
- Low level clock functions

Problems / solutions with previous API implementations:
1) Can not think of cases that we need QEMUTimerList APIs.
   Reference:  kernel_tree/Documentation/SubmittingPatches
   -- Section "4) Don't over-design"
   Purpose:simplify API
   Solution:   remove them from APIs
2) Implementations of some APIs are interwined
   Purpose:put them together according to their categories, thus new
   engineers are easy to understand them
   Solution:   put them together
3) Unnecessary header files are included
   Purpose:simplify the included header files
   Solution:   only include the minimally required header file

This patchset includes below changes:
- put QEMUTimerList related functions together and make them private
- put QEMUClockType related functions together
- move QEMUTimerListGroup function to be below QEMUClockType
- put QEMUTimer related functions together
- put general utility functions together
- clean unnecessary #include and use minimal required #include

Xuebing Wang (7):
  timer: move QEMUTimerList functions together
  timer: make QEMUTimerList functions private (remove from APIs)
  timer: move QEMUClockType related functions together
  timer: move QEMUTimerListGroup function to be below QEMUClockType
  timer: move QEMUTimer related functions together
  timer: move general utility functions together
  timer: clean unnecessary #include and use minimal required #include

 include/qemu/timer.h |   94 
 qemu-timer.c |  595 +-
 2 files changed, 341 insertions(+), 348 deletions(-)

-- 
1.7.9.5




[Qemu-devel] [PATCH 3/7] timer: move QEMUClockType related functions together

2014-02-25 Thread Xuebing Wang

Signed-off-by: Xuebing Wang 
---
 qemu-timer.c |  160 ++
 1 file changed, 82 insertions(+), 78 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index 2db87ba..471150c 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -314,6 +314,10 @@ static void timerlist_rearm(QEMUTimerList *timer_list)
 timerlist_notify(timer_list);
 }
 
+/*
+ * QEMUClockType
+ */
+
 static void qemu_clock_init(QEMUClockType type)
 {
 QEMUClock *clock = qemu_clock_ptr(type);
@@ -326,11 +330,71 @@ static void qemu_clock_init(QEMUClockType type)
 main_loop_tlg.tl[type] = timerlist_new(type, NULL, NULL);
 }
 
+int64_t qemu_clock_get_ns(QEMUClockType type)
+{
+int64_t now, last;
+QEMUClock *clock = qemu_clock_ptr(type);
+
+switch (type) {
+case QEMU_CLOCK_REALTIME:
+return get_clock();
+default:
+case QEMU_CLOCK_VIRTUAL:
+if (use_icount) {
+return cpu_get_icount();
+} else {
+return cpu_get_clock();
+}
+case QEMU_CLOCK_HOST:
+now = get_clock_realtime();
+last = clock->last;
+clock->last = now;
+if (now < last) {
+notifier_list_notify(&clock->reset_notifiers, &now);
+}
+return now;
+}
+}
+
+bool qemu_clock_has_timers(QEMUClockType type)
+{
+return timerlist_has_timers(
+main_loop_tlg.tl[type]);
+}
+
+bool qemu_clock_expired(QEMUClockType type)
+{
+return timerlist_expired(
+main_loop_tlg.tl[type]);
+}
+
 bool qemu_clock_use_for_deadline(QEMUClockType type)
 {
 return !(use_icount && (type == QEMU_CLOCK_VIRTUAL));
 }
 
+/* Calculate the soonest deadline across all timerlists attached
+ * to the clock. This is used for the icount timeout so we
+ * ignore whether or not the clock should be used in deadline
+ * calculations.
+ */
+int64_t qemu_clock_deadline_ns_all(QEMUClockType type)
+{
+int64_t deadline = -1;
+QEMUTimerList *timer_list;
+QEMUClock *clock = qemu_clock_ptr(type);
+QLIST_FOREACH(timer_list, &clock->timerlists, list) {
+deadline = qemu_soonest_timeout(deadline,
+timerlist_deadline_ns(timer_list));
+}
+return deadline;
+}
+
+QEMUTimerList *qemu_clock_get_main_loop_timerlist(QEMUClockType type)
+{
+return main_loop_tlg.tl[type];
+}
+
 void qemu_clock_notify(QEMUClockType type)
 {
 QEMUTimerList *timer_list;
@@ -362,38 +426,34 @@ void qemu_clock_enable(QEMUClockType type, bool enabled)
 }
 }
 
-bool qemu_clock_has_timers(QEMUClockType type)
+void qemu_clock_register_reset_notifier(QEMUClockType type,
+Notifier *notifier)
 {
-return timerlist_has_timers(
-main_loop_tlg.tl[type]);
+QEMUClock *clock = qemu_clock_ptr(type);
+notifier_list_add(&clock->reset_notifiers, notifier);
 }
 
-bool qemu_clock_expired(QEMUClockType type)
+void qemu_clock_unregister_reset_notifier(QEMUClockType type,
+  Notifier *notifier)
 {
-return timerlist_expired(
-main_loop_tlg.tl[type]);
+notifier_remove(notifier);
 }
 
-/* Calculate the soonest deadline across all timerlists attached
- * to the clock. This is used for the icount timeout so we
- * ignore whether or not the clock should be used in deadline
- * calculations.
- */
-int64_t qemu_clock_deadline_ns_all(QEMUClockType type)
+bool qemu_clock_run_timers(QEMUClockType type)
 {
-int64_t deadline = -1;
-QEMUTimerList *timer_list;
-QEMUClock *clock = qemu_clock_ptr(type);
-QLIST_FOREACH(timer_list, &clock->timerlists, list) {
-deadline = qemu_soonest_timeout(deadline,
-timerlist_deadline_ns(timer_list));
-}
-return deadline;
+return timerlist_run_timers(main_loop_tlg.tl[type]);
 }
 
-QEMUTimerList *qemu_clock_get_main_loop_timerlist(QEMUClockType type)
+bool qemu_clock_run_all_timers(void)
 {
-return main_loop_tlg.tl[type];
+bool progress = false;
+QEMUClockType type;
+
+for (type = 0; type < QEMU_CLOCK_MAX; type++) {
+progress |= qemu_clock_run_timers(type);
+}
+
+return progress;
 }
 
 /* Transition function to convert a nanosecond timeout to ms
@@ -570,11 +630,6 @@ bool timer_expired(QEMUTimer *timer_head, int64_t 
current_time)
 return timer_expired_ns(timer_head, current_time * timer_head->scale);
 }
 
-bool qemu_clock_run_timers(QEMUClockType type)
-{
-return timerlist_run_timers(main_loop_tlg.tl[type]);
-}
-
 void timerlistgroup_init(QEMUTimerListGroup *tlg,
  QEMUTimerListNotifyCB *cb, void *opaque)
 {
@@ -616,45 +671,6 @@ int64_t timerlistgroup_deadline_ns(QEMUTimerListGroup *tlg)
 return deadline;
 }
 
-int64_t qemu_clock_get_ns(QEMUClockType type)
-{
-int64_t now, last;
-QEMUClock *clock = qemu_clock_ptr(type);
-
-switch (type) {
-case QEMU_CLOCK_REALTIME:
-return get_clock();
-default:

Re: [Qemu-devel] [RFC PATCH] block: optimize zero writes with bdrv_write_zeroes

2014-02-25 Thread Kevin Wolf
Am 24.02.2014 um 14:01 hat Peter Lieven geschrieben:
> On 24.02.2014 11:38, Paolo Bonzini wrote:
> >Il 24/02/2014 11:26, Peter Lieven ha scritto:
> >>
> >>I personally do not need this for QCOW2 but for iSCSI. Here the optimization
> >>is basically saved bandwidth since a zero write becomes a WRITESAME.
> >
> >It saves bandwidth, but at the potential cost of extra host CPU
> >utilization.  I would be fine with having this automatically, but
> >drv->bdrv_co_write_zeroes is not the right check because it is
> >true for qcow2 and raw formats.  Something using bdrv_get_info is
> >probably better, because it would have fewer or no false
> >positives.
> >
> >>In all cases if unmap=on it would additionally save disk space.
> >
> >It would also cause worse performance though.  I think the automatic 
> >addition BDRV_REQ_MAY_UNMAP is what should be a separate option. Perhaps you 
> >can have a three-state option, detect-zeros=no/yes/unmap.
> 
> What would be the desired way to store this flag in the BlockDriverState?

Some new enum field?

Kevin



[Qemu-devel] [PATCH 5/7] timer: move QEMUTimer related functions together

2014-02-25 Thread Xuebing Wang

Signed-off-by: Xuebing Wang 
---
 qemu-timer.c |   13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index 6f13a76..c9801da 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -548,6 +548,9 @@ int qemu_poll_ns(GPollFD *fds, guint nfds, int64_t timeout)
 #endif
 }
 
+/*
+ * QEMUTimer
+ */
 
 void timer_init(QEMUTimer *ts,
 QEMUTimerList *timer_list, int scale,
@@ -675,6 +678,11 @@ bool timer_expired(QEMUTimer *timer_head, int64_t 
current_time)
 return timer_expired_ns(timer_head, current_time * timer_head->scale);
 }
 
+uint64_t timer_expire_time_ns(QEMUTimer *ts)
+{
+return timer_pending(ts) ? ts->expire_time : -1;
+}
+
 void init_clocks(void)
 {
 QEMUClockType type;
@@ -686,8 +694,3 @@ void init_clocks(void)
 prctl(PR_SET_TIMERSLACK, 1, 0, 0, 0);
 #endif
 }
-
-uint64_t timer_expire_time_ns(QEMUTimer *ts)
-{
-return timer_pending(ts) ? ts->expire_time : -1;
-}
-- 
1.7.9.5




[Qemu-devel] [PATCH 6/7] timer: move general utility functions together

2014-02-25 Thread Xuebing Wang

Signed-off-by: Xuebing Wang 
---
 qemu-timer.c |   97 ++
 1 file changed, 50 insertions(+), 47 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index c9801da..e592c14 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -501,53 +501,6 @@ int64_t timerlistgroup_deadline_ns(QEMUTimerListGroup *tlg)
 return deadline;
 }
 
-/* Transition function to convert a nanosecond timeout to ms
- * This is used where a system does not support ppoll
- */
-int qemu_timeout_ns_to_ms(int64_t ns)
-{
-int64_t ms;
-if (ns < 0) {
-return -1;
-}
-
-if (!ns) {
-return 0;
-}
-
-/* Always round up, because it's better to wait too long than to wait too
- * little and effectively busy-wait
- */
-ms = (ns + SCALE_MS - 1) / SCALE_MS;
-
-/* To avoid overflow problems, limit this to 2^31, i.e. approx 25 days */
-if (ms > (int64_t) INT32_MAX) {
-ms = INT32_MAX;
-}
-
-return (int) ms;
-}
-
-
-/* qemu implementation of g_poll which uses a nanosecond timeout but is
- * otherwise identical to g_poll
- */
-int qemu_poll_ns(GPollFD *fds, guint nfds, int64_t timeout)
-{
-#ifdef CONFIG_PPOLL
-if (timeout < 0) {
-return ppoll((struct pollfd *)fds, nfds, NULL, NULL);
-} else {
-struct timespec ts;
-ts.tv_sec = timeout / 10LL;
-ts.tv_nsec = timeout % 10LL;
-return ppoll((struct pollfd *)fds, nfds, &ts, NULL);
-}
-#else
-return g_poll(fds, nfds, qemu_timeout_ns_to_ms(timeout));
-#endif
-}
-
 /*
  * QEMUTimer
  */
@@ -683,6 +636,56 @@ uint64_t timer_expire_time_ns(QEMUTimer *ts)
 return timer_pending(ts) ? ts->expire_time : -1;
 }
 
+/*
+ * General utility functions
+ */
+
+/* Transition function to convert a nanosecond timeout to ms
+ * This is used where a system does not support ppoll
+ */
+int qemu_timeout_ns_to_ms(int64_t ns)
+{
+int64_t ms;
+if (ns < 0) {
+return -1;
+}
+
+if (!ns) {
+return 0;
+}
+
+/* Always round up, because it's better to wait too long than to wait too
+ * little and effectively busy-wait
+ */
+ms = (ns + SCALE_MS - 1) / SCALE_MS;
+
+/* To avoid overflow problems, limit this to 2^31, i.e. approx 25 days */
+if (ms > (int64_t) INT32_MAX) {
+ms = INT32_MAX;
+}
+
+return (int) ms;
+}
+
+/* qemu implementation of g_poll which uses a nanosecond timeout but is
+ * otherwise identical to g_poll
+ */
+int qemu_poll_ns(GPollFD *fds, guint nfds, int64_t timeout)
+{
+#ifdef CONFIG_PPOLL
+if (timeout < 0) {
+return ppoll((struct pollfd *)fds, nfds, NULL, NULL);
+} else {
+struct timespec ts;
+ts.tv_sec = timeout / 10LL;
+ts.tv_nsec = timeout % 10LL;
+return ppoll((struct pollfd *)fds, nfds, &ts, NULL);
+}
+#else
+return g_poll(fds, nfds, qemu_timeout_ns_to_ms(timeout));
+#endif
+}
+
 void init_clocks(void)
 {
 QEMUClockType type;
-- 
1.7.9.5




  1   2   3   >