[Qemu-devel] [Bug 1312561] Re: libstdc++-6.dll is missing from your computer

2014-05-05 Thread Rupert Russell
Ok, so we need to wait for a recompiled version I guess.
I did after your post get the dll from the mingw site, and that error went 
away, but then replaced by application failed with (0x07b) error.
How much of the mingw package would we need to install to fix the problem if a 
recompiled version is some time away please?

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

Title:
  libstdc++-6.dll is missing from your computer

Status in QEMU:
  New

Bug description:
  qemu-w64-setup-20140418.exe

  Windows 7 64 bit PC.

  qemu-system-armw -kernel kernel-qemu -cpu arm1176 -m 256 -M
  versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1
  rootfstype=ext4 rw" -hda c:\11\rasimg\test.vhd

  
  qemu-system-armw.exe - System Error
  The program can't start because libstdc++-6.dll is missing from your 
computer. 

  Try reinstalling the program to fix this problem.

  I tried reinstalling, but no change.

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



[Qemu-devel] [PATCH] qapi: Document optional arguments' backwards compatibility

2014-05-05 Thread Fam Zheng
Signed-off-by: Fam Zheng 
---
 docs/qapi-code-gen.txt | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/docs/qapi-code-gen.txt b/docs/qapi-code-gen.txt
index d78921f..d7b19ab 100644
--- a/docs/qapi-code-gen.txt
+++ b/docs/qapi-code-gen.txt
@@ -51,8 +51,10 @@ example of a complex type is:
 
 The use of '*' as a prefix to the name means the member is optional.  Optional
 members should always be added to the end of the dictionary to preserve
-backwards compatibility.
-
+backwards compatibility. Even there is no strict restriction for default values
+of those optional arguments between QEMU's versions, the backwards
+compatibility should be preserved by keeping the user visible behavior
+unchanged.
 
 A complex type definition can specify another complex type as its base.
 In this case, the fields of the base type are included as top-level fields
-- 
1.9.2




Re: [Qemu-devel] [PATCH 9/9] tcg-s390: Don't force -march=z990

2014-05-05 Thread Christian Borntraeger
On 03/05/14 16:08, Richard Henderson wrote:
> While we still require the LONG DISPLACEMENT facility, defaults
> have moved on since then.  Don't override the system compiler,
> whose default may be set to z9-109 or later.
> 
> Signed-off-by: Richard Henderson 
> ---
>  configure | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/configure b/configure
> index 2fbec59..a73fb9f 100755
> --- a/configure
> +++ b/configure
> @@ -1132,11 +1132,11 @@ case "$cpu" in
> CPU_CFLAGS="-m64 -mcpu=ultrasparc"
> ;;
>  s390)
> -   CPU_CFLAGS="-m31 -march=z990"
> +   CPU_CFLAGS="-m31"
> LDFLAGS="-m31 $LDFLAGS"
> ;;
>  s390x)
> -   CPU_CFLAGS="-m64 -march=z990"
> +   CPU_CFLAGS="-m64"
> LDFLAGS="-m64 $LDFLAGS"
> ;;
>  i386)
> 

Acked-by: Christian Borntraeger 
for this patch.





[Qemu-devel] [PATCH] docs/memory.txt: Fix document on MMIO operations

2014-05-05 Thread Fam Zheng
.impl.valid should be .impl.unaligned and the description needs some
fixes.

.old_portio is removed since commit b40acf99b (ioport: Switch
dispatching to memory core layer).

Signed-off-by: Fam Zheng 
---
 docs/memory.txt   | 10 +-
 include/exec/memory.h |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/docs/memory.txt b/docs/memory.txt
index 22eaec7..5bdbdb3 100644
--- a/docs/memory.txt
+++ b/docs/memory.txt
@@ -232,8 +232,8 @@ various constraints can be supplied to control how these 
callbacks are called:
(in bytes) supported by the *implementation*; other access sizes will be
emulated using the ones available.  For example a 4-byte write will be
emulated using four 1-byte writes, if .impl.max_access_size = 1.
- - .impl.valid specifies that the *implementation* only supports unaligned
-   accesses; unaligned accesses will be emulated by two aligned accesses.
- - .old_portio and .old_mmio can be used to ease porting from code using
-   cpu_register_io_memory() and register_ioport().  They should not be used
-   in new code.
+ - .impl.unaligned specifies that the *implementation* supports unaligned
+   accesses; if false, unaligned accesses will be emulated by two aligned
+   accesses.
+ - .old_mmio can be used to ease porting from code using
+   cpu_register_io_memory(). It should not be used in new code.
diff --git a/include/exec/memory.h b/include/exec/memory.h
index c084db2..1d55ad9 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -110,7 +110,7 @@ struct MemoryRegionOps {
 /* If true, unaligned accesses are supported.  Otherwise all accesses
  * are converted to (possibly multiple) naturally aligned accesses.
  */
- bool unaligned;
+bool unaligned;
 } impl;
 
 /* If .read and .write are not present, old_mmio may be used for
-- 
1.9.2




Re: [Qemu-devel] [PATCH] docs/memory.txt: Fix document on MMIO operations

2014-05-05 Thread Paolo Bonzini

Il 05/05/2014 09:53, Fam Zheng ha scritto:

.impl.valid should be .impl.unaligned and the description needs some
fixes.

.old_portio is removed since commit b40acf99b (ioport: Switch
dispatching to memory core layer).

Signed-off-by: Fam Zheng 
---
 docs/memory.txt   | 10 +-
 include/exec/memory.h |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/docs/memory.txt b/docs/memory.txt
index 22eaec7..5bdbdb3 100644
--- a/docs/memory.txt
+++ b/docs/memory.txt
@@ -232,8 +232,8 @@ various constraints can be supplied to control how these 
callbacks are called:
(in bytes) supported by the *implementation*; other access sizes will be
emulated using the ones available.  For example a 4-byte write will be
emulated using four 1-byte writes, if .impl.max_access_size = 1.
- - .impl.valid specifies that the *implementation* only supports unaligned
-   accesses; unaligned accesses will be emulated by two aligned accesses.
- - .old_portio and .old_mmio can be used to ease porting from code using
-   cpu_register_io_memory() and register_ioport().  They should not be used
-   in new code.
+ - .impl.unaligned specifies that the *implementation* supports unaligned
+   accesses; if false, unaligned accesses will be emulated by two aligned
+   accesses.
+ - .old_mmio can be used to ease porting from code using
+   cpu_register_io_memory(). It should not be used in new code.
diff --git a/include/exec/memory.h b/include/exec/memory.h
index c084db2..1d55ad9 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -110,7 +110,7 @@ struct MemoryRegionOps {
 /* If true, unaligned accesses are supported.  Otherwise all accesses
  * are converted to (possibly multiple) naturally aligned accesses.
  */
- bool unaligned;
+bool unaligned;
 } impl;

 /* If .read and .write are not present, old_mmio may be used for



Applied, thanks!

Paolo



Re: [Qemu-devel] [PATCH] i8259: don't abort when trying to use level sensitive irqs

2014-05-05 Thread Michael S. Tsirkin
On Sat, May 03, 2014 at 10:39:37PM +0200, Hervé Poussineau wrote:
> Ping.
> 
> Le 22/04/2014 23:00, Hervé Poussineau a écrit :
> >This is a guest-triggerable error, as seen when using Xenix 2.3.4.
> >Replace hw_error by LOG_UNIMPL, so that guests have at least a chance to 
> >continue.
> >
> >Signed-off-by: Hervé Poussineau 

Is it just "a chance" or does Xenix actually work well with this
applied?


> >---
> >  hw/intc/i8259.c |3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> >diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c
> >index c6f248b..a069d04 100644
> >--- a/hw/intc/i8259.c
> >+++ b/hw/intc/i8259.c
> >@@ -265,7 +265,8 @@ static void pic_ioport_write(void *opaque, hwaddr addr64,
> >  s->init4 = val & 1;
> >  s->single_mode = val & 2;
> >  if (val & 0x08) {
> >-hw_error("level sensitive irq not supported");
> >+qemu_log_mask(LOG_UNIMP,
> >+  "i8259: level sensitive irq not supported\n");
> >  }
> >  } else if (val & 0x08) {
> >  if (val & 0x04) {
> >



[Qemu-devel] [PATCH v3 0/4] little-endian dump for ppc64

2014-05-05 Thread Greg Kurz
Hi,

Please find the latest patch set for dump-guest-memory to support
little-endian ppc64 guest kernels. The only change since the last
post is a better naming of the dump endian helpers. Since it
affects patches 1 & 2, I resend the full serie, with Alex's
Reviewed-by tags from the last review.

Cheers.

---

Bharata B Rao (3):
  dump: Make DumpState and endian conversion routines available for 
arch-specific dump code
  ppc64-dump: Support dump for little endian ppc64
  ppc64 dump: Set the correct endianness in ELF dump header

Greg Kurz (1):
  target-ppc: ppc can be either endian


 dump.c  |  228 ---
 include/sysemu/dump-arch.h  |   28 +
 include/sysemu/dump.h   |   48 +++--
 stubs/dump.c|2 
 target-ppc/arch_dump.c  |   94 +++---
 target-ppc/cpu-qom.h|1 
 target-ppc/translate_init.c |   16 +++
 7 files changed, 228 insertions(+), 189 deletions(-)
 create mode 100644 include/sysemu/dump-arch.h

-- 
Greg




[Qemu-devel] [PATCH v3 1/4] dump: Make DumpState and endian conversion routines available for arch-specific dump code

2014-05-05 Thread Greg Kurz
From: Bharata B Rao 

Make DumpState and endian conversion routines available for arch-specific dump
code by moving into dump.h. DumpState will be needed by arch-specific dump
code to access target endian information from DumpState->ArchDumpInfo. Also
break the dependency of dump.h from stubs/dump.c by creating a separate
dump-arch.h.

This patch doesn't change any functionality.

Signed-off-by: Bharata B Rao 
[ rebased on top of current master branch,
  renamed endian helpers to cpu_to_dump{16,32,64},
  pass a DumpState * argument to endian helpers,
  Greg Kurz  ]
Signed-off-by: Greg Kurz 
---

Changes in v3:
- better taste with the endian helpers naming

 dump.c |  228 +---
 include/sysemu/dump-arch.h |   28 +
 include/sysemu/dump.h  |   48 +++--
 stubs/dump.c   |2 
 4 files changed, 154 insertions(+), 152 deletions(-)
 create mode 100644 include/sysemu/dump-arch.h

diff --git a/dump.c b/dump.c
index 14b3d1d..d24b865 100644
--- a/dump.c
+++ b/dump.c
@@ -36,9 +36,9 @@
 #define ELF_MACHINE_UNAME "Unknown"
 #endif
 
-static uint16_t cpu_convert_to_target16(uint16_t val, int endian)
+uint16_t cpu_to_dump16(DumpState *s, uint16_t val)
 {
-if (endian == ELFDATA2LSB) {
+if (s->dump_info.d_endian == ELFDATA2LSB) {
 val = cpu_to_le16(val);
 } else {
 val = cpu_to_be16(val);
@@ -47,9 +47,9 @@ static uint16_t cpu_convert_to_target16(uint16_t val, int 
endian)
 return val;
 }
 
-static uint32_t cpu_convert_to_target32(uint32_t val, int endian)
+uint32_t cpu_to_dump32(DumpState *s, uint32_t val)
 {
-if (endian == ELFDATA2LSB) {
+if (s->dump_info.d_endian == ELFDATA2LSB) {
 val = cpu_to_le32(val);
 } else {
 val = cpu_to_be32(val);
@@ -58,9 +58,9 @@ static uint32_t cpu_convert_to_target32(uint32_t val, int 
endian)
 return val;
 }
 
-static uint64_t cpu_convert_to_target64(uint64_t val, int endian)
+uint64_t cpu_to_dump64(DumpState *s, uint64_t val)
 {
-if (endian == ELFDATA2LSB) {
+if (s->dump_info.d_endian == ELFDATA2LSB) {
 val = cpu_to_le64(val);
 } else {
 val = cpu_to_be64(val);
@@ -69,39 +69,6 @@ static uint64_t cpu_convert_to_target64(uint64_t val, int 
endian)
 return val;
 }
 
-typedef struct DumpState {
-GuestPhysBlockList guest_phys_blocks;
-ArchDumpInfo dump_info;
-MemoryMappingList list;
-uint16_t phdr_num;
-uint32_t sh_info;
-bool have_section;
-bool resume;
-ssize_t note_size;
-hwaddr memory_offset;
-int fd;
-
-GuestPhysBlock *next_block;
-ram_addr_t start;
-bool has_filter;
-int64_t begin;
-int64_t length;
-Error **errp;
-
-uint8_t *note_buf;  /* buffer for notes */
-size_t note_buf_offset; /* the writing place in note_buf */
-uint32_t nr_cpus;   /* number of guest's cpu */
-size_t page_size;   /* guest's page size */
-uint32_t page_shift;/* guest's page shift */
-uint64_t max_mapnr; /* the biggest guest's phys-mem's number */
-size_t len_dump_bitmap; /* the size of the place used to store
-   dump_bitmap in vmcore */
-off_t offset_dump_bitmap;   /* offset of dump_bitmap part in vmcore */
-off_t offset_page;  /* offset of page part in vmcore */
-size_t num_dumpable;/* number of page that can be dumped */
-uint32_t flag_compress; /* indicate the compression format */
-} DumpState;
-
 static int dump_cleanup(DumpState *s)
 {
 int ret = 0;
@@ -140,29 +107,25 @@ static int write_elf64_header(DumpState *s)
 {
 Elf64_Ehdr elf_header;
 int ret;
-int endian = s->dump_info.d_endian;
 
 memset(&elf_header, 0, sizeof(Elf64_Ehdr));
 memcpy(&elf_header, ELFMAG, SELFMAG);
 elf_header.e_ident[EI_CLASS] = ELFCLASS64;
 elf_header.e_ident[EI_DATA] = s->dump_info.d_endian;
 elf_header.e_ident[EI_VERSION] = EV_CURRENT;
-elf_header.e_type = cpu_convert_to_target16(ET_CORE, endian);
-elf_header.e_machine = cpu_convert_to_target16(s->dump_info.d_machine,
-   endian);
-elf_header.e_version = cpu_convert_to_target32(EV_CURRENT, endian);
-elf_header.e_ehsize = cpu_convert_to_target16(sizeof(elf_header), endian);
-elf_header.e_phoff = cpu_convert_to_target64(sizeof(Elf64_Ehdr), endian);
-elf_header.e_phentsize = cpu_convert_to_target16(sizeof(Elf64_Phdr),
- endian);
-elf_header.e_phnum = cpu_convert_to_target16(s->phdr_num, endian);
+elf_header.e_type = cpu_to_dump16(s, ET_CORE);
+elf_header.e_machine = cpu_to_dump16(s, s->dump_info.d_machine);
+elf_header.e_version = cpu_to_dump32(s, EV_CURRENT);
+elf_header.e_ehsize = cpu_to_dump16(s, sizeof(elf_header));
+elf_header.e_phoff = cpu_to_dump64(s, sizeof(Elf64_Ehdr));
+elf_header.e_phentsize = cpu_to_dump16(s, 

[Qemu-devel] [PATCH v3 2/4] ppc64-dump: Support dump for little endian ppc64

2014-05-05 Thread Greg Kurz
From: Bharata B Rao 

Fix ppc64 arch specific dump code to work correctly for little endian
guests.

We introduce a NoteFuncArg type to avoid adding extra arguments to all note
functions.

Signed-off-by: Bharata B Rao 
[ rebased on top of current master branch,
  introduced NoteFuncArg,
  use new cpu_to_dump{16,32,64} endian helpers,
  Greg Kurz  ]
Reviewed-by: Alexander Graf 
Signed-off-by: Greg Kurz 
---

Changes in v3:
- better taste with the endian helpers naming

 target-ppc/arch_dump.c |   82 +---
 1 file changed, 49 insertions(+), 33 deletions(-)

diff --git a/target-ppc/arch_dump.c b/target-ppc/arch_dump.c
index 9dccf1a..5487b61 100644
--- a/target-ppc/arch_dump.c
+++ b/target-ppc/arch_dump.c
@@ -79,94 +79,109 @@ typedef struct noteStruct {
 } contents;
 } QEMU_PACKED Note;
 
+typedef struct NoteFuncArg {
+Note note;
+DumpState *state;
+} NoteFuncArg;
 
-static void ppc64_write_elf64_prstatus(Note *note, PowerPCCPU *cpu)
+static void ppc64_write_elf64_prstatus(NoteFuncArg *arg, PowerPCCPU *cpu)
 {
 int i;
 uint64_t cr;
 struct PPC64ElfPrstatus *prstatus;
 struct PPC64UserRegStruct *reg;
+Note *note = &arg->note;
+DumpState *s = arg->state;
 
-note->hdr.n_type = cpu_to_be32(NT_PRSTATUS);
+note->hdr.n_type = cpu_to_dump32(s, NT_PRSTATUS);
 
 prstatus = ¬e->contents.prstatus;
 memset(prstatus, 0, sizeof(*prstatus));
 reg = &prstatus->pr_reg;
 
 for (i = 0; i < 32; i++) {
-reg->gpr[i] = cpu_to_be64(cpu->env.gpr[i]);
+reg->gpr[i] = cpu_to_dump64(s, cpu->env.gpr[i]);
 }
-reg->nip = cpu_to_be64(cpu->env.nip);
-reg->msr = cpu_to_be64(cpu->env.msr);
-reg->ctr = cpu_to_be64(cpu->env.ctr);
-reg->link = cpu_to_be64(cpu->env.lr);
-reg->xer = cpu_to_be64(cpu_read_xer(&cpu->env));
+reg->nip = cpu_to_dump64(s, cpu->env.nip);
+reg->msr = cpu_to_dump64(s, cpu->env.msr);
+reg->ctr = cpu_to_dump64(s, cpu->env.ctr);
+reg->link = cpu_to_dump64(s, cpu->env.lr);
+reg->xer = cpu_to_dump64(s, cpu_read_xer(&cpu->env));
 
 cr = 0;
 for (i = 0; i < 8; i++) {
 cr |= (cpu->env.crf[i] & 15) << (4 * (7 - i));
 }
-reg->ccr = cpu_to_be64(cr);
+reg->ccr = cpu_to_dump64(s, cr);
 }
 
-static void ppc64_write_elf64_fpregset(Note *note, PowerPCCPU *cpu)
+static void ppc64_write_elf64_fpregset(NoteFuncArg *arg, PowerPCCPU *cpu)
 {
 int i;
 struct PPC64ElfFpregset  *fpregset;
+Note *note = &arg->note;
+DumpState *s = arg->state;
 
-note->hdr.n_type = cpu_to_be32(NT_PRFPREG);
+note->hdr.n_type = cpu_to_dump32(s, NT_PRFPREG);
 
 fpregset = ¬e->contents.fpregset;
 memset(fpregset, 0, sizeof(*fpregset));
 
 for (i = 0; i < 32; i++) {
-fpregset->fpr[i] = cpu_to_be64(cpu->env.fpr[i]);
+fpregset->fpr[i] = cpu_to_dump64(s, cpu->env.fpr[i]);
 }
-fpregset->fpscr = cpu_to_be64(cpu->env.fpscr);
+fpregset->fpscr = cpu_to_dump64(s, cpu->env.fpscr);
 }
 
-static void ppc64_write_elf64_vmxregset(Note *note, PowerPCCPU *cpu)
+static void ppc64_write_elf64_vmxregset(NoteFuncArg *arg, PowerPCCPU *cpu)
 {
 int i;
 struct PPC64ElfVmxregset *vmxregset;
+Note *note = &arg->note;
+DumpState *s = arg->state;
 
-note->hdr.n_type = cpu_to_be32(NT_PPC_VMX);
+note->hdr.n_type = cpu_to_dump32(s, NT_PPC_VMX);
 vmxregset = ¬e->contents.vmxregset;
 memset(vmxregset, 0, sizeof(*vmxregset));
 
 for (i = 0; i < 32; i++) {
-vmxregset->avr[i].u64[0] = cpu_to_be64(cpu->env.avr[i].u64[0]);
-vmxregset->avr[i].u64[1] = cpu_to_be64(cpu->env.avr[i].u64[1]);
+vmxregset->avr[i].u64[0] = cpu_to_dump64(s, cpu->env.avr[i].u64[0]);
+vmxregset->avr[i].u64[1] = cpu_to_dump64(s, cpu->env.avr[i].u64[1]);
 }
-vmxregset->vscr.u32[3] = cpu_to_be32(cpu->env.vscr);
+vmxregset->vscr.u32[3] = cpu_to_dump32(s, cpu->env.vscr);
 }
-static void ppc64_write_elf64_vsxregset(Note *note, PowerPCCPU *cpu)
+static void ppc64_write_elf64_vsxregset(NoteFuncArg *arg, PowerPCCPU *cpu)
 {
 int i;
 struct PPC64ElfVsxregset *vsxregset;
+Note *note = &arg->note;
+DumpState *s = arg->state;
 
-note->hdr.n_type = cpu_to_be32(NT_PPC_VSX);
+note->hdr.n_type = cpu_to_dump32(s, NT_PPC_VSX);
 vsxregset = ¬e->contents.vsxregset;
 memset(vsxregset, 0, sizeof(*vsxregset));
 
 for (i = 0; i < 32; i++) {
-vsxregset->vsr[i] = cpu_to_be64(cpu->env.vsr[i]);
+vsxregset->vsr[i] = cpu_to_dump64(s, cpu->env.vsr[i]);
 }
 }
-static void ppc64_write_elf64_speregset(Note *note, PowerPCCPU *cpu)
+static void ppc64_write_elf64_speregset(NoteFuncArg *arg, PowerPCCPU *cpu)
 {
 struct PPC64ElfSperegset *speregset;
-note->hdr.n_type = cpu_to_be32(NT_PPC_SPE);
+Note *note = &arg->note;
+DumpState *s = arg->state;
+
+note->hdr.n_type = cpu_to_dump32(s, NT_PPC_SPE);
 speregset = ¬e->contents.speregset;
 memset(speregset, 0, sizeof(*sper

[Qemu-devel] [PATCH v3 3/4] target-ppc: ppc can be either endian

2014-05-05 Thread Greg Kurz
POWER7, POWER7+ and POWER8 families use the ILE bit of the LPCR
special purpose register to decide the endianness to use when
entering interrupt handlers. When running a Linux guest, this
provides a hint on the endianness used by the kernel. From a
QEMU point of view, the information is needed for legacy virtio
support and crash dump support as well.

Suggested-by: Benjamin Herrenschmidt 
Reviewed-by: Alexander Graf 
Signed-off-by: Greg Kurz 
---

 No changes, resent in case it helps

 target-ppc/cpu-qom.h|1 +
 target-ppc/translate_init.c |   16 
 2 files changed, 17 insertions(+)

diff --git a/target-ppc/cpu-qom.h b/target-ppc/cpu-qom.h
index 47dc8e6..fdce638 100644
--- a/target-ppc/cpu-qom.h
+++ b/target-ppc/cpu-qom.h
@@ -76,6 +76,7 @@ typedef struct PowerPCCPUClass {
 int (*handle_mmu_fault)(PowerPCCPU *cpu, target_ulong eaddr, int rwx,
 int mmu_idx);
 #endif
+bool (*interrupts_big_endian)(PowerPCCPU *cpu);
 } PowerPCCPUClass;
 
 /**
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 7f53c33..a27e5a7 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -3102,6 +3102,18 @@ static int check_pow_hid0_74xx (CPUPPCState *env)
 return 0;
 }
 
+static bool ppc_cpu_interrupts_big_endian_always(PowerPCCPU *cpu)
+{
+return true;
+}
+
+#ifdef TARGET_PPC64
+static bool ppc_cpu_interrupts_big_endian_lpcr(PowerPCCPU *cpu)
+{
+return !(cpu->env.spr[SPR_LPCR] & LPCR_ILE);
+}
+#endif
+
 /*/
 /* PowerPC implementations definitions   */
 
@@ -7089,6 +7101,7 @@ POWERPC_FAMILY(POWER7)(ObjectClass *oc, void *data)
  POWERPC_FLAG_VSX;
 pcc->l1_dcache_size = 0x8000;
 pcc->l1_icache_size = 0x8000;
+pcc->interrupts_big_endian = ppc_cpu_interrupts_big_endian_lpcr;
 }
 
 POWERPC_FAMILY(POWER7P)(ObjectClass *oc, void *data)
@@ -7132,6 +7145,7 @@ POWERPC_FAMILY(POWER7P)(ObjectClass *oc, void *data)
  POWERPC_FLAG_VSX;
 pcc->l1_dcache_size = 0x8000;
 pcc->l1_icache_size = 0x8000;
+pcc->interrupts_big_endian = ppc_cpu_interrupts_big_endian_lpcr;
 }
 
 static void init_proc_POWER8(CPUPPCState *env)
@@ -7189,6 +7203,7 @@ POWERPC_FAMILY(POWER8)(ObjectClass *oc, void *data)
  POWERPC_FLAG_VSX;
 pcc->l1_dcache_size = 0x8000;
 pcc->l1_icache_size = 0x8000;
+pcc->interrupts_big_endian = ppc_cpu_interrupts_big_endian_lpcr;
 }
 #endif /* defined (TARGET_PPC64) */
 
@@ -8511,6 +8526,7 @@ static void ppc_cpu_class_init(ObjectClass *oc, void 
*data)
 pcc->parent_realize = dc->realize;
 pcc->pvr = CPU_POWERPC_DEFAULT_MASK;
 pcc->pvr_mask = CPU_POWERPC_DEFAULT_MASK;
+pcc->interrupts_big_endian = ppc_cpu_interrupts_big_endian_always;
 dc->realize = ppc_cpu_realizefn;
 dc->unrealize = ppc_cpu_unrealizefn;
 




[Qemu-devel] [PATCH v2 4/4] ppc64 dump: Set the correct endianness in ELF dump header

2014-05-05 Thread Greg Kurz
From: Bharata B Rao 

Signed-off-by: Bharata B Rao 
[ use PowerPCCPUClass::interrupts_big_endian(),
  Greg Kurz  ]
Reviewed-by: Alexander Graf 
Signed-off-by: Greg Kurz 
---

No changes, resent in case it helps

 target-ppc/arch_dump.c |   12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/target-ppc/arch_dump.c b/target-ppc/arch_dump.c
index 5487b61..53e2fe0 100644
--- a/target-ppc/arch_dump.c
+++ b/target-ppc/arch_dump.c
@@ -196,12 +196,16 @@ typedef struct NoteFuncDescStruct NoteFuncDesc;
 int cpu_get_dump_info(ArchDumpInfo *info,
   const struct GuestPhysBlockList *guest_phys_blocks)
 {
-/*
- * Currently only handling PPC64 big endian.
- */
+PowerPCCPU *cpu = POWERPC_CPU(first_cpu);
+PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
+
 info->d_machine = EM_PPC64;
-info->d_endian = ELFDATA2MSB;
 info->d_class = ELFCLASS64;
+if ((*pcc->interrupts_big_endian)(cpu)) {
+info->d_endian = ELFDATA2MSB;
+} else {
+info->d_endian = ELFDATA2LSB;
+}
 
 return 0;
 }




Re: [Qemu-devel] [PATCH 16/22] sheepdog: implement .bdrv_detach/attach_aio_context()

2014-05-05 Thread Liu Yuan
On Thu, May 01, 2014 at 04:54:40PM +0200, Stefan Hajnoczi wrote:
> Drop the assumption that we're using the main AioContext.  Convert
> qemu_aio_set_fd_handler() to aio_set_fd_handler() and qemu_aio_wait() to
> aio_poll().
> 
> The .bdrv_detach/attach_aio_context() interfaces also need to be
> implemented to move the socket fd handler from the old to the new
> AioContext.
> 
> Cc: MORITA Kazutaka 
> Cc: Liu Yuan 
> Signed-off-by: Stefan Hajnoczi 
> ---
>  block/sheepdog.c | 118 
> +--
>  1 file changed, 80 insertions(+), 38 deletions(-)
> 
> diff --git a/block/sheepdog.c b/block/sheepdog.c
> index 0eb33ee..4727fc1 100644
> --- a/block/sheepdog.c
> +++ b/block/sheepdog.c
> @@ -314,6 +314,7 @@ struct SheepdogAIOCB {
>  
>  typedef struct BDRVSheepdogState {
>  BlockDriverState *bs;
> +AioContext *aio_context;
>  
>  SheepdogInode inode;
>  
> @@ -496,7 +497,7 @@ static void sd_aio_cancel(BlockDriverAIOCB *blockacb)
>  sd_finish_aiocb(acb);
>  return;
>  }
> -qemu_aio_wait();
> +aio_poll(s->aio_context, true);
>  }
>  }
>  
> @@ -582,6 +583,7 @@ static void restart_co_req(void *opaque)
>  
>  typedef struct SheepdogReqCo {
>  int sockfd;
> +AioContext *aio_context;
>  SheepdogReq *hdr;
>  void *data;
>  unsigned int *wlen;
> @@ -602,14 +604,14 @@ static coroutine_fn void do_co_req(void *opaque)
>  unsigned int *rlen = srco->rlen;
>  
>  co = qemu_coroutine_self();
> -qemu_aio_set_fd_handler(sockfd, NULL, restart_co_req, co);
> +aio_set_fd_handler(srco->aio_context, sockfd, NULL, restart_co_req, co);
>  
>  ret = send_co_req(sockfd, hdr, data, wlen);
>  if (ret < 0) {
>  goto out;
>  }
>  
> -qemu_aio_set_fd_handler(sockfd, restart_co_req, NULL, co);
> +aio_set_fd_handler(srco->aio_context, sockfd, restart_co_req, NULL, co);
>  
>  ret = qemu_co_recv(sockfd, hdr, sizeof(*hdr));
>  if (ret != sizeof(*hdr)) {
> @@ -634,18 +636,19 @@ static coroutine_fn void do_co_req(void *opaque)
>  out:
>  /* there is at most one request for this sockfd, so it is safe to
>   * set each handler to NULL. */
> -qemu_aio_set_fd_handler(sockfd, NULL, NULL, NULL);
> +aio_set_fd_handler(srco->aio_context, sockfd, NULL, NULL, NULL);
>  
>  srco->ret = ret;
>  srco->finished = true;
>  }
>  
> -static int do_req(int sockfd, SheepdogReq *hdr, void *data,
> -  unsigned int *wlen, unsigned int *rlen)
> +static int do_req(int sockfd, AioContext *aio_context, SheepdogReq *hdr,
> +  void *data, unsigned int *wlen, unsigned int *rlen)
>  {
>  Coroutine *co;
>  SheepdogReqCo srco = {
>  .sockfd = sockfd,
> +.aio_context = aio_context,
>  .hdr = hdr,
>  .data = data,
>  .wlen = wlen,
> @@ -660,7 +663,7 @@ static int do_req(int sockfd, SheepdogReq *hdr, void 
> *data,
>  co = qemu_coroutine_create(do_co_req);
>  qemu_coroutine_enter(co, &srco);
>  while (!srco.finished) {
> -qemu_aio_wait();
> +aio_poll(aio_context, true);
>  }
>  }
>  
> @@ -712,7 +715,7 @@ static coroutine_fn void reconnect_to_sdog(void *opaque)
>  BDRVSheepdogState *s = opaque;
>  AIOReq *aio_req, *next;
>  
> -qemu_aio_set_fd_handler(s->fd, NULL, NULL, NULL);
> +aio_set_fd_handler(s->aio_context, s->fd, NULL, NULL, NULL);
>  close(s->fd);
>  s->fd = -1;
>  
> @@ -923,7 +926,7 @@ static int get_sheep_fd(BDRVSheepdogState *s)
>  return fd;
>  }
>  
> -qemu_aio_set_fd_handler(fd, co_read_response, NULL, s);
> +aio_set_fd_handler(s->aio_context, fd, co_read_response, NULL, s);
>  return fd;
>  }
>  
> @@ -1093,7 +1096,7 @@ static int find_vdi_name(BDRVSheepdogState *s, const 
> char *filename,
>  hdr.snapid = snapid;
>  hdr.flags = SD_FLAG_CMD_WRITE;
>  
> -ret = do_req(fd, (SheepdogReq *)&hdr, buf, &wlen, &rlen);
> +ret = do_req(fd, s->aio_context, (SheepdogReq *)&hdr, buf, &wlen, &rlen);
>  if (ret) {
>  goto out;
>  }
> @@ -1173,7 +1176,8 @@ static void coroutine_fn 
> add_aio_request(BDRVSheepdogState *s, AIOReq *aio_req,
>  
>  qemu_co_mutex_lock(&s->lock);
>  s->co_send = qemu_coroutine_self();
> -qemu_aio_set_fd_handler(s->fd, co_read_response, co_write_request, s);
> +aio_set_fd_handler(s->aio_context, s->fd,
> +   co_read_response, co_write_request, s);
>  socket_set_cork(s->fd, 1);
>  
>  /* send a header */
> @@ -1191,12 +1195,13 @@ static void coroutine_fn 
> add_aio_request(BDRVSheepdogState *s, AIOReq *aio_req,
>  }
>  out:
>  socket_set_cork(s->fd, 0);
> -qemu_aio_set_fd_handler(s->fd, co_read_response, NULL, s);
> +aio_set_fd_handler(s->aio_context, s->fd, co_read_response, NULL, s);
>  s->co_send = NULL;
>  qemu_co_mutex_unlock(&s->lock);
>  }
>  
> -static int read_write

Re: [Qemu-devel] [PATCH v3 0/4] Add max-ram-below-4g (was Add pci_hole_min_size machine option)

2014-05-05 Thread Michael S. Tsirkin
On Tue, Apr 22, 2014 at 12:31:16PM -0400, Don Slutz wrote:
> On 04/18/14 10:10, Andreas Färber wrote:
> >Am 25.03.2014 10:08, schrieb Michael S. Tsirkin:
> >>On Mon, Mar 24, 2014 at 07:55:32PM -0400, Don Slutz wrote:
> >>>Changes v2 to v3:
> >>>   Stefano Stabellini:
> >>> Acked-by #1 "xen-all: Fix xen_hvm_init() to adjust pc memory"
> >>> Adjust for code readability #4 "xen-all: Pass max_ram_below_4g to 
> >>> xen_hvm_init."
> >>>Set max_ram_below_4g always and use it to calculate 
> >>> above_4g_mem_size,
> >>>below_4g_mem_size.
> >>>
> >>>Changes v1 to v2:
> >>>   Michael S. Tsirkin:
> >>> Rename option.
> >>> Only add it to machine types that support it.
> >>>   Split into 4 parts.
> >>>
> >>>1/4 -- xen-all: Fix xen_hvm_init() to adjust pc memory layout
> >>>
> >>>   This looks to be a possible bug that has yet to be found.
> >>>   below_4g_mem_size and above_4g_mem_size are stored in PcGuestInfo
> >>>   (pc_guest_info_init) which are currently not "correct".  This and
> >>>   4/4 change the same lines.
> >>>
> >>>2/4 -- GlobalProperty: Display warning about unused -global
> >>>
> >>> My testing showed that setting a global property on an object
> >>> that is not used is not reported at all.  This is added to help
> >>> when the new global is set but not used.  The negative not_used
> >>> was picked so that all static objects are assumed to be used
> >>> even when they are not.
> >>>
> >>>3/4 -- pc & q35: Add new object pc-memory-layout
> >>>
> >>>   The objects that it might make sense to add this property to all
> >>>   get created too late.  So add a new object just to hold this
> >>>   property.  Name it so that it is expected that only pc (and q35)
> >>>   machine types support it.
> >>>
> >>>4/4 -- xen-all: Pass max_ram_below_4g to xen_hvm_init
> >>>
> >>>   Seprate the xen only part of the change.  Currectly based on patch 1/4
> >>>
> >>>Don Slutz (4):
> >>>   xen-all: Fix xen_hvm_init() to adjust pc memory layout.
> >>>   GlobalProperty: Display warning about unused -global
> >>>   pc & q35: Add new object pc-memory-layout.
> >>>   xen-all: Pass max_ram_below_4g to xen_hvm_init.
> >>>
> >>>  hw/core/qdev-properties-system.c |  1 +
> >>>  hw/core/qdev-properties.c| 15 
> >>>  hw/i386/pc.c | 42 
> >>>  hw/i386/pc_piix.c| 52 
> >>> +++-
> >>>  hw/i386/pc_q35.c | 50 
> >>> ++
> >>>  include/hw/i386/pc.h |  2 ++
> >>>  include/hw/qdev-core.h   |  1 +
> >>>  include/hw/qdev-properties.h |  1 +
> >>>  include/hw/xen/xen.h |  3 ++-
> >>>  vl.c |  2 ++
> >>>  xen-all.c| 46 +++
> >>>  xen-stub.c   |  3 ++-
> >>>  12 files changed, 165 insertions(+), 53 deletions(-)
> >>Andreas, could you review pls, esp patch 2?
> >Michael, I don't see a dependency of the later patches on 2/4, so I'd
> >like to split that one out of this series and reiterate.
> 
> I am happy to split out 2/4.

I'm waiting for a repost or did I misunderstand?

> >I'll have some minor comments on the rest.
> >
> >Don, in general please do not end subjects with a dot.
> 
> Ok, will attempt to do so.
> 
>-Don Slutz
> 
> >CC'ing Eduardo and Igor who looked into 4G issues previously.
> >
> >Regards,
> >Andreas
> >



Re: [Qemu-devel] [PATCH v2 1/2] qapi: Allow decimal values

2014-05-05 Thread Markus Armbruster
Eric Blake  writes:

> On 04/29/2014 03:44 AM, Fam Zheng wrote:
>> This allows giving decimal constants in the schema as expr.
>> 
>> Signed-off-by: Fam Zheng 
>> ---
>>  scripts/qapi.py | 15 +--
>>  1 file changed, 13 insertions(+), 2 deletions(-)
>> 
>> diff --git a/scripts/qapi.py b/scripts/qapi.py
>> index b474c39..6022de5 100644
>> --- a/scripts/qapi.py
>> +++ b/scripts/qapi.py
>> @@ -108,6 +108,14 @@ class QAPISchema:
>>  return
>>  else:
>>  string += ch
>> +elif self.tok in "123456789":
>> +self.val = int(self.tok)
>> +while True:
>> +ch = self.src[self.cursor]
>> +if ch not in "1234567890":
>> +return
>> +self.val = self.val * 10 + int(ch)
>> +self.cursor += 1
>
> What does this do on integer overflow?  Should you validate that the
> result fits in [u]int64_t?  Should you allow for a leading '-' sign for
> a default of a negative number?  You have forbidden '0' as a valid
> number (although you correctly forbid '00' and any non-zero number with
> a leading 0, which matches JSON restrictions).

If every valid JSON number is also a valid Python number, then you can
accumulate the token, then convert it with built-in function int().
Just like our C JSON lexer uses strtoll(), in parse_literal().

>> -if not self.tok in [ '{', '[', "'" ]:
>> -raise QAPISchemaError(self, 'Expected "{", "[", "]" or string')
>> +if not self.tok in "{['123456789":
>> + raise QAPISchemaError(self, 'Expected "{", "[", "]", string or
>> number')
>
> Again, this forbids the use of '0' as a default.

The spec for our lexical analysis comes from RFC 4627.  We take some
liberties with it, but we should do so only deliberately, and with a
sensible reason.  We should also keep the Python version (qapi.py)
consistent with the C version (qobject/json*.[ch]).

In particular see how parse_literal() deals with integer overflow.

Grammar for numbers, straight from RFC 4627:

 number = [ minus ] int [ frac ] [ exp ]

 decimal-point = %x2E   ; .

 digit1-9 = %x31-39 ; 1-9

 e = %x65 / %x45; e E

 exp = e [ minus / plus ] 1*DIGIT

 frac = decimal-point 1*DIGIT

 int = zero / ( digit1-9 *DIGIT )

 minus = %x2D   ; -

 plus = %x2B; +

 zero = %x30; 0

Since we distinguish between integral and fractional numbers everywhere
in our usage of JSON, it makes sense to do so here as well.

This means we want to accept this sub-grammar:

inum = [ minus ] int

 minus = %x2D   ; -

 digit1-9 = %x31-39 ; 1-9

 zero = %x30; 0

 int = zero / ( digit1-9 *DIGIT )

json-lexer.c's state machine implements this faithfully (as far as I can
tell).

Fractional numbers could be left for later here, since your PATCH 2/2,
the first and so far only user of numbers, arbitrarily restricts them to
integer.  Just implementing them might be easier than documenting the
restriction, though...



Re: [Qemu-devel] [PATCH 07/22] gluster: use BlockDriverState's AioContext

2014-05-05 Thread Bharata B Rao
On Thu, May 01, 2014 at 04:54:31PM +0200, Stefan Hajnoczi wrote:
> Drop the assumption that we're using the main AioContext.  Use
> aio_bh_new() instead of qemu_bh_new().
> 
> The .bdrv_detach_aio_context() and .bdrv_attach_aio_context() interfaces
> are not needed since no fd handlers, timers, or BHs stay registered when
> requests have been drained.
> 
> Cc: Bharata B Rao 
> Signed-off-by: Stefan Hajnoczi 
> ---
>  block/gluster.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

Changes look fine from gluster driver's point of view.

Regards,
Bharata.




[Qemu-devel] [RFC PATCH V4 0/6] PSCI v0.2 support for KVM ARM/ARM64

2014-05-05 Thread Pranavkumar Sawargaonkar
This patchset adds the QEMU side changes for providing PSCI v0.2 to VM.

ChangeLog:

V4:
- Rebase this patch against v11 patchset for in-kernel PSCI v0.2 emulation
 (http://www.spinics.net/lists/kvm-arm/msg09182.html)
- Used PSCI 0.2 DT bindings for linux kernel.
  (http://www.spinics.net/lists/arm-kernel/msg326044.html).

V3:
 - Rebase this patchset against v8 patchset for in-kernel PSCI v0.2 emulation
   (http://www.spinics.net/lists/kvm-arm/msg08780.html)
 - Added common kvm_arm_vcpu_init() function for kvm arm and kvm arm64

V2:
 - Rebase this patchset against v6 patchset for in-kernel PSCI v0.2 emulation
   (http://www.spinics.net/lists/arm-kernel/msg319037.html)
 - Handle KVM_EXIT_SYSTEM_EVENT in kvm-all.c:kvm_cpu_exec()
 - Drop change in kvm_arm_get_host_cpu_features()
 - Improve comments and description of kvm_arch_reset_vcpu() implementation

V1:
 - Initial RFC patchset

Pranavkumar Sawargaonkar (6):
  linux-headers: Update KVM headers from linux-3.16-rc1
  kvm: Handle exit reason KVM_EXIT_SYSTEM_EVENT
  target-arm: Enable KVM_ARM_VCPU_PSCI_0_2 feature when possible
  hw/arm/virt: Use PSCI v0.2 compatible when kernel supports it
  target-arm: Common kvm_arm_vcpu_init() for KVM ARM and KVM ARM64
  target-arm: Implement kvm_arch_reset_vcpu() for KVM ARM64

 hw/arm/virt.c |   16 +---
 kvm-all.c |   16 
 linux-headers/asm-arm/kvm.h   |   10 +++--
 linux-headers/asm-arm64/kvm.h |   10 +++--
 linux-headers/linux/kvm.h |   27 -
 linux-headers/linux/psci.h|   90 +
 target-arm/kvm.c  |   23 +++
 target-arm/kvm32.c|   15 ++-
 target-arm/kvm64.c|   23 ++-
 target-arm/kvm_arm.h  |   14 +++
 10 files changed, 206 insertions(+), 38 deletions(-)
 create mode 100644 linux-headers/linux/psci.h

-- 
1.7.9.5




[Qemu-devel] [RFC PATCH V4 2/6] kvm: Handle exit reason KVM_EXIT_SYSTEM_EVENT

2014-05-05 Thread Pranavkumar Sawargaonkar
In-kernel PSCI v0.2 emulation of KVM ARM/ARM64 forwards SYSTEM_OFF
and SYSTEM_RESET function calls to QEMU using KVM_EXIT_SYSTEM_EVENT
exit reason.

This patch updates kvm_cpu_exec() to handle KVM_SYSTEM_EVENT_SHUTDOWN
and KVM_SYSTEM_EVENT_RESET system-level events from QEMU-side.

Signed-off-by: Pranavkumar Sawargaonkar 
Signed-off-by: Anup Patel 
---
 kvm-all.c |   16 
 1 file changed, 16 insertions(+)

diff --git a/kvm-all.c b/kvm-all.c
index 82a9119..9335c50 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -1724,6 +1724,22 @@ int kvm_cpu_exec(CPUState *cpu)
 case KVM_EXIT_INTERNAL_ERROR:
 ret = kvm_handle_internal_error(cpu, run);
 break;
+case KVM_EXIT_SYSTEM_EVENT:
+switch (run->system_event.type) {
+case KVM_SYSTEM_EVENT_SHUTDOWN:
+qemu_system_shutdown_request();
+ret = EXCP_INTERRUPT;
+break;
+case KVM_SYSTEM_EVENT_RESET:
+qemu_system_reset_request();
+ret = EXCP_INTERRUPT;
+break;
+default:
+DPRINTF("kvm_arch_handle_exit\n");
+ret = kvm_arch_handle_exit(cpu, run);
+break;
+}
+break;
 default:
 DPRINTF("kvm_arch_handle_exit\n");
 ret = kvm_arch_handle_exit(cpu, run);
-- 
1.7.9.5




[Qemu-devel] [RFC PATCH V4 1/6] linux-headers: Update KVM headers from linux-3.16-rc1

2014-05-05 Thread Pranavkumar Sawargaonkar
Syncup KVM related linux headers from linux-3.16-rc1

Signed-off-by: Pranavkumar Sawargaonkar 
Signed-off-by: Anup Patel 
---
 linux-headers/asm-arm/kvm.h   |   10 +++--
 linux-headers/asm-arm64/kvm.h |   10 +++--
 linux-headers/linux/kvm.h |   27 -
 linux-headers/linux/psci.h|   90 +
 4 files changed, 128 insertions(+), 9 deletions(-)
 create mode 100644 linux-headers/linux/psci.h

diff --git a/linux-headers/asm-arm/kvm.h b/linux-headers/asm-arm/kvm.h
index ef0c878..e6ebdd3 100644
--- a/linux-headers/asm-arm/kvm.h
+++ b/linux-headers/asm-arm/kvm.h
@@ -20,6 +20,7 @@
 #define __ARM_KVM_H__
 
 #include 
+#include 
 #include 
 
 #define __KVM_HAVE_GUEST_DEBUG
@@ -83,6 +84,7 @@ struct kvm_regs {
 #define KVM_VGIC_V2_CPU_SIZE   0x2000
 
 #define KVM_ARM_VCPU_POWER_OFF 0 /* CPU is started in OFF state */
+#define KVM_ARM_VCPU_PSCI_0_2  1 /* CPU uses PSCI v0.2 */
 
 struct kvm_vcpu_init {
__u32 target;
@@ -201,9 +203,9 @@ struct kvm_arch_memory_slot {
 #define KVM_PSCI_FN_CPU_ON KVM_PSCI_FN(2)
 #define KVM_PSCI_FN_MIGRATEKVM_PSCI_FN(3)
 
-#define KVM_PSCI_RET_SUCCESS   0
-#define KVM_PSCI_RET_NI((unsigned long)-1)
-#define KVM_PSCI_RET_INVAL ((unsigned long)-2)
-#define KVM_PSCI_RET_DENIED((unsigned long)-3)
+#define KVM_PSCI_RET_SUCCESS   PSCI_RET_SUCCESS
+#define KVM_PSCI_RET_NIPSCI_RET_NOT_SUPPORTED
+#define KVM_PSCI_RET_INVAL PSCI_RET_INVALID_PARAMS
+#define KVM_PSCI_RET_DENIEDPSCI_RET_DENIED
 
 #endif /* __ARM_KVM_H__ */
diff --git a/linux-headers/asm-arm64/kvm.h b/linux-headers/asm-arm64/kvm.h
index eaf54a3..e6471da 100644
--- a/linux-headers/asm-arm64/kvm.h
+++ b/linux-headers/asm-arm64/kvm.h
@@ -31,6 +31,7 @@
 #define KVM_NR_SPSR5
 
 #ifndef __ASSEMBLY__
+#include 
 #include 
 #include 
 
@@ -77,6 +78,7 @@ struct kvm_regs {
 
 #define KVM_ARM_VCPU_POWER_OFF 0 /* CPU is started in OFF state */
 #define KVM_ARM_VCPU_EL1_32BIT 1 /* CPU running a 32bit VM */
+#define KVM_ARM_VCPU_PSCI_0_2  2 /* CPU uses PSCI v0.2 */
 
 struct kvm_vcpu_init {
__u32 target;
@@ -186,10 +188,10 @@ struct kvm_arch_memory_slot {
 #define KVM_PSCI_FN_CPU_ON KVM_PSCI_FN(2)
 #define KVM_PSCI_FN_MIGRATEKVM_PSCI_FN(3)
 
-#define KVM_PSCI_RET_SUCCESS   0
-#define KVM_PSCI_RET_NI((unsigned long)-1)
-#define KVM_PSCI_RET_INVAL ((unsigned long)-2)
-#define KVM_PSCI_RET_DENIED((unsigned long)-3)
+#define KVM_PSCI_RET_SUCCESS   PSCI_RET_SUCCESS
+#define KVM_PSCI_RET_NIPSCI_RET_NOT_SUPPORTED
+#define KVM_PSCI_RET_INVAL PSCI_RET_INVALID_PARAMS
+#define KVM_PSCI_RET_DENIEDPSCI_RET_DENIED
 
 #endif
 
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index e27a4b3..1371821 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -8,7 +8,6 @@
  */
 
 #include 
-
 #include 
 #include 
 
@@ -171,6 +170,7 @@ struct kvm_pit_config {
 #define KVM_EXIT_WATCHDOG 21
 #define KVM_EXIT_S390_TSCH22
 #define KVM_EXIT_EPR  23
+#define KVM_EXIT_SYSTEM_EVENT 24
 
 /* For KVM_EXIT_INTERNAL_ERROR */
 /* Emulate instruction failed. */
@@ -301,6 +301,13 @@ struct kvm_run {
struct {
__u32 epr;
} epr;
+   /* KVM_EXIT_SYSTEM_EVENT */
+   struct {
+#define KVM_SYSTEM_EVENT_SHUTDOWN   1
+#define KVM_SYSTEM_EVENT_RESET  2
+   __u32 type;
+   __u64 flags;
+   } system_event;
/* Fix the size of the union. */
char padding[256];
};
@@ -740,6 +747,10 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_SPAPR_MULTITCE 94
 #define KVM_CAP_EXT_EMUL_CPUID 95
 #define KVM_CAP_HYPERV_TIME 96
+#define KVM_CAP_IOAPIC_POLARITY_IGNORED 97
+#define KVM_CAP_ENABLE_CAP_VM 98
+#define KVM_CAP_S390_IRQCHIP 99
+#define KVM_CAP_ARM_PSCI_0_2 100
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
@@ -755,9 +766,18 @@ struct kvm_irq_routing_msi {
__u32 pad;
 };
 
+struct kvm_irq_routing_s390_adapter {
+   __u64 ind_addr;
+   __u64 summary_addr;
+   __u64 ind_offset;
+   __u32 summary_offset;
+   __u32 adapter_id;
+};
+
 /* gsi routing entry types */
 #define KVM_IRQ_ROUTING_IRQCHIP 1
 #define KVM_IRQ_ROUTING_MSI 2
+#define KVM_IRQ_ROUTING_S390_ADAPTER 3
 
 struct kvm_irq_routing_entry {
__u32 gsi;
@@ -767,6 +787,7 @@ struct kvm_irq_routing_entry {
union {
struct kvm_irq_routing_irqchip irqchip;
struct kvm_irq_routing_msi msi;
+   struct kvm_irq_routing_s390_adapter adapter;
__u32 pad[8];
} u;
 };
@@ -1075,6 +1096,10 @@ struct kvm_s390_ucas_mapping {
 /* Available with KVM_CA

[Qemu-devel] [RFC PATCH V4 4/6] hw/arm/virt: Use PSCI v0.2 compatible when kernel supports it

2014-05-05 Thread Pranavkumar Sawargaonkar
If we have in-kernel emulation of PSCI v0.2 for KVM ARM/ARM64 then
we enable PSCI v0.2 for each VCPU at the time of VCPU init hence we
need to provide PSCI v0.2 compatible string via generated DTB.

This patch updates generated DTB to have PSCI v0.2 compatible string
when we have in-kernel emulation PSCI v0.2 for KVM ARM/ARM64.

Signed-off-by: Pranavkumar Sawargaonkar 
Signed-off-by: Anup Patel 
---
 hw/arm/virt.c |   16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 2bbc931..e4ae8ba 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -185,13 +185,17 @@ static void create_fdt(VirtBoardInfo *vbi)
 /* No PSCI for TCG yet */
 if (kvm_enabled()) {
 qemu_fdt_add_subnode(fdt, "/psci");
-qemu_fdt_setprop_string(fdt, "/psci", "compatible", "arm,psci");
-qemu_fdt_setprop_string(fdt, "/psci", "method", "hvc");
-qemu_fdt_setprop_cell(fdt, "/psci", "cpu_suspend",
+if (kvm_check_extension(kvm_state, KVM_CAP_ARM_PSCI_0_2)) {
+qemu_fdt_setprop_string(fdt, "/psci", "compatible", 
"arm,psci-0.2");
+} else {
+qemu_fdt_setprop_string(fdt, "/psci", "compatible", "arm,psci");
+qemu_fdt_setprop_cell(fdt, "/psci", "cpu_suspend",
   PSCI_FN_CPU_SUSPEND);
-qemu_fdt_setprop_cell(fdt, "/psci", "cpu_off", PSCI_FN_CPU_OFF);
-qemu_fdt_setprop_cell(fdt, "/psci", "cpu_on", PSCI_FN_CPU_ON);
-qemu_fdt_setprop_cell(fdt, "/psci", "migrate", PSCI_FN_MIGRATE);
+qemu_fdt_setprop_cell(fdt, "/psci", "cpu_off", PSCI_FN_CPU_OFF);
+qemu_fdt_setprop_cell(fdt, "/psci", "cpu_on", PSCI_FN_CPU_ON);
+qemu_fdt_setprop_cell(fdt, "/psci", "migrate", PSCI_FN_MIGRATE);
+}
+qemu_fdt_setprop_string(fdt, "/psci", "method", "hvc");
 }
 }
 
-- 
1.7.9.5




[Qemu-devel] [RFC PATCH V4 3/6] target-arm: Enable KVM_ARM_VCPU_PSCI_0_2 feature when possible

2014-05-05 Thread Pranavkumar Sawargaonkar
Latest linux kernel supports in-kernel emulation of PSCI v0.2 but
to enable it we need to select KVM_ARM_VCPU_PSCI_0_2 feature using
KVM_ARM_VCPU_INIT ioctl.

Also, we can use KVM_ARM_VCPU_PSCI_0_2 feature for VCPU only when
linux kernel has KVM_CAP_ARM_PSCI_0_2 capability.

This patch updates kvm_arch_init_vcpu() to enable KVM_ARM_VCPU_PSCI_0_2
feature for VCPU when KVM ARM/ARM64 has KVM_CAP_ARM_PSCI_0_2 capability.

Signed-off-by: Pranavkumar Sawargaonkar 
Signed-off-by: Anup Patel 
---
 target-arm/kvm32.c |5 -
 target-arm/kvm64.c |5 -
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/target-arm/kvm32.c b/target-arm/kvm32.c
index a690d99..cd9ac03 100644
--- a/target-arm/kvm32.c
+++ b/target-arm/kvm32.c
@@ -182,7 +182,10 @@ int kvm_arch_init_vcpu(CPUState *cs)
 init.target = cpu->kvm_target;
 memset(init.features, 0, sizeof(init.features));
 if (cpu->start_powered_off) {
-init.features[0] = 1 << KVM_ARM_VCPU_POWER_OFF;
+init.features[0] |= 1 << KVM_ARM_VCPU_POWER_OFF;
+}
+if (kvm_check_extension(cs->kvm_state, KVM_CAP_ARM_PSCI_0_2)) {
+init.features[0] |= 1 << KVM_ARM_VCPU_PSCI_0_2;
 }
 ret = kvm_vcpu_ioctl(cs, KVM_ARM_VCPU_INIT, &init);
 if (ret) {
diff --git a/target-arm/kvm64.c b/target-arm/kvm64.c
index e115879..bc6cd74 100644
--- a/target-arm/kvm64.c
+++ b/target-arm/kvm64.c
@@ -90,7 +90,10 @@ int kvm_arch_init_vcpu(CPUState *cs)
 init.target = cpu->kvm_target;
 memset(init.features, 0, sizeof(init.features));
 if (cpu->start_powered_off) {
-init.features[0] = 1 << KVM_ARM_VCPU_POWER_OFF;
+init.features[0] |= 1 << KVM_ARM_VCPU_POWER_OFF;
+}
+if (kvm_check_extension(cs->kvm_state, KVM_CAP_ARM_PSCI_0_2)) {
+init.features[0] |= 1 << KVM_ARM_VCPU_PSCI_0_2;
 }
 ret = kvm_vcpu_ioctl(cs, KVM_ARM_VCPU_INIT, &init);
 
-- 
1.7.9.5




[Qemu-devel] [RFC PATCH V4 5/6] target-arm: Common kvm_arm_vcpu_init() for KVM ARM and KVM ARM64

2014-05-05 Thread Pranavkumar Sawargaonkar
Introduce a common kvm_arm_vcpu_init() for doing KVM_ARM_VCPU_INIT
ioctl in KVM ARM and KVM ARM64. This also helps us factor-out few
common code lines from kvm_arch_init_vcpu() for KVM ARM/ARM64.

Signed-off-by: Pranavkumar Sawargaonkar 
Signed-off-by: Anup Patel 
---
 target-arm/kvm.c |   23 +++
 target-arm/kvm32.c   |   18 +++---
 target-arm/kvm64.c   |   22 --
 target-arm/kvm_arm.h |   14 ++
 4 files changed, 48 insertions(+), 29 deletions(-)

diff --git a/target-arm/kvm.c b/target-arm/kvm.c
index 39202d7..55bc3a3 100644
--- a/target-arm/kvm.c
+++ b/target-arm/kvm.c
@@ -27,6 +27,29 @@ const KVMCapabilityInfo kvm_arch_required_capabilities[] = {
 KVM_CAP_LAST_INFO
 };
 
+int kvm_arm_vcpu_init(CPUState *cs, uint32_t feature0_extra)
+{
+ARMCPU *cpu = ARM_CPU(cs);
+struct kvm_vcpu_init init;
+
+if (cpu->kvm_target == QEMU_KVM_ARM_TARGET_NONE) {
+fprintf(stderr, "KVM is not supported for this guest CPU type\n");
+return -EINVAL;
+}
+
+init.target = cpu->kvm_target;
+memset(init.features, 0, sizeof(init.features));
+if (cpu->start_powered_off) {
+init.features[0] |= 1 << KVM_ARM_VCPU_POWER_OFF;
+}
+if (kvm_check_extension(cs->kvm_state, KVM_CAP_ARM_PSCI_0_2)) {
+init.features[0] |= 1 << KVM_ARM_VCPU_PSCI_0_2;
+}
+init.features[0] |= feature0_extra;
+
+return kvm_vcpu_ioctl(cs, KVM_ARM_VCPU_INIT, &init);
+}
+
 bool kvm_arm_create_scratch_host_vcpu(const uint32_t *cpus_to_try,
   int *fdarray,
   struct kvm_vcpu_init *init)
diff --git a/target-arm/kvm32.c b/target-arm/kvm32.c
index cd9ac03..0034248 100644
--- a/target-arm/kvm32.c
+++ b/target-arm/kvm32.c
@@ -166,7 +166,6 @@ static int compare_u64(const void *a, const void *b)
 
 int kvm_arch_init_vcpu(CPUState *cs)
 {
-struct kvm_vcpu_init init;
 int i, ret, arraylen;
 uint64_t v;
 struct kvm_one_reg r;
@@ -174,23 +173,12 @@ int kvm_arch_init_vcpu(CPUState *cs)
 struct kvm_reg_list *rlp;
 ARMCPU *cpu = ARM_CPU(cs);
 
-if (cpu->kvm_target == QEMU_KVM_ARM_TARGET_NONE) {
-fprintf(stderr, "KVM is not supported for this guest CPU type\n");
-return -EINVAL;
-}
-
-init.target = cpu->kvm_target;
-memset(init.features, 0, sizeof(init.features));
-if (cpu->start_powered_off) {
-init.features[0] |= 1 << KVM_ARM_VCPU_POWER_OFF;
-}
-if (kvm_check_extension(cs->kvm_state, KVM_CAP_ARM_PSCI_0_2)) {
-init.features[0] |= 1 << KVM_ARM_VCPU_PSCI_0_2;
-}
-ret = kvm_vcpu_ioctl(cs, KVM_ARM_VCPU_INIT, &init);
+/* Do KVM_ARM_VCPU_INIT ioctl */
+ret = kvm_arm_vcpu_init(cs, 0x0);
 if (ret) {
 return ret;
 }
+
 /* Query the kernel to make sure it supports 32 VFP
  * registers: QEMU's "cortex-a15" CPU is always a
  * VFP-D32 core. The simplest way to do this is just
diff --git a/target-arm/kvm64.c b/target-arm/kvm64.c
index bc6cd74..f7cc3ef 100644
--- a/target-arm/kvm64.c
+++ b/target-arm/kvm64.c
@@ -77,29 +77,23 @@ bool kvm_arm_get_host_cpu_features(ARMHostCPUClass *ahcc)
 
 int kvm_arch_init_vcpu(CPUState *cs)
 {
-ARMCPU *cpu = ARM_CPU(cs);
-struct kvm_vcpu_init init;
 int ret;
+ARMCPU *cpu = ARM_CPU(cs);
 
-if (cpu->kvm_target == QEMU_KVM_ARM_TARGET_NONE ||
-!arm_feature(&cpu->env, ARM_FEATURE_AARCH64)) {
-fprintf(stderr, "KVM is not supported for this guest CPU type\n");
+if (!arm_feature(&cpu->env, ARM_FEATURE_AARCH64)) {
+fprintf(stderr, "KVM only support Aarch64 CPU type\n");
 return -EINVAL;
 }
 
-init.target = cpu->kvm_target;
-memset(init.features, 0, sizeof(init.features));
-if (cpu->start_powered_off) {
-init.features[0] |= 1 << KVM_ARM_VCPU_POWER_OFF;
-}
-if (kvm_check_extension(cs->kvm_state, KVM_CAP_ARM_PSCI_0_2)) {
-init.features[0] |= 1 << KVM_ARM_VCPU_PSCI_0_2;
+/* Do KVM_ARM_VCPU_INIT ioctl */
+ret = kvm_arm_vcpu_init(cs, 0x0);
+if (ret) {
+return ret;
 }
-ret = kvm_vcpu_ioctl(cs, KVM_ARM_VCPU_INIT, &init);
 
 /* TODO : support for save/restore/reset of system regs via tuple list */
 
-return ret;
+return 0;
 }
 
 #define AARCH64_CORE_REG(x)   (KVM_REG_ARM64 | KVM_REG_SIZE_U64 | \
diff --git a/target-arm/kvm_arm.h b/target-arm/kvm_arm.h
index 137c567..1889ba1 100644
--- a/target-arm/kvm_arm.h
+++ b/target-arm/kvm_arm.h
@@ -15,6 +15,20 @@
 #include "exec/memory.h"
 
 /**
+ * kvm_arm_vcpu_init:
+ * @cs: CPUState
+ * @feature0_extra: additional features
+ *
+ * KVM ARM and KVM ARM64 need to use KVM_ARM_VCPU_INIT ioctl for
+ * init/re-init/reset the VCPU with given feature flags.
+ * This is a common function for doing KVM_ARM_VCPU_INIT ioctl
+ * independent of KVM ARM or KVM ARM64.
+ *
+ * Returns: 0 if success else < 0 error code
+ */
+int kvm_arm_vcpu_init(CPUState *cs, uint32_t feature0_extra

[Qemu-devel] [RFC PATCH V4 6/6] target-arm: Implement kvm_arch_reset_vcpu() for KVM ARM64

2014-05-05 Thread Pranavkumar Sawargaonkar
To implement kvm_arch_reset_vcpu(), we simply re-init the VCPU
using kvm_arm_vcpu_init() so that all registers of VCPU are set
to their reset values by in-kernel KVM code.

Signed-off-by: Pranavkumar Sawargaonkar 
Signed-off-by: Anup Patel 
---
 target-arm/kvm64.c |4 
 1 file changed, 4 insertions(+)

diff --git a/target-arm/kvm64.c b/target-arm/kvm64.c
index f7cc3ef..4855b4b 100644
--- a/target-arm/kvm64.c
+++ b/target-arm/kvm64.c
@@ -259,4 +259,8 @@ int kvm_arch_get_registers(CPUState *cs)
 
 void kvm_arch_reset_vcpu(CPUState *cs)
 {
+/* Re-init VCPU so that all registers are set to
+ * their respective reset values.
+ */
+kvm_arm_vcpu_init(cs, 0x0);
 }
-- 
1.7.9.5




Re: [Qemu-devel] [PATCH V26 12/32] change block layer to support both QemuOpts and QEMUOptionParamter

2014-05-05 Thread Chun Yan Liu


>>> On 5/2/2014 at 06:09 AM, in message
<20140501220948.GK29944@dorilex-lnv.MultilaserAP>, Leandro Dorileo
 wrote: 
> Chunyan, 
>  
> On Tue, Apr 29, 2014 at 05:08:21PM +0800, Chunyan Liu wrote: 
> > Change block layer to support both QemuOpts and QEMUOptionParameter. 
> > After this patch, it will change backend drivers one by one. At the end, 
> > QEMUOptionParameter will be removed and only QemuOpts is kept. 
>  
>  
> This patch breaks the tests in the intermediate tree state, when you clean  
> things 
> up in the end of your series most problems this patch introduces are removed  
> as well, 
> I saw problems with 061 which I could easily find the problem (see below)  
> and then 
> I saw an error on 063 with a mem corruption (this last one I had no time to  
> investigate 
> more). 

Fix qemu_opts_append:
g_free(tmp_list) -> qemu_opts_free(tmp_list) 

> Your patch series is looking very good, just take some time to make sure  
> you're not 
> breaking the tests and the build in the intermediate states (on all you  
> patches). 
>  
>  
> >  
> > Signed-off-by: Dong Xu Wang  
> > Signed-off-by: Chunyan Liu  
> > --- 
> > Changes to V25: 
> >   * fix Eric's comments: 
> >   * update bdrv_create_co_entry and bdrv_amend_options code, to let it 
> > more readable. 
> >   * add assertion in bdrv_register. 
> >   * improve comments to create_opts in header file. 
> >  
> >  block.c   | 158 
> > -- 
> >  block/cow.c   |   2 +- 
> >  block/qcow.c  |   2 +- 
> >  block/qcow2.c |   2 +- 
> >  block/qed.c   |   2 +- 
> >  block/raw_bsd.c   |   2 +- 
> >  block/vhdx.c  |   2 +- 
> >  block/vmdk.c  |   4 +- 
> >  block/vvfat.c |   2 +- 
> >  include/block/block.h |   7 +- 
> >  include/block/block_int.h |  13 +++- 
> >  qemu-img.c|  94 +-- 
> >  12 files changed, 180 insertions(+), 110 deletions(-) 
> >  
> > diff --git a/block.c b/block.c 
> > index 4745712..124f045 100644 
> > --- a/block.c 
> > +++ b/block.c 
> > @@ -328,6 +328,13 @@ void bdrv_register(BlockDriver *bdrv) 
> >  } 
> >  } 
> >   
> > +if (bdrv->bdrv_create) { 
> > +assert(!bdrv->bdrv_create2 && !bdrv->create_opts); 
> > +assert(!bdrv->bdrv_amend_options2); 
> > +} else if (bdrv->bdrv_create2) { 
> > +assert(!bdrv->bdrv_create && !bdrv->create_options); 
> > +assert(!bdrv->bdrv_amend_options); 
> > +} 
> >  QLIST_INSERT_HEAD(&bdrv_drivers, bdrv, list); 
> >  } 
> >   
> > @@ -419,6 +426,7 @@ typedef struct CreateCo { 
> >  BlockDriver *drv; 
> >  char *filename; 
> >  QEMUOptionParameter *options; 
> > +QemuOpts *opts; 
> >  int ret; 
> >  Error *err; 
> >  } CreateCo; 
> > @@ -430,8 +438,28 @@ static void coroutine_fn bdrv_create_co_entry(void  
> *opaque) 
> >   
> >  CreateCo *cco = opaque; 
> >  assert(cco->drv); 
> > +assert(!(cco->options && cco->opts)); 
> >   
> > -ret = cco->drv->bdrv_create(cco->filename, cco->options, &local_err); 
> > +if (cco->drv->bdrv_create2) { 
> > +QemuOptsList *opts_list = NULL; 
> > +if (cco->options) { 
> > +opts_list = params_to_opts(cco->options); 
> > +cco->opts = qemu_opts_create(opts_list, NULL, 0, 
> > &error_abort); 
> > +} 
> > +ret = cco->drv->bdrv_create2(cco->filename, cco->opts, 
> > &local_err); 
> > +if (cco->options) { 
> > +qemu_opts_del(cco->opts); 
> > +qemu_opts_free(opts_list); 
> > +} 
> > +} else { 
> > +if (cco->opts) { 
> > +cco->options = opts_to_params(cco->opts); 
> > +} 
> > +ret = cco->drv->bdrv_create(cco->filename, cco->options, 
> > &local_err); 
> > +if (cco->opts) { 
> > +free_option_parameters(cco->options); 
> > +} 
> > +} 
> >  if (local_err) { 
> >  error_propagate(&cco->err, local_err); 
> >  } 
> > @@ -439,7 +467,8 @@ static void coroutine_fn bdrv_create_co_entry(void  
> *opaque) 
> >  } 
> >   
> >  int bdrv_create(BlockDriver *drv, const char* filename, 
> > -QEMUOptionParameter *options, Error **errp) 
> > +QEMUOptionParameter *options, 
> > +QemuOpts *opts, Error **errp) 
> >  { 
> >  int ret; 
> >   
> > @@ -448,11 +477,12 @@ int bdrv_create(BlockDriver *drv, const char*  
> filename, 
> >  .drv = drv, 
> >  .filename = g_strdup(filename), 
> >  .options = options, 
> > +.opts = opts, 
> >  .ret = NOT_DONE, 
> >  .err = NULL, 
> >  }; 
> >   
> > -if (!drv->bdrv_create) { 
> > +if (!drv->bdrv_create && !drv->bdrv_create2) { 
> >  error_setg(errp, "Driver '%s' does not support image creation",  
> drv->format_name); 
> >  ret = -ENOTSUP; 
> >  goto out; 
> > @@ -

Re: [Qemu-devel] [Qemu-trivial] [PATCH] qmp: Report path ambiguity error.

2014-05-05 Thread Michael Tokarev
03.05.2014 12:38, Michael Tokarev wrote:
[]
> --- a/qmp.c
> +++ b/qmp.c
> @@ -200,7 +200,9 @@ ObjectPropertyInfoList *qmp_qom_list(const char *path, 
> Error **errp)
> 
>  obj = object_resolve_path(path, &ambiguous);
>  if (obj == NULL) {
> -error_set(errp, QERR_DEVICE_NOT_FOUND, path);
> +error_set(errp,
> +  ambiguous ? "Path '%s' is ambiguous" : 
> QERR_DEVICE_NOT_FOUND,
> +  path);
>  return NULL;
>  }

I've applied this version.

Thanks,

/mjt



[Qemu-devel] E1000 emulation in qemu and pci configuration space

2014-05-05 Thread Ayaz Akram
Does e1000's emulation in QEMU require that the guest set its base address
register(pci configuration space register) or qemu has default value for
its base address register?


Re: [Qemu-devel] [PATCH] migration: Increase default max_downtime from 30ms to 300ms

2014-05-05 Thread Alexey Kardashevskiy
On 04/30/2014 11:10 AM, Alexey Kardashevskiy wrote:
> On 04/13/2014 12:38 AM, Alexey Kardashevskiy wrote:
>> On 03/27/2014 08:01 PM, Markus Armbruster wrote:
>>> Adding Juan.
>>
>>
>> Ping?
> 
> 
> Ping?
> 
> 

Ping?


>>
>>>
>>> Alexey Kardashevskiy  writes:
>>>
 The existing timeout is 30ms which on 100MB/s (1Gbit) gives us
 3MB/s rate maximum. If we put some load on the guest, it is easy to
 get page dirtying rate too big so live migration will never complete.
 In the case of libvirt that means that the guest will be stopped
 anyway after a timeout specified in the "virsh migrate" command and
 this normally generates even bigger delay.

 This changes max_downtime to 300ms which seems to be more
 reasonable value.

 Signed-off-by: Alexey Kardashevskiy 
 ---
  migration.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/migration.c b/migration.c
 index e0e24d4..02bbce9 100644
 --- a/migration.c
 +++ b/migration.c
 @@ -144,7 +144,7 @@ void process_incoming_migration(QEMUFile *f)
   * the choice of nanoseconds is because it is the maximum resolution that
   * get_clock() can achieve. It is an internal measure. All user-visible
   * units must be in seconds */
 -static uint64_t max_downtime = 3000;
 +static uint64_t max_downtime = 3;
  
  uint64_t migrate_max_downtime(void)
  {
>>
>>
> 
> 


-- 
Alexey



Re: [Qemu-devel] [PATCH 00/22] dataplane: use QEMU block layer

2014-05-05 Thread Christian Borntraeger
On 01/05/14 16:54, Stefan Hajnoczi wrote:
> This patch series switches virtio-blk data-plane from a custom Linux AIO
> request queue to the QEMU block layer.  The previous "raw files only"
> limitation is lifted.  All image formats and protocols can now be used with
> virtio-blk data-plane.

Nice. Is there a git branch somewhere, so that we can test this on s390?

Christian
> 
> How to review this series
> -
> I CCed the maintainer of each block driver that I modified.  You probably 
> don't
> need to review the entire series, just your patch.
> 
> From now on fd handlers, timers, BHs, and event loop wait must explicitly use
> BlockDriverState's AioContext instead of the main loop.  Use
> bdrv_get_aio_context(bs) to get the AioContext.  The following function calls
> need to be converted:
> 
>  * qemu_aio_set_fd_handler() -> aio_set_fd_handler()
>  * timer_new*() -> aio_timer_new()
>  * qemu_bh_new() -> aio_bh_new()
>  * qemu_aio_wait() -> aio_poll(aio_context, true)
> 
> For simple block drivers this modification suffices and it is now safe to use
> outside the QEMU global mutex.
> 
> Block drivers that keep fd handlers, timers, or BHs registered when requests
> have been drained need a little bit more work.  Examples of this are network
> block drivers with keepalive timers, like iSCSI.
> 
> This series adds a new bdrv_set_aio_context(bs, aio_context) function that
> moves a BlockDriverState into a new AioContext.  This function calls the block
> driver's optional .bdrv_detach_aio_context() and .bdrv_attach_aio_context()
> functions.  Implement detach/attach to move the fd handlers, timers, or BHs to
> the new AioContext.
> 
> Finally, block drivers that manage their own child nodes also need to
> implement detach/attach because the generic block layer doesn't know about
> their children.  Both ->file and ->backing_hd are automatically taken care of
> but blkverify, quorum, and VMDK need to manually propagate detach/attach to
> their children.
> 
> I have audited and modified all block drivers.  Block driver maintainers,
> please check I did it correctly and didn't break your code.
> 
> Background
> --
> The block layer is currently tied to the QEMU main loop for fd handlers, timer
> callbacks, and BHs.  This means that even on hosts with many cores, parts of
> block I/O processing happen in one thread and depend on the QEMU global mutex.
> 
> virtio-blk data-plane has shown that 1,000,000 IOPS is achievable if we use
> additional threads that are not under the QEMU global mutex.
> 
> It is necessary to make the QEMU block layer aware that there may be more than
> one event loop.  This way BlockDriverState can be used from a thread without
> contention on the QEMU global mutex.
> 
> This series builds on the aio_context_acquire/release() interface that allows 
> a
> thread to temporarily grab an AioContext.  We add bdrv_set_aio_context(bs,
> aio_context) for changing which AioContext a BlockDriverState uses.
> 
> The final patches convert virtio-blk data-plane to use the QEMU block layer 
> and
> let the BlockDriverState run in the IOThread AioContext.
> 
> What's next?
> 
> I have already made block I/O throttling work in another AioContext and will
> send the series out next week.
> 
> In order to keep this series reviewable, I'm holding back those patches for
> now.  One could say, "throttling" them.
> 
> Thank you, thank you, I'll be here all night!
> 
> Stefan Hajnoczi (22):
>   block: use BlockDriverState AioContext
>   block: acquire AioContext in bdrv_close_all()
>   block: add bdrv_set_aio_context()
>   blkdebug: use BlockDriverState's AioContext
>   blkverify: implement .bdrv_detach/attach_aio_context()
>   curl: implement .bdrv_detach/attach_aio_context()
>   gluster: use BlockDriverState's AioContext
>   iscsi: implement .bdrv_detach/attach_aio_context()
>   nbd: implement .bdrv_detach/attach_aio_context()
>   nfs: implement .bdrv_detach/attach_aio_context()
>   qed: use BlockDriverState's AioContext
>   quorum: implement .bdrv_detach/attach_aio_context()
>   block/raw-posix: implement .bdrv_detach/attach_aio_context()
>   block/linux-aio: fix memory and fd leak
>   rbd: use BlockDriverState's AioContext
>   sheepdog: implement .bdrv_detach/attach_aio_context()
>   ssh: use BlockDriverState's AioContext
>   vmdk: implement .bdrv_detach/attach_aio_context()
>   dataplane: use the QEMU block layer for I/O
>   dataplane: delete IOQueue since it is no longer used
>   dataplane: implement async flush
>   raw-posix: drop raw_get_aio_fd() since it is no longer used
> 
>  block.c  |  88 +--
>  block/blkdebug.c |   2 +-
>  block/blkverify.c|  47 +---
>  block/curl.c | 194 +++-
>  block/gluster.c  |   7 +-
>  block/iscsi.c|  79 +
>  block/linux-aio.c|  24 +++-
>  block/nbd-clien

[Qemu-devel] [PATCH] readline: use g_strndup instead of open-coding it

2014-05-05 Thread Michael Tokarev
Signed-off-by: Michael Tokarev 
---
 util/readline.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/util/readline.c b/util/readline.c
index 8441be4..a3fd2cb 100644
--- a/util/readline.c
+++ b/util/readline.c
@@ -279,9 +279,7 @@ static void readline_completion(ReadLineState *rs)
 
 rs->nb_completions = 0;
 
-cmdline = g_malloc(rs->cmd_buf_index + 1);
-memcpy(cmdline, rs->cmd_buf, rs->cmd_buf_index);
-cmdline[rs->cmd_buf_index] = '\0';
+cmdline = g_strndup(rs->cmd_buf, rs->cmd_buf_index);
 rs->completion_finder(rs->opaque, cmdline);
 g_free(cmdline);
 
-- 
1.7.10.4




Re: [Qemu-devel] [Qemu-trivial] [PATCH] qmp: Report path ambiguity error.

2014-05-05 Thread Andreas Färber
Am 05.05.2014 11:12, schrieb Michael Tokarev:
> 03.05.2014 12:38, Michael Tokarev wrote:
> []
>> --- a/qmp.c
>> +++ b/qmp.c
>> @@ -200,7 +200,9 @@ ObjectPropertyInfoList *qmp_qom_list(const char *path, 
>> Error **errp)
>>
>>  obj = object_resolve_path(path, &ambiguous);
>>  if (obj == NULL) {
>> -error_set(errp, QERR_DEVICE_NOT_FOUND, path);
>> +error_set(errp,
>> +  ambiguous ? "Path '%s' is ambiguous" : 
>> QERR_DEVICE_NOT_FOUND,
>> +  path);
>>  return NULL;
>>  }
> 
> I've applied this version.

Please undo. error_set() unlike error_setg() expects an ErrorClass
argument before the string. QERR_* macro contains *two* comma-separated
values, so it is on top filling in the device-not-found message as path
in the ambiguous case.

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 1/3] curl: Fix parsing of readahead option from filename

2014-05-05 Thread Kevin Wolf
Am 01.05.2014 um 10:56 hat Matthew Booth geschrieben:
> On 30/04/14 16:16, Kevin Wolf wrote:
> > Am 30.04.2014 um 16:20 hat Matthew Booth geschrieben:
> >> curl_parse_filename wasn't removing the option string from the url,
> >> resulting in a 404.
> >>
> >> This change is a essentially a rewrite of that function as I also need
> >> to extend it to handle more options. The rewrite is also much easier
> >> to read.
> >>
> >> Signed-off-by: Matthew Booth 
> >> ---
> >>  block/curl.c | 81 
> >> ++--
> >>  1 file changed, 52 insertions(+), 29 deletions(-)
> >>
> >> diff --git a/block/curl.c b/block/curl.c
> >> index d2f1084..4de6856 100644
> >> --- a/block/curl.c
> >> +++ b/block/curl.c
> >> @@ -46,12 +46,15 @@
> >>  #define CURL_NUM_STATES 8
> >>  #define CURL_NUM_ACB8
> >>  #define SECTOR_SIZE 512
> >> -#define READ_AHEAD_SIZE (256 * 1024)
> >> +#define READ_AHEAD_DEFAULT (256 * 1024)
> >>  
> >>  #define FIND_RET_NONE   0
> >>  #define FIND_RET_OK 1
> >>  #define FIND_RET_WAIT   2
> >>  
> >> +#define CURL_BLOCK_OPT_URL   "url"
> >> +#define CURL_BLOCK_OPT_READAHEAD "readahead"
> >> +
> >>  struct BDRVCURLState;
> >>  
> >>  typedef struct CURLAIOCB {
> >> @@ -396,41 +399,60 @@ static void curl_clean_state(CURLState *s)
> >>  static void curl_parse_filename(const char *filename, QDict *options,
> >>  Error **errp)
> >>  {
> >> -
> >> -#define RA_OPTSTR ":readahead="
> >>  char *file;
> >> -char *ra;
> >> -const char *ra_val;
> >> -int parse_state = 0;
> >> +char *end;
> >>  
> >>  file = g_strdup(filename);
> >> +end = file + strlen(file) - 1;
> >> +
> >> +/* Don't fail if we've been passed an empty string.
> >> + * Only examine strings with a trailing ':'
> >> + */
> >> +if (end >= file && *end == ':') {
> >> +/* We exit this loop when we don't find a recognised option 
> >> immediately
> >> + * preceding the trailing ':' of the form ':='
> >> + *
> >> + * If filename has a trailing ':' but no preceding options, we 
> >> don't
> >> + * remove the trailing ':'.
> >> + */
> >> +for (;;) {
> >> +/* Look for the preceding colon */
> >> +char *colon = memrchr(file, ':', end - file);
> >> +if (NULL == colon) {
> >> +break;
> >> +}
> >>  
> >> -/* Parse a trailing ":readahead=#:" param, if present. */
> >> -ra = file + strlen(file) - 1;
> >> -while (ra >= file) {
> >> -if (parse_state == 0) {
> >> -if (*ra == ':') {
> >> -parse_state++;
> >> -} else {
> >> +char *opt_start = colon + 1;
> >> +
> >> +/* Look for an equals sign */
> >> +char *equals = memchr(opt_start, '=', end - opt_start);
> >> +if (NULL == equals) {
> >>  break;
> >>  }
> >> -} else if (parse_state == 1) {
> >> -if (*ra > '9' || *ra < '0') {
> >> -char *opt_start = ra - strlen(RA_OPTSTR) + 1;
> >> -if (opt_start > file &&
> >> -strncmp(opt_start, RA_OPTSTR, strlen(RA_OPTSTR)) == 
> >> 0) {
> >> -ra_val = ra + 1;
> >> -ra -= strlen(RA_OPTSTR) - 1;
> >> -*ra = '\0';
> >> -qdict_put(options, "readahead", 
> >> qstring_from_str(ra_val));
> >> -}
> >> +
> >> +size_t opt_len = equals - opt_start;
> >> +char *value = equals + 1;
> >> +size_t value_len = end - value;
> >> +
> >> +if (opt_len == strlen(CURL_BLOCK_OPT_READAHEAD) &&
> >> +memcmp(opt_start, CURL_BLOCK_OPT_READAHEAD, opt_len) == 
> >> 0) {
> >> +/* This is redundant after the first iteration */
> >> +*end = '\0';
> >> +qdict_put(options, CURL_BLOCK_OPT_READAHEAD,
> >> +  qstring_from_str(value));
> >> +} else {
> >> +/* Unknown option */
> >>  break;
> > 
> > So if we get an unknown option, we simply abort parsing the filename.
> > This means that we'll try to open a URL that still contains an option
> > and will probably fail with a rather confusing error message.
> > 
> > Shouldn't we set a clear error message about the unknown option here
> > with error_setg() and immediately return?
> 
> TBH I was just trying to stay compatible with the behaviour which most
> recently worked. Hence the weirdness with the trailing ':', for example.
> 
> I did consider whether to do ignore these options or not. I decided to
> ignore them because the option syntax isn't safe: the string
> ':readahead=1k:' could be found at the end of a valid URL. Ignoring
> unknown options reduces the chances of a false positive. For example, in:
> 
> http://example.com/path?query=fo

Re: [Qemu-devel] [Qemu-trivial] [PATCH] readline: Sort completions before printing them.

2014-05-05 Thread Michael Tokarev
Applied to -trivial, thank you!

/mjt



Re: [Qemu-devel] [Qemu-trivial] [PATCH] qmp: Report path ambiguity error.

2014-05-05 Thread Michael Tokarev
05.05.2014 13:26, Andreas Färber пишет:
>> 03.05.2014 12:38, Michael Tokarev wrote:

>>> +error_set(errp,
>>> +  ambiguous ? "Path '%s' is ambiguous" : 
>>> QERR_DEVICE_NOT_FOUND,
>>> +  path);

>> I've applied this version.
> 
> Please undo. error_set() unlike error_setg() expects an ErrorClass
> argument before the string. QERR_* macro contains *two* comma-separated
> values, so it is on top filling in the device-not-found message as path
> in the ambiguous case.

Heh, I havent tried to compile it yet ;)  Ofcourse I'd find this out before
sending the pull request.  Actually this is a classic ENOCOFFEE, twice.

I'll fix this for real.  This makes way too many iterations.

/mjt




Re: [Qemu-devel] [PATCH] qcow2: Fix alloc_clusters_noref() overflow detection

2014-05-05 Thread Kevin Wolf
Am 04.05.2014 um 05:31 hat Max Reitz geschrieben:
> If the very first allocation has a length of 0, the free_cluster_index
> is still 0 after the for loop, which means that subtracting one from it
> will underflow and signal an invalid range of clusters by returning
> -EFBIG. However, there is no such range, as its length is 0.
> 
> Fix this by preventing underflows on free_cluster_index during the
> check.
> 
> Signed-off-by: Max Reitz 

Heh, I wondered about this when I reviewed that other patch, and came to
the conclusion that it probably doesn't happen. Did you find a case
where it does happen in fact?

Anyway, this can't hurt:

Reviewed-by: Kevin Wolf 



Re: [Qemu-devel] [PATCH] qmp: Report path ambiguity error.

2014-05-05 Thread Andreas Färber
Am 29.04.2014 00:46, schrieb Hani Benhabiles:
> Signed-off-by: Hani Benhabiles 
> Suggested-by: Andreas Färber 
> ---
>  qmp.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/qmp.c b/qmp.c
> index 74107be..0d49abf 100644
> --- a/qmp.c
> +++ b/qmp.c
> @@ -199,7 +199,10 @@ ObjectPropertyInfoList *qmp_qom_list(const char *path, 
> Error **errp)
>  ObjectProperty *prop;
>  
>  obj = object_resolve_path(path, &ambiguous);
> -if (obj == NULL) {
> +if (ambiguous) {
> +error_setg(errp, "Path '%s' is ambiguous", path);
> +return NULL;
> +} else if (obj == NULL) {
>  error_set(errp, QERR_DEVICE_NOT_FOUND, path);
>  return NULL;
>  }

This is not quite what I suggested, but assuming bool ambiguous gets
initialized to false, this variant should work too.

Hani, please note that your Signed-off-by should be the last line in the
commit message. No need to resend just for that. I'll try to dig out the
code for a proper Rb later.

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] readline: use g_strndup instead of open-coding it

2014-05-05 Thread Andreas Färber
Am 05.05.2014 11:25, schrieb Michael Tokarev:
> Signed-off-by: Michael Tokarev 
> ---
>  util/readline.c |4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/util/readline.c b/util/readline.c
> index 8441be4..a3fd2cb 100644
> --- a/util/readline.c
> +++ b/util/readline.c
> @@ -279,9 +279,7 @@ static void readline_completion(ReadLineState *rs)
>  
>  rs->nb_completions = 0;
>  
> -cmdline = g_malloc(rs->cmd_buf_index + 1);
> -memcpy(cmdline, rs->cmd_buf, rs->cmd_buf_index);
> -cmdline[rs->cmd_buf_index] = '\0';
> +cmdline = g_strndup(rs->cmd_buf, rs->cmd_buf_index);
>  rs->completion_finder(rs->opaque, cmdline);
>  g_free(cmdline);
>  

Reviewed-by: Andreas Färber 

Andreas

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



[Qemu-devel] [PATCH v3] qmp: report path ambiguity error

2014-05-05 Thread Michael Tokarev
Without this, ambiguous path is reported to the user as
"not found", which is confusing at least.

Signed-off-by: Michael Tokarev 
---
 qmp.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/qmp.c b/qmp.c
index 74107be..37bd7dc 100644
--- a/qmp.c
+++ b/qmp.c
@@ -200,7 +200,11 @@ ObjectPropertyInfoList *qmp_qom_list(const char *path, 
Error **errp)
 
 obj = object_resolve_path(path, &ambiguous);
 if (obj == NULL) {
-error_set(errp, QERR_DEVICE_NOT_FOUND, path);
+if (ambiguous) {
+error_setg(errp, "Path '%s' is ambiguous", path);
+} else {
+error_set(errp, QERR_DEVICE_NOT_FOUND, path);
+}
 return NULL;
 }
 
-- 
1.7.10.4




Re: [Qemu-devel] [PATCH] linux-user: fix getrusage and wait4 failures with invalid rusage struct

2014-05-05 Thread Petar Jovanovic
ping

http://patchwork.ozlabs.org/patch/337703/


From: Petar Jovanovic [petar.jovano...@rt-rk.com]
Sent: Tuesday, April 08, 2014 7:24 PM
To: qemu-devel@nongnu.org
Cc: Petar Jovanovic; riku.voi...@linaro.org
Subject: [PATCH] linux-user: fix getrusage and wait4 failures with invalid 
rusage struct

From: Petar Jovanovic 

Implementations of system calls getrusage and wait4 have not previously
handled correctly cases when incorrect address of struct rusage is
passed.
This change makes sure return values are correctly set for these cases.

Signed-off-by: Petar Jovanovic 
---
 linux-user/syscall.c |   11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 9864813..fc52f0b 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -6309,7 +6309,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
 struct rusage rusage;
 ret = get_errno(getrusage(arg1, &rusage));
 if (!is_error(ret)) {
-host_to_target_rusage(arg2, &rusage);
+ret = host_to_target_rusage(arg2, &rusage);
 }
 }
 break;
@@ -6974,6 +6974,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
 abi_long status_ptr = arg2;
 struct rusage rusage, *rusage_ptr;
 abi_ulong target_rusage = arg4;
+abi_long rusage_err;
 if (target_rusage)
 rusage_ptr = &rusage;
 else
@@ -6985,8 +6986,12 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
arg1,
 if (put_user_s32(status, status_ptr))
 goto efault;
 }
-if (target_rusage)
-host_to_target_rusage(target_rusage, &rusage);
+if (target_rusage) {
+rusage_err = host_to_target_rusage(target_rusage, &rusage);
+if (rusage_err) {
+ret = rusage_err;
+}
+}
 }
 }
 break;
--
1.7.9.5




Re: [Qemu-devel] [PATCH v2 2/2] qapi: Allow setting default values for optional parameters

2014-05-05 Thread Markus Armbruster
Eric Blake  writes:

> On 04/29/2014 05:24 AM, Kevin Wolf wrote:
>> Am 29.04.2014 um 11:44 hat Fam Zheng geschrieben:
>>> In command definition, 'defaults' is now parsed as a dict of default
>>> values. Only optional parameters will have effect in generated code.
>>>
>>> 'str' and 'int' are supported. In generated code, 'str' will be
>>> converted to g_strdup'ed string pointer, 'int' will be identically
>>> assigned.
>>>
>
>>>   { 'command': 'my-command',
>>> -   'data': { 'arg1': 'str', '*arg2': 'str' },
>>> +   'data': { 'arg1': 'str', '*arg2': 'str', '*arg3': 'int' },
>>> +   'defaults': { 'arg2': 'default value for arg2', 'arg3': 12345 },
>>> 'returns': 'str' }
>> 
>> I think we should document what effect setting a default has for the
>> code generation, and that it can be left out even for optional arguments
>> (because your example sets it for every optional member).
>
> That includes documenting that omitting a defaults entry for an optional
> parameter will now guarantee 0-initialization of that member.

Currently, an optional FOO should only be used when has_FOO.  We
initialize it anyway, to suppress complaints from static analyzers.

Do we want to relax the rule "officially", so that code can rely on
zero-initialization instead of checking has_FOO?

>> Also, for the actual qmp_foo() handler, I would very much prefer if it
>> didn't get a has_foo argument which is meaningless because it is always
>> true. Instead, the has_foo argument shouldn't even be generated in the
>> first place if the schema has a default for foo.
>
> Yes, that's a nice idea - anywhere we have a qapi-documented default, we
> can simplify the code to take advantage of the default.  It's backward
> compatible since none of the existing code has any contract on defaults.

s/can simplify/should simplify/!  Defining a default value for FOO
renders anything guarded by !has_FOO dead code.  Not generating has_FOO
is good, because it forces us to bury the dead code properly.

Losely related: I want to get rid of has_FOO for pointer-valued FOOs,
too.

> Also, is the default value allowed to change between qemu versions?
> What are the back-compat ramifications if two different releases want to
> tweak an omitted variable to different defaults?  The documentation
> should mention the rule of thumb that we plan on enforcing during
> reviews.  I could go either way: the wire format is unimpacted by what
> default value is used when an argument is omitted, and management can
> always explicitly specify a parameter if they don't trust the default;
> on the other hand, if changing a default changes visible behavior, then
> we have not maintained ABI compatibility.

We should use common sense.

Changing the schema in a way that alters the meaning of existing usage
is a no-no, and that applies to defaults as much as to anything else.
But not every change of a default necessarily does that.  Contrieved
example: if the value defines a buffer size, and it's specified to
default to a sensible size, then we can and should let the default value
evolve along with our idea of what a sensible size is.



Re: [Qemu-devel] [PATCH] linux-user: fix getrusage and wait4 failures with invalid rusage struct

2014-05-05 Thread Andreas Färber
Am 08.04.2014 19:24, schrieb Petar Jovanovic:
> From: Petar Jovanovic 
> 
> Implementations of system calls getrusage and wait4 have not previously
> handled correctly cases when incorrect address of struct rusage is
> passed.
> This change makes sure return values are correctly set for these cases.
> 
> Signed-off-by: Petar Jovanovic 
> ---
>  linux-user/syscall.c |   11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index 9864813..fc52f0b 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -6309,7 +6309,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
> arg1,
>  struct rusage rusage;
>  ret = get_errno(getrusage(arg1, &rusage));
>  if (!is_error(ret)) {
> -host_to_target_rusage(arg2, &rusage);
> +ret = host_to_target_rusage(arg2, &rusage);
>  }
>  }
>  break;

Why do you always set ret here ...

> @@ -6974,6 +6974,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
> arg1,
>  abi_long status_ptr = arg2;
>  struct rusage rusage, *rusage_ptr;
>  abi_ulong target_rusage = arg4;
> +abi_long rusage_err;
>  if (target_rusage)
>  rusage_ptr = &rusage;
>  else
> @@ -6985,8 +6986,12 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
> arg1,
>  if (put_user_s32(status, status_ptr))
>  goto efault;
>  }
> -if (target_rusage)
> -host_to_target_rusage(target_rusage, &rusage);
> +if (target_rusage) {
> +rusage_err = host_to_target_rusage(target_rusage, 
> &rusage);
> +if (rusage_err) {
> +ret = rusage_err;
> +}
> +}
>  }
>  }
>  break;

... but only on error here? Isn't obvious from the commit message.

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] [RFC PATCH V4 6/6] target-arm: Implement kvm_arch_reset_vcpu() for KVM ARM64

2014-05-05 Thread Andreas Färber
Am 05.05.2014 11:01, schrieb Pranavkumar Sawargaonkar:
> To implement kvm_arch_reset_vcpu(), we simply re-init the VCPU
> using kvm_arm_vcpu_init() so that all registers of VCPU are set
> to their reset values by in-kernel KVM code.
> 
> Signed-off-by: Pranavkumar Sawargaonkar 
> Signed-off-by: Anup Patel 
> ---
>  target-arm/kvm64.c |4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/target-arm/kvm64.c b/target-arm/kvm64.c
> index f7cc3ef..4855b4b 100644
> --- a/target-arm/kvm64.c
> +++ b/target-arm/kvm64.c
> @@ -259,4 +259,8 @@ int kvm_arch_get_registers(CPUState *cs)
>  
>  void kvm_arch_reset_vcpu(CPUState *cs)
>  {
> +/* Re-init VCPU so that all registers are set to
> + * their respective reset values.
> + */
> +kvm_arm_vcpu_init(cs, 0x0);
>  }
> 

CC'ing Paolo, who was about to drop kvm_arch_reset_vcpu().

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] [RFC PATCH V4 5/6] target-arm: Common kvm_arm_vcpu_init() for KVM ARM and KVM ARM64

2014-05-05 Thread Andreas Färber
Am 05.05.2014 11:00, schrieb Pranavkumar Sawargaonkar:
> Introduce a common kvm_arm_vcpu_init() for doing KVM_ARM_VCPU_INIT
> ioctl in KVM ARM and KVM ARM64. This also helps us factor-out few
> common code lines from kvm_arch_init_vcpu() for KVM ARM/ARM64.
> 
> Signed-off-by: Pranavkumar Sawargaonkar 
> Signed-off-by: Anup Patel 
> ---
>  target-arm/kvm.c |   23 +++
>  target-arm/kvm32.c   |   18 +++---
>  target-arm/kvm64.c   |   22 --
>  target-arm/kvm_arm.h |   14 ++
>  4 files changed, 48 insertions(+), 29 deletions(-)
> 
> diff --git a/target-arm/kvm.c b/target-arm/kvm.c
> index 39202d7..55bc3a3 100644
> --- a/target-arm/kvm.c
> +++ b/target-arm/kvm.c
> @@ -27,6 +27,29 @@ const KVMCapabilityInfo kvm_arch_required_capabilities[] = 
> {
>  KVM_CAP_LAST_INFO
>  };
>  
> +int kvm_arm_vcpu_init(CPUState *cs, uint32_t feature0_extra)

Since this is ARM-specific code and both kvm_arch_* implementations cast
it, you could use an ARMCPU *cpu argument - but as you need cs for the
ioctl, it's no net win, so your/PMM's choice.

Apart from that, refactoring looks fine to me.

Cleaning up the fprintf() moved will hopefully be done independently.

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] linux-user: fix getrusage and wait4 failures with invalid rusage struct

2014-05-05 Thread Petar Jovanovic


From: Andreas Färber [afaer...@suse.de]
Sent: Monday, May 05, 2014 11:55 AM
To: Petar Jovanovic; qemu-devel@nongnu.org
Cc: riku.voi...@linaro.org; Petar Jovanovic
Subject: Re: [Qemu-devel] [PATCH] linux-user: fix getrusage and wait4 failures 
with invalid rusage struct

Am 08.04.2014 19:24, schrieb Petar Jovanovic:
> From: Petar Jovanovic 
>
> Implementations of system calls getrusage and wait4 have not previously
> handled correctly cases when incorrect address of struct rusage is
> passed.
> This change makes sure return values are correctly set for these cases.
>
> Signed-off-by: Petar Jovanovic 
> ---
>  linux-user/syscall.c |   11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index 9864813..fc52f0b 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -6309,7 +6309,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
> arg1,
>  struct rusage rusage;
>  ret = get_errno(getrusage(arg1, &rusage));
>  if (!is_error(ret)) {
> -host_to_target_rusage(arg2, &rusage);
> +ret = host_to_target_rusage(arg2, &rusage);
>  }
>  }
>  break;

> Why do you always set ret here ...

> @@ -6974,6 +6974,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
> arg1,
>  abi_long status_ptr = arg2;
>  struct rusage rusage, *rusage_ptr;
>  abi_ulong target_rusage = arg4;
> +abi_long rusage_err;
>  if (target_rusage)
>  rusage_ptr = &rusage;
>  else
> @@ -6985,8 +6986,12 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
> arg1,
>  if (put_user_s32(status, status_ptr))
>  goto efault;
>  }
> -if (target_rusage)
> -host_to_target_rusage(target_rusage, &rusage);
> +if (target_rusage) {
> +rusage_err = host_to_target_rusage(target_rusage, 
> &rusage);
> +if (rusage_err) {
> +ret = rusage_err;
> +}
> +}
>  }
>  }
>  break;

> ... but only on error here? Isn't obvious from the commit message.

This is due to the fact that on success, wait4() returns the process ID
of the child whose state has changed. So, the code needs to take care
not to override it.

Regards,
Petar




Re: [Qemu-devel] [RFC PATCH V4 6/6] target-arm: Implement kvm_arch_reset_vcpu() for KVM ARM64

2014-05-05 Thread Paolo Bonzini

Il 05/05/2014 11:57, Andreas Färber ha scritto:

Am 05.05.2014 11:01, schrieb Pranavkumar Sawargaonkar:

To implement kvm_arch_reset_vcpu(), we simply re-init the VCPU
using kvm_arm_vcpu_init() so that all registers of VCPU are set
to their reset values by in-kernel KVM code.

Signed-off-by: Pranavkumar Sawargaonkar 
Signed-off-by: Anup Patel 
---
 target-arm/kvm64.c |4 
 1 file changed, 4 insertions(+)

diff --git a/target-arm/kvm64.c b/target-arm/kvm64.c
index f7cc3ef..4855b4b 100644
--- a/target-arm/kvm64.c
+++ b/target-arm/kvm64.c
@@ -259,4 +259,8 @@ int kvm_arch_get_registers(CPUState *cs)

 void kvm_arch_reset_vcpu(CPUState *cs)
 {
+/* Re-init VCPU so that all registers are set to
+ * their respective reset values.
+ */
+kvm_arm_vcpu_init(cs, 0x0);
 }



CC'ing Paolo, who was about to drop kvm_arch_reset_vcpu().


No big deal, it will have a small conflict but the functionality will 
remain in ARM (just renamed to kvm_arm_reset_vcpu and taking an ARMCPU*).


Thanks for the heads up.

Paolo



Re: [Qemu-devel] [PATCH] docs/memory.txt: Fix document on MMIO operations

2014-05-05 Thread Peter Maydell
On 5 May 2014 08:53, Fam Zheng  wrote:
> .impl.valid should be .impl.unaligned and the description needs some
> fixes.
>
> .old_portio is removed since commit b40acf99b (ioport: Switch
> dispatching to memory core layer).

I've already sent a patch for that part, which mjt has applied
to the trivial branch :

http://patchwork.ozlabs.org/patch/343332/

so this patch is going to cause a merge conflict with that
if Paolo takes it via a different tree.

thanks
-- PMM



Re: [Qemu-devel] [RFC PATCH V4 5/6] target-arm: Common kvm_arm_vcpu_init() for KVM ARM and KVM ARM64

2014-05-05 Thread Peter Maydell
On 5 May 2014 10:00, Pranavkumar Sawargaonkar  wrote:
> Introduce a common kvm_arm_vcpu_init() for doing KVM_ARM_VCPU_INIT
> ioctl in KVM ARM and KVM ARM64. This also helps us factor-out few
> common code lines from kvm_arch_init_vcpu() for KVM ARM/ARM64.
>
> Signed-off-by: Pranavkumar Sawargaonkar 
> Signed-off-by: Anup Patel 
> ---
>  target-arm/kvm.c |   23 +++
>  target-arm/kvm32.c   |   18 +++---
>  target-arm/kvm64.c   |   22 --
>  target-arm/kvm_arm.h |   14 ++
>  4 files changed, 48 insertions(+), 29 deletions(-)
>
> diff --git a/target-arm/kvm.c b/target-arm/kvm.c
> index 39202d7..55bc3a3 100644
> --- a/target-arm/kvm.c
> +++ b/target-arm/kvm.c
> @@ -27,6 +27,29 @@ const KVMCapabilityInfo kvm_arch_required_capabilities[] = 
> {
>  KVM_CAP_LAST_INFO
>  };
>
> +int kvm_arm_vcpu_init(CPUState *cs, uint32_t feature0_extra)
> +{
> +ARMCPU *cpu = ARM_CPU(cs);
> +struct kvm_vcpu_init init;
> +
> +if (cpu->kvm_target == QEMU_KVM_ARM_TARGET_NONE) {
> +fprintf(stderr, "KVM is not supported for this guest CPU type\n");
> +return -EINVAL;
> +}
> +
> +init.target = cpu->kvm_target;
> +memset(init.features, 0, sizeof(init.features));
> +if (cpu->start_powered_off) {
> +init.features[0] |= 1 << KVM_ARM_VCPU_POWER_OFF;
> +}
> +if (kvm_check_extension(cs->kvm_state, KVM_CAP_ARM_PSCI_0_2)) {
> +init.features[0] |= 1 << KVM_ARM_VCPU_PSCI_0_2;
> +}
> +init.features[0] |= feature0_extra;
> +
> +return kvm_vcpu_ioctl(cs, KVM_ARM_VCPU_INIT, &init);
> +}

I said back in the review comments for v2 of this series that we
didn't need to do all this just for reset. Put the features word in
cpu along with kvm_target:
http://patchwork.ozlabs.org/patch/335900/

thanks
-- PMM



Re: [Qemu-devel] [PATCH] docs/memory.txt: Fix document on MMIO operations

2014-05-05 Thread Fam Zheng
On Mon, 05/05 11:41, Peter Maydell wrote:
> On 5 May 2014 08:53, Fam Zheng  wrote:
> > .impl.valid should be .impl.unaligned and the description needs some
> > fixes.
> >
> > .old_portio is removed since commit b40acf99b (ioport: Switch
> > dispatching to memory core layer).
> 
> I've already sent a patch for that part, which mjt has applied
> to the trivial branch :
> 
> http://patchwork.ozlabs.org/patch/343332/
> 
> so this patch is going to cause a merge conflict with that
> if Paolo takes it via a different tree.
> 
> thanks
> -- PMM

I overlooked that one. I'll respin to base on your patch and send for -trivial,
so Paolo could drop it.

Thanks,
Fam



Re: [Qemu-devel] [PULL 0/7] smbios: make qemu generate smbios tables.

2014-05-05 Thread Gerd Hoffmann
  Hi,

> I'm afraid this doesn't compile:

/me goes add a -m32 build to the test matrix.

Hmm, looks like "make check" has issues on 32bit:

  CCtests/test-cutils.o
/home/kraxel/projects/qemu/tests/test-cutils.c: In function
‘test_parse_uint_llong_max’:
/home/kraxel/projects/qemu/tests/test-cutils.c:168:5: error: overflow in
implicit constant conversion [-Werror=overflow]
 g_assert_cmpint(i, ==, (unsigned long long)LLONG_MAX + 1);
 ^
/home/kraxel/projects/qemu/tests/test-cutils.c: In function
‘test_parse_uint_overflow’:
/home/kraxel/projects/qemu/tests/test-cutils.c:185:5: error: overflow in
implicit constant conversion [-Werror=overflow]
 g_assert_cmpint(i, ==, ULLONG_MAX);
 ^
cc1: all warnings being treated as errors
make: *** [tests/test-cutils.o] Error 1
test failure

cheers,
  Gerd





[Qemu-devel] [PATCH v2 2/2] docs/memory.txt: Fix document on MMIO operations

2014-05-05 Thread Fam Zheng
.impl.valid should be .impl.unaligned and the description needs some
fixes.

Signed-off-by: Fam Zheng 
---
 docs/memory.txt | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/docs/memory.txt b/docs/memory.txt
index d5abc92..4c7bc43 100644
--- a/docs/memory.txt
+++ b/docs/memory.txt
@@ -232,7 +232,8 @@ various constraints can be supplied to control how these 
callbacks are called:
(in bytes) supported by the *implementation*; other access sizes will be
emulated using the ones available. For example a 4-byte write will be
emulated using four 1-byte writes, if .impl.max_access_size = 1.
- - .impl.valid specifies that the *implementation* only supports unaligned
-   accesses; unaligned accesses will be emulated by two aligned accesses.
+ - .impl.unaligned specifies that the *implementation* supports unaligned
+   accesses; if false, an unaligned access will be emulated by two aligned
+   accesses.
  - .old_mmio can be used to ease porting from code using
cpu_register_io_memory(). It should not be used in new code.
-- 
1.9.2




[Qemu-devel] [PATCH v2 1/2] docs/memory.txt: Put one whitespace between sentences

2014-05-05 Thread Fam Zheng
In other words, whitespace changes only.

Signed-off-by: Fam Zheng 
---
 docs/memory.txt | 42 +-
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/docs/memory.txt b/docs/memory.txt
index d344879..d5abc92 100644
--- a/docs/memory.txt
+++ b/docs/memory.txt
@@ -2,7 +2,7 @@ The memory API
 ==
 
 The memory API models the memory and I/O buses and controllers of a QEMU
-machine.  It attempts to allow modelling of:
+machine. It attempts to allow modelling of:
 
  - ordinary RAM
  - memory-mapped I/O (MMIO)
@@ -15,7 +15,7 @@ The memory model provides support for
  - setting up coalesced memory for kvm
  - setting up ioeventfd regions for kvm
 
-Memory is modelled as an acyclic graph of MemoryRegion objects.  Sinks
+Memory is modelled as an acyclic graph of MemoryRegion objects. Sinks
 (leaves) are RAM and MMIO regions, while other nodes represent
 buses, memory controllers, and memory regions that have been rerouted.
 
@@ -36,20 +36,20 @@ MemoryRegion):
   each read or write causes a callback to be called on the host.
 
 - container: a container simply includes other memory regions, each at
-  a different offset.  Containers are useful for grouping several regions
-  into one unit.  For example, a PCI BAR may be composed of a RAM region
+  a different offset. Containers are useful for grouping several regions
+  into one unit. For example, a PCI BAR may be composed of a RAM region
   and an MMIO region.
 
-  A container's subregions are usually non-overlapping.  In some cases it is
+  A container's subregions are usually non-overlapping. In some cases it is
   useful to have overlapping regions; for example a memory controller that
   can overlay a subregion of RAM with MMIO or ROM, or a PCI controller
   that does not prevent card from claiming overlapping BARs.
 
-- alias: a subsection of another region.  Aliases allow a region to be
-  split apart into discontiguous regions.  Examples of uses are memory banks
+- alias: a subsection of another region. Aliases allow a region to be
+  split apart into discontiguous regions. Examples of uses are memory banks
   used when the guest address space is smaller than the amount of RAM
   addressed, or a memory controller that splits main memory to expose a "PCI
-  hole".  Aliases may point to any type of region, including other aliases,
+  hole". Aliases may point to any type of region, including other aliases,
   but an alias may not point back to itself, directly or indirectly.
 
 It is valid to add subregions to a region which is not a pure container
@@ -65,27 +65,27 @@ Subregions cannot be added to an alias region.
 Region names
 
 
-Regions are assigned names by the constructor.  For most regions these are
+Regions are assigned names by the constructor. For most regions these are
 only used for debugging purposes, but RAM regions also use the name to identify
-live migration sections.  This means that RAM region names need to have ABI
+live migration sections. This means that RAM region names need to have ABI
 stability.
 
 Region lifecycle
 
 
 A region is created by one of the constructor functions (memory_region_init*())
-and destroyed by the destructor (memory_region_destroy()).  In between,
+and destroyed by the destructor (memory_region_destroy()). In between,
 a region can be added to an address space by using 
memory_region_add_subregion()
-and removed using memory_region_del_subregion().  Region attributes may be
+and removed using memory_region_del_subregion(). Region attributes may be
 changed at any point; they take effect once the region becomes exposed to the
 guest.
 
 Overlapping regions and priority
 
 Usually, regions may not overlap each other; a memory address decodes into
-exactly one target.  In some cases it is useful to allow regions to overlap,
+exactly one target. In some cases it is useful to allow regions to overlap,
 and sometimes to control which of an overlapping regions is visible to the
-guest.  This is done with memory_region_add_subregion_overlap(), which
+guest. This is done with memory_region_add_subregion_overlap(), which
 allows the region to overlap any other region in the same container, and
 specifies a priority that allows the core to decide which of two regions at
 the same address are visible (highest wins).
@@ -190,13 +190,13 @@ ram: ram@0x-0x
 
 This is a (simplified) PC memory map. The 4GB RAM block is mapped into the
 system address space via two aliases: "lomem" is a 1:1 mapping of the first
-3.5GB; "himem" maps the last 0.5GB at address 4GB.  This leaves 0.5GB for the
+3.5GB; "himem" maps the last 0.5GB at address 4GB. This leaves 0.5GB for the
 so-called PCI hole, that allows a 32-bit PCI bus to exist in a system with
 4GB of memory.
 
 The memory controller diverts addresses in the range 640K-768K to the PCI
-address space.  This is modelled using the "vga-window" alias, map

[Qemu-devel] How to overclock guest timers?

2014-05-05 Thread Марк Коренберг
What I want - is to make all virtual clocks run faster. This means, for
example, if I run command 'sleep 10' on the guest, and virtual clocks are
10 times overclocked, this command should take 1 real second. In other
words, all timers should be 10 times faster, even timers that wait for IO
in the guest VM. At the point of virtual guest, nothing should say about
fast timers. Only one thing - guest OS will think that virtual CPU is 10x
slower than generic processor. Because it perform 10x lesser commands per
tick. Yes, things like TSC should also be 10x faster.

So, how I can speedup qemu timers? I tried my own patches, but something
recalibrates timers and speedup did not happen. Maybe you known how I can
"speedup" guest OS with modifying guest kernel?

-- 
Segmentation fault


Re: [Qemu-devel] [PATCH] docs/memory.txt: Fix document on MMIO operations

2014-05-05 Thread Paolo Bonzini

Il 05/05/2014 12:51, Fam Zheng ha scritto:

On Mon, 05/05 11:41, Peter Maydell wrote:

On 5 May 2014 08:53, Fam Zheng  wrote:

.impl.valid should be .impl.unaligned and the description needs some
fixes.

.old_portio is removed since commit b40acf99b (ioport: Switch
dispatching to memory core layer).


I've already sent a patch for that part, which mjt has applied
to the trivial branch :

http://patchwork.ozlabs.org/patch/343332/

so this patch is going to cause a merge conflict with that
if Paolo takes it via a different tree.

thanks
-- PMM


I overlooked that one. I'll respin to base on your patch and send for -trivial,
so Paolo could drop it.


Ok, will drop.

Paolo





[Qemu-devel] [PATCH v2 0/2] docs/memory.txt: Fixes on whitespace and MMIO operations

2014-05-05 Thread Fam Zheng


Fam Zheng (2):
  docs/memory.txt: Put one whitespace between sentences
  docs/memory.txt: Fix document on MMIO operations

 docs/memory.txt | 47 ---
 1 file changed, 24 insertions(+), 23 deletions(-)

-- 
1.9.2




Re: [Qemu-devel] [PATCH v3 2/4] ppc64-dump: Support dump for little endian ppc64

2014-05-05 Thread Alexander Graf

On 05/05/2014 10:05 AM, Greg Kurz wrote:

From: Bharata B Rao 

Fix ppc64 arch specific dump code to work correctly for little endian
guests.

We introduce a NoteFuncArg type to avoid adding extra arguments to all note
functions.

Signed-off-by: Bharata B Rao 
[ rebased on top of current master branch,
   introduced NoteFuncArg,
   use new cpu_to_dump{16,32,64} endian helpers,
   Greg Kurz  ]
Reviewed-by: Alexander Graf 
Signed-off-by: Greg Kurz 
---

Changes in v3:
- better taste with the endian helpers naming

  target-ppc/arch_dump.c |   82 +---
  1 file changed, 49 insertions(+), 33 deletions(-)

diff --git a/target-ppc/arch_dump.c b/target-ppc/arch_dump.c
index 9dccf1a..5487b61 100644
--- a/target-ppc/arch_dump.c
+++ b/target-ppc/arch_dump.c
@@ -79,94 +79,109 @@ typedef struct noteStruct {
  } contents;
  } QEMU_PACKED Note;
  
+typedef struct NoteFuncArg {

+Note note;
+DumpState *state;
+} NoteFuncArg;
  
-static void ppc64_write_elf64_prstatus(Note *note, PowerPCCPU *cpu)

+static void ppc64_write_elf64_prstatus(NoteFuncArg *arg, PowerPCCPU *cpu)
  {
  int i;
  uint64_t cr;
  struct PPC64ElfPrstatus *prstatus;
  struct PPC64UserRegStruct *reg;
+Note *note = &arg->note;
+DumpState *s = arg->state;
  
-note->hdr.n_type = cpu_to_be32(NT_PRSTATUS);

+note->hdr.n_type = cpu_to_dump32(s, NT_PRSTATUS);
  
  prstatus = ¬e->contents.prstatus;

  memset(prstatus, 0, sizeof(*prstatus));
  reg = &prstatus->pr_reg;
  
  for (i = 0; i < 32; i++) {

-reg->gpr[i] = cpu_to_be64(cpu->env.gpr[i]);
+reg->gpr[i] = cpu_to_dump64(s, cpu->env.gpr[i]);
  }
-reg->nip = cpu_to_be64(cpu->env.nip);
-reg->msr = cpu_to_be64(cpu->env.msr);
-reg->ctr = cpu_to_be64(cpu->env.ctr);
-reg->link = cpu_to_be64(cpu->env.lr);
-reg->xer = cpu_to_be64(cpu_read_xer(&cpu->env));
+reg->nip = cpu_to_dump64(s, cpu->env.nip);
+reg->msr = cpu_to_dump64(s, cpu->env.msr);
+reg->ctr = cpu_to_dump64(s, cpu->env.ctr);
+reg->link = cpu_to_dump64(s, cpu->env.lr);
+reg->xer = cpu_to_dump64(s, cpu_read_xer(&cpu->env));
  
  cr = 0;

  for (i = 0; i < 8; i++) {
  cr |= (cpu->env.crf[i] & 15) << (4 * (7 - i));
  }
-reg->ccr = cpu_to_be64(cr);
+reg->ccr = cpu_to_dump64(s, cr);
  }
  
-static void ppc64_write_elf64_fpregset(Note *note, PowerPCCPU *cpu)

+static void ppc64_write_elf64_fpregset(NoteFuncArg *arg, PowerPCCPU *cpu)
  {
  int i;
  struct PPC64ElfFpregset  *fpregset;
+Note *note = &arg->note;
+DumpState *s = arg->state;
  
-note->hdr.n_type = cpu_to_be32(NT_PRFPREG);

+note->hdr.n_type = cpu_to_dump32(s, NT_PRFPREG);
  
  fpregset = ¬e->contents.fpregset;

  memset(fpregset, 0, sizeof(*fpregset));
  
  for (i = 0; i < 32; i++) {

-fpregset->fpr[i] = cpu_to_be64(cpu->env.fpr[i]);
+fpregset->fpr[i] = cpu_to_dump64(s, cpu->env.fpr[i]);
  }
-fpregset->fpscr = cpu_to_be64(cpu->env.fpscr);
+fpregset->fpscr = cpu_to_dump64(s, cpu->env.fpscr);
  }
  
-static void ppc64_write_elf64_vmxregset(Note *note, PowerPCCPU *cpu)

+static void ppc64_write_elf64_vmxregset(NoteFuncArg *arg, PowerPCCPU *cpu)
  {
  int i;
  struct PPC64ElfVmxregset *vmxregset;
+Note *note = &arg->note;
+DumpState *s = arg->state;
  
-note->hdr.n_type = cpu_to_be32(NT_PPC_VMX);

+note->hdr.n_type = cpu_to_dump32(s, NT_PPC_VMX);
  vmxregset = ¬e->contents.vmxregset;
  memset(vmxregset, 0, sizeof(*vmxregset));
  
  for (i = 0; i < 32; i++) {

-vmxregset->avr[i].u64[0] = cpu_to_be64(cpu->env.avr[i].u64[0]);
-vmxregset->avr[i].u64[1] = cpu_to_be64(cpu->env.avr[i].u64[1]);
+vmxregset->avr[i].u64[0] = cpu_to_dump64(s, cpu->env.avr[i].u64[0]);
+vmxregset->avr[i].u64[1] = cpu_to_dump64(s, cpu->env.avr[i].u64[1]);


Is this correct? Tom, could you please ack if it is?


Alex




Re: [Qemu-devel] [PATCH v2 0/2] docs/memory.txt: Fixes on whitespace and MMIO operations

2014-05-05 Thread Fam Zheng
On Mon, 05/05 18:59, Fam Zheng wrote:
> 
> 
> Fam Zheng (2):
>   docs/memory.txt: Put one whitespace between sentences
>   docs/memory.txt: Fix document on MMIO operations

Michael, this is based on Peter's

[PATCH] docs/memory.txt: old_portio has gone, so don't mention it

So you could apply on top.

Thanks,
Fam



Re: [Qemu-devel] [PATCH v2 1/2] docs/memory.txt: Put one whitespace between sentences

2014-05-05 Thread Michael Tokarev
05.05.2014 14:59, Fam Zheng wrote:
> In other words, whitespace changes only.

>  The memory API models the memory and I/O buses and controllers of a QEMU
> -machine.  It attempts to allow modelling of:
> +machine. It attempts to allow modelling of:

What's the point?  In text form, it is quite often and, to my taste, quite
normal to use 2 spaces after the full-dot (at the end of the sentence), just
like an extra line between paragraphs.  This way, it is easier to separate
sentences between each other.

In real typography, 1.5-sized space is usually used in such places.  But since
plaintext format has no 1.5-sized space, 2 spaces is used.

I'd send an opposite patch, which adds additional space where it is missing.. :)

Thanks,

/mjt



Re: [Qemu-devel] [PATCH v2 2/2] qapi: Allow setting default values for optional parameters

2014-05-05 Thread Markus Armbruster
Fam Zheng  writes:

> In command definition, 'defaults' is now parsed as a dict of default
> values. Only optional parameters will have effect in generated code.
>
> 'str' and 'int' are supported. In generated code, 'str' will be
> converted to g_strdup'ed string pointer, 'int' will be identically
> assigned.
>
> E.g.
>
> { 'command': 'block-commit',
>   'data': { 'device': 'str', '*base': 'str', 'top': 'str',
> '*speed': 'int' },
>   'defaults': {'base': 'earthquake', 'speed': 100 } }
>
> will generate
>
> int qmp_marshal_input_block_commit(Monitor *mon, const QDict *qdict, 
> QObject **ret)
> {
> ...
> bool has_base = true;
> char * base = g_strdup("earthquake");
> ...
> bool has_speed = true;
> int64_t speed = 100;
>
> Updated docs/qapi-code-gen.txt and qapi-schema tests.
>
> Signed-off-by: Fam Zheng 
> ---
>  docs/qapi-code-gen.txt  |  8 ++--
>  scripts/qapi-commands.py| 29 ++---
>  scripts/qapi.py |  8 
>  tests/qapi-schema/qapi-schema-test.json |  3 +++
>  tests/qapi-schema/qapi-schema-test.out  |  1 +
>  tests/test-qmp-commands.c   |  7 +++
>  6 files changed, 47 insertions(+), 9 deletions(-)
>
> diff --git a/docs/qapi-code-gen.txt b/docs/qapi-code-gen.txt
> index d78921f..b4cc6ed 100644
> --- a/docs/qapi-code-gen.txt
> +++ b/docs/qapi-code-gen.txt
> @@ -172,12 +172,16 @@ This example allows using both of the following example 
> objects:
>  
>  Commands are defined by using a list containing three members.  The first
>  member is the command name, the second member is a dictionary containing
> -arguments, and the third member is the return type.
> +arguments, the third member is optional to define default values for optional
> +arguments in 'data' dictionary, and the fourth member is the return type.
> +
> +Non-optional argument names are not allowed in the 'defaults' dictionary.
>  
>  An example command is:
>  
>   { 'command': 'my-command',
> -   'data': { 'arg1': 'str', '*arg2': 'str' },
> +   'data': { 'arg1': 'str', '*arg2': 'str', '*arg3': 'int' },
> +   'defaults': { 'arg2': 'default value for arg2', 'arg3': 12345 },
> 'returns': 'str' }
>  
>  

I'm only reviewing schema design here.

So far, a command parameter has three propagated: name, type, and
whether it's optional.  Undocumented hack: a type '**' means "who
knows", and suppresses marshalling function generation for the command.

The three properties are encoded in a single member of 'data': name
becomes the member name, and type becomes the value, except optional is
shoehorned into the name as well[*].

Your patch adds have a fourth property, namely the default value.  It is
only valid for optional parameters.  You put it into a separate member
'defaults', next to 'data.  This spreads parameter properties over two
separate objects.  I don't like that.  What if we come up with a fifth
one?  Then it'll get even worse.

Can we keep a parameter's properties together?  Perhaps like this:

NAME: { 'type': TYPE, 'default': DEFAULT }

where

NAME: { 'type': TYPE }

can be abbreviated to

NAME: TYPE

and

NAME: { 'type': TYPE, 'default': null }
to

NAME-PREFIXED-BY_ASKTERISK: TYPE

if we think these abbreviations enhance schema readability enough to be
worthwhile.  The first one does, in my opinion. but I'm not so sure
about the second one.


[*] I'm sure that felt like a good idea at the time.



Re: [Qemu-devel] [PATCH v2 0/2] docs/memory.txt: Fixes on whitespace and MMIO operations

2014-05-05 Thread Michael Tokarev
05.05.2014 15:05, Fam Zheng пишет:
> On Mon, 05/05 18:59, Fam Zheng wrote:
>>
>>
>> Fam Zheng (2):
>>   docs/memory.txt: Put one whitespace between sentences
>>   docs/memory.txt: Fix document on MMIO operations
> 
> Michael, this is based on Peter's
> 
> [PATCH] docs/memory.txt: old_portio has gone, so don't mention it
> 
> So you could apply on top.

I'd rather drop the Peter's patch and apply your first version, so
we don't have 2 halves but one whole :)   I can pick it from your
initial submission ;)

Thanks,

/mjt



Re: [Qemu-devel] [PATCH v3 0/4] little-endian dump for ppc64

2014-05-05 Thread Alexander Graf

On 05/05/2014 10:02 AM, Greg Kurz wrote:

Hi,

Please find the latest patch set for dump-guest-memory to support
little-endian ppc64 guest kernels. The only change since the last
post is a better naming of the dump endian helpers. Since it
affects patches 1 & 2, I resend the full serie, with Alex's
Reviewed-by tags from the last review.


I like the patch set. If I also get an ack from Tom on the data layout 
of AVR registers I'd be more than happy to apply it to my tree. I'd also 
welcome someone non-ppc to review the dump patches.



Alex




[Qemu-devel] [PULL 02/10] usb: mtp: replace debug printfs with trace points

2014-05-05 Thread Gerd Hoffmann
Signed-off-by: Gerd Hoffmann 
Reviewed-by: Peter Wu 
Reviewed-by: Stefan Hajnoczi 
---
 hw/usb/dev-mtp.c | 8 
 trace-events | 3 +++
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
index 8b44032..17df447 100644
--- a/hw/usb/dev-mtp.c
+++ b/hw/usb/dev-mtp.c
@@ -294,7 +294,7 @@ static MTPObject *usb_mtp_object_alloc(MTPState *s, 
uint32_t handle,
 goto ignore;
 }
 
-fprintf(stderr, "%s: 0x%x %s\n", __func__, o->handle, o->path);
+trace_usb_mtp_object_alloc(s->dev.addr, o->handle, o->path);
 
 QTAILQ_INSERT_TAIL(&s->objects, o, next);
 return o;
@@ -310,7 +310,7 @@ static void usb_mtp_object_free(MTPState *s, MTPObject *o)
 {
 int i;
 
-fprintf(stderr, "%s: 0x%x %s\n", __func__, o->handle, o->path);
+trace_usb_mtp_object_free(s->dev.addr, o->handle, o->path);
 
 QTAILQ_REMOVE(&s->objects, o, next);
 for (i = 0; i < o->nchildren; i++) {
@@ -843,8 +843,7 @@ static void usb_mtp_command(MTPState *s, MTPControl *c)
 res0 = data_in->length;
 break;
 default:
-fprintf(stderr, "%s: unknown command code 0x%04x\n",
-__func__, c->code);
+trace_usb_mtp_op_unknown(s->dev.addr, c->code);
 usb_mtp_queue_result(s, RES_OPERATION_NOT_SUPPORTED,
  c->trans, 0, 0, 0);
 return;
@@ -892,6 +891,7 @@ static void usb_mtp_handle_control(USBDevice *dev, 
USBPacket *p,
 
 static void usb_mtp_cancel_packet(USBDevice *dev, USBPacket *p)
 {
+/* we don't use async packets, so this should never be called */
 fprintf(stderr, "%s\n", __func__);
 }
 
diff --git a/trace-events b/trace-events
index a5218ba..af4449d 100644
--- a/trace-events
+++ b/trace-events
@@ -453,6 +453,9 @@ usb_mtp_op_get_object_handles(int dev, uint32_t handle, 
const char *path) "dev %
 usb_mtp_op_get_object_info(int dev, uint32_t handle, const char *path) "dev 
%d, handle 0x%x, path %s"
 usb_mtp_op_get_object(int dev, uint32_t handle, const char *path) "dev %d, 
handle 0x%x, path %s"
 usb_mtp_op_get_partial_object(int dev, uint32_t handle, const char *path, 
uint32_t offset, uint32_t length) "dev %d, handle 0x%x, path %s, off %d, len %d"
+usb_mtp_op_unknown(int dev, uint32_t code) "dev %d, command code 0x%x"
+usb_mtp_object_alloc(int dev, uint32_t handle, const char *path) "dev %d, 
handle 0x%x, path %s"
+usb_mtp_object_free(int dev, uint32_t handle, const char *path) "dev %d, 
handle 0x%x, path %s"
 
 # hw/usb/host-libusb.c
 usb_host_open_started(int bus, int addr) "dev %d:%d"
-- 
1.8.3.1




[Qemu-devel] [PULL 00/10] usb patch queue

2014-05-05 Thread Gerd Hoffmann
  Hi,

Here comes the next usb patch queue pull, featuring a bunch of mtp
bugfixes and ohci live migration support.

please pull,
  Gerd

The following changes since commit fdaad4715ae9e998fd0595bedfb16fdaf0c68ccc:

  Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20140501' 
into staging (2014-05-02 11:32:00 +0100)

are available in the git repository at:


  git://git.kraxel.org/qemu tags/pull-usb-6

for you to fetch changes up to 8ebb87635790e7033e19e9a26e8c5eef22560bcc:

  usb: mtp: reply INCOMPLETE_TRANSFER on read errors (2014-05-05 12:58:02 +0200)


ohci live migration.
mtp bugfixes.


Alexey Kardashevskiy (1):
  usb-ohci: Add vmstate descriptor

Gerd Hoffmann (9):
  usb: mtp: replace debug printfs with trace points
  usb: mtp: fix usb_mtp_add_u64
  usb: mtp: fix version (is decimal not bcd)
  usb: mtp: fix serial (must be exact 32 chars)
  usb: mtp: fix error path memory leak
  usb: mtp: avoid empty description string
  usb: mtp: drop data-out hexdump
  usb: mtp: fix possible buffer overflow
  usb: mtp: reply INCOMPLETE_TRANSFER on read errors

 hw/usb/dev-mtp.c  |  35 ++--
 hw/usb/hcd-ohci.c | 119 ++
 trace-events  |   3 ++
 3 files changed, 137 insertions(+), 20 deletions(-)



[Qemu-devel] [PULL 01/10] usb-ohci: Add vmstate descriptor

2014-05-05 Thread Gerd Hoffmann
From: Alexey Kardashevskiy 

This adds migration support for OHCI.

This defines a descriptor for OHCIState.
This changes some OHCIState field types to be migration compatible.
This adds a descriptor for OHCIPort.
This migrates the EOF timer if the USB was started at the time of
migration.

Cc: Gerd Hoffmann 
Cc: Peter Maydell 
Signed-off-by: Alexey Kardashevskiy 
Signed-off-by: Gerd Hoffmann 
---
 hw/usb/hcd-ohci.c | 119 ++
 1 file changed, 111 insertions(+), 8 deletions(-)

diff --git a/hw/usb/hcd-ohci.c b/hw/usb/hcd-ohci.c
index 93f186f..cd87074 100644
--- a/hw/usb/hcd-ohci.c
+++ b/hw/usb/hcd-ohci.c
@@ -80,13 +80,13 @@ typedef struct {
 uint32_t bulk_head, bulk_cur;
 uint32_t per_cur;
 uint32_t done;
-int done_count;
+int32_t done_count;
 
 /* Frame counter partition */
-uint32_t fsmps:15;
-uint32_t fit:1;
-uint32_t fi:14;
-uint32_t frt:1;
+uint16_t fsmps;
+uint8_t fit;
+uint16_t fi;
+uint8_t frt;
 uint16_t frame_number;
 uint16_t padding;
 uint32_t pstart;
@@ -111,7 +111,7 @@ typedef struct {
 USBPacket usb_packet;
 uint8_t usb_buf[8192];
 uint32_t async_td;
-int async_complete;
+bool async_complete;
 
 } OHCIState;
 
@@ -693,7 +693,7 @@ static void ohci_async_complete_packet(USBPort *port, 
USBPacket *packet)
 #ifdef DEBUG_PACKET
 DPRINTF("Async packet complete\n");
 #endif
-ohci->async_complete = 1;
+ohci->async_complete = true;
 ohci_process_lists(ohci, 1);
 }
 
@@ -1058,7 +1058,7 @@ static int ohci_service_td(OHCIState *ohci, struct 
ohci_ed *ed)
 #endif
 if (completion) {
 ohci->async_td = 0;
-ohci->async_complete = 0;
+ohci->async_complete = false;
 } else {
 if (ohci->async_td) {
 /* ??? The hardware should allow one active packet per
@@ -1984,6 +1984,108 @@ static Property ohci_pci_properties[] = {
 DEFINE_PROP_END_OF_LIST(),
 };
 
+static const VMStateDescription vmstate_ohci_state_port = {
+.name = "ohci-core/port",
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields = (VMStateField []) {
+VMSTATE_UINT32(ctrl, OHCIPort),
+VMSTATE_END_OF_LIST()
+},
+};
+
+static bool ohci_eof_timer_needed(void *opaque)
+{
+OHCIState *ohci = opaque;
+
+return ohci->eof_timer != NULL;
+}
+
+static int ohci_eof_timer_pre_load(void *opaque)
+{
+OHCIState *ohci = opaque;
+
+ohci_bus_start(ohci);
+
+return 0;
+}
+
+static const VMStateDescription vmstate_ohci_eof_timer = {
+.name = "ohci-core/eof-timer",
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.pre_load = ohci_eof_timer_pre_load,
+.fields = (VMStateField []) {
+VMSTATE_TIMER(eof_timer, OHCIState),
+VMSTATE_END_OF_LIST()
+},
+};
+
+const VMStateDescription vmstate_ohci_state = {
+.name = "ohci-core",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_INT64(sof_time, OHCIState),
+VMSTATE_UINT32(ctl, OHCIState),
+VMSTATE_UINT32(status, OHCIState),
+VMSTATE_UINT32(intr_status, OHCIState),
+VMSTATE_UINT32(intr, OHCIState),
+VMSTATE_UINT32(hcca, OHCIState),
+VMSTATE_UINT32(ctrl_head, OHCIState),
+VMSTATE_UINT32(ctrl_cur, OHCIState),
+VMSTATE_UINT32(bulk_head, OHCIState),
+VMSTATE_UINT32(bulk_cur, OHCIState),
+VMSTATE_UINT32(per_cur, OHCIState),
+VMSTATE_UINT32(done, OHCIState),
+VMSTATE_INT32(done_count, OHCIState),
+VMSTATE_UINT16(fsmps, OHCIState),
+VMSTATE_UINT8(fit, OHCIState),
+VMSTATE_UINT16(fi, OHCIState),
+VMSTATE_UINT8(frt, OHCIState),
+VMSTATE_UINT16(frame_number, OHCIState),
+VMSTATE_UINT16(padding, OHCIState),
+VMSTATE_UINT32(pstart, OHCIState),
+VMSTATE_UINT32(lst, OHCIState),
+VMSTATE_UINT32(rhdesc_a, OHCIState),
+VMSTATE_UINT32(rhdesc_b, OHCIState),
+VMSTATE_UINT32(rhstatus, OHCIState),
+VMSTATE_STRUCT_ARRAY(rhport, OHCIState, OHCI_MAX_PORTS, 0,
+ vmstate_ohci_state_port, OHCIPort),
+VMSTATE_UINT32(hstatus, OHCIState),
+VMSTATE_UINT32(hmask, OHCIState),
+VMSTATE_UINT32(hreset, OHCIState),
+VMSTATE_UINT32(htest, OHCIState),
+VMSTATE_UINT32(old_ctl, OHCIState),
+VMSTATE_UINT8_ARRAY(usb_buf, OHCIState, 8192),
+VMSTATE_UINT32(async_td, OHCIState),
+VMSTATE_BOOL(async_complete, OHCIState),
+VMSTATE_END_OF_LIST()
+},
+.subsections = (VMStateSubsection []) {
+{
+.vmsd = &vmstate_ohci_eof_timer,
+.needed = ohci_eof_timer_needed,
+} , {
+/* empty */
+}
+}
+};
+
+static const VMStateDescription vmstate_ohci = {
+.name = "ohci",
+.version_id = 1,
+.minimum_version_id = 

[Qemu-devel] [PULL 04/10] usb: mtp: fix version (is decimal not bcd)

2014-05-05 Thread Gerd Hoffmann
Signed-off-by: Gerd Hoffmann 
Reviewed-by: Peter Wu 
Reviewed-by: Stefan Hajnoczi 
---
 hw/usb/dev-mtp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
index 063a426..dff2618 100644
--- a/hw/usb/dev-mtp.c
+++ b/hw/usb/dev-mtp.c
@@ -533,7 +533,7 @@ static MTPData *usb_mtp_get_device_info(MTPState *s, 
MTPControl *c)
 
 trace_usb_mtp_op_get_device_info(s->dev.addr);
 
-usb_mtp_add_u16(d, 0x0100);
+usb_mtp_add_u16(d, 100);
 usb_mtp_add_u32(d, 0x);
 usb_mtp_add_u16(d, 0x0101);
 usb_mtp_add_wstr(d, L"");
-- 
1.8.3.1




[Qemu-devel] [PULL 06/10] usb: mtp: fix error path memory leak

2014-05-05 Thread Gerd Hoffmann
Signed-off-by: Gerd Hoffmann 
Reviewed-by: Peter Wu 
Reviewed-by: Stefan Hajnoczi 
---
 hw/usb/dev-mtp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
index 775dc8d..45f9562 100644
--- a/hw/usb/dev-mtp.c
+++ b/hw/usb/dev-mtp.c
@@ -669,6 +669,7 @@ static MTPData *usb_mtp_get_object(MTPState *s, MTPControl 
*c,
 
 d->fd = open(o->path, O_RDONLY);
 if (d->fd == -1) {
+usb_mtp_data_free(d);
 return NULL;
 }
 d->length = o->stat.st_size;
@@ -688,6 +689,7 @@ static MTPData *usb_mtp_get_partial_object(MTPState *s, 
MTPControl *c,
 
 d->fd = open(o->path, O_RDONLY);
 if (d->fd == -1) {
+usb_mtp_data_free(d);
 return NULL;
 }
 
-- 
1.8.3.1




[Qemu-devel] [PULL 09/10] usb: mtp: fix possible buffer overflow

2014-05-05 Thread Gerd Hoffmann
Signed-off-by: Gerd Hoffmann 
Reviewed-by: Peter Wu 
Reviewed-by: Stefan Hajnoczi 
---
 hw/usb/dev-mtp.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
index b6eaeae..62428d8 100644
--- a/hw/usb/dev-mtp.c
+++ b/hw/usb/dev-mtp.c
@@ -998,6 +998,14 @@ static void usb_mtp_handle_data(USBDevice *dev, USBPacket 
*p)
 cmd.argc = (le32_to_cpu(container.length) - sizeof(container))
 / sizeof(uint32_t);
 cmd.trans = le32_to_cpu(container.trans);
+if (cmd.argc > ARRAY_SIZE(cmd.argv)) {
+cmd.argc = ARRAY_SIZE(cmd.argv);
+}
+if (p->iov.size < sizeof(container) + cmd.argc * sizeof(uint32_t)) 
{
+trace_usb_mtp_stall(s->dev.addr, "packet too small");
+p->status = USB_RET_STALL;
+return;
+}
 usb_packet_copy(p, ¶ms, cmd.argc * sizeof(uint32_t));
 for (i = 0; i < cmd.argc; i++) {
 cmd.argv[i] = le32_to_cpu(params[i]);
-- 
1.8.3.1




[Qemu-devel] [PULL 08/10] usb: mtp: drop data-out hexdump

2014-05-05 Thread Gerd Hoffmann
Signed-off-by: Gerd Hoffmann 
Reviewed-by: Peter Wu 
Reviewed-by: Stefan Hajnoczi 
---
 hw/usb/dev-mtp.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
index a30a886..b6eaeae 100644
--- a/hw/usb/dev-mtp.c
+++ b/hw/usb/dev-mtp.c
@@ -1011,8 +1011,7 @@ static void usb_mtp_handle_data(USBDevice *dev, USBPacket 
*p)
 usb_mtp_command(s, &cmd);
 break;
 default:
-iov_hexdump(p->iov.iov, p->iov.niov, stderr, "mtp-out", 32);
-trace_usb_mtp_stall(s->dev.addr, "TODO: implement data-out");
+/* not needed as long as the mtp device is read-only */
 p->status = USB_RET_STALL;
 return;
 }
-- 
1.8.3.1




[Qemu-devel] [PULL 03/10] usb: mtp: fix usb_mtp_add_u64

2014-05-05 Thread Gerd Hoffmann
Signed-off-by: Gerd Hoffmann 
Reviewed-by: Peter Wu 
Reviewed-by: Stefan Hajnoczi 
---
 hw/usb/dev-mtp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
index 17df447..063a426 100644
--- a/hw/usb/dev-mtp.c
+++ b/hw/usb/dev-mtp.c
@@ -416,7 +416,7 @@ static void usb_mtp_add_u32(MTPData *data, uint32_t val)
 
 static void usb_mtp_add_u64(MTPData *data, uint64_t val)
 {
-usb_mtp_realloc(data, 4);
+usb_mtp_realloc(data, 8);
 data->data[data->length++] = (val >>  0) & 0xff;
 data->data[data->length++] = (val >>  8) & 0xff;
 data->data[data->length++] = (val >> 16) & 0xff;
@@ -424,7 +424,7 @@ static void usb_mtp_add_u64(MTPData *data, uint64_t val)
 data->data[data->length++] = (val >> 32) & 0xff;
 data->data[data->length++] = (val >> 40) & 0xff;
 data->data[data->length++] = (val >> 48) & 0xff;
-data->data[data->length++] = (val >> 54) & 0xff;
+data->data[data->length++] = (val >> 56) & 0xff;
 }
 
 static void usb_mtp_add_u16_array(MTPData *data, uint32_t len,
-- 
1.8.3.1




[Qemu-devel] [PULL 10/10] usb: mtp: reply INCOMPLETE_TRANSFER on read errors

2014-05-05 Thread Gerd Hoffmann
Signed-off-by: Gerd Hoffmann 
Reviewed-by: Peter Wu 
Reviewed-by: Stefan Hajnoczi 
---
 hw/usb/dev-mtp.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
index 62428d8..943f930 100644
--- a/hw/usb/dev-mtp.c
+++ b/hw/usb/dev-mtp.c
@@ -50,6 +50,7 @@ enum mtp_code {
 RES_INVALID_TRANSACTION_ID = 0x2004,
 RES_OPERATION_NOT_SUPPORTED= 0x2005,
 RES_PARAMETER_NOT_SUPPORTED= 0x2006,
+RES_INCOMPLETE_TRANSFER= 0x2007,
 RES_INVALID_STORAGE_ID = 0x2008,
 RES_INVALID_OBJECT_HANDLE  = 0x2009,
 RES_SPEC_BY_FORMAT_UNSUPPORTED = 0x2014,
@@ -946,7 +947,8 @@ static void usb_mtp_handle_data(USBDevice *dev, USBPacket 
*p)
 }
 rc = read(d->fd, d->data, dlen);
 if (rc != dlen) {
-fprintf(stderr, "%s: TODO: handle read error\n", __func__);
+memset(d->data, 0, dlen);
+s->result->code = RES_INCOMPLETE_TRANSFER;
 }
 usb_packet_copy(p, d->data, dlen);
 }
-- 
1.8.3.1




[Qemu-devel] [PULL 07/10] usb: mtp: avoid empty description string

2014-05-05 Thread Gerd Hoffmann
Signed-off-by: Gerd Hoffmann 
Reviewed-by: Peter Wu 
Reviewed-by: Stefan Hajnoczi 
---
 hw/usb/dev-mtp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
index 45f9562..a30a886 100644
--- a/hw/usb/dev-mtp.c
+++ b/hw/usb/dev-mtp.c
@@ -1046,7 +1046,7 @@ static int usb_mtp_initfn(USBDevice *dev)
 QTAILQ_INIT(&s->objects);
 if (s->desc == NULL) {
 s->desc = strrchr(s->root, '/');
-if (s->desc) {
+if (s->desc && s->desc[0]) {
 s->desc = g_strdup(s->desc + 1);
 } else {
 s->desc = g_strdup("none");
-- 
1.8.3.1




[Qemu-devel] [PULL 05/10] usb: mtp: fix serial (must be exact 32 chars)

2014-05-05 Thread Gerd Hoffmann
Signed-off-by: Gerd Hoffmann 
Reviewed-by: Peter Wu 
Reviewed-by: Stefan Hajnoczi 
---
 hw/usb/dev-mtp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
index dff2618..775dc8d 100644
--- a/hw/usb/dev-mtp.c
+++ b/hw/usb/dev-mtp.c
@@ -548,7 +548,7 @@ static MTPData *usb_mtp_get_device_info(MTPState *s, 
MTPControl *c)
 usb_mtp_add_wstr(d, L"" MTP_MANUFACTURER);
 usb_mtp_add_wstr(d, L"" MTP_PRODUCT);
 usb_mtp_add_wstr(d, L"0.1");
-usb_mtp_add_wstr(d, L"123456789abcdef123456789abcdef");
+usb_mtp_add_wstr(d, L"0123456789abcdef0123456789abcdef");
 
 return d;
 }
-- 
1.8.3.1




[Qemu-devel] [PULL v2 2/7] E820: Add interface for accessing e820 table

2014-05-05 Thread Gerd Hoffmann
From: "Gabriel L. Somlo" 

Add the following two functions:

  - e820_get_num_entries() - query the size of the e820 table
  - e820_get_entry() - grab an entry matching a given set of criteria

This interface is currently necessary for creating type 19
(memory array mapped address) structures in smbios.

Signed-off-by: Gabriel Somlo 
Signed-off-by: Gerd Hoffmann 
---
 hw/i386/pc.c | 15 +++
 include/hw/i386/pc.h |  2 ++
 2 files changed, 17 insertions(+)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 14f0d91..aefb315 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -612,6 +612,21 @@ int e820_add_entry(uint64_t address, uint64_t length, 
uint32_t type)
 return e820_entries;
 }
 
+int e820_get_num_entries(void)
+{
+return e820_entries;
+}
+
+bool e820_get_entry(int idx, uint32_t type, uint64_t *address, uint64_t 
*length)
+{
+if (idx < e820_entries && e820_table[idx].type == cpu_to_le32(type)) {
+*address = le64_to_cpu(e820_table[idx].address);
+*length = le64_to_cpu(e820_table[idx].length);
+return true;
+}
+return false;
+}
+
 /* Calculates the limit to CPU APIC ID values
  *
  * This function returns the limit for the APIC ID value, so that all
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 9010246..9f26e14 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -239,6 +239,8 @@ uint16_t pvpanic_port(void);
 #define E820_UNUSABLE   5
 
 int e820_add_entry(uint64_t, uint64_t, uint32_t);
+int e820_get_num_entries(void);
+bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
 
 #define PC_Q35_COMPAT_1_7 \
 PC_COMPAT_1_7, \
-- 
1.8.3.1




[Qemu-devel] [PULL v2 1/7] pc: add 2.1 machine type

2014-05-05 Thread Gerd Hoffmann
From: "Michael S. Tsirkin" 

At the moment, 2.1 and 2.0 machines are identical.
As several people are working on incompatible changes
to the PC machine, collaboration will be made easier
by merging this place-holder.

Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Gerd Hoffmann 
---
 hw/i386/pc_piix.c | 28 
 hw/i386/pc_q35.c  | 26 +++---
 2 files changed, 47 insertions(+), 7 deletions(-)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 7930a26..810f323 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -262,8 +262,13 @@ static void pc_init_pci(QEMUMachineInitArgs *args)
 pc_init1(args, 1, 1);
 }
 
+static void pc_compat_2_0(QEMUMachineInitArgs *args)
+{
+}
+
 static void pc_compat_1_7(QEMUMachineInitArgs *args)
 {
+pc_compat_2_0(args);
 smbios_type1_defaults = false;
 gigabyte_align = false;
 option_rom_has_mr = true;
@@ -303,6 +308,12 @@ static void pc_compat_1_2(QEMUMachineInitArgs *args)
 x86_cpu_compat_disable_kvm_features(FEAT_KVM, KVM_FEATURE_PV_EOI);
 }
 
+static void pc_init_pci_2_0(QEMUMachineInitArgs *args)
+{
+pc_compat_2_0(args);
+pc_init_pci(args);
+}
+
 static void pc_init_pci_1_7(QEMUMachineInitArgs *args)
 {
 pc_compat_1_7(args);
@@ -383,18 +394,26 @@ static void pc_xen_hvm_init(QEMUMachineInitArgs *args)
 .desc = "Standard PC (i440FX + PIIX, 1996)", \
 .hot_add_cpu = pc_hot_add_cpu
 
-#define PC_I440FX_2_0_MACHINE_OPTIONS   \
+#define PC_I440FX_2_1_MACHINE_OPTIONS   \
 PC_I440FX_MACHINE_OPTIONS,  \
 .default_machine_opts = "firmware=bios-256k.bin"
 
-static QEMUMachine pc_i440fx_machine_v2_0 = {
-PC_I440FX_2_0_MACHINE_OPTIONS,
-.name = "pc-i440fx-2.0",
+static QEMUMachine pc_i440fx_machine_v2_1 = {
+PC_I440FX_2_1_MACHINE_OPTIONS,
+.name = "pc-i440fx-2.1",
 .alias = "pc",
 .init = pc_init_pci,
 .is_default = 1,
 };
 
+#define PC_I440FX_2_0_MACHINE_OPTIONS PC_I440FX_2_1_MACHINE_OPTIONS
+
+static QEMUMachine pc_i440fx_machine_v2_0 = {
+PC_I440FX_2_0_MACHINE_OPTIONS,
+.name = "pc-i440fx-2.0",
+.init = pc_init_pci_2_0,
+};
+
 #define PC_I440FX_1_7_MACHINE_OPTIONS PC_I440FX_MACHINE_OPTIONS
 
 static QEMUMachine pc_i440fx_machine_v1_7 = {
@@ -817,6 +836,7 @@ static QEMUMachine xenfv_machine = {
 
 static void pc_machine_init(void)
 {
+qemu_register_machine(&pc_i440fx_machine_v2_1);
 qemu_register_machine(&pc_i440fx_machine_v2_0);
 qemu_register_machine(&pc_i440fx_machine_v1_7);
 qemu_register_machine(&pc_i440fx_machine_v1_6);
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index c844dc2..89cf10c 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -240,8 +240,13 @@ static void pc_q35_init(QEMUMachineInitArgs *args)
 }
 }
 
+static void pc_compat_2_0(QEMUMachineInitArgs *args)
+{
+}
+
 static void pc_compat_1_7(QEMUMachineInitArgs *args)
 {
+pc_compat_2_0(args);
 smbios_type1_defaults = false;
 gigabyte_align = false;
 option_rom_has_mr = true;
@@ -268,6 +273,12 @@ static void pc_compat_1_4(QEMUMachineInitArgs *args)
 x86_cpu_compat_set_features("Westmere", FEAT_1_ECX, 0, 
CPUID_EXT_PCLMULQDQ);
 }
 
+static void pc_q35_init_2_0(QEMUMachineInitArgs *args)
+{
+pc_compat_2_0(args);
+pc_q35_init(args);
+}
+
 static void pc_q35_init_1_7(QEMUMachineInitArgs *args)
 {
 pc_compat_1_7(args);
@@ -297,15 +308,23 @@ static void pc_q35_init_1_4(QEMUMachineInitArgs *args)
 .desc = "Standard PC (Q35 + ICH9, 2009)", \
 .hot_add_cpu = pc_hot_add_cpu
 
-#define PC_Q35_2_0_MACHINE_OPTIONS  \
+#define PC_Q35_2_1_MACHINE_OPTIONS  \
 PC_Q35_MACHINE_OPTIONS, \
 .default_machine_opts = "firmware=bios-256k.bin"
 
+static QEMUMachine pc_q35_machine_v2_1 = {
+PC_Q35_2_1_MACHINE_OPTIONS,
+.name = "pc-q35-2.1",
+.alias = "q35",
+.init = pc_q35_init,
+};
+
+#define PC_Q35_2_0_MACHINE_OPTIONS PC_Q35_2_1_MACHINE_OPTIONS
+
 static QEMUMachine pc_q35_machine_v2_0 = {
 PC_Q35_2_0_MACHINE_OPTIONS,
 .name = "pc-q35-2.0",
-.alias = "q35",
-.init = pc_q35_init,
+.init = pc_q35_init_2_0,
 };
 
 #define PC_Q35_1_7_MACHINE_OPTIONS PC_Q35_MACHINE_OPTIONS
@@ -358,6 +377,7 @@ static QEMUMachine pc_q35_machine_v1_4 = {
 
 static void pc_q35_machine_init(void)
 {
+qemu_register_machine(&pc_q35_machine_v2_1);
 qemu_register_machine(&pc_q35_machine_v2_0);
 qemu_register_machine(&pc_q35_machine_v1_7);
 qemu_register_machine(&pc_q35_machine_v1_6);
-- 
1.8.3.1




[Qemu-devel] [PULL v2 0/7] smbios: make qemu generate smbios tables

2014-05-05 Thread Gerd Hoffmann
  Hi,

This patch series makes qemu generate smbios tables for 2.1 & newer
machine types.  Most patches are created by Gabriel L. Somlo.  For the
new machine type I've picked mst's patch though, so git should have an
easier job sorting things in case the same thing comes in through
another branch.

v2: fixed build failure on 32bit.

please pull,
  Gerd

The following changes since commit fdaad4715ae9e998fd0595bedfb16fdaf0c68ccc:

  Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20140501' 
into staging (2014-05-02 11:32:00 +0100)

are available in the git repository at:


  git://git.kraxel.org/qemu tags/pull-smbios-2

for you to fetch changes up to c97294ec1b9e36887e119589d456557d72ab37b5:

  SMBIOS: Build aggregate smbios tables and entry point (2014-05-05 13:14:48 
+0200)


smbios: make qemu generate smbios tables.


Gabriel L. Somlo (6):
  E820: Add interface for accessing e820 table
  SMBIOS: Rename symbols to better reflect future use
  SMBIOS: Update header file definitions
  SMBIOS: Use macro to set smbios defaults
  SMBIOS: Use bitmaps to prevent incompatible comand line options
  SMBIOS: Build aggregate smbios tables and entry point

Michael S. Tsirkin (1):
  pc: add 2.1 machine type

 hw/i386/pc.c |  39 ++-
 hw/i386/pc_piix.c|  44 ++-
 hw/i386/pc_q35.c |  38 ++-
 hw/i386/smbios.c | 789 +++
 include/hw/i386/pc.h |   2 +
 include/hw/i386/smbios.h |  99 --
 6 files changed, 902 insertions(+), 109 deletions(-)



[Qemu-devel] [PULL v2 6/7] SMBIOS: Use bitmaps to prevent incompatible comand line options

2014-05-05 Thread Gerd Hoffmann
From: "Gabriel L. Somlo" 

Replace existing smbios_check_collision() functionality with
a pair of bitmaps: have_binfile_bitmap and have_fields_bitmap.
Bits corresponding to each smbios type are set by smbios_entry_add(),
which also uses the bitmaps to ensure that binary blobs and field
values are never accepted for the same type.

These bitmaps will also be used in the future to decide whether
or not to build a full table for a given smbios type.

Signed-off-by: Gabriel Somlo 
Signed-off-by: Gerd Hoffmann 
---
 hw/i386/smbios.c | 50 +++-
 include/hw/i386/smbios.h |  2 ++
 2 files changed, 22 insertions(+), 30 deletions(-)

diff --git a/hw/i386/smbios.c b/hw/i386/smbios.c
index 9f83bfb..6bbfd15 100644
--- a/hw/i386/smbios.c
+++ b/hw/i386/smbios.c
@@ -51,11 +51,8 @@ static size_t smbios_entries_len;
 static int smbios_type4_count = 0;
 static bool smbios_immutable;
 
-static struct {
-bool seen;
-int headertype;
-Location loc;
-} first_opt[2];
+static DECLARE_BITMAP(have_binfile_bitmap, SMBIOS_MAX_TYPE+1);
+static DECLARE_BITMAP(have_fields_bitmap, SMBIOS_MAX_TYPE+1);
 
 static struct {
 const char *vendor, *version, *date;
@@ -166,29 +163,6 @@ static void smbios_validate_table(void)
 }
 }
 
-/*
- * To avoid unresolvable overlaps in data, don't allow both
- * tables and fields for the same smbios type.
- */
-static void smbios_check_collision(int type, int entry)
-{
-if (type < ARRAY_SIZE(first_opt)) {
-if (first_opt[type].seen) {
-if (first_opt[type].headertype != entry) {
-error_report("Can't mix file= and type= for same type");
-loc_push_restore(&first_opt[type].loc);
-error_report("This is the conflicting setting");
-loc_pop(&first_opt[type].loc);
-exit(1);
-}
-} else {
-first_opt[type].seen = true;
-first_opt[type].headertype = entry;
-loc_save(&first_opt[type].loc);
-}
-}
-}
-
 
 /* legacy setup functions for <= 2.0 machines */
 static void smbios_add_field(int type, int offset, const void *data, size_t 
len)
@@ -337,7 +311,14 @@ void smbios_entry_add(QemuOpts *opts)
 }
 
 header = (struct smbios_structure_header *)(table->data);
-smbios_check_collision(header->type, SMBIOS_TABLE_ENTRY);
+
+if (test_bit(header->type, have_fields_bitmap)) {
+error_report("can't load type %d struct, fields already 
specified!",
+ header->type);
+exit(1);
+}
+set_bit(header->type, have_binfile_bitmap);
+
 if (header->type == 4) {
 smbios_type4_count++;
 }
@@ -352,7 +333,16 @@ void smbios_entry_add(QemuOpts *opts)
 if (val) {
 unsigned long type = strtoul(val, NULL, 0);
 
-smbios_check_collision(type, SMBIOS_FIELD_ENTRY);
+if (type > SMBIOS_MAX_TYPE) {
+error_report("out of range!");
+exit(1);
+}
+
+if (test_bit(type, have_binfile_bitmap)) {
+error_report("can't add fields, binary file already loaded!");
+exit(1);
+}
+set_bit(type, have_fields_bitmap);
 
 switch (type) {
 case 0:
diff --git a/include/hw/i386/smbios.h b/include/hw/i386/smbios.h
index 777e025..3a9361d 100644
--- a/include/hw/i386/smbios.h
+++ b/include/hw/i386/smbios.h
@@ -15,6 +15,8 @@
 
 #include "qemu/option.h"
 
+#define SMBIOS_MAX_TYPE 127
+
 void smbios_entry_add(QemuOpts *opts);
 void smbios_set_defaults(const char *manufacturer, const char *product,
  const char *version);
-- 
1.8.3.1




[Qemu-devel] [PULL v2 3/7] SMBIOS: Rename symbols to better reflect future use

2014-05-05 Thread Gerd Hoffmann
From: "Gabriel L. Somlo" 

Rename the following symbols:

  - smbios_set_type1_defaults() to the more general smbios_set_defaults();
  - bool smbios_type1_defaults to the more general smbios_defaults;
  - smbios_get_table() to smbios_get_table_legacy();

This patch contains no functional changes.

Signed-off-by: Gabriel Somlo 
Signed-off-by: Gerd Hoffmann 
---
 hw/i386/pc.c |  2 +-
 hw/i386/pc_piix.c| 14 +++---
 hw/i386/pc_q35.c | 10 +-
 hw/i386/smbios.c | 18 --
 include/hw/i386/smbios.h |  6 +++---
 5 files changed, 28 insertions(+), 22 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index aefb315..7155269 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -670,7 +670,7 @@ static FWCfgState *bochs_bios_init(void)
  acpi_tables, acpi_tables_len);
 fw_cfg_add_i32(fw_cfg, FW_CFG_IRQ0_OVERRIDE, kvm_allows_irq0_override());
 
-smbios_table = smbios_get_table(&smbios_len);
+smbios_table = smbios_get_table_legacy(&smbios_len);
 if (smbios_table)
 fw_cfg_add_bytes(fw_cfg, FW_CFG_SMBIOS_ENTRIES,
  smbios_table, smbios_len);
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 810f323..e4e176e 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -60,7 +60,7 @@ static const int ide_irq[MAX_IDE_BUS] = { 14, 15 };
 
 static bool has_pci_info;
 static bool has_acpi_build = true;
-static bool smbios_type1_defaults = true;
+static bool smbios_defaults = true;
 /* Make sure that guest addresses aligned at 1Gbyte boundaries get mapped to
  * host addresses aligned at 1Gbyte boundaries.  This way we can use 1GByte
  * pages in the host.
@@ -143,10 +143,10 @@ static void pc_init1(QEMUMachineInitArgs *args,
 guest_info->has_pci_info = has_pci_info;
 guest_info->isapc_ram_fw = !pci_enabled;
 
-if (smbios_type1_defaults) {
+if (smbios_defaults) {
 /* These values are guest ABI, do not change */
-smbios_set_type1_defaults("QEMU", "Standard PC (i440FX + PIIX, 1996)",
-  args->machine->name);
+smbios_set_defaults("QEMU", "Standard PC (i440FX + PIIX, 1996)",
+args->machine->name);
 }
 
 /* allocate ram and load rom/bios */
@@ -269,7 +269,7 @@ static void pc_compat_2_0(QEMUMachineInitArgs *args)
 static void pc_compat_1_7(QEMUMachineInitArgs *args)
 {
 pc_compat_2_0(args);
-smbios_type1_defaults = false;
+smbios_defaults = false;
 gigabyte_align = false;
 option_rom_has_mr = true;
 x86_cpu_compat_disable_kvm_features(FEAT_1_ECX, CPUID_EXT_X2APIC);
@@ -356,7 +356,7 @@ static void pc_init_pci_no_kvmclock(QEMUMachineInitArgs 
*args)
 {
 has_pci_info = false;
 has_acpi_build = false;
-smbios_type1_defaults = false;
+smbios_defaults = false;
 x86_cpu_compat_disable_kvm_features(FEAT_KVM, KVM_FEATURE_PV_EOI);
 enable_compat_apic_id_mode();
 pc_init1(args, 1, 0);
@@ -366,7 +366,7 @@ static void pc_init_isa(QEMUMachineInitArgs *args)
 {
 has_pci_info = false;
 has_acpi_build = false;
-smbios_type1_defaults = false;
+smbios_defaults = false;
 if (!args->cpu_model) {
 args->cpu_model = "486";
 }
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 89cf10c..312e1ae 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -50,7 +50,7 @@
 
 static bool has_pci_info;
 static bool has_acpi_build = true;
-static bool smbios_type1_defaults = true;
+static bool smbios_defaults = true;
 /* Make sure that guest addresses aligned at 1Gbyte boundaries get mapped to
  * host addresses aligned at 1Gbyte boundaries.  This way we can use 1GByte
  * pages in the host.
@@ -130,10 +130,10 @@ static void pc_q35_init(QEMUMachineInitArgs *args)
 guest_info->isapc_ram_fw = false;
 guest_info->has_acpi_build = has_acpi_build;
 
-if (smbios_type1_defaults) {
+if (smbios_defaults) {
 /* These values are guest ABI, do not change */
-smbios_set_type1_defaults("QEMU", "Standard PC (Q35 + ICH9, 2009)",
-  args->machine->name);
+smbios_set_defaults("QEMU", "Standard PC (Q35 + ICH9, 2009)",
+args->machine->name);
 }
 
 /* allocate ram and load rom/bios */
@@ -247,7 +247,7 @@ static void pc_compat_2_0(QEMUMachineInitArgs *args)
 static void pc_compat_1_7(QEMUMachineInitArgs *args)
 {
 pc_compat_2_0(args);
-smbios_type1_defaults = false;
+smbios_defaults = false;
 gigabyte_align = false;
 option_rom_has_mr = true;
 x86_cpu_compat_disable_kvm_features(FEAT_1_ECX, CPUID_EXT_X2APIC);
diff --git a/hw/i386/smbios.c b/hw/i386/smbios.c
index e8f41ad..e734d4c 100644
--- a/hw/i386/smbios.c
+++ b/hw/i386/smbios.c
@@ -21,9 +21,8 @@
 #include "hw/i386/smbios.h"
 #include "hw/loader.h"
 
-/*
- * Structures shared with the BIOS
- */
+
+/* legacy structures and constants for <= 2.0 machines */
 struct smbios_header {
 uin

Re: [Qemu-devel] [PATCH] migration: Increase default max_downtime from 30ms to 300ms

2014-05-05 Thread Juan Quintela
Alexey Kardashevskiy  wrote:
> On 04/13/2014 12:38 AM, Alexey Kardashevskiy wrote:
>> On 03/27/2014 08:01 PM, Markus Armbruster wrote:
>>> Adding Juan.
>> 
>> 
>> Ping?

Patch is OK for me.

As sender says, with guests doing anything/bigger than 1GB RAM is
basically implosible to get into the 30ms downtime.

Later, Juan.

>
>
> Ping?
>
>
>> 
>>>
>>> Alexey Kardashevskiy  writes:
>>>
 The existing timeout is 30ms which on 100MB/s (1Gbit) gives us
 3MB/s rate maximum. If we put some load on the guest, it is easy to
 get page dirtying rate too big so live migration will never complete.
 In the case of libvirt that means that the guest will be stopped
 anyway after a timeout specified in the "virsh migrate" command and
 this normally generates even bigger delay.

 This changes max_downtime to 300ms which seems to be more
 reasonable value.

 Signed-off-by: Alexey Kardashevskiy 
 ---
  migration.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/migration.c b/migration.c
 index e0e24d4..02bbce9 100644
 --- a/migration.c
 +++ b/migration.c
 @@ -144,7 +144,7 @@ void process_incoming_migration(QEMUFile *f)
   * the choice of nanoseconds is because it is the maximum resolution that
   * get_clock() can achieve. It is an internal measure. All user-visible
   * units must be in seconds */
 -static uint64_t max_downtime = 3000;
 +static uint64_t max_downtime = 3;
  
  uint64_t migrate_max_downtime(void)
  {
>> 
>> 



[Qemu-devel] [PULL v2 4/7] SMBIOS: Update header file definitions

2014-05-05 Thread Gerd Hoffmann
From: "Gabriel L. Somlo" 

Add definitions for smbios entry point (anchor), and for type 2
(base board) structure which is required by some versions of OS X.

Remove definition for type 20 (memory device mapped address)
structure, which is no longer required as of smbios spec v2.5.

Update all other structure definitions to bring them into
compliance with smbios spec v2.8.

This patch contains no functional changes.

Signed-off-by: Gabriel Somlo 
Signed-off-by: Gerd Hoffmann 
---
 include/hw/i386/smbios.h | 88 
 1 file changed, 66 insertions(+), 22 deletions(-)

diff --git a/include/hw/i386/smbios.h b/include/hw/i386/smbios.h
index f808199..777e025 100644
--- a/include/hw/i386/smbios.h
+++ b/include/hw/i386/smbios.h
@@ -24,6 +24,26 @@ uint8_t *smbios_get_table_legacy(size_t *length);
  * SMBIOS spec defined tables
  */
 
+/* SMBIOS entry point (anchor).
+ * BIOS must place this at a 16-bit-aligned address between 0xf and 
0xf.
+ */
+struct smbios_entry_point {
+uint8_t anchor_string[4];
+uint8_t checksum;
+uint8_t length;
+uint8_t smbios_major_version;
+uint8_t smbios_minor_version;
+uint16_t max_structure_size;
+uint8_t entry_point_revision;
+uint8_t formatted_area[5];
+uint8_t intermediate_anchor_string[5];
+uint8_t intermediate_checksum;
+uint16_t structure_table_length;
+uint32_t structure_table_address;
+uint16_t number_of_structures;
+uint8_t smbios_bcd_revision;
+} QEMU_PACKED;
+
 /* This goes at the beginning of every SMBIOS structure. */
 struct smbios_structure_header {
 uint8_t type;
@@ -60,7 +80,23 @@ struct smbios_type_1 {
 uint8_t family_str;
 } QEMU_PACKED;
 
-/* SMBIOS type 3 - System Enclosure (v2.3) */
+/* SMBIOS type 2 - Base Board */
+struct smbios_type_2 {
+struct smbios_structure_header header;
+uint8_t manufacturer_str;
+uint8_t product_str;
+uint8_t version_str;
+uint8_t serial_number_str;
+uint8_t asset_tag_number_str;
+uint8_t feature_flags;
+uint8_t location_str;
+uint16_t chassis_handle;
+uint8_t board_type;
+uint8_t contained_element_count;
+/* contained elements follow */
+} QEMU_PACKED;
+
+/* SMBIOS type 3 - System Enclosure (v2.7) */
 struct smbios_type_3 {
 struct smbios_structure_header header;
 uint8_t manufacturer_str;
@@ -76,10 +112,11 @@ struct smbios_type_3 {
 uint8_t height;
 uint8_t number_of_power_cords;
 uint8_t contained_element_count;
-// contained elements follow
+uint8_t sku_number_str;
+/* contained elements follow */
 } QEMU_PACKED;
 
-/* SMBIOS type 4 - Processor Information (v2.0) */
+/* SMBIOS type 4 - Processor Information (v2.6) */
 struct smbios_type_4 {
 struct smbios_structure_header header;
 uint8_t socket_designation_str;
@@ -97,11 +134,17 @@ struct smbios_type_4 {
 uint16_t l1_cache_handle;
 uint16_t l2_cache_handle;
 uint16_t l3_cache_handle;
+uint8_t serial_number_str;
+uint8_t asset_tag_number_str;
+uint8_t part_number_str;
+uint8_t core_count;
+uint8_t core_enabled;
+uint8_t thread_count;
+uint16_t processor_characteristics;
+uint16_t processor_family2;
 } QEMU_PACKED;
 
-/* SMBIOS type 16 - Physical Memory Array
- *   Associated with one type 17 (Memory Device).
- */
+/* SMBIOS type 16 - Physical Memory Array (v2.7) */
 struct smbios_type_16 {
 struct smbios_structure_header header;
 uint8_t location;
@@ -110,10 +153,10 @@ struct smbios_type_16 {
 uint32_t maximum_capacity;
 uint16_t memory_error_information_handle;
 uint16_t number_of_memory_devices;
+uint64_t extended_maximum_capacity;
 } QEMU_PACKED;
-/* SMBIOS type 17 - Memory Device
- *   Associated with one type 19
- */
+
+/* SMBIOS type 17 - Memory Device (v2.8) */
 struct smbios_type_17 {
 struct smbios_structure_header header;
 uint16_t physical_memory_array_handle;
@@ -127,27 +170,28 @@ struct smbios_type_17 {
 uint8_t bank_locator_str;
 uint8_t memory_type;
 uint16_t type_detail;
+uint16_t speed;
+uint8_t manufacturer_str;
+uint8_t serial_number_str;
+uint8_t asset_tag_number_str;
+uint8_t part_number_str;
+uint8_t attributes;
+uint32_t extended_size;
+uint32_t configured_clock_speed;
+uint32_t minimum_voltage;
+uint32_t maximum_voltage;
+uint32_t configured_voltage;
 } QEMU_PACKED;
 
-/* SMBIOS type 19 - Memory Array Mapped Address */
+/* SMBIOS type 19 - Memory Array Mapped Address (v2.7) */
 struct smbios_type_19 {
 struct smbios_structure_header header;
 uint32_t starting_address;
 uint32_t ending_address;
 uint16_t memory_array_handle;
 uint8_t partition_width;
-} QEMU_PACKED;
-
-/* SMBIOS type 20 - Memory Device Mapped Address */
-struct smbios_type_20 {
-struct smbios_structure_header header;
-uint32_t starting_address;
-uint32_t ending_address;
-uint16_t memory_device_handle;
-uint16_t memory_array_ma

Re: [Qemu-devel] [v4 PATCH 0/2] apic: bump emulated lapic version to 0x14

2014-05-05 Thread Alexander Graf

On 05/02/2014 08:02 PM, Gabriel L. Somlo wrote:

I decided to split the patch into the boilerplate compat_props for v2.0
and older (1/2) and the actual lapic-version "payload" (2/2).

The first (boilerplate) patch depends on another patch for which a pull
request is already pending:

http://lists.nongnu.org/archive/html/qemu-devel/2014-04/msg04728.html,

Please let me know what you all think.


From what I understand about the compat bits (which is little) this 
makes a lot of sense. And the version is a proper property now, which is 
great :).


Acked-by: Alexander Graf 


Alex



Re: [Qemu-devel] [RFC PATCH V4 5/6] target-arm: Common kvm_arm_vcpu_init() for KVM ARM and KVM ARM64

2014-05-05 Thread Pranavkumar Sawargaonkar
Hi Peter,

On 5 May 2014 16:14, Peter Maydell  wrote:
> On 5 May 2014 10:00, Pranavkumar Sawargaonkar  wrote:
>> Introduce a common kvm_arm_vcpu_init() for doing KVM_ARM_VCPU_INIT
>> ioctl in KVM ARM and KVM ARM64. This also helps us factor-out few
>> common code lines from kvm_arch_init_vcpu() for KVM ARM/ARM64.
>>
>> Signed-off-by: Pranavkumar Sawargaonkar 
>> Signed-off-by: Anup Patel 
>> ---
>>  target-arm/kvm.c |   23 +++
>>  target-arm/kvm32.c   |   18 +++---
>>  target-arm/kvm64.c   |   22 --
>>  target-arm/kvm_arm.h |   14 ++
>>  4 files changed, 48 insertions(+), 29 deletions(-)
>>
>> diff --git a/target-arm/kvm.c b/target-arm/kvm.c
>> index 39202d7..55bc3a3 100644
>> --- a/target-arm/kvm.c
>> +++ b/target-arm/kvm.c
>> @@ -27,6 +27,29 @@ const KVMCapabilityInfo kvm_arch_required_capabilities[] 
>> = {
>>  KVM_CAP_LAST_INFO
>>  };
>>
>> +int kvm_arm_vcpu_init(CPUState *cs, uint32_t feature0_extra)
>> +{
>> +ARMCPU *cpu = ARM_CPU(cs);
>> +struct kvm_vcpu_init init;
>> +
>> +if (cpu->kvm_target == QEMU_KVM_ARM_TARGET_NONE) {
>> +fprintf(stderr, "KVM is not supported for this guest CPU type\n");
>> +return -EINVAL;
>> +}
>> +
>> +init.target = cpu->kvm_target;
>> +memset(init.features, 0, sizeof(init.features));
>> +if (cpu->start_powered_off) {
>> +init.features[0] |= 1 << KVM_ARM_VCPU_POWER_OFF;
>> +}
>> +if (kvm_check_extension(cs->kvm_state, KVM_CAP_ARM_PSCI_0_2)) {
>> +init.features[0] |= 1 << KVM_ARM_VCPU_PSCI_0_2;
>> +}
>> +init.features[0] |= feature0_extra;
>> +
>> +return kvm_vcpu_ioctl(cs, KVM_ARM_VCPU_INIT, &init);
>> +}
>
> I said back in the review comments for v2 of this series that we
> didn't need to do all this just for reset. Put the features word in
> cpu along with kvm_target:
> http://patchwork.ozlabs.org/patch/335900/

Sure, I will do it.

>
> thanks
> -- PMM
Thanks,
Pranav



Re: [Qemu-devel] [PATCH 06/22] curl: implement .bdrv_detach/attach_aio_context()

2014-05-05 Thread Stefan Hajnoczi
On Sun, May 04, 2014 at 07:00:26PM +0800, Fam Zheng wrote:
> On Thu, 05/01 16:54, Stefan Hajnoczi wrote:
> > The curl block driver uses fd handlers, timers, and BHs.  The fd
> > handlers and timers are managed on behalf of libcurl, which controls
> > them using callback functions that the block driver implements.
> > 
> > The simplest way to implement .bdrv_detach/attach_aio_context() is to
> > clean up libcurl in the old event loop and initialize it again in the
> > new event loop.  We do not need to keep track of anything since there
> > are no pending requests when the AioContext is changed.
> > 
> > Also make sure to use aio_set_fd_handler() instead of
> > qemu_aio_set_fd_handler() and aio_bh_new() instead of qemu_bh_new() so
> > the current AioContext is passed in.
> > 
> > Cc: Alexander Graf 
> > Cc: Fam Zheng 
> > Signed-off-by: Stefan Hajnoczi 
> 
> Might need to rebase on current master because of the latest curl fixes.
> 
> The patch itself looks good. Minor comments below.
> 
> > ---
> >  block/curl.c | 194 
> > +++
> >  1 file changed, 116 insertions(+), 78 deletions(-)
> > 
> > diff --git a/block/curl.c b/block/curl.c
> > index 6731d28..88638ec 100644
> > --- a/block/curl.c
> > +++ b/block/curl.c
> > @@ -430,6 +434,55 @@ static void curl_parse_filename(const char *filename, 
> > QDict *options,
> >  g_free(file);
> >  }
> >  
> > +static void curl_detach_aio_context(BlockDriverState *bs)
> > +{
> > +BDRVCURLState *s = bs->opaque;
> > +int i;
> > +
> > +for (i = 0; i < CURL_NUM_STATES; i++) {
> > +if (s->states[i].in_use) {
> > +curl_clean_state(&s->states[i]);
> > +}
> > +if (s->states[i].curl) {
> > +curl_easy_cleanup(s->states[i].curl);
> > +s->states[i].curl = NULL;
> > +}
> > +if (s->states[i].orig_buf) {
> > +g_free(s->states[i].orig_buf);
> > +s->states[i].orig_buf = NULL;
> > +}
> > +}
> > +if (s->multi) {
> > +curl_multi_cleanup(s->multi);
> > +s->multi = NULL;
> > +}
> > +
> > +timer_del(&s->timer);
> > +}
> > +
> > +static void curl_attach_aio_context(BlockDriverState *bs,
> > +AioContext *new_context)
> > +{
> > +BDRVCURLState *s = bs->opaque;
> > +
> > +aio_timer_init(new_context, &s->timer,
> > +   QEMU_CLOCK_REALTIME, SCALE_NS,
> > +   curl_multi_timeout_do, s);
> > +
> > +// Now we know the file exists and its size, so let's
> > +// initialize the multi interface!
> 
> I would keep this comment where it was. :)

Good point.

> > +
> > +s->multi = curl_multi_init();
> 
> Should we assert bdrv_attach_aio_context() is never called repeatedly or
> without a preceding bdrv_detach_aio_context()? Otherwise s->multi could leak.

I'll add the appropriate assertions.

> > +s->aio_context = new_context;
> > +curl_multi_setopt(s->multi, CURLMOPT_SOCKETDATA, s);
> > +curl_multi_setopt(s->multi, CURLMOPT_SOCKETFUNCTION, curl_sock_cb);
> > +#ifdef NEED_CURL_TIMER_CALLBACK
> > +curl_multi_setopt(s->multi, CURLMOPT_TIMERDATA, s);
> > +curl_multi_setopt(s->multi, CURLMOPT_TIMERFUNCTION, curl_timer_cb);
> > +#endif
> > +curl_multi_do(s);
> 
> If you rebase to master, this call to curl_multi_do() is gone, among other
> changes.

Okay.  I'll rebase and resolve the conflicts.

Stefan



[Qemu-devel] [PULL v2 7/7] SMBIOS: Build aggregate smbios tables and entry point

2014-05-05 Thread Gerd Hoffmann
From: "Gabriel L. Somlo" 

Build an aggregate set of smbios tables and an entry point structure.

Insert tables and entry point into fw_cfg respectively under
"etc/smbios/smbios-tables" and "etc/smbios/smbios-anchor".

Machine types <= 2.0 will for now continue using field-by-field
overrides to SeaBIOS defaults, but for machine types 2.1 and up we
expect the BIOS to look for and use the aggregate tables generated
by this patch.

Signed-off-by: Gabriel Somlo 

[ kraxel: fix 32bit build ]

Signed-off-by: Gerd Hoffmann 
---
 hw/i386/pc.c |  24 +-
 hw/i386/pc_piix.c|   4 +-
 hw/i386/pc_q35.c |   4 +-
 hw/i386/smbios.c | 708 +--
 include/hw/i386/smbios.h |   5 +-
 5 files changed, 720 insertions(+), 25 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 7155269..07de238 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -642,8 +642,8 @@ static unsigned int pc_apic_id_limit(unsigned int max_cpus)
 static FWCfgState *bochs_bios_init(void)
 {
 FWCfgState *fw_cfg;
-uint8_t *smbios_table;
-size_t smbios_len;
+uint8_t *smbios_tables, *smbios_anchor;
+size_t smbios_tables_len, smbios_anchor_len;
 uint64_t *numa_fw_cfg;
 int i, j;
 unsigned int apic_id_limit = pc_apic_id_limit(max_cpus);
@@ -670,10 +670,21 @@ static FWCfgState *bochs_bios_init(void)
  acpi_tables, acpi_tables_len);
 fw_cfg_add_i32(fw_cfg, FW_CFG_IRQ0_OVERRIDE, kvm_allows_irq0_override());
 
-smbios_table = smbios_get_table_legacy(&smbios_len);
-if (smbios_table)
+smbios_tables = smbios_get_table_legacy(&smbios_tables_len);
+if (smbios_tables) {
 fw_cfg_add_bytes(fw_cfg, FW_CFG_SMBIOS_ENTRIES,
- smbios_table, smbios_len);
+ smbios_tables, smbios_tables_len);
+}
+
+smbios_get_tables(&smbios_tables, &smbios_tables_len,
+  &smbios_anchor, &smbios_anchor_len);
+if (smbios_anchor) {
+fw_cfg_add_file(fw_cfg, "etc/smbios/smbios-tables",
+smbios_tables, smbios_tables_len);
+fw_cfg_add_file(fw_cfg, "etc/smbios/smbios-anchor",
+smbios_anchor, smbios_anchor_len);
+}
+
 fw_cfg_add_bytes(fw_cfg, FW_CFG_E820_TABLE,
  &e820_reserve, sizeof(e820_reserve));
 fw_cfg_add_file(fw_cfg, "etc/e820", e820_table,
@@ -1042,6 +1053,9 @@ void pc_cpus_init(const char *cpu_model, DeviceState 
*icc_bridge)
 sysbus_mmio_map_overlap(SYS_BUS_DEVICE(icc_bridge), 0,
 APIC_DEFAULT_ADDRESS, 0x1000);
 }
+
+/* tell smbios about cpuid version and features */
+smbios_set_cpuid(cpu->env.cpuid_version, cpu->env.features[FEAT_1_EDX]);
 }
 
 /* pci-info ROM file. Little endian format */
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index e4e176e..ea72502 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -61,6 +61,7 @@ static const int ide_irq[MAX_IDE_BUS] = { 14, 15 };
 static bool has_pci_info;
 static bool has_acpi_build = true;
 static bool smbios_defaults = true;
+static bool smbios_legacy_mode;
 /* Make sure that guest addresses aligned at 1Gbyte boundaries get mapped to
  * host addresses aligned at 1Gbyte boundaries.  This way we can use 1GByte
  * pages in the host.
@@ -146,7 +147,7 @@ static void pc_init1(QEMUMachineInitArgs *args,
 if (smbios_defaults) {
 /* These values are guest ABI, do not change */
 smbios_set_defaults("QEMU", "Standard PC (i440FX + PIIX, 1996)",
-args->machine->name);
+args->machine->name, smbios_legacy_mode);
 }
 
 /* allocate ram and load rom/bios */
@@ -264,6 +265,7 @@ static void pc_init_pci(QEMUMachineInitArgs *args)
 
 static void pc_compat_2_0(QEMUMachineInitArgs *args)
 {
+smbios_legacy_mode = true;
 }
 
 static void pc_compat_1_7(QEMUMachineInitArgs *args)
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 312e1ae..3306f89 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -51,6 +51,7 @@
 static bool has_pci_info;
 static bool has_acpi_build = true;
 static bool smbios_defaults = true;
+static bool smbios_legacy_mode;
 /* Make sure that guest addresses aligned at 1Gbyte boundaries get mapped to
  * host addresses aligned at 1Gbyte boundaries.  This way we can use 1GByte
  * pages in the host.
@@ -133,7 +134,7 @@ static void pc_q35_init(QEMUMachineInitArgs *args)
 if (smbios_defaults) {
 /* These values are guest ABI, do not change */
 smbios_set_defaults("QEMU", "Standard PC (Q35 + ICH9, 2009)",
-args->machine->name);
+args->machine->name, smbios_legacy_mode);
 }
 
 /* allocate ram and load rom/bios */
@@ -242,6 +243,7 @@ static void pc_q35_init(QEMUMachineInitArgs *args)
 
 static void pc_compat_2_0(QEMUMachineInitArgs *args)
 {
+smbios_legacy_mode = true;
 }
 
 static void pc

Re: [Qemu-devel] [PULL 7/8] gtk: Fix -serial vc

2014-05-05 Thread Gerd Hoffmann
  Hi,

> Looks better thanks to "gtk: zap scrolled_window" (monitor is properly
> formatted again). But the whole queue spits this out on the terminal:
> 
> (:13169): Gtk-CRITICAL **: IA__gtk_window_resize: assertion `width > 
> 0' failed
> 
> (:13169): Gdk-CRITICAL **: IA__gdk_window_set_cursor: assertion 
> `GDK_IS_WINDOW (window)' failed

Yes, there is some work-in-progress stuff in that branch causing this.

cheers,
  Gerd





Re: [Qemu-devel] [PATCH v2 1/2] docs/memory.txt: Put one whitespace between sentences

2014-05-05 Thread Fam Zheng
On Mon, 05/05 15:05, Michael Tokarev wrote:
> 05.05.2014 14:59, Fam Zheng wrote:
> > In other words, whitespace changes only.
> 
> >  The memory API models the memory and I/O buses and controllers of a QEMU
> > -machine.  It attempts to allow modelling of:
> > +machine. It attempts to allow modelling of:
> 
> What's the point?  In text form, it is quite often and, to my taste, quite
> normal to use 2 spaces after the full-dot (at the end of the sentence), just
> like an extra line between paragraphs.  This way, it is easier to separate
> sentences between each other.
> 
> In real typography, 1.5-sized space is usually used in such places.  But since
> plaintext format has no 1.5-sized space, 2 spaces is used.
> 
> I'd send an opposite patch, which adds additional space where it is missing.. 
> :)
> 

Well, out of my first reaction on the inconsistency. I just get a feeling on
this controversy by looking at the length of this Wikipedia page's reference
section:

http://en.wikipedia.org/wiki/Sentence_spacing#References

Does NOT matter for me, anyway :)

Thanks,
Fam




Re: [Qemu-devel] [PULL 7/8] gtk: Fix -serial vc

2014-05-05 Thread Gerd Hoffmann
  Hi,

> >> Check out gerd's ui-gtk-next branch, there's a few extra patches related to
> >> vte sizing that might fix it.
> > 
> > Looks better thanks to "gtk: zap scrolled_window" (monitor is properly
> > formatted again).
> 
> ...err - no. The price of this patch is that the window is no longer
> properly resized on all guest mode changes. There is still more broken.

Indeed.  Switching to higher resolutions make the window larger, but
switching back to lower res doesn't make it smaller.  I'll have a look.

cheers,
  Gerd





[Qemu-devel] [PULL v2 5/7] SMBIOS: Use macro to set smbios defaults

2014-05-05 Thread Gerd Hoffmann
From: "Gabriel L. Somlo" 

The function smbios_set_defaults() uses a repeating code pattern
for each field. This patch replaces that pattern with a macro.

This patch contains no functional changes.

Signed-off-by: Gabriel Somlo 
Signed-off-by: Gerd Hoffmann 
---
 hw/i386/smbios.c | 27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/hw/i386/smbios.c b/hw/i386/smbios.c
index e734d4c..9f83bfb 100644
--- a/hw/i386/smbios.c
+++ b/hw/i386/smbios.c
@@ -260,20 +260,6 @@ static void smbios_build_type_1_fields(void)
 }
 }
 
-void smbios_set_defaults(const char *manufacturer, const char *product,
- const char *version)
-{
-if (!type1.manufacturer) {
-type1.manufacturer = manufacturer;
-}
-if (!type1.product) {
-type1.product = product;
-}
-if (!type1.version) {
-type1.version = version;
-}
-}
-
 uint8_t *smbios_get_table_legacy(size_t *length)
 {
 if (!smbios_immutable) {
@@ -288,6 +274,19 @@ uint8_t *smbios_get_table_legacy(size_t *length)
 /* end: legacy setup functions for <= 2.0 machines */
 
 
+#define SMBIOS_SET_DEFAULT(field, value)  \
+if (!field) { \
+field = value;\
+}
+
+void smbios_set_defaults(const char *manufacturer, const char *product,
+ const char *version)
+{
+SMBIOS_SET_DEFAULT(type1.manufacturer, manufacturer);
+SMBIOS_SET_DEFAULT(type1.product, product);
+SMBIOS_SET_DEFAULT(type1.version, version);
+}
+
 static void save_opt(const char **dest, QemuOpts *opts, const char *name)
 {
 const char *val = qemu_opt_get(opts, name);
-- 
1.8.3.1




Re: [Qemu-devel] [PATCH 18/22] vmdk: implement .bdrv_detach/attach_aio_context()

2014-05-05 Thread Stefan Hajnoczi
On Sun, May 04, 2014 at 06:17:45PM +0800, Fam Zheng wrote:
> On Thu, 05/01 16:54, Stefan Hajnoczi wrote:
> > @@ -2118,6 +2139,8 @@ static BlockDriver bdrv_vmdk = {
> >  .bdrv_has_zero_init   = vmdk_has_zero_init,
> >  .bdrv_get_specific_info   = vmdk_get_specific_info,
> >  .bdrv_refresh_limits  = vmdk_refresh_limits,
> > +.bdrv_detach_aio_context  = vmdk_detach_aio_context,
> > +.bdrv_attach_aio_context  = vmdk_attach_aio_context,
> >  
> >  .create_options   = vmdk_create_options,
> >  };
> > -- 
> 
> I'm wondering why we need to separate detach and attach as two functions, and
> also add bdrv_set_aio_context in block.c, instead of a single
> .bdrv_set_aio_context member which is called in bdrv_set_aio_context()? The
> latter seems less code.

I can see it working either way, but here is why I chose to keep them
separate:

The detach/attach happens in two phases:

1. Parents are detached before child nodes - just in case the parent
   still needs the child in order to detach.

2. The new AioContext is acquired and then children are attached before
   their parent nodes - that way the parent knows it can already use its
   children during attach.

Acquiring the new AioContext for the minimum amount of time (attach
only) seems like a good idea.  Remember the AioContext may be
responsible for other I/O devices too so we should minimize the scope of
acquire/release.

Doing it all in a single .bdrv_set_aio_context() forces detach to happen
while the new AioContext is held.

Another reason why separate detach/attach is nice is that it allows
block drivers to avoid code duplication.  .bdrv_open() calls attach()
and .bdrv_close() calls detach().  A single .bdrv_set_aio_context()
function would need extra code to deal with the open (currently not
attached) and close (don't attach to a new context) scenarios.

Stefan



Re: [Qemu-devel] [PATCH 19/22] dataplane: use the QEMU block layer for I/O

2014-05-05 Thread Stefan Hajnoczi
On Sun, May 04, 2014 at 07:51:40PM +0800, Fam Zheng wrote:
> On Thu, 05/01 16:54, Stefan Hajnoczi wrote:
> > +VirtIOBlockRequest *req = g_slice_new(VirtIOBlockRequest);
> 
> Could be g_slice_new0,
> 
> > +QEMUIOVector *qiov;
> > +int nb_sectors;
> > +
> > +/* Fill in virtio block metadata needed for completion */
> > +memset(req, 0, sizeof(*req));
> 
> so this memset is not needed.

Thanks, will fix.



Re: [Qemu-devel] [PATCH 00/22] dataplane: use QEMU block layer

2014-05-05 Thread Stefan Hajnoczi
On Mon, May 05, 2014 at 11:17:44AM +0200, Christian Borntraeger wrote:
> On 01/05/14 16:54, Stefan Hajnoczi wrote:
> > This patch series switches virtio-blk data-plane from a custom Linux AIO
> > request queue to the QEMU block layer.  The previous "raw files only"
> > limitation is lifted.  All image formats and protocols can now be used with
> > virtio-blk data-plane.
> 
> Nice. Is there a git branch somewhere, so that we can test this on s390?

Hi Christian,
I'm getting to work on v2 but you can grab this v1 series from git in
the meantime:

https://github.com/stefanha/qemu.git bdrv_set_aio_context

Stefan



Re: [Qemu-devel] [PATCH 3/3] glib: add compat wrapper for GStaticMutex

2014-05-05 Thread Stefan Hajnoczi
On Fri, May 02, 2014 at 03:08:07PM +0400, Michael Tokarev wrote:
> Stefan Hajnoczi:
> 
> > Avoid duplicating ifdefs for the deprecated GStaticMutex API by
> > introducing compat_g_static_mutex_*() in glib-compat.h.
> >
> > GStaticMutex users should use the compat API to avoid dealing with
> > deprecation.
> 
> To my taste this is a wrong(ish) approach.

The different approaches to hiding gthread API deprecation have their
pros/cons but mostly a question of taste.  If you want to merge your
patch I'm fine with that.

Stefan



Re: [Qemu-devel] [PATCH v2 0/8] x86: correctly implement soft reset

2014-05-05 Thread Michael S. Tsirkin
On Fri, May 02, 2014 at 04:33:14PM +0200, Paolo Bonzini wrote:
> A repost of an old patch series, rebased and retested.  Patches 3 to 5
> are new, everything else already carries a Reviewed-by.
> 
> v1->v2: compile-tested on ARM (I also have had a /dev/kvm on my ARM board
> for two hours now, but still no guest to try this on).

Went over all of the series, it all looks good to me.

Acked-by: Michael S. Tsirkin 

mostly kvm stuff so I guess your tree makes more sense,
but if you want me to take it instead let me know,
won't be a problem.


> Paolo Bonzini (8):
>   kvm: reset state from the CPU's reset method
>   kvm: forward INIT signals coming from the chipset
>   target-i386: fix set of registers zeroed on reset
>   target-i386: preserve FPU and MSR state on INIT
>   apic: do not accept SIPI on the bootstrap processor
>   cpu: make CPU_INTERRUPT_RESET available on all targets
>   pc: port 92 reset requires a low->high transition
>   x86: correctly implement soft reset
> 
>  cpu-exec.c | 23 ++-
>  cpus.c |  9 
>  hw/i386/pc.c   |  6 +++--
>  hw/input/pckbd.c   |  5 +++--
>  hw/intc/apic_common.c  |  2 +-
>  hw/isa/lpc_ich9.c  | 12 --
>  hw/pci-host/piix.c |  8 +--
>  include/exec/cpu-all.h |  8 ---
>  include/sysemu/cpus.h  |  1 +
>  include/sysemu/kvm.h   |  2 --
>  kvm-all.c  | 11 -
>  target-arm/cpu.c   |  7 ++
>  target-arm/kvm32.c |  4 +---
>  target-arm/kvm64.c |  2 +-
>  target-arm/kvm_arm.h   |  8 +++
>  target-i386/cpu.c  | 11 +
>  target-i386/cpu.h  | 60 
> ++
>  target-i386/helper.c   | 14 ++--
>  target-i386/kvm.c  | 39 +---
>  target-i386/kvm_i386.h |  2 ++
>  target-ppc/cpu.h   |  3 ---
>  target-ppc/kvm.c   |  4 
>  target-s390x/cpu.c |  4 
>  target-s390x/cpu.h |  5 +
>  target-s390x/kvm.c |  6 +++--
>  25 files changed, 165 insertions(+), 91 deletions(-)
> 
> -- 
> 1.8.3.1
> 



Re: [Qemu-devel] [PATCH v2 8/8] x86: correctly implement soft reset

2014-05-05 Thread Michael S. Tsirkin
On Fri, May 02, 2014 at 04:33:22PM +0200, Paolo Bonzini wrote:
> Do not do a hard reset for port 92h, keyboard controller, or cf9h soft reset.
> These only reset the CPU.
> 
> Reviewed-by: Anthony Liguori 
> Signed-off-by: Paolo Bonzini 

I note that we allow setting reset type in the same write
with reset itself.
i440fx spec says
2
Reset CPU (RCPU). RCPU is used to initiate a hard or soft reset to the
CPU. During hard reset, the
PMC asserts CRESET# for 2 msec and PCIRST# for 1 msec. During soft
reset, the PMC asserts INIT#.
BISTE and SHRE must be set up prior to writing a 1 to this bit. Two
operations are required to initiate a
reset using this register. The first write operation programs BISTE and
SHRE to the appropriate state
while setting RCPU to 0. The second write operation keeps the BISTE and
SHRE at their programmed
state while setting RCPU to 1.

it does not actually say what happens if you try to change reset type
in the same access as the reset so I think we are ok
with this simple logic that you implemented.



> ---
>  hw/i386/pc.c   |  3 ++-
>  hw/input/pckbd.c   |  5 +++--
>  hw/isa/lpc_ich9.c  | 12 ++--
>  hw/pci-host/piix.c |  8 ++--
>  4 files changed, 21 insertions(+), 7 deletions(-)
> 
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index a59e958..8716864 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -45,6 +45,7 @@
>  #include "kvm_i386.h"
>  #include "hw/xen/xen.h"
>  #include "sysemu/blockdev.h"
> +#include "sysemu/cpus.h"
>  #include "hw/block/block.h"
>  #include "ui/qemu-spice.h"
>  #include "exec/memory.h"
> @@ -477,7 +478,7 @@ static void port92_write(void *opaque, hwaddr addr, 
> uint64_t val,
>  s->outport = val;
>  qemu_set_irq(*s->a20_out, (val >> 1) & 1);
>  if ((val & 1) && !(oldval & 1)) {
> -qemu_system_reset_request();
> +cpu_soft_reset();
>  }
>  }
>  
> diff --git a/hw/input/pckbd.c b/hw/input/pckbd.c
> index 29af3d7..fd87776 100644
> --- a/hw/input/pckbd.c
> +++ b/hw/input/pckbd.c
> @@ -26,6 +26,7 @@
>  #include "hw/i386/pc.h"
>  #include "hw/input/ps2.h"
>  #include "sysemu/sysemu.h"
> +#include "sysemu/cpus.h"
>  
>  /* debug PC keyboard */
>  //#define DEBUG_KBD
> @@ -220,7 +221,7 @@ static void outport_write(KBDState *s, uint32_t val)
>  qemu_set_irq(*s->a20_out, (val >> 1) & 1);
>  }
>  if (!(val & 1)) {
> -qemu_system_reset_request();
> +cpu_soft_reset();
>  }
>  }
>  
> @@ -299,7 +300,7 @@ static void kbd_write_command(void *opaque, hwaddr addr,
>  s->outport &= ~KBD_OUT_A20;
>  break;
>  case KBD_CCMD_RESET:
> -qemu_system_reset_request();
> +cpu_soft_reset();
>  break;
>  case KBD_CCMD_NO_OP:
>  /* ignore that */
> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
> index 51ce12d..e9fde85 100644
> --- a/hw/isa/lpc_ich9.c
> +++ b/hw/isa/lpc_ich9.c
> @@ -45,6 +45,7 @@
>  #include "hw/pci/pci_bus.h"
>  #include "exec/address-spaces.h"
>  #include "sysemu/sysemu.h"
> +#include "sysemu/cpus.h"
>  
>  static int ich9_lpc_sci_irq(ICH9LPCState *lpc);
>  
> @@ -507,8 +508,15 @@ static void ich9_rst_cnt_write(void *opaque, hwaddr 
> addr, uint64_t val,
>  ICH9LPCState *lpc = opaque;
>  
>  if (val & 4) {
> -qemu_system_reset_request();
> -return;
> +/* In a real ICH9, FULL_RST affects whether the hardware goes to S5
> + * for 3-5 seconds, but is not enough alone; you need to set SYS_RST
> + * too.
> + */
> +if (val & 2) {
> +qemu_system_reset_request();
> +} else {
> +cpu_soft_reset();
> +}
>  }
>  lpc->rst_cnt = val & 0xA; /* keep FULL_RST (bit 3) and SYS_RST (bit 1) */
>  }
> diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
> index ffdc853..1e60172 100644
> --- a/hw/pci-host/piix.c
> +++ b/hw/pci-host/piix.c
> @@ -34,6 +34,7 @@
>  #include "sysemu/sysemu.h"
>  #include "hw/i386/ioapic.h"
>  #include "qapi/visitor.h"
> +#include "sysemu/cpus.h"
>  
>  /*
>   * I440FX chipset data sheet.
> @@ -587,8 +588,11 @@ static void rcr_write(void *opaque, hwaddr addr, 
> uint64_t val, unsigned len)
>  PIIX3State *d = opaque;
>  
>  if (val & 4) {
> -qemu_system_reset_request();
> -return;
> +if (val & 2) {
> +qemu_system_reset_request();
> +} else {
> +cpu_soft_reset();
> +}
>  }
>  d->rcr = val & 2; /* keep System Reset type only */
>  }
> -- 
> 1.8.3.1
> 



Re: [Qemu-devel] [PATCH 20/35] acpi: memory hotplug ACPI hardware implementation

2014-05-05 Thread Vasilis Liaskovitis
Hi,

On Fri, Apr 04, 2014 at 03:36:45PM +0200, Igor Mammedov wrote:
> - implements QEMU hardware part of memory hotplug protocol
>   described at "docs/specs/acpi_mem_hotplug.txt"
> - handles only memory add notification event for now
>
[...]
> +  [0x4-0x7] OST event code reported by OSPM
> +  [0x8-0xb] OST status code reported by OSPM
> +case 0x4: /* _OST event  */
> +mdev = &mem_st->devs[mem_st->selector];
> +if (data == 1) {
> +/* TODO: handle device insert OST event */
> +} else if (data == 3) {
> +/* TODO: handle device remove OST event */
> +}

Are there any patches planned to report _OST notifications to upper management
layers? E.g. some older patchseries implemented a queue for these notifications
that could be queried with an "info memhp" command.

As a more general question for the patchseries: How do we query status/presence
of dimms present? Some posssible options could be:

- info qtree: If links<> are implemented between dimms and an acpi machine
adapter, would the dimms show up in the general device tree? Currently I believe
they don't.

- info dimm: We could have a new "info dimm" command that shows information for
present DIMMs: start-end guest physical address, last _OST notification received
for this DIMM, as well as backing memdev object for this dimm.

(qemu) info dimm
dimm0: range="start_address - end_address" memdev="obj0" _OST="last_OST message"
dimm1: range="start_address - end_address" memdev="obj1" _OST="last_OST message"

where last_OST message could be "hot-add succesfull", "hot-add failed",
"hot-remove failed". Not sure how "hot-remove successful" would be reported
though, as the dimm device would be removed (or soon to be removed) from the
machine. Unless we have a separate command for OST messages received/queued, as
mentioned above.

If the guest does not support _OST, the OST entries would remain empty,
at least giving management layer a hint that the guest may not have succesfully
completed the requested hot-operation.

The examples are all in hmp, but there should obviously be qmp support.
Thoughts?

thanks,

- Vasilis




Re: [Qemu-devel] [PATCH] qcow2: Fix alloc_clusters_noref() overflow detection

2014-05-05 Thread Stefan Hajnoczi
On Sun, May 04, 2014 at 05:31:40AM +0200, Max Reitz wrote:
> If the very first allocation has a length of 0, the free_cluster_index
> is still 0 after the for loop, which means that subtracting one from it
> will underflow and signal an invalid range of clusters by returning
> -EFBIG. However, there is no such range, as its length is 0.
> 
> Fix this by preventing underflows on free_cluster_index during the
> check.
> 
> Signed-off-by: Max Reitz 
> ---
>  block/qcow2-refcount.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Thanks, applied to my block tree:
https://github.com/stefanha/qemu/commits/block

Stefan



Re: [Qemu-devel] [PATCH] iotests: Use configured python

2014-05-05 Thread Stefan Hajnoczi
On Sat, May 03, 2014 at 04:47:08PM +0200, Max Reitz wrote:
> @@ -56,22 +57,22 @@ for IMGOPTS in "compat=0.10" "compat=1.1"; do
>  echo === Create image with unknown header extension ===
>  echo
>  _make_test_img 64M
> -./qcow2.py "$TEST_IMG" add-header-ext 0x12345678 "This is a test header 
> extension"
> -./qcow2.py "$TEST_IMG" dump-header
> +$PYTHON qcow2.py "$TEST_IMG" add-header-ext 0x12345678 "This is a test 
> header extension"
> +$PYTHON qcow2.py "$TEST_IMG" dump-header

Please use "$PYTHON" to humor the people who like to put spaces in their
path names.

> @@ -215,9 +222,16 @@ do
>  
>  start=`_wallclock`
>  $timestamp && echo -n "["`date "+%T"`"]"
> -[ ! -x $seq ] && chmod u+x $seq # ensure we can run it
> +
> +if [ "$(head -n 1 $seq)" == "#!/usr/bin/env python" ]; then
> +run_command="$PYTHON $seq"

The code generally uses the older `` notation instead of $().  Please
use ``.



Re: [Qemu-devel] [PATCH] linux-user: fix getrusage and wait4 failures with invalid rusage struct

2014-05-05 Thread Riku Voipio
Hi,

Thanks, looks good and fixes getrusage02 ltp test.

Added to the linux-user que:

https://git.linaro.org/people/riku.voipio/qemu.git/shortlog/refs/heads/linux-user-for-upstream

Peter, do you prefer a new pull request for linux-user with this patch
added on top, or is pulling the updated branch good enough for you?

Riku


On 5 May 2014 12:02, Petar Jovanovic  wrote:

> ping
>
> http://patchwork.ozlabs.org/patch/337703/
>
> 
> From: Petar Jovanovic [petar.jovano...@rt-rk.com]
> Sent: Tuesday, April 08, 2014 7:24 PM
> To: qemu-devel@nongnu.org
> Cc: Petar Jovanovic; riku.voi...@linaro.org
> Subject: [PATCH] linux-user: fix getrusage and wait4 failures with invalid
> rusage struct
>
> From: Petar Jovanovic 
>
> Implementations of system calls getrusage and wait4 have not previously
> handled correctly cases when incorrect address of struct rusage is
> passed.
> This change makes sure return values are correctly set for these cases.
>
> Signed-off-by: Petar Jovanovic 
> ---
>  linux-user/syscall.c |   11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index 9864813..fc52f0b 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -6309,7 +6309,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
> arg1,
>  struct rusage rusage;
>  ret = get_errno(getrusage(arg1, &rusage));
>  if (!is_error(ret)) {
> -host_to_target_rusage(arg2, &rusage);
> +ret = host_to_target_rusage(arg2, &rusage);
>  }
>  }
>  break;
> @@ -6974,6 +6974,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
> arg1,
>  abi_long status_ptr = arg2;
>  struct rusage rusage, *rusage_ptr;
>  abi_ulong target_rusage = arg4;
> +abi_long rusage_err;
>  if (target_rusage)
>  rusage_ptr = &rusage;
>  else
> @@ -6985,8 +6986,12 @@ abi_long do_syscall(void *cpu_env, int num,
> abi_long arg1,
>  if (put_user_s32(status, status_ptr))
>  goto efault;
>  }
> -if (target_rusage)
> -host_to_target_rusage(target_rusage, &rusage);
> +if (target_rusage) {
> +rusage_err = host_to_target_rusage(target_rusage,
> &rusage);
> +if (rusage_err) {
> +ret = rusage_err;
> +}
> +}
>  }
>  }
>  break;
> --
> 1.7.9.5
>
>


Re: [Qemu-devel] [PATCH] linux-user: fix getrusage and wait4 failures with invalid rusage struct

2014-05-05 Thread Peter Maydell
On 5 May 2014 13:27, Riku Voipio  wrote:
> Hi,
>
> Thanks, looks good and fixes getrusage02 ltp test.
>
> Added to the linux-user que:
>
> https://git.linaro.org/people/riku.voipio/qemu.git/shortlog/refs/heads/linux-user-for-upstream
>
> Peter, do you prefer a new pull request for linux-user with this patch added
> on top, or is pulling the updated branch good enough for you?

Send a new cover letter email, then it will go into my folder
of pending requests correctly.

thanks
-- PMM



Re: [Qemu-devel] E1000 emulation in qemu and pci configuration space

2014-05-05 Thread Stefan Hajnoczi
On Mon, May 05, 2014 at 02:15:05PM +0500, Ayaz Akram wrote:
> Does e1000's emulation in QEMU require that the guest set its base address
> register(pci configuration space register) or qemu has default value for
> its base address register?

There is no default.

Drivers for some operating systems (Mac OS X?) may assume the device
state set up by the firmware (UEFI).  It's nasty to do that but it
happens.  Since QEMU's firmware is different from that on real machines
a hack may be necessary to make the guest OS driver work.  That hack
shouldn't be in QEMU's device emulation code though - putting it into
the guest firmware is closest to how the physical machine works.

Stefan



[Qemu-devel] [PULL v2 00/15] linux-user update

2014-05-05 Thread riku . voipio
From: Riku Voipio 

The following changes since commit fdaad4715ae9e998fd0595bedfb16fdaf0c68ccc:

  Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20140501' 
into staging (2014-05-02 11:32:00 +0100)

are available in the git repository at:

  http://git.linaro.org/git/people/riku.voipio/qemu.git 

for you to fetch changes up to a39fb273bddd315b440b0617783051456a148242:

  linux-user: fix getrusage and wait4 failures with invalid rusage struct 
(2014-05-05 15:21:05 +0300)

Huw Davies (2):
  linux-user: Move if-elses to a switch statement.
  linux-user: Add support for SCM_CREDENTIALS.

James Hogan (2):
  linux-user: Assert stack used for auxvec, envp, argv
  linux-user: Handle arches with llseek instead of _llseek

Maxim Ostapenko (1):
  linux-user: Add /proc/self/exe open forwarding

Natanael Copa (1):
  linux-user: avoid using glibc internals in _syscall5 and in definition
of target_sigevent struct

Petar Jovanovic (1):
  linux-user: fix getrusage and wait4 failures with invalid rusage
struct

Peter Maydell (5):
  linux-user/signal.c: Set fault address in AArch64 signal info
  linux-user/elfload.c: Fix incorrect ARM HWCAP bits
  linux-user/elfload.c: Update ARM HWCAP bits
  linux-user/elfload.c: Fix A64 code which was incorrectly acting like
A32
  linux-user/elfload.c: Support ARM HWCAP2 flags

Riku Voipio (3):
  linux-user: rename cpu-uname -> uname
  linux-user: move uname functions to uname.c
  linux-user: remove configure option for setting uname release

 configure |   8 --
 include/elf.h |   1 +
 linux-user/Makefile.objs  |   2 +-
 linux-user/cpu-uname.c|  72 --
 linux-user/cpu-uname.h|   1 -
 linux-user/elfload.c  | 147 +++-
 linux-user/main.c |   2 +-
 linux-user/signal.c   |   3 +-
 linux-user/syscall.c  | 189 --
 linux-user/syscall_defs.h |  16 +++-
 linux-user/uname.c| 171 +
 linux-user/uname.h|  10 +++
 12 files changed, 392 insertions(+), 230 deletions(-)
 delete mode 100644 linux-user/cpu-uname.c
 delete mode 100644 linux-user/cpu-uname.h
 create mode 100644 linux-user/uname.c
 create mode 100644 linux-user/uname.h

-- 
2.0.0.rc0




Re: [Qemu-devel] [PATCH 00/22] dataplane: use QEMU block layer

2014-05-05 Thread Christian Borntraeger
On 05/05/14 14:05, Stefan Hajnoczi wrote:
> On Mon, May 05, 2014 at 11:17:44AM +0200, Christian Borntraeger wrote:
>> On 01/05/14 16:54, Stefan Hajnoczi wrote:
>>> This patch series switches virtio-blk data-plane from a custom Linux AIO
>>> request queue to the QEMU block layer.  The previous "raw files only"
>>> limitation is lifted.  All image formats and protocols can now be used with
>>> virtio-blk data-plane.
>>
>> Nice. Is there a git branch somewhere, so that we can test this on s390?
> 
> Hi Christian,
> I'm getting to work on v2 but you can grab this v1 series from git in
> the meantime:
> 
> https://github.com/stefanha/qemu.git bdrv_set_aio_context
> 
> Stefan
> 

In general the main path seems to work fine.

With lots of devices (one qcow2, 23 raw scsi disks)
I get a hang on shutdown. kvm_stat claims that nothing is going on any more, 
but somehow threads are stuck in ppoll.

gdb tells me that 

all cpus have
#0  0x03fffcde0ba0 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x03fffcde3c0c in __pthread_mutex_cond_lock () from 
/lib64/libpthread.so.0
#2  0x03fffcddc99a in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
#3  0x801f183a in qemu_cond_wait (cond=, 
mutex=mutex@entry=0x8072ba30 ) at 
/home/cborntra/REPOS/qemu/util/qemu-thread-posix.c:135
#4  0x801512f2 in qemu_kvm_wait_io_event (cpu=) at 
/home/cborntra/REPOS/qemu/cpus.c:842
#5  qemu_kvm_cpu_thread_fn (arg=0x80a53e10) at 
/home/cborntra/REPOS/qemu/cpus.c:878

all iothreads have
#0  0x03fffbc348e0 in ppoll () from /lib64/libc.so.6
#1  0x800fcce6 in ppoll (__ss=0x0, __timeout=0x0, __nfds=, __fds=) at /usr/include/bits/poll2.h:77
#2  qemu_poll_ns (fds=fds@entry=0x3fff4001b00, nfds=nfds@entry=3, timeout=-1) 
at /home/cborntra/REPOS/qemu/qemu-timer.c:311
#3  0x8001ae4c in aio_poll (ctx=0x807dd610, 
blocking=blocking@entry=true) at /home/cborntra/REPOS/qemu/aio-posix.c:221
#4  0x800b2f6c in iothread_run (opaque=0x807dd4c8) at 
/home/cborntra/REPOS/qemu/iothread.c:41
#5  0x03fffcdd8412 in start_thread () from /lib64/libpthread.so.0
#6  0x03fffbc3f0ae in thread_start () from /lib64/libc.so.6

the main thread has
Thread 1 (Thread 0x3fff9e5c9b0 (LWP 33684)):
#0  0x03fffbc348e0 in ppoll () from /lib64/libc.so.6
#1  0x800fcce6 in ppoll (__ss=0x0, __timeout=0x0, __nfds=, __fds=) at /usr/include/bits/poll2.h:77
#2  qemu_poll_ns (fds=fds@entry=0x80ae8030, nfds=nfds@entry=4, timeout=-1) at 
/home/cborntra/REPOS/qemu/qemu-timer.c:311
#3  0x8001ae4c in aio_poll (ctx=ctx@entry=0x809a7ea0, 
blocking=blocking@entry=true) at /home/cborntra/REPOS/qemu/aio-posix.c:221
#4  0x80030c46 in bdrv_flush (bs=bs@entry=0x807e5900) at 
/home/cborntra/REPOS/qemu/block.c:4904
#5  0x80030ce8 in bdrv_flush_all () at 
/home/cborntra/REPOS/qemu/block.c:3723
#6  0x80152fe8 in do_vm_stop (state=) at 
/home/cborntra/REPOS/qemu/cpus.c:538
#7  vm_stop (state=) at /home/cborntra/REPOS/qemu/cpus.c:1219
#8  0x in ?? ()


How are the ppoll calls supposed to return if there is nothing going on?

PS: I think I have seen this before recently during managedsave, so it might 
have been introduced with the iothread rework instead of this one.





 full trace 
Thread 34 (Thread 0x3fff919c910 (LWP 33696)):
#0  0x03fffcde0b5e in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x03fffcde3c0c in __pthread_mutex_cond_lock () from 
/lib64/libpthread.so.0
#2  0x03fffcddc99a in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
#3  0x801f183a in qemu_cond_wait (cond=, 
mutex=mutex@entry=0x8072ba30 ) at 
/home/cborntra/REPOS/qemu/util/qemu-thread-posix.c:135
#4  0x801512f2 in qemu_kvm_wait_io_event (cpu=) at 
/home/cborntra/REPOS/qemu/cpus.c:842
#5  qemu_kvm_cpu_thread_fn (arg=0x809e1f00) at 
/home/cborntra/REPOS/qemu/cpus.c:878
#6  0x03fffcdd8412 in start_thread () from /lib64/libpthread.so.0
#7  0x03fffbc3f0ae in thread_start () from /lib64/libc.so.6

Thread 33 (Thread 0x3fff899c910 (LWP 33697)):
#0  0x03fffcde0ba0 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x03fffcde3c0c in __pthread_mutex_cond_lock () from 
/lib64/libpthread.so.0
#2  0x03fffcddc99a in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
#3  0x801f183a in qemu_cond_wait (cond=, 
mutex=mutex@entry=0x8072ba30 ) at 
/home/cborntra/REPOS/qemu/util/qemu-thread-posix.c:135
#4  0x801512f2 in qemu_kvm_wait_io_event (cpu=) at 
/home/cborntra/REPOS/qemu/cpus.c:842
#5  qemu_kvm_cpu_thread_fn (arg=0x809f2370) at 
/home/cborntra/REPOS/qemu/cpus.c:878
#6  0x03fffcdd8412 in start_thread () from /lib64/libpthread.so.0
#7  0x03fffbc3f0ae in thread_start () from /lib64/libc.so.6

Thread 32 (Thread 0x3fef3fff910 (LWP 33698)):
#0  0x03fffcde0ba0 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x03fffcde3c0c in __pthread_mutex_cond_lock () from 
/lib64/libpthread.so.0
#2  0x03

Re: [Qemu-devel] [PULL v2 00/15] linux-user update

2014-05-05 Thread Peter Maydell
On 5 May 2014 13:34,   wrote:
> From: Riku Voipio 
>
> The following changes since commit fdaad4715ae9e998fd0595bedfb16fdaf0c68ccc:
>
>   Merge remote-tracking branch 
> 'remotes/pmaydell/tags/pull-target-arm-20140501' into staging (2014-05-02 
> 11:32:00 +0100)
>
> are available in the git repository at:
>
>   http://git.linaro.org/git/people/riku.voipio/qemu.git

This seems to be missing the branch or tag name to pull from...

thanks
-- PMM



Re: [Qemu-devel] [PATCH] iotests: Use configured python

2014-05-05 Thread Peter Maydell
On 5 May 2014 13:26, Stefan Hajnoczi  wrote:
> On Sat, May 03, 2014 at 04:47:08PM +0200, Max Reitz wrote:
>> @@ -56,22 +57,22 @@ for IMGOPTS in "compat=0.10" "compat=1.1"; do
>>  echo === Create image with unknown header extension ===
>>  echo
>>  _make_test_img 64M
>> -./qcow2.py "$TEST_IMG" add-header-ext 0x12345678 "This is a test header 
>> extension"
>> -./qcow2.py "$TEST_IMG" dump-header
>> +$PYTHON qcow2.py "$TEST_IMG" add-header-ext 0x12345678 "This is a test 
>> header extension"
>> +$PYTHON qcow2.py "$TEST_IMG" dump-header
>
> Please use "$PYTHON" to humor the people who like to put spaces in their
> path names.

Won't that cause problems if configure sets $PYTHON to "python -B" ?

>> @@ -215,9 +222,16 @@ do
>>
>>  start=`_wallclock`
>>  $timestamp && echo -n "["`date "+%T"`"]"
>> -[ ! -x $seq ] && chmod u+x $seq # ensure we can run it
>> +
>> +if [ "$(head -n 1 $seq)" == "#!/usr/bin/env python" ]; then
>> +run_command="$PYTHON $seq"
>
> The code generally uses the older `` notation instead of $().  Please
> use ``.

$() is nicer though...

thanks
-- PMM



  1   2   3   4   >