[Qemu-devel] [PATCH] vhost: make priority higher than kvm

2013-05-08 Thread Liu Ping Fan
From: Liu Ping Fan pingf...@linux.vnet.ibm.com

vhost should have high priority than kvm.
Take the following scenario:
  kvm_region_add earlier before vhost_region_add, then vring's desc[i]
can refer addressX known by guest, and then used by guest. But vhost
does not know this yet, and the vring handler will fail.

Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com
---
 hw/virtio/vhost.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index fbabf99..91c313b 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -856,7 +856,7 @@ int vhost_dev_init(struct vhost_dev *hdev, int devfd, const 
char *devpath,
 .log_global_stop = vhost_log_global_stop,
 .eventfd_add = vhost_eventfd_add,
 .eventfd_del = vhost_eventfd_del,
-.priority = 10
+.priority = 9
 };
 hdev-mem = g_malloc0(offsetof(struct vhost_memory, regions));
 hdev-n_mem_sections = 0;
-- 
1.7.4.4




Re: [Qemu-devel] unknown keycodes

2013-05-08 Thread Ali
Daniel P. Berrange berrange at redhat.com writes:

 
 Good, those are the interesting bits I wanted to see
 
  _XKB_RULES_NAMES(STRING) = base, empty, empty, , 
 
 I'll prepare a patch to test out which ought to fix OS-X
 
 Regards,
 Daniel

Any luck with this patch? I'm having the same issue:
Mac OS X, XQuartz - Ubuntu X11/XAuth server 
- QEMU





[Qemu-devel] qemu-img problem when create a file larger than fs's size

2013-05-08 Thread yuxh

Hello all,

I have to consult you a qemu-img's problem.

Is this reasonable to create a file which is larger than the available 
size of the fs by qemu-img cmd ?


When I use qemu-img create a file which is larger than the available 
size of the fs, the creation is completed succesfully.


However when I use this file in guest as a guest's disk, and write 
beyond the size the host file can provides, the guest was paused by 
qemu-kvm or libvirt and was in maybe a infinite circle where the guest 
just can't be used except I detach the disk from guest or destroy the guest.


I read the qemu-img's code and found it just create the file as we 
required and doesn't check if the size we specify is reasonable.But this 
may let the guest in a risk of meeting the problem I describe above.


Exp:
[root@build mytest]# df -ah /mytest/
FilesystemSize  Used Avail Use% Mounted on
/dev/sdb2 2.0G  3.1M  1.9G   1% /mytest
[root@build mytest]# qemu-img create -f raw test.raw 3G
Formatting 'test.raw', fmt=raw size=3221225472
[root@build mytest]# ls -l test.raw
-rw-r--r--. 1 root root 3221225472 May  8 12:23 test.raw
[root@build mytest]#

Thank you.

Best Regards
Xinghai Yu



Re: [Qemu-devel] [RFC PATCH 0/8] MemoryRegion and FlatView refcounting, replace hostmem with memory_region_find

2013-05-08 Thread liu ping fan
On Mon, May 6, 2013 at 10:25 PM, Paolo Bonzini pbonz...@redhat.com wrote:
 Hi,

 this is an alternative approach to refactoring of dataplane's HostMem
 code.  Here, I take Ping Fan's idea of RCU-style updating of the
 region list and apply it to the AddressSpace's FlatView.  With this

In fact, I am worrying about the priority of MemoryListener, if it is
true, then we should drop RCU-style idea. Also if it is true, there is
already a bug with hostmem listener. It should use region_del, not
region_nop to reconstruct the local view. But just let me have a deep
thinking.

Regards,
Pingfan
 change, dataplane can simply use memory_region_find instead of
 hostmem.

 This is a somewhat larger change, but I prefer it for two reasons.

 1) it splits the task of adding BQL-less memory dispatch in two parts,
tacking memory_region_find first (which is simpler because locking
is left to the caller).

 2) HostMem duplicates a lot of the FlatView logic, and adding the
RCU-style update in FlatView benefits everyone.

 The missing ingredients here are:

 1) remember and unreference the MemoryRegions that are used in
a vring entry.  In order to implement this, it is probably simpler
to change vring.c to use virtio.c's VirtQueueElement data structure.
We want something like that anyway in order to support migration.

 2) add an owner field to MemoryRegion, and set it for all MemoryRegions
for hot-unpluggable devices.  In this series, ref/unref are stubs.

 For simplicity I based the patches on my IOMMU rebase.  I placed the
 tree at git://github.com/bonzini/qemu.git, branch iommu.

 Paolo

 Paolo Bonzini (8):
   memory: add ref/unref calls
   exec: check MRU in qemu_ram_addr_from_host
   memory: return MemoryRegion from qemu_ram_addr_from_host
   memory: ref/unref memory across address_space_map/unmap
   memory: access FlatView from a local variable
   memory: use a new FlatView pointer on every topology update
   memory: add reference counting to FlatView
   dataplane: replace hostmem with memory_region_find

  exec.c|   63 +---
  hw/core/loader.c  |1 +
  hw/display/exynos4210_fimd.c  |6 +
  hw/display/framebuffer.c  |   10 +-
  hw/i386/kvm/ioapic.c  |2 +
  hw/i386/kvmvapic.c|1 +
  hw/misc/vfio.c|2 +
  hw/virtio/dataplane/Makefile.objs |2 +-
  hw/virtio/dataplane/hostmem.c |  176 
 -
  hw/virtio/dataplane/vring.c   |   56 +--
  hw/virtio/vhost.c |2 +
  hw/virtio/virtio-balloon.c|1 +
  hw/xen/xen_pt.c   |4 +
  include/exec/cpu-common.h |2 +-
  include/exec/memory.h |9 ++
  include/hw/virtio/dataplane/hostmem.h |   57 ---
  include/hw/virtio/dataplane/vring.h   |3 +-
  kvm-all.c |2 +
  memory.c  |  142 +-
  target-arm/kvm.c  |2 +
  target-i386/kvm.c |4 +-
  target-sparc/mmu_helper.c |1 +
  xen-all.c |2 +
  23 files changed, 253 insertions(+), 297 deletions(-)
  delete mode 100644 hw/virtio/dataplane/hostmem.c
  delete mode 100644 include/hw/virtio/dataplane/hostmem.h




Re: [Qemu-devel] qemu-img problem when create a file larger than fs's size

2013-05-08 Thread Fam Zheng
I think it's the system admin to be responsible for the risk of over
provisioning. We have host sparse file[1] (as your example) for
preallocated image (for example, -f raw), as well as sparse image (as
supported in qcow2, vmdk, etc.). There are cases that host file system
is extended or the vm disk is moved to a larger storage when the actual
data grows closer to full, so it's not very practical to limit the
creating size, just as this is quietly valid in linux, no matter how
small your /tmp is.

# df /tmp/ -h
Filesystem  Size  Used Avail Use% Mounted on
tmpfs   3.8G   14M  3.8G   1% /tmp
# touch /tmp/a
# truncate /tmp/a --size 1T
# ls -l /tmp/a
-rw-rw-r--. 1 fam fam 1099511627776 May  8 14:33 /tmp/a

[1]: http://en.wikipedia.org/wiki/Sparse_file

On Wed, 05/08 13:18, yuxh wrote:
 Hello all,
 
 I have to consult you a qemu-img's problem.
 
 Is this reasonable to create a file which is larger than the
 available size of the fs by qemu-img cmd ?
 
 When I use qemu-img create a file which is larger than the available
 size of the fs, the creation is completed succesfully.
 
 However when I use this file in guest as a guest's disk, and write
 beyond the size the host file can provides, the guest was paused by
 qemu-kvm or libvirt and was in maybe a infinite circle where the
 guest just can't be used except I detach the disk from guest or
 destroy the guest.
 
 I read the qemu-img's code and found it just create the file as we
 required and doesn't check if the size we specify is reasonable.But
 this may let the guest in a risk of meeting the problem I describe
 above.
 
 Exp:
 [root@build mytest]# df -ah /mytest/
 FilesystemSize  Used Avail Use% Mounted on
 /dev/sdb2 2.0G  3.1M  1.9G   1% /mytest
 [root@build mytest]# qemu-img create -f raw test.raw 3G
 Formatting 'test.raw', fmt=raw size=3221225472
 [root@build mytest]# ls -l test.raw
 -rw-r--r--. 1 root root 3221225472 May  8 12:23 test.raw
 [root@build mytest]#
 
 Thank you.
 
 Best Regards
 Xinghai Yu
 

-- 
Fam



Re: [Qemu-devel] [ANNOUNCE] QEMU 1.5.0-rc0 is now available

2013-05-08 Thread Dongsheng Song
On Wed, May 8, 2013 at 12:27 AM, Anthony Liguori aligu...@us.ibm.com wrote:

 Hi,

 On behalf of the QEMU Team, I'd like to announce the availability of the
 first release candidate for the QEMU 1.5 release.  This release is meant
 for testing purposes and should not be used in a production environment.

 http://wiki.qemu.org/download/qemu-1.5.0-rc0.tar.bz2

 You can help improve the quality of the QEMU 1.5 release by testing this
 release and reporting bugs on Launchpad:

 https://bugs.launchpad.net/qemu/

 The release plan for the 1.5 release is available at:

 http://wiki.qemu.org/Planning/1.5

 Please add entries to the ChangeLog for the 1.5 release below:

 http://wiki.qemu.org/ChangeLog/Next

 Regards,

 Anthony Liguori

For convenience, I had upload qemu-build-dependency-r1.zip,
qemu-1.5.0-rc0-win32.7z and qemu-1.5.0-rc0-win64.7z

https://code.google.com/p/i18n-zh/downloads/list

Regards,
Dongsheng



Re: [Qemu-devel] [Qemu-ppc] Incorrect handling of more PPC64 insns (PATCH)

2013-05-08 Thread Aurelien Jarno
On Tue, May 07, 2013 at 09:30:24PM +0200, Torbjorn Granlund wrote:
 I realised a possible problem with my suggested patch.
 
 What about a 32-bit processor?  Then NARROW_MODE macro is identical 0.
 
 The pre-patch behaviour was then to ignore the L bit and decode both
 32-bit and 64-bit instruction in the same way.
 
 Apparently that is correct behaviour.  (The manual is slightly vague,
 but I let hardware decide.)
 
 With my patch, the bit is not ignored, and invalid code will be
 generated for 32-bit targets, if they'd set the L bit.
 
 Here is an uglier but hopefully completely correct patch.
 
 diff --git a/target-ppc/translate.c b/target-ppc/translate.c
 index 1a84653..69d684c 100644
 --- a/target-ppc/translate.c
 +++ b/target-ppc/translate.c
 @@ -675,49 +675,65 @@ static inline void gen_set_Rc0(DisasContext *ctx, TCGv 
 reg)
  /* cmp */
  static void gen_cmp(DisasContext *ctx)
  {
 -if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
 +#if defined(TARGET_PPC64)
 +if (!(ctx-opcode  0x0020)) {
 +#endif
  gen_op_cmp32(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
   1, crfD(ctx-opcode));
 +#if defined(TARGET_PPC64)
  } else {
  gen_op_cmp(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
 1, crfD(ctx-opcode));
  }
 +#endif
  }

I agree that there is a bug there, and that cmp32 should be used with
when L=0. That said your code is not going to generate and invalid code
on a 32-bit CPU with L=1, but instead just skip the instruction.
Moreover as Alexander pointed, TARGET_PPC64 doesn't mean it's a 64-bit
CPU, but that the resulting qemu binaries support 64-bit CPU.

What about the following patch (only lightly tested).


From: Aurelien Jarno aurel...@aurel32.net

target-ppc: fix cmp instructions on 64-bit CPUs

64-bit CPUs check for the L bit of comparison instruction to determine
if the instruction is 32-bit wide, and not to the MSR SF bit.

L=1 on a 32-bit CPU should generate an invalid instruction exception.

Reported-by: Torbjorn Granlund t...@gmplib.org
Signed-off-by: Aurelien Jarno aurel...@aurel32.net
---
 target-ppc/translate.c |   48 
 1 file changed, 32 insertions(+), 16 deletions(-)

diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index 0886f4d..ab41dc1 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -675,48 +675,64 @@ static inline void gen_set_Rc0(DisasContext *ctx, TCGv 
reg)
 /* cmp */
 static void gen_cmp(DisasContext *ctx)
 {
-if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
+if (ctx-opcode  0x0020) {
+if (unlikely(!(ctx-insns_flags  PPC_64B))) {
+gen_inval_exception(ctx, POWERPC_EXCP_INVAL_INVAL);
+} else {
+gen_op_cmp(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
+   1, crfD(ctx-opcode));
+}
+} else {
 gen_op_cmp32(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
  1, crfD(ctx-opcode));
-} else {
-gen_op_cmp(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
-   1, crfD(ctx-opcode));
 }
 }
 
 /* cmpi */
 static void gen_cmpi(DisasContext *ctx)
 {
-if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
+if (ctx-opcode  0x0020) {
+if (unlikely(!(ctx-insns_flags  PPC_64B))) {
+gen_inval_exception(ctx, POWERPC_EXCP_INVAL_INVAL);
+} else {
+gen_op_cmpi(cpu_gpr[rA(ctx-opcode)], SIMM(ctx-opcode),
+1, crfD(ctx-opcode));
+}
+} else {
 gen_op_cmpi32(cpu_gpr[rA(ctx-opcode)], SIMM(ctx-opcode),
   1, crfD(ctx-opcode));
-} else {
-gen_op_cmpi(cpu_gpr[rA(ctx-opcode)], SIMM(ctx-opcode),
-1, crfD(ctx-opcode));
 }
 }
 
 /* cmpl */
 static void gen_cmpl(DisasContext *ctx)
 {
-if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
+if (ctx-opcode  0x0020) {
+if (unlikely(!(ctx-insns_flags  PPC_64B))) {
+gen_inval_exception(ctx, POWERPC_EXCP_INVAL_INVAL);
+} else {
+gen_op_cmp(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
+   0, crfD(ctx-opcode));
+}
+} else {
 gen_op_cmp32(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
  0, crfD(ctx-opcode));
-} else {
-gen_op_cmp(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
-   0, crfD(ctx-opcode));
 }
 }
 
 /* cmpli */
 static void gen_cmpli(DisasContext *ctx)
 {
-if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
+if (ctx-opcode  0x0020) {
+if (unlikely(!(ctx-insns_flags  PPC_64B))) {
+gen_inval_exception(ctx, POWERPC_EXCP_INVAL_INVAL);
+} else {
+gen_op_cmpi(cpu_gpr[rA(ctx-opcode)], UIMM(ctx-opcode),
+0, crfD(ctx-opcode));
+}
+} else {
 

Re: [Qemu-devel] [Qemu-ppc] Incorrect handling of more PPC64 insns (PATCH)

2013-05-08 Thread Alexander Graf

On 08.05.2013, at 08:50, Aurelien Jarno wrote:

 On Tue, May 07, 2013 at 09:30:24PM +0200, Torbjorn Granlund wrote:
 I realised a possible problem with my suggested patch.
 
 What about a 32-bit processor?  Then NARROW_MODE macro is identical 0.
 
 The pre-patch behaviour was then to ignore the L bit and decode both
 32-bit and 64-bit instruction in the same way.
 
 Apparently that is correct behaviour.  (The manual is slightly vague,
 but I let hardware decide.)
 
 With my patch, the bit is not ignored, and invalid code will be
 generated for 32-bit targets, if they'd set the L bit.
 
 Here is an uglier but hopefully completely correct patch.
 
 diff --git a/target-ppc/translate.c b/target-ppc/translate.c
 index 1a84653..69d684c 100644
 --- a/target-ppc/translate.c
 +++ b/target-ppc/translate.c
 @@ -675,49 +675,65 @@ static inline void gen_set_Rc0(DisasContext *ctx, TCGv 
 reg)
 /* cmp */
 static void gen_cmp(DisasContext *ctx)
 {
 -if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
 +#if defined(TARGET_PPC64)
 +if (!(ctx-opcode  0x0020)) {
 +#endif
 gen_op_cmp32(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
  1, crfD(ctx-opcode));
 +#if defined(TARGET_PPC64)
 } else {
 gen_op_cmp(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
1, crfD(ctx-opcode));
 }
 +#endif
 }
 
 I agree that there is a bug there, and that cmp32 should be used with
 when L=0. That said your code is not going to generate and invalid code
 on a 32-bit CPU with L=1, but instead just skip the instruction.
 Moreover as Alexander pointed, TARGET_PPC64 doesn't mean it's a 64-bit
 CPU, but that the resulting qemu binaries support 64-bit CPU.
 
 What about the following patch (only lightly tested).
 
 
 From: Aurelien Jarno aurel...@aurel32.net
 
 target-ppc: fix cmp instructions on 64-bit CPUs
 
 64-bit CPUs check for the L bit of comparison instruction to determine
 if the instruction is 32-bit wide, and not to the MSR SF bit.
 
 L=1 on a 32-bit CPU should generate an invalid instruction exception.
 
 Reported-by: Torbjorn Granlund t...@gmplib.org
 Signed-off-by: Aurelien Jarno aurel...@aurel32.net
 ---
 target-ppc/translate.c |   48 
 1 file changed, 32 insertions(+), 16 deletions(-)
 
 diff --git a/target-ppc/translate.c b/target-ppc/translate.c
 index 0886f4d..ab41dc1 100644
 --- a/target-ppc/translate.c
 +++ b/target-ppc/translate.c
 @@ -675,48 +675,64 @@ static inline void gen_set_Rc0(DisasContext *ctx, TCGv 
 reg)
 /* cmp */
 static void gen_cmp(DisasContext *ctx)
 {
 -if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
 +if (ctx-opcode  0x0020) {
 +if (unlikely(!(ctx-insns_flags  PPC_64B))) {
 +gen_inval_exception(ctx, POWERPC_EXCP_INVAL_INVAL);

Can't we handle this through the reserved bits in the instruction map?


Alex

 +} else {
 +gen_op_cmp(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
 +   1, crfD(ctx-opcode));
 +}
 +} else {
 gen_op_cmp32(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
  1, crfD(ctx-opcode));
 -} else {
 -gen_op_cmp(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
 -   1, crfD(ctx-opcode));
 }
 }
 
 /* cmpi */
 static void gen_cmpi(DisasContext *ctx)
 {
 -if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
 +if (ctx-opcode  0x0020) {
 +if (unlikely(!(ctx-insns_flags  PPC_64B))) {
 +gen_inval_exception(ctx, POWERPC_EXCP_INVAL_INVAL);
 +} else {
 +gen_op_cmpi(cpu_gpr[rA(ctx-opcode)], SIMM(ctx-opcode),
 +1, crfD(ctx-opcode));
 +}
 +} else {
 gen_op_cmpi32(cpu_gpr[rA(ctx-opcode)], SIMM(ctx-opcode),
   1, crfD(ctx-opcode));
 -} else {
 -gen_op_cmpi(cpu_gpr[rA(ctx-opcode)], SIMM(ctx-opcode),
 -1, crfD(ctx-opcode));
 }
 }
 
 /* cmpl */
 static void gen_cmpl(DisasContext *ctx)
 {
 -if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
 +if (ctx-opcode  0x0020) {
 +if (unlikely(!(ctx-insns_flags  PPC_64B))) {
 +gen_inval_exception(ctx, POWERPC_EXCP_INVAL_INVAL);
 +} else {
 +gen_op_cmp(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
 +   0, crfD(ctx-opcode));
 +}
 +} else {
 gen_op_cmp32(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
  0, crfD(ctx-opcode));
 -} else {
 -gen_op_cmp(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
 -   0, crfD(ctx-opcode));
 }
 }
 
 /* cmpli */
 static void gen_cmpli(DisasContext *ctx)
 {
 -if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
 +if (ctx-opcode  0x0020) {
 +if (unlikely(!(ctx-insns_flags  PPC_64B))) {
 +gen_inval_exception(ctx, POWERPC_EXCP_INVAL_INVAL);
 +

Re: [Qemu-devel] sparc-linux-user: Fix missing symbols in .rel/.rela.plt sections

2013-05-08 Thread Michael Tokarev
Ping #2?

06.04.2013 10:08, Michael Tokarev wrote:
 This patch was submitted more than a year ago (at Jan-2012).
 Is it still needed?  If yes, why it hasn't been applied?
 
 It still applies cleanly to the current git, with the exception
 of s|^|ldscripts/| - sparc.ld moved from the top directory to
 ldscripts/.
 
 (Ref: http://patchwork.ozlabs.org/patch/135267 )
 
 Thanks,
 
 /mjt
 
 
 10.01.2012 11:38, Aurelien Jarno wrote:
 sparc-linux-user: Fix missing symbols in .rel/.rela.plt sections

 Fix .rel.plt sections in the output to not only include .rel.plt
 sections from the input but also the .rel.iplt sections and to define
 the hidden symbols __rel_iplt_start and __rel_iplt_end around
 .rel.iplt as otherwise we get undefined references to these when
 linking statically to a multiarch enabled libc (using STT_GNU_IFUNC).

 Cc: Blue Swirl blauwir...@gmail.com
 Signed-off-by: Aurelien Jarno aurel...@aurel32.net

 ---
 sparc.ld |   16 ++--
  1 files changed, 14 insertions(+), 2 deletions(-)

 diff --git a/sparc.ld b/sparc.ld
 index 56efe34..cec17c9 100644
 --- a/sparc.ld
 +++ b/sparc.ld
 @@ -37,8 +37,20 @@ SECTIONS
.rela.fini : { *(.rela.fini)  }
.rel.bss   : { *(.rel.bss)}
.rela.bss  : { *(.rela.bss)   }
 -  .rel.plt   : { *(.rel.plt)}
 -  .rela.plt  : { *(.rela.plt)   }
 +  .rel.plt  :
 +  {
 +*(.rel.plt)
 +PROVIDE (__rel_iplt_start = .);
 +*(.rel.iplt)
 +PROVIDE (__rel_iplt_end = .);
 +  }
 +  .rela.plt   :
 +  {
 +*(.rela.plt)
 +PROVIDE (__rela_iplt_start = .);
 +*(.rela.iplt)
 +PROVIDE (__rela_iplt_end = .);
 +  }
.init  : { *(.init)   } =0x47ff041f
.text  :
{

 
 




Re: [Qemu-devel] [Qemu-trivial] [PATCH] docs: mention AddressSpaces in docs/memory.txt

2013-05-08 Thread Michael Tokarev
06.05.2013 20:23, Paolo Bonzini wrote:
 Reported-by: David Gibson da...@gibson.dropbear.id.au
 Signed-off-by: Paolo Bonzini pbonz...@redhat.com
 ---
  docs/memory.txt | 11 +++
  1 file changed, 7 insertions(+), 4 deletions(-)

Thanks,  applied to the trivial patches tree.

/mjt



Re: [Qemu-devel] Reporting Heisenbugs in qemu

2013-05-08 Thread Paolo Bonzini
Il 08/05/2013 00:57, Aurelien Jarno ha scritto:
 On Tue, May 07, 2013 at 11:29:20PM +0200, Artyom Tarasenko wrote:
 On Tue, May 7, 2013 at 1:38 PM, Torbjorn Granlund t...@gmplib.org wrote:
 The 2nd table of http://gmplib.org/devel/testsystems.html shows all
 emulated systems I am using, most of which are qemu-based.

 Do I read it correct that qemu-system-ppc64 with the slowdown factor
 of 33 is ~3 times faster than qemu-system-sparc64 with the slowdown
 factor of 96 ?
 Do they both use Debian Wheezy guest? You have a remark that ppc64 has
 problems with its clock. Was it taken into account when the slowdown
 factors were calculated?

 
 Clock or not, it should be noted that qemu-system-sparc64 is undoubtedly
 slower (at least 5 to 10 times) than qemu-system-{arm,ppc,mips,...} on
 some type of load like perl scripts.

I guess that's the register windows.  There's only so much you can do to
optimize them, and heavily recursive workloads (like Perl, or the RTL
half of GCC) pay a hefty price.

Paolo



Re: [Qemu-devel] qemu-img problem when create a file larger than fs's size

2013-05-08 Thread yuxh


Thank you for your reply. I agreed what you said.
And do you think we shall print a prompt to user when the size user 
specified is larger than available space ?


On 05/08/2013 02:36 PM, Fam Zheng wrote:

I think it's the system admin to be responsible for the risk of over
provisioning. We have host sparse file[1] (as your example) for
preallocated image (for example, -f raw), as well as sparse image (as
supported in qcow2, vmdk, etc.). There are cases that host file system
is extended or the vm disk is moved to a larger storage when the actual
data grows closer to full, so it's not very practical to limit the
creating size, just as this is quietly valid in linux, no matter how
small your /tmp is.

 # df /tmp/ -h
 Filesystem  Size  Used Avail Use% Mounted on
 tmpfs   3.8G   14M  3.8G   1% /tmp
 # touch /tmp/a
 # truncate /tmp/a --size 1T
 # ls -l /tmp/a
 -rw-rw-r--. 1 fam fam 1099511627776 May  8 14:33 /tmp/a

[1]: http://en.wikipedia.org/wiki/Sparse_file

On Wed, 05/08 13:18, yuxh wrote:

Hello all,

I have to consult you a qemu-img's problem.

Is this reasonable to create a file which is larger than the
available size of the fs by qemu-img cmd ?

When I use qemu-img create a file which is larger than the available
size of the fs, the creation is completed succesfully.

However when I use this file in guest as a guest's disk, and write
beyond the size the host file can provides, the guest was paused by
qemu-kvm or libvirt and was in maybe a infinite circle where the
guest just can't be used except I detach the disk from guest or
destroy the guest.

I read the qemu-img's code and found it just create the file as we
required and doesn't check if the size we specify is reasonable.But
this may let the guest in a risk of meeting the problem I describe
above.

Exp:
[root@build mytest]# df -ah /mytest/
FilesystemSize  Used Avail Use% Mounted on
/dev/sdb2 2.0G  3.1M  1.9G   1% /mytest
[root@build mytest]# qemu-img create -f raw test.raw 3G
Formatting 'test.raw', fmt=raw size=3221225472
[root@build mytest]# ls -l test.raw
-rw-r--r--. 1 root root 3221225472 May  8 12:23 test.raw
[root@build mytest]#

Thank you.

Best Regards
Xinghai Yu





--
以上

第一软件事业部 第一开发部 driver组 于星海
Best Regards
--
Yu Xinghai
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
No.6 Wenzhu Road, Nanjing, 210012, China
TEL: +86+25-86630566-8533
FUJITSU INTERNAL: 7998-8533
FAX: +86+25-83317685
MAIL: yuxing...@cn.fujitsu.com
--



[Qemu-devel] [PATCH] [ARM] i.MX25: Fix DTS tree for real hardware.

2013-05-08 Thread Jean-Christophe DUBOIS
i.MX25 PDK only has 64 MB DDR

Signed-off-by: Jean-Christophe DUBOIS j...@tribudubois.net
---
 arch/arm/board/imx25/dts/3dstack/3dstack.dtsi| 3 ++-
 arch/arm/board/imx25/dts/3dstack/one_guest_versatile.dts | 5 +
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/arm/board/imx25/dts/3dstack/3dstack.dtsi 
b/arch/arm/board/imx25/dts/3dstack/3dstack.dtsi
index 29ff746..9c59d93 100644
--- a/arch/arm/board/imx25/dts/3dstack/3dstack.dtsi
+++ b/arch/arm/board/imx25/dts/3dstack/3dstack.dtsi
@@ -27,9 +27,10 @@
 * unless specified by -m option. If you have
 * X MB then we will be able to access only first
 * X MB starting at physical_addr.
+ * Note: the 3Dstack board only has 64 MB DDR.
 */
physical_addr = 0x8000;
-   physical_size = 0x0800; /* 128 MB */
+   physical_size = 0x0400; /* 64 MB */
};
 
soc {
diff --git a/arch/arm/board/imx25/dts/3dstack/one_guest_versatile.dts 
b/arch/arm/board/imx25/dts/3dstack/one_guest_versatile.dts
index e6ec7ea..7d5e2d6 100644
--- a/arch/arm/board/imx25/dts/3dstack/one_guest_versatile.dts
+++ b/arch/arm/board/imx25/dts/3dstack/one_guest_versatile.dts
@@ -10,10 +10,7 @@
 
  /* Update guest0 memory regions */
  devtree attr set /guests/guest0/aspace/mem0 
host_physical_addr physaddr 0x8200,
- devtree attr set /guests/guest0/aspace/mem0 
physical_size physsize 0x0600,
-
- /* Connect guest0/virtio-net0 netport to netbridge0 */
- devtree attr set /guests/guest0/aspace/virtio-net0 
switch string netbridge0,
+ devtree attr set /guests/guest0/aspace/mem0 
physical_size physsize 0x0200,
 
  /* Update guest0 flash region */
  devtree attr set /guests/guest0/aspace/nor_flash 
host_physical_addr physaddr 0x8100,
-- 
1.8.1.2




Re: [Qemu-devel] [PATCH 40/40] memory: add reference counting to FlatView

2013-05-08 Thread Jan Kiszka
On 2013-05-07 21:44, Paolo Bonzini wrote:
 Il 07/05/2013 20:00, Jan Kiszka ha scritto:
 On 2013-05-07 16:17, Paolo Bonzini wrote:
 With this change, a FlatView can be used even after a concurrent
 update has replaced it.  Because we do not have RCU, we use a
 mutex to protect the small critical sections that read/write the
 as-current_map pointer.  Accesses to the FlatView can be done
 outside the mutex.

 If a MemoryRegion will be used after the FlatView is unref-ed (or after
 a MemoryListener callback is returned), a reference has to be added to
 that MemoryRegion.  For example, memory_region_find adds a reference to
 the MemoryRegion that it returns.

 For my understanding: Every lookup, e.g. triggered by address_space_rw,
 will briefly reference the FlatView of that address space and drop that
 reference again after referencing the target memory region.

 Provided that is true: If we run that lookup on an address space that
 happens to be modified in parallel, the lookup may actually cause the
 final deref and, thus, release of the FlatView - even if the target
 memory region was totally unrelated to the ongoing change. That could
 make a hot-path pay the price of an action a slow path caused. Not
 really a beautiful concept. Even if the FlatView finalization is a
 simple free() (that is the minimum), we would pull the memory allocator
 into code paths that might try hard to keep a safe distance for the sake
 of predictability.
 
 All this is correct.  But I hope to get RCU in 1.6, otherwise we can use
 a bottom half.  In any case, this is obviously no worse than current
 code that requires the BQL (hence the lookup would serialize against the
 free).

Sure, not a regression. But I'd like to avoid that we are moving in the
potentially wrong direction /wrt final goal. And I'm very interested in
having increments that can be used in RT demonstration scenarios without
having to hack too much on the code.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux



Re: [Qemu-devel] Possible ppc comparision optimisation

2013-05-08 Thread Paolo Bonzini
Il 08/05/2013 00:56, Torbjorn Granlund ha scritto:
 The current ppc gen_op_cmp generates a long sequence of instructions,
 using a plain series of three disjoint compares.
 
 It is possible to compute the 3 result bits more cleverly.  Below is a
 possible replacement gen_op_cmp.  (It is tested by booting GNU/Linux
 ppx64, but not much more than that.)
 
 Surely this should be faster than the old code?  OK, it is less
 readable, but cmp is pretty critical and should be made fast.
 
 Should one truncate things using tcg_gen_trunc_tl_i32 and do the add,
 xori, addi as i32 variants?  (Why?)

I think that would be faster on 32-bit hosts, truncs are cheap.

 There could be a disadvantage of this compared to the old code, since
 this has a chained algebraic dependency, while the old code's many
 instructions might have been more independent.

What about these alternatives:

setcond LT, t0, arg0, arg1
setcond EQ, t1, arg0, arg1
trunc  s0, t0
trunc  s1, t1
shli   s0, s0, 1; s0 = (arg0  arg1) ? 2 : 0
subi   s1, s1, 2; s1 = (arg0 != arg1) ? -2 : -1
subs0, s0, s1   ;  4   == 1   2
shli   s0, s0, 1;  8   == 2   4

===

setcond LT, t0, arg0, arg1
setcond NE, t1, arg0, arg1
trunc   s0, t0
trunc   s1, t1
add s0, s0, s1  ;  2   == 0   1
movis1, 1
add s0, s0, s1  ;  3   == 1   2
shl s1, s1, s0  ;  8   == 2   4

Paolo

 static inline void gen_op_cmp(TCGv arg0, TCGv arg1, int s, int crf)
 {
 TCGv t0 = tcg_temp_new();
 TCGv t1 = tcg_temp_new();
 TCGv_i32 s0 = tcg_temp_new_i32();
 
 tcg_gen_trunc_tl_i32(cpu_crf[crf], cpu_so);
 
 tcg_gen_setcond_tl((s ? TCG_COND_LE: TCG_COND_LEU), t0, arg0, arg1);
 tcg_gen_setcond_tl((s ? TCG_COND_LT: TCG_COND_LTU), t1, arg0, arg1);
 tcg_gen_add_tl(t0, t0, t1);
 tcg_gen_xori_tl(t0, t0, 1);
 tcg_gen_addi_tl(t0, t0, 1);
 tcg_gen_trunc_tl_i32(s0, t0);
 tcg_gen_shli_i32(s0, s0, 1);
 tcg_gen_or_i32(cpu_crf[crf], cpu_crf[crf], s0);
 
 tcg_temp_free(t0);
 tcg_temp_free(t1);
 tcg_temp_free_i32(s0);
 }
 




Re: [Qemu-devel] qemu-img problem when create a file larger than fs's size

2013-05-08 Thread Fam Zheng
On Wed, 05/08 15:34, yuxh wrote:
 
 Thank you for your reply. I agreed what you said.
 And do you think we shall print a prompt to user when the size user
 specified is larger than available space ?

Might be nice, but it's hard to define available space, and available
space at creating time promises nothing. Even if the user creates a
small image which seems safe, risk is still there: when other
applications' data fills up the available space, the use still
experiences the same problem.

 
 On 05/08/2013 02:36 PM, Fam Zheng wrote:
 I think it's the system admin to be responsible for the risk of over
 provisioning. We have host sparse file[1] (as your example) for
 preallocated image (for example, -f raw), as well as sparse image (as
 supported in qcow2, vmdk, etc.). There are cases that host file system
 is extended or the vm disk is moved to a larger storage when the actual
 data grows closer to full, so it's not very practical to limit the
 creating size, just as this is quietly valid in linux, no matter how
 small your /tmp is.
 
  # df /tmp/ -h
  Filesystem  Size  Used Avail Use% Mounted on
  tmpfs   3.8G   14M  3.8G   1% /tmp
  # touch /tmp/a
  # truncate /tmp/a --size 1T
  # ls -l /tmp/a
  -rw-rw-r--. 1 fam fam 1099511627776 May  8 14:33 /tmp/a
 
 [1]: http://en.wikipedia.org/wiki/Sparse_file
 
 On Wed, 05/08 13:18, yuxh wrote:
 Hello all,
 
 I have to consult you a qemu-img's problem.
 
 Is this reasonable to create a file which is larger than the
 available size of the fs by qemu-img cmd ?
 
 When I use qemu-img create a file which is larger than the available
 size of the fs, the creation is completed succesfully.
 
 However when I use this file in guest as a guest's disk, and write
 beyond the size the host file can provides, the guest was paused by
 qemu-kvm or libvirt and was in maybe a infinite circle where the
 guest just can't be used except I detach the disk from guest or
 destroy the guest.
 
 I read the qemu-img's code and found it just create the file as we
 required and doesn't check if the size we specify is reasonable.But
 this may let the guest in a risk of meeting the problem I describe
 above.
 
 Exp:
 [root@build mytest]# df -ah /mytest/
 FilesystemSize  Used Avail Use% Mounted on
 /dev/sdb2 2.0G  3.1M  1.9G   1% /mytest
 [root@build mytest]# qemu-img create -f raw test.raw 3G
 Formatting 'test.raw', fmt=raw size=3221225472
 [root@build mytest]# ls -l test.raw
 -rw-r--r--. 1 root root 3221225472 May  8 12:23 test.raw
 [root@build mytest]#
 
 Thank you.
 
 Best Regards
 Xinghai Yu
 
 
 
 -- 
 以上
 
 第一软件事业部 第一开发部 driver组 于星海
 Best Regards
 --
 Yu Xinghai
 Development Dept.I
 Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
 No.6 Wenzhu Road, Nanjing, 210012, China
 TEL: +86+25-86630566-8533
 FUJITSU INTERNAL: 7998-8533
 FAX: +86+25-83317685
 MAIL: yuxing...@cn.fujitsu.com
 --

-- 
Fam



[Qemu-devel] (i386) TCG is broken in 1.5-rc0 with guest kernel 3.2?

2013-05-08 Thread Michael Tokarev
Something strange is going on here.

I just tried 1.5-rc0 (32bit x86 userspace), and guest kernel
crashes in an interesting way right at init time.

 qemu-system-x86_64 -net none -kernel /boot/vmlinuz-3.2-amd64 -append 
console=ttyS0 -serial file:serial

This results in:

[0.071315] mce: CPU supports 10 MCE banks
[0.082316] SMP alternatives: switching to UP code
[0.658457] Freeing SMP alternatives: 16k freed
[0.660716] ACPI: Core revision 20110623
[0.744749] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[0.778545] CPU0: AMD QEMU Virtual CPU version 1.4.90 stepping 03
[0.887450] Performance Events: Broken PMU hardware detected, using software 
events only.
[0.889372] NMI watchdog disabled (cpu0): hardware events not enabled
[0.889372] Brought up 1 CPUs
[0.889372] Total of 1 processors activated (6432.01 BogoMIPS).
[0.889372] devtmpfs: initialized
[0.889372] [ cut here ]
[0.889372] WARNING: at fs/sysfs/group.c:138 dpm_sysfs_add+0xb4/0xc0()
[0.889372] Hardware name: Bochs
[0.889372] sysfs group 814bece0 not found for kobject 'platform'
[0.889372] Modules linked in:
[0.889372] Pid: 1, comm: swapper/0 Not tainted 3.2.0-amd64 #3.2.42
[0.889372] Call Trace:
[0.889372]  [812791c4] ? dpm_sysfs_add+0xb4/0xc0
...

[0.889372] ---[ end trace ef00d87ab31a38ca ]---
[0.889372] NET: Registered protocol family 16
[0.889372] [ cut here ]
[0.889372] WARNING: at fs/sysfs/group.c:138 dpm_sysfs_add+0xb4/0xc0()
[0.889372] Hardware name: Bochs
[0.889372] sysfs group 814bece0 not found for kobject 'vtcon0'
[0.889372] Modules linked in:
[0.889372] Pid: 1, comm: swapper/0 Tainted: GW3.2.0-amd64 
#3.2.42
[0.889372] Call Trace:
[0.889372]  [812791c4] ? dpm_sysfs_add+0xb4/0xc0
...

and finally
[0.889372] kernel BUG at kernel/params.c:780!
[0.889372] invalid opcode:  [#1] SMP
...
[0.893968] Kernel panic - not syncing: Attempted to kill init!



The same happens with other 3.2.x kernels, for example, ubuntu precise:
http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/linux


qemu-system-x86_64 from qemu-1.4.x lets these kernels to boot fine,
it all boots fine when adding -enable-kvm.  So it is some change(s)
in TCG between 1.4 and 1.5, maybe triggering a bug in guest kernel.

For added fun, for example, 3.8 guest kernel does NOT have problems
with this config.

I'm trying to bisect the issue now.

This happened when CarlFK (Cc'd) mentioned that he has issues with
installing ubuntu precise in a 1.5 virtual machine.  But in his
case, the prob was different, -- his installer does not configure
NIC properly due to dhclient segfaulting, which, again, does not
happen with previous versions of qemu.  This may be related or
not, I don't know yet.

That's just a heads-up for now, will post more details as something
will become available.

Thanks,

/mjt



[Qemu-devel] [PATCH v5 4/4] Add qtest support for i.MX I2C device emulation.

2013-05-08 Thread Jean-Christophe DUBOIS
This is using a ds1338 RTC chip on the i2c bus. This RTC
chip is not present on the real board.

Signed-off-by: Jean-Christophe DUBOIS j...@tribudubois.net
---

Changes since v1:
* not present on v1

Changes since v2:
* use a common header file for I2C regs definition

Changes since v3:
* rework GPL headers.

Changes since v4:
* none

 tests/Makefile |   3 +
 tests/ds1338-test.c|  75 ++
 tests/libqos/i2c-imx.c | 209 +
 tests/libqos/i2c.h |   3 +
 4 files changed, 290 insertions(+)
 create mode 100644 tests/ds1338-test.c
 create mode 100644 tests/libqos/i2c-imx.c

diff --git a/tests/Makefile b/tests/Makefile
index bf41d10..5f7a0e0 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -64,6 +64,7 @@ gcov-files-x86_64-y = $(subst 
i386-softmmu/,x86_64-softmmu/,$(gcov-files-i386-y)
 gcov-files-sparc-y += hw/m48t59.c
 gcov-files-sparc64-y += hw/m48t59.c
 check-qtest-arm-y = tests/tmp105-test$(EXESUF)
+check-qtest-arm-y += tests/ds1338-test$(EXESUF)
 gcov-files-arm-y += hw/tmp105.c
 
 GENERATED_HEADERS += tests/test-qapi-types.h tests/test-qapi-visit.h 
tests/test-qmp-commands.h
@@ -123,12 +124,14 @@ libqos-obj-y += tests/libqos/i2c.o
 libqos-pc-obj-y = $(libqos-obj-y) tests/libqos/pci-pc.o 
tests/libqos/fw_cfg-pc.o
 libqos-pc-obj-y += tests/libqos/malloc-pc.o
 libqos-omap-obj-y = $(libqos-obj-y) tests/libqos/i2c-omap.o
+libqos-imx-obj-y = $(libqos-obj-y) tests/libqos/i2c-imx.o
 
 tests/rtc-test$(EXESUF): tests/rtc-test.o
 tests/m48t59-test$(EXESUF): tests/m48t59-test.o
 tests/fdc-test$(EXESUF): tests/fdc-test.o
 tests/hd-geo-test$(EXESUF): tests/hd-geo-test.o
 tests/tmp105-test$(EXESUF): tests/tmp105-test.o $(libqos-omap-obj-y)
+tests/ds1338-test$(EXESUF): tests/ds1338-test.o $(libqos-imx-obj-y)
 tests/i440fx-test$(EXESUF): tests/i440fx-test.o $(libqos-pc-obj-y)
 tests/fw_cfg-test$(EXESUF): tests/fw_cfg-test.o $(libqos-pc-obj-y)
 
diff --git a/tests/ds1338-test.c b/tests/ds1338-test.c
new file mode 100644
index 000..fbc989b
--- /dev/null
+++ b/tests/ds1338-test.c
@@ -0,0 +1,75 @@
+/*
+ * QTest testcase for the DS1338 RTC
+ *
+ * Copyright (c) 2013 Jean-Christophe Dubois
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but WITHOUT
+ *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ *  FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ *  for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, see http://www.gnu.org/licenses/.
+ */
+
+#include libqtest.h
+#include libqos/i2c.h
+
+#include glib.h
+
+#define IMX25_I2C_0_BASE 0x43F8
+
+#define DS1338_ADDR 0x68
+
+static I2CAdapter *i2c;
+static uint8_t addr;
+
+#define bcd2bin(x)(((x)  0x0f) + ((x)  4) * 10)
+
+static void send_and_receive(void)
+{
+uint8_t cmd[1];
+uint8_t resp[7];
+time_t now = time(NULL);
+struct tm *tm_ptr = gmtime(now);
+
+/* reset the index in the RTC memory */
+cmd[0] = 0;
+i2c_send(i2c, addr, cmd, 1);
+
+/* retrieve the date */
+i2c_recv(i2c, addr, resp, 7);
+
+/* check retreived time againt local time */
+g_assert_cmpuint(bcd2bin(resp[4]), == , tm_ptr-tm_mday);
+g_assert_cmpuint(bcd2bin(resp[5]), == , 1 + tm_ptr-tm_mon);
+g_assert_cmpuint(2000 + bcd2bin(resp[6]), == , 1900 + tm_ptr-tm_year);
+}
+
+int main(int argc, char **argv)
+{
+QTestState *s = NULL;
+int ret;
+
+g_test_init(argc, argv, NULL);
+
+s = qtest_start(-display none -machine imx25_3ds);
+i2c = imx_i2c_create(IMX25_I2C_0_BASE);
+addr = DS1338_ADDR;
+
+qtest_add_func(/ds1338/tx-rx, send_and_receive);
+
+ret = g_test_run();
+
+if (s) {
+qtest_quit(s);
+}
+g_free(i2c);
+
+return ret;
+}
diff --git a/tests/libqos/i2c-imx.c b/tests/libqos/i2c-imx.c
new file mode 100644
index 000..2b18581
--- /dev/null
+++ b/tests/libqos/i2c-imx.c
@@ -0,0 +1,209 @@
+/*
+ * QTest i.MX I2C driver
+ *
+ * Copyright (c) 2013 Jean-Christophe Dubois
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but WITHOUT
+ *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ *  FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ *  for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, see 

[Qemu-devel] [PATCH v5 3/4] Add i.MX25 3DS evaluation board support.

2013-05-08 Thread Jean-Christophe DUBOIS
For now we support:
* timers (GPT and EPIT)
* serial ports
* ethernet (through the newly added FEC emulator)
* I2C (through the newly added I2C emulator)

Signed-off-by: Jean-Christophe DUBOIS j...@tribudubois.net
---

Changes since v1:
* Added a ds1338 I2C device for qtest purpose.

Changes since v2:
* none
 
Changes since v3:
* Rework GPL header  
* use I2C constructor helper.

Changes since v4:
* use sysbus_create_simple() instead of I2C constructor helper

 hw/arm/Makefile.objs |   1 +
 hw/arm/imx25_3ds.c   | 250 +++
 2 files changed, 251 insertions(+)
 create mode 100644 hw/arm/imx25_3ds.c

diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index 9e3a06f..2f4280d 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -2,6 +2,7 @@ obj-y += boot.o collie.o exynos4_boards.o gumstix.o highbank.o
 obj-y += integratorcp.o kzm.o mainstone.o musicpal.o nseries.o
 obj-y += omap_sx1.o palm.o pic_cpu.o realview.o spitz.o stellaris.o
 obj-y += tosa.o versatilepb.o vexpress.o xilinx_zynq.o z2.o
+obj-y += imx25_3ds.o
 
 obj-y += armv7m.o exynos4210.o pxa2xx.o pxa2xx_gpio.o pxa2xx_pic.o
 obj-y += omap1.o omap2.o strongarm.o
diff --git a/hw/arm/imx25_3ds.c b/hw/arm/imx25_3ds.c
new file mode 100644
index 000..c845195
--- /dev/null
+++ b/hw/arm/imx25_3ds.c
@@ -0,0 +1,250 @@
+/*
+ * Copyright (c) 2013 Jean-Christophe Dubois
+ *
+ * 3Dstack Board System emulation.
+ *
+ * Based on hw/arm/kzm.c
+ *
+ * Copyright (c) 2008 OKL and 2011 NICTA
+ * Written by Hans at OK-Labs
+ * Updated by Peter Chubb.
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but WITHOUT
+ *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ *  FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ *  for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, see http://www.gnu.org/licenses/.
+ */
+
+#include hw/sysbus.h
+#include exec/address-spaces.h
+#include hw/hw.h
+#include hw/arm/arm.h
+#include hw/devices.h
+#include net/net.h
+#include sysemu/sysemu.h
+#include hw/boards.h
+#include hw/char/serial.h
+#include hw/arm/imx.h
+#include hw/i2c/i2c.h
+
+#include sysemu/qtest.h
+
+/* Memory map for 3D-Stack Emulation Baseboard:
+ * 0x-0x3fff 16k ROM  IGNORED
+ * 0x4000-0x00403fff Reserved IGNORED
+ * 0x00404000-0x00408fff 20k ROM  IGNORED
+ * 0x00409000-0x0fff Reserved IGNORED
+ * 0x1000-0x1fff Reserved IGNORED
+ * 0x2000-0x2fff Reserved IGNORED
+ * 0x3000-0x3fff Reserved IGNORED
+ * 0x4000-0x43ef Reserved IGNORED
+ * 0x43f0-0x6fff I.MX25 Internal Register Space
+ *   0x43f0 IO_AREA0
+ *   0x43f8 I2C0  EMULATED
+ *   0x43f84000 I2C2  EMULATED
+ *   0x43f98000 I2C1  EMULATED
+ *   0x43f9 UART1 EMULATED
+ *   0x43f94000 UART2 EMULATED
+ *   0x5000c000 UART3 EMULATED
+ *   0x53f8 CCM   EMULATED
+ *   0x53f84000 GPT 4 EMULATED
+ *   0x53f88000 GPT 3 EMULATED
+ *   0x53f8c000 GPT 2 EMULATED
+ *   0x53f9 GPT 1 EMULATED
+ *   0x53f94000 PIT 1 EMULATED
+ *   0x53f98000 PIT 2 EMULATED
+ *   0x6800 ASIC  EMULATED
+ * 0x7800-0x7801 SRAM EMULATED
+ * 0x7802-0x7fff SRAM AliasingEMULATED
+ * 0x8000-0x87ff RAM + Alias  EMULATED
+ * 0x9000-0x9fff RAM + Alias  EMULATED
+ * 0xa000-0xa7ff FlashIGNORED
+ * 0xa800-0xafff FlashIGNORED
+ * 0xb000-0xb1ff SRAM IGNORED
+ * 0xb200-0xb3ff SRAM IGNORED
+ * 0xb400-0xb5ff CS4  IGNORED
+ * 0xb600-0xb8000fff Reserved IGNORED
+ * 0xb8001000-0xb8001fff SDRAM CTRL reg   IGNORED
+ * 0xb8002000-0xb8002fff WEIM CTRL regIGNORED
+ * 0xb8003000-0xb8003fff M3IF CTRL regIGNORED
+ * 0xb8004000-0xb8004fff EMI CTRL reg IGNORED
+ * 0xb8005000-0xbaff Reserved IGNORED
+ * 0xbb00-0xbb000fff NAND flash area buf  IGNORED
+ * 0xbb001000-0xbb0011ff NAND flash reserved  IGNORED
+ * 0xbb001200-0xbb001dff Reserved IGNORED
+ * 0xbb001e00-0xbb001fff NAN flash CTRL reg   IGNORED
+ * 

Re: [Qemu-devel] [PATCH] [ARM] i.MX25: Fix DTS tree for real hardware.

2013-05-08 Thread Peter Maydell
On 8 May 2013 08:51, Jean-Christophe DUBOIS j...@tribudubois.net wrote:
 i.MX25 PDK only has 64 MB DDR

 Signed-off-by: Jean-Christophe DUBOIS j...@tribudubois.net
 ---
  arch/arm/board/imx25/dts/3dstack/3dstack.dtsi| 3 ++-
  arch/arm/board/imx25/dts/3dstack/one_guest_versatile.dts | 5 +
  2 files changed, 3 insertions(+), 5 deletions(-)

 diff --git a/arch/arm/board/imx25/dts/3dstack/3dstack.dtsi 
 b/arch/arm/board/imx25/dts/3dstack/3dstack.dtsi
 index 29ff746..9c59d93 100644
 --- a/arch/arm/board/imx25/dts/3dstack/3dstack.dtsi
 +++ b/arch/arm/board/imx25/dts/3dstack/3dstack.dtsi
 @@ -27,9 +27,10 @@
  * unless specified by -m option. If you have
  * X MB then we will be able to access only first
  * X MB starting at physical_addr.
 + * Note: the 3Dstack board only has 64 MB DDR.
  */
 physical_addr = 0x8000;
 -   physical_size = 0x0800; /* 128 MB */
 +   physical_size = 0x0400; /* 64 MB */
 };

 soc {
 diff --git a/arch/arm/board/imx25/dts/3dstack/one_guest_versatile.dts 
 b/arch/arm/board/imx25/dts/3dstack/one_guest_versatile.dts
 index e6ec7ea..7d5e2d6 100644
 --- a/arch/arm/board/imx25/dts/3dstack/one_guest_versatile.dts
 +++ b/arch/arm/board/imx25/dts/3dstack/one_guest_versatile.dts
 @@ -10,10 +10,7 @@

   /* Update guest0 memory regions */
   devtree attr set /guests/guest0/aspace/mem0 
 host_physical_addr physaddr 0x8200,
 - devtree attr set /guests/guest0/aspace/mem0 
 physical_size physsize 0x0600,
 -
 - /* Connect guest0/virtio-net0 netport to netbridge0 
 */
 - devtree attr set /guests/guest0/aspace/virtio-net0 
 switch string netbridge0,

This bit of the patch doesn't seem to have anything to do with
memory size ?

 + devtree attr set /guests/guest0/aspace/mem0 
 physical_size physsize 0x0200,

   /* Update guest0 flash region */
   devtree attr set /guests/guest0/aspace/nor_flash 
 host_physical_addr physaddr 0x8100,

thanks
-- PMM



[Qemu-devel] [PATCH v5 2/4] Add i.MX I2C controller emulator

2013-05-08 Thread Jean-Christophe DUBOIS
The slave mode is not implemented.

Signed-off-by: Jean-Christophe DUBOIS j...@tribudubois.net
---

Changes since v1: 
* use QOM cast
* run checkpatch on code
* added restrictin on MemoryRegionOps
* use DeviceClass::realise as init function

Changes since v2:
* use CamelCase for state type   
* use extrac32() for bit manipilation.
* improve QOM cast   
* separate regs definition in its own file (to be reused by qtest)
 
Changes since v3:
* More QOM cast.
* Rework GPL headers
* Add a constructor helper.
* fix reset()
* rework debug printf

Changes since v4:
* remove the constructor helper

 default-configs/arm-softmmu.mak |   2 +
 hw/i2c/Makefile.objs|   1 +
 hw/i2c/imx_i2c.c| 357 
 hw/i2c/imx_i2c_regs.h   |  63 +++
 4 files changed, 423 insertions(+)
 create mode 100644 hw/i2c/imx_i2c.c
 create mode 100644 hw/i2c/imx_i2c_regs.h

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index b3a0207..a20f112 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -81,3 +81,5 @@ CONFIG_VERSATILE_PCI=y
 CONFIG_VERSATILE_I2C=y
 
 CONFIG_SDHCI=y
+
+CONFIG_IMX_I2C=y
diff --git a/hw/i2c/Makefile.objs b/hw/i2c/Makefile.objs
index 648278e..d27bbaa 100644
--- a/hw/i2c/Makefile.objs
+++ b/hw/i2c/Makefile.objs
@@ -4,4 +4,5 @@ common-obj-$(CONFIG_ACPI) += smbus_ich9.o
 common-obj-$(CONFIG_APM) += pm_smbus.o
 common-obj-$(CONFIG_BITBANG_I2C) += bitbang_i2c.o
 common-obj-$(CONFIG_EXYNOS4) += exynos4210_i2c.o
+common-obj-$(CONFIG_IMX_I2C) += imx_i2c.o
 obj-$(CONFIG_OMAP) += omap_i2c.o
diff --git a/hw/i2c/imx_i2c.c b/hw/i2c/imx_i2c.c
new file mode 100644
index 000..292c07b
--- /dev/null
+++ b/hw/i2c/imx_i2c.c
@@ -0,0 +1,357 @@
+/*
+ *  i.MX I2C Bus Serial Interface Emulation
+ *
+ *  Copyright (C) 2013 Jean-Christophe Dubois.
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but WITHOUT
+ *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ *  FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ *  for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, see http://www.gnu.org/licenses/.
+ *
+ */
+
+#include qemu/bitops.h
+
+#include hw/sysbus.h
+#include hw/i2c/i2c.h
+
+#include hw/arm/imx.h
+
+#include hw/i2c/imx_i2c_regs.h
+
+#ifndef IMX_I2C_DEBUG
+#define IMX_I2C_DEBUG 0
+#endif
+
+#define TYPE_IMX_I2C  imx.i2c
+
+#if IMX_I2C_DEBUG
+#define DPRINT(fmt, ...)  \
+do { fprintf(stderr, %s[%s]:  fmt, TYPE_IMX_I2C, __func__, \
+ ## __VA_ARGS__); \
+} while (0)
+
+static const char *imx_i2c_get_regname(unsigned offset)
+{
+switch (offset) {
+case IADR_ADDR:
+return IADR;
+case IFDR_ADDR:
+return IFDR;
+case I2CR_ADDR:
+return I2CR;
+case I2SR_ADDR:
+return I2SR;
+case I2DR_ADDR:
+return I2DR;
+default:
+return [?];
+}
+}
+#else
+#define DPRINT(fmt, args...)  do { } while (0)
+#endif
+
+#define IMX_I2C(obj)  \
+OBJECT_CHECK(IMXI2CState, (obj), TYPE_IMX_I2C)
+
+typedef struct IMXI2CState {
+SysBusDevice parent_obj;
+
+MemoryRegion iomem;
+i2c_bus *bus;
+qemu_irq irq;
+
+uint16_t  address;
+
+uint16_t iadr;
+uint16_t ifdr;
+uint16_t i2cr;
+uint16_t i2sr;
+uint16_t i2dr_read;
+uint16_t i2dr_write;
+} IMXI2CState;
+
+static inline bool imx_i2c_is_enabled(IMXI2CState *s)
+{
+return s-i2cr  I2CR_IEN;
+}
+
+static inline bool imx_i2c_interrupt_is_enabled(IMXI2CState *s)
+{
+return s-i2cr  I2CR_IIEN;
+}
+
+static inline bool imx_i2c_is_master(IMXI2CState *s)
+{
+return s-i2cr  I2CR_MSTA;
+}
+
+static inline bool imx_i2c_direction_is_tx(IMXI2CState *s)
+{
+return s-i2cr  I2CR_MTX;
+}
+
+static void imx_i2c_reset(DeviceState *dev)
+{
+IMXI2CState *s = IMX_I2C(dev);
+
+s-address= ADDR_RESET;
+s-iadr   = IADR_RESET;
+s-ifdr   = IFDR_RESET;
+s-i2cr   = I2CR_RESET;
+s-i2sr   = I2SR_RESET;
+s-i2dr_read  = I2DR_RESET;
+s-i2dr_write = I2DR_RESET;
+}
+
+static inline void imx_i2c_raise_interrupt(IMXI2CState *s)
+{
+/*
+ * raise an interrupt if the device is enabled and it is configured
+ * to generate some interrupts.
+ */
+if (imx_i2c_is_enabled(s)  imx_i2c_interrupt_is_enabled(s)) {
+s-i2sr |= I2SR_IIF;
+qemu_irq_raise(s-irq);
+}
+}
+
+static uint64_t imx_i2c_read(void *opaque, hwaddr offset,
+ 

Re: [Qemu-devel] qemu-img problem when create a file larger than fs's size

2013-05-08 Thread yuxh



On 05/08/2013 04:20 PM, Fam Zheng wrote:

On Wed, 05/08 15:34, yuxh wrote:


Thank you for your reply. I agreed what you said.
And do you think we shall print a prompt to user when the size user
specified is larger than available space ?


Might be nice, but it's hard to define available space, and available
space at creating time promises nothing. Even if the user creates a
small image which seems safe, risk is still there: when other
applications' data fills up the available space, the use still
experiences the same problem.



Yes. That means the prompt means nothing. Thank you very much!

yuxh



On 05/08/2013 02:36 PM, Fam Zheng wrote:

I think it's the system admin to be responsible for the risk of over
provisioning. We have host sparse file[1] (as your example) for
preallocated image (for example, -f raw), as well as sparse image (as
supported in qcow2, vmdk, etc.). There are cases that host file system
is extended or the vm disk is moved to a larger storage when the actual
data grows closer to full, so it's not very practical to limit the
creating size, just as this is quietly valid in linux, no matter how
small your /tmp is.

 # df /tmp/ -h
 Filesystem  Size  Used Avail Use% Mounted on
 tmpfs   3.8G   14M  3.8G   1% /tmp
 # touch /tmp/a
 # truncate /tmp/a --size 1T
 # ls -l /tmp/a
 -rw-rw-r--. 1 fam fam 1099511627776 May  8 14:33 /tmp/a

[1]: http://en.wikipedia.org/wiki/Sparse_file

On Wed, 05/08 13:18, yuxh wrote:

Hello all,

I have to consult you a qemu-img's problem.

Is this reasonable to create a file which is larger than the
available size of the fs by qemu-img cmd ?

When I use qemu-img create a file which is larger than the available
size of the fs, the creation is completed succesfully.

However when I use this file in guest as a guest's disk, and write
beyond the size the host file can provides, the guest was paused by
qemu-kvm or libvirt and was in maybe a infinite circle where the
guest just can't be used except I detach the disk from guest or
destroy the guest.

I read the qemu-img's code and found it just create the file as we
required and doesn't check if the size we specify is reasonable.But
this may let the guest in a risk of meeting the problem I describe
above.

Exp:
[root@build mytest]# df -ah /mytest/
FilesystemSize  Used Avail Use% Mounted on
/dev/sdb2 2.0G  3.1M  1.9G   1% /mytest
[root@build mytest]# qemu-img create -f raw test.raw 3G
Formatting 'test.raw', fmt=raw size=3221225472
[root@build mytest]# ls -l test.raw
-rw-r--r--. 1 root root 3221225472 May  8 12:23 test.raw
[root@build mytest]#

Thank you.

Best Regards
Xinghai Yu





--
以上

第一软件事业部 第一开发部 driver组 于星海
Best Regards
--
Yu Xinghai
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
No.6 Wenzhu Road, Nanjing, 210012, China
TEL: +86+25-86630566-8533
FUJITSU INTERNAL: 7998-8533
FAX: +86+25-83317685
MAIL: yuxing...@cn.fujitsu.com
--




--
以上

第一软件事业部 第一开发部 driver组 于星海
Best Regards
--
Yu Xinghai
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
No.6 Wenzhu Road, Nanjing, 210012, China
TEL: +86+25-86630566-8533
FUJITSU INTERNAL: 7998-8533
FAX: +86+25-83317685
MAIL: yuxing...@cn.fujitsu.com
--



Re: [Qemu-devel] [PATCH 1/9] Add API to manipulate dump_bitmap

2013-05-08 Thread qiaonuohan
 -Original Message-
 From: Eric Blake [mailto:ebl...@redhat.com]
 Sent: Wednesday, May 08, 2013 12:14 AM
 To: Qiao Nuohan
 Cc: qemu-devel@nongnu.org
 Subject: Re: [Qemu-devel] [PATCH 1/9] Add API to manipulate dump_bitmap
 
 On 05/07/2013 01:16 AM, Qiao Nuohan wrote:
  Struct dump_bitmap is associated with a tmp file, and the tmp file can be
 used
  to save data of bitmap in kdump-compressed format temporarily.
  The following patch will use these functions to get the data of bitmap and
 cache
  them into tmp files.
 
  Signed-off-by: Qiao Nuohan qiaonuo...@cn.fujitsu.com
  Reviewed-by: Zhang Xiaohe zhan...@cn.fujitsu.com
  ---
 
  +db-file_name = (char *)g_malloc(strlen(filename) + strlen(tmpname) +
 1);
  +
  +strcpy(db-file_name, tmpname);
  +strcat(db-file_name, /);
  +strcat(db-file_name, filename);
 
 Off-by-one buffer overflow, since you forgot space for the NUL byte.  We
 use C, not C++, so you don't need to cast the result of g_malloc().

I will fix it as Daniel suggested.

 
  +++ b/include/dump_bitmap.h
  @@ -0,0 +1,57 @@
  +/*
  + * QEMU dump bitmap
  + *
  + * Copyright Fujitsu, Corp. 2013
  + *
  + * Authors:
  + * Qiao Nuohan qiaonuo...@cn.fujitsu.com
  + *
  + * This work is licensed under the terms of the GNU GPL, version 2 or 
  later.
  + * See the COPYING file in the top-level directory.
  + *
  + */
  +
 
 No double-inclusion guard?
 
  +#define TMP_DIR /tmp
 
 Why not reuse P_tmpdir from stdio.h instead of reinventing a new name
 for this constant?
 
  +#define BITPERBYTE  (8)
 
 Why not use CHAR_BIT from limits.h instead of reinventing a new name
 for this constant?
 
  +#define BUFSIZE_BITMAP  (4096)
  +#define PFN_BUFBITMAP   (BITPERBYTE * BUFSIZE_BITMAP)
  +
  +struct dump_bitmap {
  +int fd; /* fd of the tmp file used to store dump
 bitmap */
  +int no_block;   /* number of block cached in buf */
 
 Trailing whitespace.  Run your patch series through scripts/checkpatch.pl.
 
 The name no_block sounds like there aren't any blocks.  You probably
 want the name num_block instead.

Got it.

Thanks for your comments.

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






[Qemu-devel] Makefile: Dependency problem

2013-05-08 Thread Kevin Wolf
Hi,

I just had a failing build like this (make -j3, so these are running in
parallel):

lt LINK libcacard.la
ARlibqemuutil.a
CCstubs/mon-printf.o
CCstubs/mon-print-filename.o
ar: stubs/mon-printf.o: No such file or directory
make: *** [libcacard.la] Fehler 1
make: *** Warte auf noch nicht beendete Prozesse...

Restarting make obviously fixed the problem, but I thought I'd mention it
here so that the dependencies can be fixed.

Kevin



Re: [Qemu-devel] [RFC][PATCH 10/15] memory: Rework sub-page handling

2013-05-08 Thread Paolo Bonzini
 On 2013-05-07 19:26, Jan Kiszka wrote:
  Well, the alternative is to handle a sub-page dispatch (ie. calling into
  subpage_[ram_]read/write just like address_space_rw: take the necessary
  lock that protect mapping changes, look into the sub-page and pick up
  the target region, invoke memory_region_ref on it, perform the access
  and unref the region again. Slow, but that's how sub-pages are. And it
  only affects TCG. Hmm, or does your IOMMU core cache translations on a
  per-page base as well?
 
 OK, there is no translation caching in the memory core. So I will
 preserve the dispatching functions of sub-pages, just like the term
 sub-page - along with a comment why we depend on page granularity.

Note that TCG will cache translations because the TLB entry is filled
with the page after translation has taken place. In fact, this is the
main change from Avi's series to mine, and a side-effect of centralizing
the translation in address_space_translate.

It shouldn't be a problem though, the TLB entry will point to the subpage
and the compiled code will dispatch to it.

Paolo



Re: [Qemu-devel] [PATCH 09/40] memory: create FlatView for new address spaces

2013-05-08 Thread Paolo Bonzini

 On 7 May 2013 15:16, Paolo Bonzini pbonz...@redhat.com wrote:
  A new address space has an empty FlatView.  In order to create it, we
  must (a) call memory_region_transaction_commit after the address space is
  inserted into the list; (b) force memory_region_transaction_commit to
  do something.
 
  This bug was latent so far because all address spaces started empty,
  including
  the PCI address space where the bus master region is initially disabled.
  However, the target address space of an IOMMU is usually rooted at
  get_system_memory(), which might not be empty at the time the IOMMU is
  created.
 
 The code looks ok but I don't entirely understand the
 commit message. Surely we're definitely already creating
 the FlatView -- that's what the g_new and flatview_init do.
 What we're not doing is calling notifiers for the initial
 contents of the address space, right? (and thus in turn
 we're not setting up the data structures those notifiers
 control, but as far as I can see from the code that's not
 the FlatView.)

Right, it should be s/create/populate/g.

Paolo



[Qemu-devel] [PATCH v5 1/4] Add i.MX FEC Ethernet emulator

2013-05-08 Thread Jean-Christophe DUBOIS
This is based on the mcf_fec.c FEC implementation for ColdFire.

* a generic phy was added (borrowed from lan9118).
* The buffer management is also modified as buffers are
  slightly different between coldfire and i.MX.

Signed-off-by: Jean-Christophe DUBOIS j...@tribudubois.net
---

Changes since V1:
* none 
  
Changes since v2:
* use QOM cast
* reworked debug printf
* use CamelCase for state type   
* warn with qemu_log_mask(LOG_GUEST_ERROR) or qemu_log_mask(LOG_UNIMP)
* move to dma_memory_read/write API
* rework interrupt handling  
* use qemu_flush_queued_packets() in rx_enable()
 
Changes since v3:
* use realise for device initialization
* More QOM cast
* reworked debug printf some more
* standardise GPL header
* use CamelCase for buffer descriptor type

Changes since v4:
* none

 default-configs/arm-softmmu.mak |   1 +
 hw/net/Makefile.objs|   1 +
 hw/net/imx_fec.c| 818 
 include/hw/arm/imx.h|  10 +-
 4 files changed, 824 insertions(+), 6 deletions(-)
 create mode 100644 hw/net/imx_fec.c

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 27cbe3d..b3a0207 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -28,6 +28,7 @@ CONFIG_SSI_SD=y
 CONFIG_SSI_M25P80=y
 CONFIG_LAN9118=y
 CONFIG_SMC91C111=y
+CONFIG_IMX_FEC=y
 CONFIG_DS1338=y
 CONFIG_PFLASH_CFI01=y
 CONFIG_PFLASH_CFI02=y
diff --git a/hw/net/Makefile.objs b/hw/net/Makefile.objs
index 951cca3..5c84727 100644
--- a/hw/net/Makefile.objs
+++ b/hw/net/Makefile.objs
@@ -18,6 +18,7 @@ common-obj-$(CONFIG_OPENCORES_ETH) += opencores_eth.o
 common-obj-$(CONFIG_XGMAC) += xgmac.o
 common-obj-$(CONFIG_MIPSNET) += mipsnet.o
 common-obj-$(CONFIG_XILINX_AXI) += xilinx_axienet.o
+common-obj-$(CONFIG_IMX_FEC) += imx_fec.o
 
 common-obj-$(CONFIG_CADENCE) += cadence_gem.o
 common-obj-$(CONFIG_STELLARIS_ENET) += stellaris_enet.o
diff --git a/hw/net/imx_fec.c b/hw/net/imx_fec.c
new file mode 100644
index 000..e25d6cd
--- /dev/null
+++ b/hw/net/imx_fec.c
@@ -0,0 +1,818 @@
+/*
+ * i.MX Fast Ethernet Controller emulation.
+ *
+ * Copyright (c) 2013 Jean-Christophe Dubois.
+ *
+ * Based on Coldfire Fast Ethernet Controller emulation.
+ *
+ * Copyright (c) 2007 CodeSourcery.
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but WITHOUT
+ *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ *  FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ *  for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, see http://www.gnu.org/licenses/.
+ */
+
+#include qemu/bitops.h
+
+#include sysemu/dma.h
+
+#include net/net.h
+
+#include hw/sysbus.h
+
+/* For crc32 */
+#include zlib.h
+
+#include hw/arm/imx.h
+
+#ifndef IMX_FEC_DEBUG
+#define IMX_FEC_DEBUG  0
+#endif
+
+#ifndef IMX_PHY_DEBUG
+#define IMX_PHY_DEBUG  0
+#endif
+
+#define TYPE_IMX_FEC  imx.fec
+
+#if IMX_FEC_DEBUG
+#define FEC_PRINTF(fmt, ...) \
+do { fprintf(stderr, %s[%s]:  fmt , TYPE_IMX_FEC, __func__, \
+ ## __VA_ARGS__); \
+} while (0)
+#else
+#define FEC_PRINTF(fmt, ...) do {} while (0)
+#endif
+
+#if IMX_PHY_DEBUG
+#define PHY_PRINTF(fmt, ...) \
+do { fprintf(stderr, %s.phy[%s]:  fmt , TYPE_IMX_FEC, __func__, \
+ ## __VA_ARGS__); \
+} while (0)
+#else
+#define PHY_PRINTF(fmt, ...) do {} while (0)
+#endif
+
+#define IMX_FEC(obj)  \
+OBJECT_CHECK(IMXFECState, (obj), TYPE_IMX_FEC)
+
+#define FEC_MAX_FRAME_SIZE 2032
+
+typedef struct {
+SysBusDevice parent_obj;
+
+NICState *nic;
+NICConf conf;
+qemu_irq irq;
+MemoryRegion iomem;
+
+uint32_t irq_state;
+uint32_t eir;
+uint32_t eimr;
+uint32_t rx_enabled;
+uint32_t rx_descriptor;
+uint32_t tx_descriptor;
+uint32_t ecr;
+uint32_t mmfr;
+uint32_t mscr;
+uint32_t mibc;
+uint32_t rcr;
+uint32_t tcr;
+uint32_t tfwr;
+uint32_t frsr;
+uint32_t erdsr;
+uint32_t etdsr;
+uint32_t emrbr;
+uint32_t miigsk_cfgr;
+uint32_t miigsk_enr;
+
+uint32_t phy_status;
+uint32_t phy_control;
+uint32_t phy_advertise;
+uint32_t phy_int;
+uint32_t phy_int_mask;
+} IMXFECState;
+
+static const VMStateDescription vmstate_imx_fec = {
+.name = TYPE_IMX_FEC,
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32(irq_state, IMXFECState),
+VMSTATE_UINT32(eir, IMXFECState),
+VMSTATE_UINT32(eimr, IMXFECState),
+  

[Qemu-devel] [PATCH V14 0/6] replace QEMUOptionParameter with QemuOpts parser

2013-05-08 Thread Dong Xu Wang
These patches will replace QEMUOptionParameter with QemuOpts. Change logs
please go to each patch's commit message.

Dong Xu Wang (6):
  add def_value_str in QemuOptDesc struct and rewrite qemu_opts_print
  avoid duplication of default value in QemuOpts
  Create four QemuOptsList related functions
  Create some QemuOpts functons
  Use QemuOpts support in block layer
  remove QEMUOptionParameter related functions and struct

 block.c   |  98 
 block/cow.c   |  52 ++---
 block/gluster.c   |  37 ++-
 block/iscsi.c |  31 ++-
 block/qcow.c  |  67 +++---
 block/qcow2.c | 199 
 block/qed.c   | 108 +
 block/qed.h   |   2 +-
 block/raw-posix.c |  59 +++--
 block/raw-win32.c |  31 +--
 block/raw.c   |  30 +--
 block/rbd.c   |  62 +++--
 block/sheepdog.c  |  81 ---
 block/ssh.c   |  29 ++-
 block/vdi.c   |  70 +++---
 block/vmdk.c  | 128 ++-
 block/vpc.c   |  65 +++---
 block/vvfat.c |  11 +-
 include/block/block.h |   5 +-
 include/block/block_int.h |   6 +-
 include/qemu/option.h |  49 ++--
 qemu-img.c|  65 +++---
 util/qemu-option.c| 571 +-
 23 files changed, 903 insertions(+), 953 deletions(-)

-- 
1.7.11.7




[Qemu-devel] [PATCH V14 2/6] avoid duplication of default value in QemuOpts

2013-05-08 Thread Dong Xu Wang
This patch will move the default value entirely to QemuOptDesc.

When getting the value of an option that hasn't been set, and
QemuOptDesc has a default value, return that.  Else, behave as
before.

Example: qemu_opt_get_number(opts, foo, 42)

   If foo has been set in opts, return its value.

   Else, if opt's QemuOptDesc has a default value for foo, return
   that.

   Else, return 42.

   Note that the last argument is useless when QemuOptDesc has a
   default value.  Ugly.  If it bothers us, we could assert.

Example: qemu_opt_get(opts, bar)

   If bar has been set in opts, return its value.

   Else, if opt's QemuOptDesc has a default value for bar, return
   that.

   Else, return NULL.

Signed-off-by: Dong Xu Wang wdon...@linux.vnet.ibm.com


---
v13-v14:
1) change code style.
2) assert errors.
 util/qemu-option.c | 66 --
 1 file changed, 49 insertions(+), 17 deletions(-)

diff --git a/util/qemu-option.c b/util/qemu-option.c
index 84d8c8b..bd2acdc 100644
--- a/util/qemu-option.c
+++ b/util/qemu-option.c
@@ -525,9 +525,31 @@ static QemuOpt *qemu_opt_find(QemuOpts *opts, const char 
*name)
 return NULL;
 }
 
+static const QemuOptDesc *find_desc_by_name(const QemuOptDesc *desc,
+const char *name)
+{
+int i;
+
+for (i = 0; desc[i].name != NULL; i++) {
+if (strcmp(desc[i].name, name) == 0) {
+return desc[i];
+}
+}
+
+return NULL;
+}
+
 const char *qemu_opt_get(QemuOpts *opts, const char *name)
 {
 QemuOpt *opt = qemu_opt_find(opts, name);
+const QemuOptDesc *desc;
+
+if (!opt) {
+desc = find_desc_by_name(opts-list-desc, name);
+if (desc  desc-def_value_str) {
+return desc-def_value_str;
+}
+}
 return opt ? opt-str : NULL;
 }
 
@@ -546,9 +568,17 @@ bool qemu_opt_has_help_opt(QemuOpts *opts)
 bool qemu_opt_get_bool(QemuOpts *opts, const char *name, bool defval)
 {
 QemuOpt *opt = qemu_opt_find(opts, name);
+const QemuOptDesc *desc;
+Error *local_err = NULL;
 
-if (opt == NULL)
+if (opt == NULL) {
+desc = find_desc_by_name(opts-list-desc, name);
+if (desc  desc-def_value_str) {
+parse_option_bool(name, desc-def_value_str, defval, local_err);
+assert(!local_err);
+}
 return defval;
+}
 assert(opt-desc  opt-desc-type == QEMU_OPT_BOOL);
 return opt-value.boolean;
 }
@@ -556,9 +586,17 @@ bool qemu_opt_get_bool(QemuOpts *opts, const char *name, 
bool defval)
 uint64_t qemu_opt_get_number(QemuOpts *opts, const char *name, uint64_t defval)
 {
 QemuOpt *opt = qemu_opt_find(opts, name);
+const QemuOptDesc *desc;
+Error *local_err = NULL;
 
-if (opt == NULL)
+if (opt == NULL) {
+desc = find_desc_by_name(opts-list-desc, name);
+if (desc  desc-def_value_str) {
+parse_option_number(name, desc-def_value_str, defval, 
local_err);
+assert(!local_err);
+}
 return defval;
+}
 assert(opt-desc  opt-desc-type == QEMU_OPT_NUMBER);
 return opt-value.uint;
 }
@@ -566,9 +604,17 @@ uint64_t qemu_opt_get_number(QemuOpts *opts, const char 
*name, uint64_t defval)
 uint64_t qemu_opt_get_size(QemuOpts *opts, const char *name, uint64_t defval)
 {
 QemuOpt *opt = qemu_opt_find(opts, name);
+const QemuOptDesc *desc;
+Error *local_err = NULL;
 
-if (opt == NULL)
+if (opt == NULL) {
+desc = find_desc_by_name(opts-list-desc, name);
+if (desc  desc-def_value_str) {
+parse_option_size(name, desc-def_value_str, defval, local_err);
+assert(!local_err);
+}
 return defval;
+}
 assert(opt-desc  opt-desc-type == QEMU_OPT_SIZE);
 return opt-value.uint;
 }
@@ -609,20 +655,6 @@ static bool opts_accepts_any(const QemuOpts *opts)
 return opts-list-desc[0].name == NULL;
 }
 
-static const QemuOptDesc *find_desc_by_name(const QemuOptDesc *desc,
-const char *name)
-{
-int i;
-
-for (i = 0; desc[i].name != NULL; i++) {
-if (strcmp(desc[i].name, name) == 0) {
-return desc[i];
-}
-}
-
-return NULL;
-}
-
 static void opt_set(QemuOpts *opts, const char *name, const char *value,
 bool prepend, Error **errp)
 {
-- 
1.7.11.7




[Qemu-devel] [PATCH V14 4/6] Create some QemuOpts functons

2013-05-08 Thread Dong Xu Wang
These functions will be used in next commit.

qemu_opt_get_(*)_del functions are used to make sure we
have the same behaviors as before: in block layer, after
parsing a parameter value, parameter list will delete it
to avoid parsing it twice.

Signed-off-by: Dong Xu Wang wdon...@linux.vnet.ibm.com


---
v13-v14:
1) rewrite commit message.
2) use def_value_str in qemu_opt_get_FOO_del() and qemu_opt_get_del().
3) delete redundant qemu_opt_del(opt).
 include/qemu/option.h |  11 -
 util/qemu-option.c| 116 +++---
 2 files changed, 119 insertions(+), 8 deletions(-)

diff --git a/include/qemu/option.h b/include/qemu/option.h
index c7a5c14..d63e447 100644
--- a/include/qemu/option.h
+++ b/include/qemu/option.h
@@ -108,6 +108,7 @@ struct QemuOptsList {
 };
 
 const char *qemu_opt_get(QemuOpts *opts, const char *name);
+const char *qemu_opt_get_del(QemuOpts *opts, const char *name);
 /**
  * qemu_opt_has_help_opt:
  * @opts: options to search for a help request
@@ -121,13 +122,18 @@ const char *qemu_opt_get(QemuOpts *opts, const char 
*name);
  */
 bool qemu_opt_has_help_opt(QemuOpts *opts);
 bool qemu_opt_get_bool(QemuOpts *opts, const char *name, bool defval);
+bool qemu_opt_get_bool_del(QemuOpts *opts, const char *name, bool defval);
 uint64_t qemu_opt_get_number(QemuOpts *opts, const char *name, uint64_t 
defval);
 uint64_t qemu_opt_get_size(QemuOpts *opts, const char *name, uint64_t defval);
+uint64_t qemu_opt_get_size_del(QemuOpts *opts, const char *name,
+   uint64_t defval);
 int qemu_opt_set(QemuOpts *opts, const char *name, const char *value);
+int qemu_opt_replace_set(QemuOpts *opts, const char *name, const char *value);
 void qemu_opt_set_err(QemuOpts *opts, const char *name, const char *value,
   Error **errp);
 int qemu_opt_set_bool(QemuOpts *opts, const char *name, bool val);
 int qemu_opt_set_number(QemuOpts *opts, const char *name, int64_t val);
+int qemu_opt_replace_set_number(QemuOpts *opts, const char *name, int64_t val);
 typedef int (*qemu_opt_loopfunc)(const char *name, const char *value, void 
*opaque);
 int qemu_opt_foreach(QemuOpts *opts, qemu_opt_loopfunc func, void *opaque,
  int abort_on_failure);
@@ -144,7 +150,10 @@ const char *qemu_opts_id(QemuOpts *opts);
 void qemu_opts_del(QemuOpts *opts);
 void qemu_opts_validate(QemuOpts *opts, const QemuOptDesc *desc, Error **errp);
 int qemu_opts_do_parse(QemuOpts *opts, const char *params, const char 
*firstname);
-QemuOpts *qemu_opts_parse(QemuOptsList *list, const char *params, int 
permit_abbrev);
+int qemu_opts_do_parse_replace(QemuOpts *opts, const char *params,
+   const char *firstname);
+QemuOpts *qemu_opts_parse(QemuOptsList *list, const char *params,
+  int permit_abbrev);
 void qemu_opts_set_defaults(QemuOptsList *list, const char *params,
 int permit_abbrev);
 QemuOpts *qemu_opts_from_qdict(QemuOptsList *list, const QDict *qdict,
diff --git a/util/qemu-option.c b/util/qemu-option.c
index e3f482f..3251adc 100644
--- a/util/qemu-option.c
+++ b/util/qemu-option.c
@@ -33,6 +33,8 @@
 #include qapi/qmp/qerror.h
 #include qemu/option_int.h
 
+static void qemu_opt_del(QemuOpt *opt);
+
 /*
  * Extracts the name of an option from the parameter string (p points at the
  * first byte of the option name)
@@ -553,6 +555,24 @@ const char *qemu_opt_get(QemuOpts *opts, const char *name)
 return opt ? opt-str : NULL;
 }
 
+const char *qemu_opt_get_del(QemuOpts *opts, const char *name)
+{
+QemuOpt *opt = qemu_opt_find(opts, name);
+const QemuOptDesc *desc;
+const char *str = NULL;
+
+if (!opt) {
+desc = find_desc_by_name(opts-list-desc, name);
+if (desc  desc-def_value_str) {
+str = g_strdup(desc-def_value_str);
+}
+} else {
+str = g_strdup(opt-str);
+qemu_opt_del(opt);
+}
+return str;
+}
+
 bool qemu_opt_has_help_opt(QemuOpts *opts)
 {
 QemuOpt *opt;
@@ -583,6 +603,27 @@ bool qemu_opt_get_bool(QemuOpts *opts, const char *name, 
bool defval)
 return opt-value.boolean;
 }
 
+bool qemu_opt_get_bool_del(QemuOpts *opts, const char *name, bool defval)
+{
+QemuOpt *opt = qemu_opt_find(opts, name);
+const QemuOptDesc *desc;
+Error *local_err = NULL;
+bool ret = defval;
+
+if (opt == NULL) {
+desc = find_desc_by_name(opts-list-desc, name);
+if (desc  desc-def_value_str) {
+parse_option_bool(name, desc-def_value_str, ret, local_err);
+assert(!local_err);
+}
+return ret;
+}
+assert(opt-desc  opt-desc-type == QEMU_OPT_BOOL);
+ret = opt-value.boolean;
+qemu_opt_del(opt);
+return ret;
+}
+
 uint64_t qemu_opt_get_number(QemuOpts *opts, const char *name, uint64_t defval)
 {
 QemuOpt *opt = qemu_opt_find(opts, name);
@@ -619,6 +660,28 @@ uint64_t qemu_opt_get_size(QemuOpts *opts, 

[Qemu-devel] [PATCH V14 1/6] add def_value_str in QemuOptDesc struct and rewrite qemu_opts_print

2013-05-08 Thread Dong Xu Wang
qemu_opts_print has no user now, so can re-write the function safely.

qemu_opts_print will be used while using qemu-img create, it will
produce the same output as previous code.

The behavior of this function has changed:

1. Print every possible option, whether a value has been set or not.
2. Option descriptors may provide a default value.
3. Print to stdout instead of stderr.

Previously the behavior was to print every option that has been set.
Options that have not been set would be skipped.

Signed-off-by: Dong Xu Wang wdon...@linux.vnet.ibm.com
---
v13-v14:
1) fix memory leak.
2) make opt_set do not accpet null value argument.

v12-v13
1) re-write commit message.

v11-v12
1) make def_value_str become the real default value string in opt_set
function.

v10-v11:
1) print all values that have actually been assigned while accept-any
cases.

v7-v8:
1) print elements = accept any params while opts_accepts_any() ==
true.
2) since def_print_str is the default value if an option isn't set,
so rename it to def_value_str.

 include/qemu/option.h |  3 ++-
 util/qemu-option.c| 32 ++--
 2 files changed, 28 insertions(+), 7 deletions(-)

diff --git a/include/qemu/option.h b/include/qemu/option.h
index bdb6d21..b928ab0 100644
--- a/include/qemu/option.h
+++ b/include/qemu/option.h
@@ -96,6 +96,7 @@ typedef struct QemuOptDesc {
 const char *name;
 enum QemuOptType type;
 const char *help;
+const char *def_value_str;
 } QemuOptDesc;
 
 struct QemuOptsList {
@@ -152,7 +153,7 @@ QDict *qemu_opts_to_qdict(QemuOpts *opts, QDict *qdict);
 void qemu_opts_absorb_qdict(QemuOpts *opts, QDict *qdict, Error **errp);
 
 typedef int (*qemu_opts_loopfunc)(QemuOpts *opts, void *opaque);
-int qemu_opts_print(QemuOpts *opts, void *dummy);
+int qemu_opts_print(QemuOpts *opts);
 int qemu_opts_foreach(QemuOptsList *list, qemu_opts_loopfunc func, void 
*opaque,
   int abort_on_failure);
 
diff --git a/util/qemu-option.c b/util/qemu-option.c
index 8b74bf1..84d8c8b 100644
--- a/util/qemu-option.c
+++ b/util/qemu-option.c
@@ -860,16 +860,36 @@ void qemu_opts_del(QemuOpts *opts)
 g_free(opts);
 }
 
-int qemu_opts_print(QemuOpts *opts, void *dummy)
+int qemu_opts_print(QemuOpts *opts)
 {
 QemuOpt *opt;
+QemuOptDesc *desc = opts-list-desc;
 
-fprintf(stderr, %s: %s:, opts-list-name,
-opts-id ? opts-id : noid);
-QTAILQ_FOREACH(opt, opts-head, next) {
-fprintf(stderr,  %s=\%s\, opt-name, opt-str);
+if (desc[0].name == NULL) {
+QTAILQ_FOREACH(opt, opts-head, next) {
+printf(%s=\%s\ , opt-name, opt-str);
+}
+return 0;
+}
+for (; desc  desc-name; desc++) {
+const char *value = desc-def_value_str;
+QemuOpt *opt;
+
+opt = qemu_opt_find(opts, desc-name);
+if (opt) {
+value = opt-str;
+}
+
+if (!value) {
+continue;
+}
+
+if (desc-type == QEMU_OPT_STRING) {
+printf(%s='%s' , desc-name, value);
+} else {
+printf(%s=%s , desc-name, value);
+}
 }
-fprintf(stderr, \n);
 return 0;
 }
 
-- 
1.7.11.7




[Qemu-devel] [PATCH V14 3/6] Create four QemuOptsList related functions

2013-05-08 Thread Dong Xu Wang
This patch will create 4 functions, count_opts_list, qemu_opts_append,
qemu_opts_free and qemu_opts_print_help, they will be used in following
commits.


Signed-off-by: Dong Xu Wang wdon...@linux.vnet.ibm.com
---
v12-v13:
1) simply assert that neither argument has merge_lists set.
2) drop superfluous paranthesesis around p == first.

v11-v12:
1) renmae functions.
2) fix loop styles and code styles.
3) qemu_opts_apend will not return NULL now.
4) merge_lists value is from arguments in qemu_opts_append.

v6-v7:
1) Fix typo.

v5-v6:
1) allocate enough space in append_opts_list function.

 include/qemu/option.h |  3 ++
 util/qemu-option.c| 82 +++
 2 files changed, 85 insertions(+)

diff --git a/include/qemu/option.h b/include/qemu/option.h
index b928ab0..c7a5c14 100644
--- a/include/qemu/option.h
+++ b/include/qemu/option.h
@@ -157,4 +157,7 @@ int qemu_opts_print(QemuOpts *opts);
 int qemu_opts_foreach(QemuOptsList *list, qemu_opts_loopfunc func, void 
*opaque,
   int abort_on_failure);
 
+QemuOptsList *qemu_opts_append(QemuOptsList *first, QemuOptsList *second);
+void qemu_opts_free(QemuOptsList *list);
+void qemu_opts_print_help(QemuOptsList *list);
 #endif
diff --git a/util/qemu-option.c b/util/qemu-option.c
index bd2acdc..e3f482f 100644
--- a/util/qemu-option.c
+++ b/util/qemu-option.c
@@ -1218,3 +1218,85 @@ int qemu_opts_foreach(QemuOptsList *list, 
qemu_opts_loopfunc func, void *opaque,
 loc_pop(loc);
 return rc;
 }
+
+static size_t count_opts_list(QemuOptsList *list)
+{
+size_t i = 0;
+
+for (i = 0; list  list-desc[i].name; i++) {
+;
+}
+
+return i;
+}
+
+/* Create a new QemuOptsList and make its desc to the merge of first
+ * and second. It will allocate space for one new QemuOptsList plus
+ * enough space for QemuOptDesc in first and second QemuOptsList.
+ * First argument's QemuOptDesc members take precedence over second's.
+ * The result's name and implied_opt_name are not copied from them.
+ * Both merge_lists should not be set. Both list can be NULL.
+ */
+QemuOptsList *qemu_opts_append(QemuOptsList *first,
+   QemuOptsList *second)
+{
+size_t num_first_opts, num_second_opts;
+QemuOptsList *dest = NULL;
+int i = 0;
+int index = 0;
+QemuOptsList *p = first;
+
+num_first_opts = count_opts_list(first);
+num_second_opts = count_opts_list(second);
+
+dest = g_malloc0(sizeof(QemuOptsList)
++ (num_first_opts + num_second_opts + 1) * sizeof(QemuOptDesc));
+
+dest-name = append_opts_list;
+dest-implied_opt_name = NULL;
+assert((!first || !first-merge_lists)
+ (!second || !second-merge_lists));
+QTAILQ_INIT(dest-head);
+
+for (i = 0; p  p-desc[i].name; i++) {
+if (!find_desc_by_name(dest-desc, p-desc[i].name)) {
+dest-desc[index].name = g_strdup(p-desc[i].name);
+dest-desc[index].help = g_strdup(p-desc[i].help);
+dest-desc[index].type = p-desc[i].type;
+dest-desc[index].def_value_str =
+g_strdup(p-desc[i].def_value_str);
+index++;
+}
+if (p == first  p  !p-desc[i].name) {
+p = second;
+i = 0;
+}
+}
+dest-desc[index].name = NULL;
+return dest;
+}
+
+/* free a QemuOptsList, can accept NULL as arguments */
+void qemu_opts_free(QemuOptsList *list)
+{
+int i = 0;
+
+for (i = 0; list  list-desc[i].name; i++) {
+g_free((char *)list-desc[i].name);
+g_free((char *)list-desc[i].help);
+g_free((char *)list-desc[i].def_value_str);
+}
+
+g_free(list);
+}
+
+void qemu_opts_print_help(QemuOptsList *list)
+{
+int i = 0;
+printf(Supported options:\n);
+for (i = 0; list  list-desc[i].name; i++) {
+printf(%-16s %s\n, list-desc[i].name,
+list-desc[i].help ?
+list-desc[i].help : No description available);
+}
+}
-- 
1.7.11.7




Re: [Qemu-devel] [PATCH 1/4] kvm-all: add kvm_ioctl, kvm_vm_ioctl, kvm_vcpu_ioctl tracepoints

2013-05-08 Thread Stefan Hajnoczi
On Fri, May 03, 2013 at 02:12:14PM +0200, Andreas Färber wrote:
  +# kvm-all.c
  +kvm_ioctl(int type, void *arg) type %d, arg %p
  +kvm_vm_ioctl(int type, void *arg) type %d, arg %p
  +kvm_vcpu_ioctl(int cpu_index, int type, void *arg) cpu_index %d, type %d, 
  arg %p
 
 Sorry that I'm just seeing this patch now (wasn't CC'ed), but I wonder
 whether cpu_index is the best thing to trace here? Can we still change
 trace event API or would we have to nack/change now?

Trace events are not stable.  We can change them.

STefan



[Qemu-devel] [PATCH v5 0/4] Add i.MX25 support through the 3DS evaluation board

2013-05-08 Thread Jean-Christophe DUBOIS
This series of patches add the support for the i.MX25 processor through the
Freescale 3DS evaluation board.

For now a limited set of devices are supported.
* GPT timers (from i.MX31)
* EPIT timers (from i.MX31)
* Serial ports (from i.MX31)
* Ethernet FEC port
* I2C controller

It also adds qtest support for the I2C controller.

Jean-Christophe DUBOIS (4):
  Add i.MX FEC Ethernet emulator
  Add i.MX I2C controller emulator
  Add i.MX25 3DS evaluation board support.
  Add qtest support for i.MX I2C device emulation.

 default-configs/arm-softmmu.mak |   3 +
 hw/arm/Makefile.objs|   1 +
 hw/arm/imx25_3ds.c  | 250 
 hw/i2c/Makefile.objs|   1 +
 hw/i2c/imx_i2c.c| 357 ++
 hw/i2c/imx_i2c_regs.h   |  63 
 hw/net/Makefile.objs|   1 +
 hw/net/imx_fec.c| 818 
 include/hw/arm/imx.h|  10 +-
 tests/Makefile  |   3 +
 tests/ds1338-test.c |  75 
 tests/libqos/i2c-imx.c  | 209 ++
 tests/libqos/i2c.h  |   3 +
 13 files changed, 1788 insertions(+), 6 deletions(-)
 create mode 100644 hw/arm/imx25_3ds.c
 create mode 100644 hw/i2c/imx_i2c.c
 create mode 100644 hw/i2c/imx_i2c_regs.h
 create mode 100644 hw/net/imx_fec.c
 create mode 100644 tests/ds1338-test.c
 create mode 100644 tests/libqos/i2c-imx.c

-- 
1.8.1.2




[Qemu-devel] [PATCH V14 6/6] remove QEMUOptionParameter related functions and struct

2013-05-08 Thread Dong Xu Wang

Signed-off-by: Dong Xu Wang wdon...@linux.vnet.ibm.com
---
 include/qemu/option.h |  32 --
 util/qemu-option.c| 285 --
 2 files changed, 317 deletions(-)

diff --git a/include/qemu/option.h b/include/qemu/option.h
index d63e447..51814cf 100644
--- a/include/qemu/option.h
+++ b/include/qemu/option.h
@@ -38,17 +38,6 @@ enum QEMUOptionParType {
 OPT_STRING,
 };
 
-typedef struct QEMUOptionParameter {
-const char *name;
-enum QEMUOptionParType type;
-union {
-uint64_t n;
-char* s;
-} value;
-const char *help;
-} QEMUOptionParameter;
-
-
 const char *get_opt_name(char *buf, int buf_size, const char *p, char delim);
 const char *get_opt_value(char *buf, int buf_size, const char *p);
 int get_next_param_value(char *buf, int buf_size,
@@ -58,27 +47,6 @@ int get_param_value(char *buf, int buf_size,
 int check_params(char *buf, int buf_size,
  const char * const *params, const char *str);
 
-
-/*
- * The following functions take a parameter list as input. This is a pointer to
- * the first element of a QEMUOptionParameter array which is terminated by an
- * entry with entry-name == NULL.
- */
-
-QEMUOptionParameter *get_option_parameter(QEMUOptionParameter *list,
-const char *name);
-int set_option_parameter(QEMUOptionParameter *list, const char *name,
-const char *value);
-int set_option_parameter_int(QEMUOptionParameter *list, const char *name,
-uint64_t value);
-QEMUOptionParameter *append_option_parameters(QEMUOptionParameter *dest,
-QEMUOptionParameter *list);
-QEMUOptionParameter *parse_option_parameters(const char *param,
-QEMUOptionParameter *list, QEMUOptionParameter *dest);
-void free_option_parameters(QEMUOptionParameter *list);
-void print_option_parameters(QEMUOptionParameter *list);
-void print_option_help(QEMUOptionParameter *list);
-
 /* -- */
 
 typedef struct QemuOpt QemuOpt;
diff --git a/util/qemu-option.c b/util/qemu-option.c
index 3251adc..e1b2a3b 100644
--- a/util/qemu-option.c
+++ b/util/qemu-option.c
@@ -155,22 +155,6 @@ int check_params(char *buf, int buf_size,
 return 0;
 }
 
-/*
- * Searches an option list for an option with the given name
- */
-QEMUOptionParameter *get_option_parameter(QEMUOptionParameter *list,
-const char *name)
-{
-while (list  list-name) {
-if (!strcmp(list-name, name)) {
-return list;
-}
-list++;
-}
-
-return NULL;
-}
-
 static void parse_option_bool(const char *name, const char *value, bool *ret,
   Error **errp)
 {
@@ -244,275 +228,6 @@ static void parse_option_size(const char *name, const 
char *value,
 }
 }
 
-/*
- * Sets the value of a parameter in a given option list. The parsing of the
- * value depends on the type of option:
- *
- * OPT_FLAG (uses value.n):
- *  If no value is given, the flag is set to 1.
- *  Otherwise the value must be on (set to 1) or off (set to 0)
- *
- * OPT_STRING (uses value.s):
- *  value is strdup()ed and assigned as option value
- *
- * OPT_SIZE (uses value.n):
- *  The value is converted to an integer. Suffixes for kilobytes etc. are
- *  allowed (powers of 1024).
- *
- * Returns 0 on succes, -1 in error cases
- */
-int set_option_parameter(QEMUOptionParameter *list, const char *name,
-const char *value)
-{
-bool flag;
-Error *local_err = NULL;
-
-// Find a matching parameter
-list = get_option_parameter(list, name);
-if (list == NULL) {
-fprintf(stderr, Unknown option '%s'\n, name);
-return -1;
-}
-
-// Process parameter
-switch (list-type) {
-case OPT_FLAG:
-parse_option_bool(name, value, flag, local_err);
-if (!error_is_set(local_err)) {
-list-value.n = flag;
-}
-break;
-
-case OPT_STRING:
-if (value != NULL) {
-list-value.s = g_strdup(value);
-} else {
-fprintf(stderr, Option '%s' needs a parameter\n, name);
-return -1;
-}
-break;
-
-case OPT_SIZE:
-parse_option_size(name, value, list-value.n, local_err);
-break;
-
-default:
-fprintf(stderr, Bug: Option '%s' has an unknown type\n, name);
-return -1;
-}
-
-if (error_is_set(local_err)) {
-qerror_report_err(local_err);
-error_free(local_err);
-return -1;
-}
-
-return 0;
-}
-
-/*
- * Sets the given parameter to an integer instead of a string.
- * This function cannot be used to set string options.
- *
- * Returns 0 on success, -1 in error cases
- */
-int set_option_parameter_int(QEMUOptionParameter *list, const char *name,
-uint64_t value)
-{
-// Find a matching parameter
-list = get_option_parameter(list, name);
-if (list == NULL) {
-fprintf(stderr, Unknown option '%s'\n, name);
-return -1;
-}
-
- 

Re: [Qemu-devel] [PATCH 9/9] Make monitor command 'dump-guest-memory' dump in kdump-compressed format

2013-05-08 Thread qiaonuohan
 -Original Message-
 From: Eric Blake [mailto:ebl...@redhat.com]
 Sent: Wednesday, May 08, 2013 1:13 AM
 To: Qiao Nuohan
 Cc: qemu-devel@nongnu.org; Zhang Xiaohe
 Subject: Re: [Qemu-devel] [PATCH 9/9] Make monitor command 'dump-guest-memory'
 dump in kdump-compressed format
 
 
  +.params = [-p] filename [flags] [begin] [length],
   .help   = dump guest memory to file
  +  \n\t\t\t flags: the type of compression
 
 That documentation does nothing for me.  What types are valid?
 
  +++ b/qapi-schema.json
  @@ -2410,6 +2410,8 @@
   #2. fd: the protocol starts with fd:, and the following
 string
   #   is the fd's name.
   #
  +# @flags: #optional if specified, the format of dump file.
  +#
 
 Missing a (since 1.6) tag to declare that it was added after the fact.
  We probably also ought to solve the introspection issue before adding
 this feature, so that QMP clients like libvirt know when this optional
 parameter is available for use.

Got it.

 
   # @begin: #optional if specified, the starting physical address.
   #
   # @length: #optional if specified, the memory size, in bytes. If you don't
  @@ -2421,8 +2423,8 @@
   # Since: 1.2
   ##
   { 'command': 'dump-guest-memory',
  -  'data': { 'paging': 'bool', 'protocol': 'str', '*begin': 'int',
  -'*length': 'int' } }
  +  'data': { 'paging': 'bool', 'protocol': 'str', '*flags': 'int',
  +'*begin': 'int', '*length': 'int' } }
 
 EW - this is a LOUSY interface. Don't make '*flags' an 'int', and
 for that matter, don't name it 'flags' (that implies that we can
 bitwise-or multiple compressions together, but it really doesn't make
 sense to do both lzo and snappy at the same time - compression really
 only makes sense as a single format at a time).  Name it for what it
 represents (compression type), and provide an enum that lists the valid
 types.  Something like:
 
 { 'enum': 'DumpGuestMemoryFormat',
   'data': [ 'uncompressed', 'zlib', 'lzo', 'snappy' ] }
 
 { 'command': 'dump-guest-memory',
   'data': { '*format': 'DumpGuestMemoryFormat', ... }}

Thanks for your suggestion. I will fix it like:

{ 'enum': 'DumpCompressionFormat',
  'data': [ 'zlib', 'lzo', 'snappy' ] }

For zlib is treated as the default compression format, and
'uncompressed' won't be an option.

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






Re: [Qemu-devel] Makefile: Dependency problem

2013-05-08 Thread Paolo Bonzini

 I just had a failing build like this (make -j3, so these are running in
 parallel):
 
 lt LINK libcacard.la
 ARlibqemuutil.a
 CCstubs/mon-printf.o
 CCstubs/mon-print-filename.o
 ar: stubs/mon-printf.o: No such file or directory
 make: *** [libcacard.la] Fehler 1
 make: *** Warte auf noch nicht beendete Prozesse...
 
 Restarting make obviously fixed the problem, but I thought I'd mention it
 here so that the dependencies can be fixed.

Please try to reproduce it with make V=1.  Did you have
an lt CC  stubs/mon-printf.lo before?

What version of Make is this?

Paolo



Re: [Qemu-devel] Makefile: Dependency problem

2013-05-08 Thread Dongsheng Song
On Wed, May 8, 2013 at 4:39 PM, Kevin Wolf kw...@redhat.com wrote:
 Hi,

 I just had a failing build like this (make -j3, so these are running in
 parallel):

 lt LINK libcacard.la
 ARlibqemuutil.a
 CCstubs/mon-printf.o
 CCstubs/mon-print-filename.o
 ar: stubs/mon-printf.o: No such file or directory
 make: *** [libcacard.la] Fehler 1
 make: *** Warte auf noch nicht beendete Prozesse...

 Restarting make obviously fixed the problem, but I thought I'd mention it
 here so that the dependencies can be fixed.

 Kevin


I use 'make -j8' on qemu 1.4.1 and 1.5.0-rc, both looks fine:

--build=x86_64-unknown-linux-gnu --host=i686-w64-mingw32
--build=x86_64-unknown-linux-gnu --host=x86_64-w64-mingw32

Regards,
Dongsheng



Re: [Qemu-devel] Makefile: Dependency problem

2013-05-08 Thread Kevin Wolf
Am 08.05.2013 um 10:44 hat Paolo Bonzini geschrieben:
 
  I just had a failing build like this (make -j3, so these are running in
  parallel):
  
  lt LINK libcacard.la
  ARlibqemuutil.a
  CCstubs/mon-printf.o
  CCstubs/mon-print-filename.o
  ar: stubs/mon-printf.o: No such file or directory
  make: *** [libcacard.la] Fehler 1
  make: *** Warte auf noch nicht beendete Prozesse...
  
  Restarting make obviously fixed the problem, but I thought I'd mention it
  here so that the dependencies can be fixed.
 
 Please try to reproduce it with make V=1.

Doesn't seem to be reproducable now.

 Did you have an lt CC  stubs/mon-printf.lo before?

Nope, neither before this, nor during the following make run. So I guess
it left an old version of it? Would explain why it doesn't reproduce
after a make clean.

 What version of Make is this?

make-3.82-13.fc18.x86_64

Kevin



Re: [Qemu-devel] (i386) TCG is broken in 1.5-rc0 with guest kernel 3.2?

2013-05-08 Thread Michael Tokarev
08.05.2013 12:22, Michael Tokarev wrote:
 Something strange is going on here.
 
 I just tried 1.5-rc0 (32bit x86 userspace), and guest kernel
 crashes in an interesting way right at init time.
 
  qemu-system-x86_64 -net none -kernel /boot/vmlinuz-3.2-amd64 -append 
 console=ttyS0 -serial file:serial
 
 This results in:
 
 [0.071315] mce: CPU supports 10 MCE banks
 [0.082316] SMP alternatives: switching to UP code
 [0.658457] Freeing SMP alternatives: 16k freed
 [0.660716] ACPI: Core revision 20110623
 [0.744749] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
 [0.778545] CPU0: AMD QEMU Virtual CPU version 1.4.90 stepping 03
 [0.887450] Performance Events: Broken PMU hardware detected, using 
 software events only.
 [0.889372] NMI watchdog disabled (cpu0): hardware events not enabled
 [0.889372] Brought up 1 CPUs
 [0.889372] Total of 1 processors activated (6432.01 BogoMIPS).
 [0.889372] devtmpfs: initialized
 [0.889372] [ cut here ]
 [0.889372] WARNING: at fs/sysfs/group.c:138 dpm_sysfs_add+0xb4/0xc0()
 [0.889372] Hardware name: Bochs
 [0.889372] sysfs group 814bece0 not found for kobject 'platform'
...


This is broken by the following:

commit 57eb0cc85469a8948d1036ab830951e63aa32f66
Author: Richard Henderson r...@twiddle.net
Date:   Wed Jan 16 11:00:14 2013 -0800

target-i386: expand cmov via movcond

Signed-off-by: Richard Henderson r...@twiddle.net


After this change, (at least) 3.2 kernel starts behaving badly,
being unable to boot in qemu TCG mode:

 The same happens with other 3.2.x kernels, for example, ubuntu precise:
 http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/linux
 
 
 qemu-system-x86_64 from qemu-1.4.x lets these kernels to boot fine,
 it all boots fine when adding -enable-kvm.  So it is some change(s)
 in TCG between 1.4 and 1.5, maybe triggering a bug in guest kernel.
 
 For added fun, for example, 3.8 guest kernel does NOT have problems
 with this config.


I'm trying 64bits now too...

/mjt



Re: [Qemu-devel] [PATCH 0/9] Make monitor command 'dump-guest-memory' dump in kdump-compressed format

2013-05-08 Thread HATAYAMA Daisuke

Please add CC list to Kumagai-san, makedumpfile maintainer, and Dave
Anderson in order to let them know this development.

(2013/05/07 16:16), Qiao Nuohan wrote:
 Hi, all
 
 Command 'dump-guest-memory' was introduced to dump guest's memory. But the
 vmcore's format is only elf32 or elf64. The message is here:
 http://lists.gnu.org/archive/html/qemu-devel/2012-04/msg03379.html
 
 These patches are used to make 'dump-guest-memory' be able to dump guest's
 memory in kdump-compressed format. Then vmcore can be much smaller, and
 easily be delivered.
 

It should be stressed here that compression feature is *regression*.

 Note, similar to 'dump-guest-memory':
 1. The guest should be x86 or x86_64. The other arch is not supported now.
 2. If the OS is in the second kernel, gdb may not work well, and crash can
 work by specifying '--machdep phys_addr=xxx' in the command line. The
 reason is that the second kernel will update the page table, and we can
 not get the page table for the first kernel.
 3. The cpu's state is stored in QEMU note.
 4. The vmcore are able to be compressed with zlib, lzo or snappy. zlib is
 available by default, and option '--enable-lzo' or '--enable-snappy'
 should be used with configure to make lzo or snappy available.
 
the kdump-compressed format is:

Rather than detail of format, qemu people should want to know more
general information about kdump-compressed format. They should think
What this format? now. At least the following is needed: the
kdump-compressed format is *linux specific* *linux standard* crash dump
format used in kdump framework.

 File offset
+--+ 0x0
|main header (struct disk_dump_header) |
|--+ block 1
|sub header (struct kdump_sub_header)  |
|--+ block 2
|1st-dump_bitmap   |
|--+ block 2 + X blocks
|2nd-dump_bitmap   | (aligned by block)
|--+ block 2 + 2 * X blocks
|  page desc for pfn 0 (struct page_desc)  | (aligned by block)
|  page desc for pfn 1 (struct page_desc)  |
|: |
|  page desc for pfn Z (struct page_desc)  |
|--| (not aligned by block)
| page data (pfn 0)|
| page data (pfn 1)|
|: |
| page data (pfn Z)|
+--+ offset_eraseinfo
|: |
+--+

Layout itself is important information. Not only describing this here,
it's better to put it anywhere of source code or point at IMPLEMENTATION
file in makedumpfile which describes orignal spec.

-- 
Thanks.
HATAYAMA, Daisuke




Re: [Qemu-devel] [PATCH 25/40] memory: add ref/unref

2013-05-08 Thread Stefan Hajnoczi
On Tue, May 07, 2013 at 04:17:03PM +0200, Paolo Bonzini wrote:
 Signed-off-by: Paolo Bonzini pbonz...@redhat.com
 ---
  include/exec/memory.h |   34 ++
  memory.c  |   14 ++
  2 files changed, 48 insertions(+), 0 deletions(-)
 
 diff --git a/include/exec/memory.h b/include/exec/memory.h
 index 5c20bac..ebac085 100644
 --- a/include/exec/memory.h
 +++ b/include/exec/memory.h
 @@ -253,6 +253,40 @@ struct MemoryListener {
  void memory_region_init(MemoryRegion *mr,
  const char *name,
  uint64_t size);
 +
 +/**
 + * memory_region_ref: Add 1 to a memory region's reference count
 + *
 + * Whenever memory regions are accessed outside the BQL, they need to be
 + * preserved against hot-unplug.  MemoryRegions actually do not have their
 + * own reference count; they piggyback on a QOM object, their owner.
 + * This function adds a reference to the owner.
 + *
 + * All MemoryRegions must have an owner if they can disappear, even if the
 + * device they belong to operates exclusively under the BQL.  This is because
 + * the region could be returned at any time by memory_region_find, and this
 + * is usually under guest control.
 + *
 + * @mr: the #MemoryRegion to be initialized

s/to be initialized//

 + * @name: used for debugging; not visible to the user or ABI
 + * @size: size of the region; any subregions beyond this size will be clipped

Copy-pasted.  These can be deleted.

 + */
 +void memory_region_ref(MemoryRegion *mr);
 +
 +/**
 + * memory_region_ref: Remove 1 to a memory region's reference count

s/memory_region_ref/memory_region_unref/

 + *
 + * Whenever memory regions are accessed outside the BQL, they need to be
 + * preserved against hot-unplug.  MemoryRegions actually do not have their
 + * own reference count; they piggyback on a QOM object, their owner.
 + * This function removes a reference to the owner and possibly destroys it.
 + *
 + * @mr: the #MemoryRegion to be initialized
 + * @name: used for debugging; not visible to the user or ABI
 + * @size: size of the region; any subregions beyond this size will be clipped

Same here.



Re: [Qemu-devel] (i386) TCG is broken in 1.5-rc0 with guest kernel 3.2?

2013-05-08 Thread Michael Tokarev
08.05.2013 13:03, Michael Tokarev wrote:
 This is broken by the following:
 
 commit 57eb0cc85469a8948d1036ab830951e63aa32f66
 Author: Richard Henderson r...@twiddle.net
 Date:   Wed Jan 16 11:00:14 2013 -0800
 
 target-i386: expand cmov via movcond
 
 Signed-off-by: Richard Henderson r...@twiddle.net

This change works fine on amd64.  Only i386 (32bit x86)
userspace is broken.  Running amd64 guest kernel inside
in all cases.

Thanks,

/mjt



Re: [Qemu-devel] [RFC PATCH 0/8] MemoryRegion and FlatView refcounting, replace hostmem with memory_region_find

2013-05-08 Thread Stefan Hajnoczi
On Mon, May 06, 2013 at 04:25:13PM +0200, Paolo Bonzini wrote:
 this is an alternative approach to refactoring of dataplane's HostMem
 code.  Here, I take Ping Fan's idea of RCU-style updating of the
 region list and apply it to the AddressSpace's FlatView.  With this
 change, dataplane can simply use memory_region_find instead of
 hostmem.
 
 This is a somewhat larger change, but I prefer it for two reasons.
 
 1) it splits the task of adding BQL-less memory dispatch in two parts,
tacking memory_region_find first (which is simpler because locking
is left to the caller).
 
 2) HostMem duplicates a lot of the FlatView logic, and adding the
RCU-style update in FlatView benefits everyone.
 
 The missing ingredients here are:
 
 1) remember and unreference the MemoryRegions that are used in
a vring entry.  In order to implement this, it is probably simpler
to change vring.c to use virtio.c's VirtQueueElement data structure.
We want something like that anyway in order to support migration.

Agreed.  I want to drop vring.c and have virtio.c use thread-safe APIs
so it can be used from dataplane.  VirtQueueElement can hide the
MemoryRegion reference so the virtio device caller (net, block, etc)
doesn't need to juggle references manually.

 2) add an owner field to MemoryRegion, and set it for all MemoryRegions
for hot-unpluggable devices.  In this series, ref/unref are stubs.
 
 For simplicity I based the patches on my IOMMU rebase.  I placed the
 tree at git://github.com/bonzini/qemu.git, branch iommu.

Are you hoping that Ping Fan will pick up this RFC or will you push it
yourself?

Either way, I'm very interested in a thread-safe memory API.

Stefan



Re: [Qemu-devel] [Qemu-ppc] Incorrect handling of more PPC64 insns (PATCH)

2013-05-08 Thread Torbjorn Granlund
Aurelien Jarno aurel...@aurel32.net writes:

  64-bit CPUs check for the L bit of comparison instruction to determine
  if the instruction is 32-bit wide, and not to the MSR SF bit.
  
  L=1 on a 32-bit CPU should generate an invalid instruction exception.
  
No.  See my previous post.

The L bit is to be ignored for 32-bit CPUs, just like the original code
did.

-- 
Torbjörn



[Qemu-devel] [Bug 1174654] Re: qemu-system-x86_64 takes 100% CPU after host machine resumed from suspend to ram

2013-05-08 Thread Maxim Loparev
The issue mostly gone after cold reboot via suspend to disk. I managed to 
reproduce it only once after reboot and it grubs CPU for only minute or two 
while i checking it and than returned to normal CPU usage. I've checked both 
distribution and the trunk version.
So suspend this bug until someone can stably reproduce it.

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

Title:
  qemu-system-x86_64 takes 100% CPU after host machine resumed from
  suspend to ram

Status in QEMU:
  Confirmed
Status in “qemu” package in Ubuntu:
  Confirmed

Bug description:
  I have Windows XP SP3  inside qemu VM. All works fine in 12.10. But
  after upgraiding to 13.04 i have to restart the VM each time i
  resuming my host machine, because qemu process starts to take CPU
  cycles and OS inside VM is very slow and sluggish. However it's still
  controllable and could be shutdown by itself.

  According to the taskmgr any active process takes 99% CPU. It's not
  stucked on some single process.

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



Re: [Qemu-devel] [RFC PATCH 0/8] MemoryRegion and FlatView refcounting, replace hostmem with memory_region_find

2013-05-08 Thread Stefan Hajnoczi
On Mon, May 06, 2013 at 04:25:13PM +0200, Paolo Bonzini wrote:
 this is an alternative approach to refactoring of dataplane's HostMem
 code.  Here, I take Ping Fan's idea of RCU-style updating of the
 region list and apply it to the AddressSpace's FlatView.  With this
 change, dataplane can simply use memory_region_find instead of
 hostmem.

Getting rid of hostmem is nice since we nearly have the necessary
infrastructure in the core memory API already.

Stefan



Re: [Qemu-devel] [PATCH RFC 0/3] seabios: move acpi table formatting out of bios

2013-05-08 Thread Gleb Natapov
On Tue, May 07, 2013 at 07:01:13PM -0400, Kevin O'Connor wrote:
 On Tue, May 07, 2013 at 09:00:48PM +0300, Michael S. Tsirkin wrote:
  On Thu, Apr 25, 2013 at 12:02:20PM +0300, Michael S. Tsirkin wrote:
   Untested yet, but I thought I'd share the
   BIOS bits so we can agree on direction.
   
   In particular check out ROM sizes:
   - Before patchset with DSDT enabled
   Total size: 127880  Fixed: 59060  Free: 3192 (used 97.6% of 128KiB 
   rom)
   - Before patchset with DSDT disabled
   Total size: 122844  Fixed: 58884  Free: 8228 (used 93.7% of 128KiB 
   rom)
   - After patchset:
   Total size: 128776  Fixed: 59100  Free: 2296 (used 98.2% of 128KiB 
   rom)
   - Legacy disabled at build time:
   Total size: 119836  Fixed: 58996  Free: 11236 (used 91.4% of 128KiB 
   rom)
   
   As can be seen from this, most size savings come
   from dropping DSDT, but we do save a bit by removing
   other tables. Of course the real reason to move tables to QEMU
   is so that ACPI can better match hardware.
   
   This patchset adds an option to move all code for formatting acpi tables
   out of BIOS. With this, QEMU has full control over the table layout.
   All tables are loaded from the new /etc/acpi/ directory.
   Any entries in this directory cause BIOS to disable
   ACPI table generation completely.
   A generic linker script, controlled by QEMU, is
   loaded from /etc/linker-script. It is used to
   patch in table pointers and checksums.
  
  After some thought, there are two additional
  options worth considering, in that they simplify
  bios code somewhat:
  
  - bios could get size from qemu, allocate a buffer
(e.g. could be one buffer for all tables)
and pass the address to qemu.
qemu does all the patching
  
  - further, qemu could do the copy of tables into
that address directly
 
 This seems more complex than necessary to me.
 
 The important task is to get the tables generated in QEMU - I'd focus
 on getting the tables generated in QEMU (one table per fw_cfg file).
 Once that is done, the SeaBIOS side can be easily implemented, and we
 can add any enhancements on top if we feel it is necessary.
 
+1. This copy of tables into that address directly is just an ad-hoc PV
isa DMA device in disguise. Such device was refused when libguestfs
asked for it, and they wanted it for much better reason - performance.
There is existing mechanism to pass data into firmware. Use it please.

--
Gleb.



Re: [Qemu-devel] [Qemu-ppc] Incorrect handling of more PPC64 insns (PATCH)

2013-05-08 Thread Alexander Graf

On 08.05.2013, at 11:20, Torbjorn Granlund wrote:

 Aurelien Jarno aurel...@aurel32.net writes:
 
  64-bit CPUs check for the L bit of comparison instruction to determine
  if the instruction is 32-bit wide, and not to the MSR SF bit.
 
  L=1 on a 32-bit CPU should generate an invalid instruction exception.
 
 No.  See my previous post.
 
 The L bit is to be ignored for 32-bit CPUs, just like the original code
 did.

I see. So if the target is 64bit capable, then we distinguish by the 
instruction bit, but for 32bit targets we always call the 32bit variant 
regardless of the bit?


Alex




[Qemu-devel] [PATCH 2/5] libqos/pci: Enable bus mastering

2013-05-08 Thread Kevin Wolf
Signed-off-by: Kevin Wolf kw...@redhat.com
---
 tests/libqos/pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/libqos/pci.c b/tests/libqos/pci.c
index 95e287b..7e0907b 100644
--- a/tests/libqos/pci.c
+++ b/tests/libqos/pci.c
@@ -71,7 +71,7 @@ void qpci_device_enable(QPCIDevice *dev)
 
 /* FIXME -- does this need to be a bus callout? */
 cmd = qpci_config_readw(dev, PCI_COMMAND);
-cmd |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY;
+cmd |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER;
 qpci_config_writew(dev, PCI_COMMAND, cmd);
 }
 
-- 
1.8.1.4




[Qemu-devel] [PATCH 1/5] ide: Reset BMIDEA bit when the bus master is stopped

2013-05-08 Thread Kevin Wolf
The device is supposed to reset the Bus Master IDE Active bit in the
status register when 0 is written to the Start/Stop Bus Master bit in
the command register.

In the common cases this happens automatically because bdrv_drain_all()
flushes the requests, but with a large PRDT it could remain set.

Signed-off-by: Kevin Wolf kw...@redhat.com
---
 hw/ide/pci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/ide/pci.c b/hw/ide/pci.c
index a310975..635a364 100644
--- a/hw/ide/pci.c
+++ b/hw/ide/pci.c
@@ -312,6 +312,7 @@ void bmdma_cmd_writeb(BMDMAState *bm, uint32_t val)
 bdrv_drain_all();
 assert(bm-bus-dma-aiocb == NULL);
 }
+bm-status = ~BM_STATUS_DMAING;
 } else {
 bm-cur_addr = bm-addr;
 if (!(bm-status  BM_STATUS_DMAING)) {
-- 
1.8.1.4




Re: [Qemu-devel] Reporting Heisenbugs in qemu

2013-05-08 Thread Torbjorn Granlund
Paolo Bonzini pbonz...@redhat.com writes:

  I guess that's the register windows.  There's only so much you can do to
  optimize them, and heavily recursive workloads (like Perl, or the RTL
  half of GCC) pay a hefty price.
  
Two qemu targets stand out for slowness, sparc (32 and 64) and mips (64,
don't know about 32).

x86 (32 and 64), arm, and ppc run with a slowdown of  30 for my bogus
benchmark of GMP configure+make.

With FreeBSD x86_64 I see a slowdown of just 13.  (My reference system
runs FreeBSD, so running FreeBSD under qemu is only far.)

My claimed slowdown factors are affected by kernel, libraries, and
unfortunately very much by gcc speed, which vary with target.

If the sparc emulation speed is due to register windows, then why does
mips seem just as slow?

If register windows shortage is a problem, it should be easy to pretend
to have lots of them, right?

-- 
Torbjörn



[Qemu-devel] [PATCH 3/5] qtest: Add IDE test case

2013-05-08 Thread Kevin Wolf
This adds a simple IDE test case and starts by verifying that IDENTIFY
can be successfully used and return the correct serial number, version
and the WCE flag is set for cache=writeback.

Signed-off-by: Kevin Wolf kw...@redhat.com
---
 tests/Makefile   |   2 +
 tests/ide-test.c | 165 +++
 2 files changed, 167 insertions(+)
 create mode 100644 tests/ide-test.c

diff --git a/tests/Makefile b/tests/Makefile
index bf41d10..a307d5a 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -51,6 +51,7 @@ check-block-$(CONFIG_POSIX) += tests/qemu-iotests-quick.sh
 # really in libqtest, not in the testcases themselves.
 check-qtest-i386-y = tests/fdc-test$(EXESUF)
 gcov-files-i386-y = hw/fdc.c
+check-qtest-i386-y += tests/ide-test$(EXESUF)
 check-qtest-i386-y += tests/hd-geo-test$(EXESUF)
 gcov-files-i386-y += hw/hd-geometry.c
 check-qtest-i386-y += tests/rtc-test$(EXESUF)
@@ -127,6 +128,7 @@ libqos-omap-obj-y = $(libqos-obj-y) tests/libqos/i2c-omap.o
 tests/rtc-test$(EXESUF): tests/rtc-test.o
 tests/m48t59-test$(EXESUF): tests/m48t59-test.o
 tests/fdc-test$(EXESUF): tests/fdc-test.o
+tests/ide-test$(EXESUF): tests/ide-test.o $(libqos-pc-obj-y)
 tests/hd-geo-test$(EXESUF): tests/hd-geo-test.o
 tests/tmp105-test$(EXESUF): tests/tmp105-test.o $(libqos-omap-obj-y)
 tests/i440fx-test$(EXESUF): tests/i440fx-test.o $(libqos-pc-obj-y)
diff --git a/tests/ide-test.c b/tests/ide-test.c
new file mode 100644
index 000..45036e3
--- /dev/null
+++ b/tests/ide-test.c
@@ -0,0 +1,165 @@
+/*
+ * IDE test cases
+ *
+ * Copyright (c) 2013 Kevin Wolf kw...@redhat.com
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include stdint.h
+#include string.h
+#include stdio.h
+
+#include glib.h
+
+#include libqtest.h
+
+#include qemu-common.h
+
+#define TEST_IMAGE_SIZE 64 * 1024 * 1024
+
+#define IDE_PCI_DEV 1
+#define IDE_PCI_FUNC1
+
+#define IDE_BASE 0x1f0
+#define IDE_PRIMARY_IRQ 14
+
+enum {
+reg_data= 0x0,
+reg_nsectors= 0x2,
+reg_lba_low = 0x3,
+reg_lba_middle  = 0x4,
+reg_lba_high= 0x5,
+reg_device  = 0x6,
+reg_status  = 0x7,
+reg_command = 0x7,
+};
+
+enum {
+BSY = 0x80,
+DRDY= 0x40,
+DF  = 0x20,
+DRQ = 0x08,
+ERR = 0x01,
+};
+
+enum {
+CMD_IDENTIFY= 0xec,
+};
+
+#define assert_bit_set(data, mask) g_assert_cmphex((data)  (mask), ==, (mask))
+#define assert_bit_clear(data, mask) g_assert_cmphex((data)  (mask), ==, 0)
+
+static char tmp_path[] = /tmp/qtest.XX;
+
+static void ide_test_start(const char *cmdline_fmt, ...)
+{
+va_list ap;
+char *cmdline;
+
+va_start(ap, cmdline_fmt);
+cmdline = g_strdup_vprintf(cmdline_fmt, ap);
+va_end(ap);
+
+qtest_start(cmdline);
+qtest_irq_intercept_in(global_qtest, ioapic);
+}
+
+static void ide_test_quit(void)
+{
+qtest_quit(global_qtest);
+}
+
+static void test_identify(void)
+{
+uint8_t data;
+uint16_t buf[256];
+int i;
+int ret;
+
+ide_test_start(
+-vnc none 
+-drive file=%s,if=ide,serial=%s,cache=writeback 
+-global ide-hd.ver=%s,
+tmp_path, testdisk, version);
+
+/* IDENTIFY command on device 0*/
+outb(IDE_BASE + reg_device, 0);
+outb(IDE_BASE + reg_command, CMD_IDENTIFY);
+
+/* Read in the IDENTIFY buffer and check registers */
+data = inb(IDE_BASE + reg_device);
+g_assert_cmpint(data  0x10, ==, 0);
+
+for (i = 0; i  256; i++) {
+data = inb(IDE_BASE + reg_status);
+assert_bit_set(data, DRDY | DRQ);
+assert_bit_clear(data, BSY | DF | ERR);
+
+((uint16_t*) buf)[i] = inw(IDE_BASE + reg_data);
+}
+
+data = inb(IDE_BASE + reg_status);
+assert_bit_set(data, DRDY);
+assert_bit_clear(data, BSY | DF | ERR | DRQ);
+
+/* Check serial number/version in the buffer */
+ret = memcmp(buf[10], ettsidks, 20);
+g_assert(ret == 0);
+

[Qemu-devel] [PATCH 1/2] clean unnecessary code

2013-05-08 Thread Trival
Duplicates a string. If str is NULL it returns NULL, so
can make code simple.

Signed-off-by: Trival triv...@linux.vnet.ibm.com
---
 util/uri.c | 2 +-
 vl.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/util/uri.c b/util/uri.c
index 4238729..e348c17 100644
--- a/util/uri.c
+++ b/util/uri.c
@@ -2162,7 +2162,7 @@ query_params_append (struct QueryParams *ps,
 }
 
 ps-p[ps-n].name = g_strdup(name);
-ps-p[ps-n].value = value ? g_strdup(value) : NULL;
+ps-p[ps-n].value = g_strdup(value);
 ps-p[ps-n].ignore = 0;
 ps-n++;
 
diff --git a/vl.c b/vl.c
index 6e6225f..be0a93c 100644
--- a/vl.c
+++ b/vl.c
@@ -1215,7 +1215,7 @@ void add_boot_device_path(int32_t bootindex, DeviceState 
*dev,
 
 node = g_malloc0(sizeof(FWBootEntry));
 node-bootindex = bootindex;
-node-suffix = suffix ? g_strdup(suffix) : NULL;
+node-suffix = g_strdup(suffix);
 node-dev = dev;
 
 QTAILQ_FOREACH(i, fw_boot_order, link) {
-- 
1.7.11.7




[Qemu-devel] [PATCH 2/2] remove needless semicolon

2013-05-08 Thread Trival
Signed-off-by: Trival triv...@linux.vnet.ibm.com
---
 block/nbd.c | 2 +-
 fsdev/virtfs-proxy-helper.c | 4 ++--
 hw/9pfs/virtio-9p-local.c   | 2 +-
 hw/i386/pc_q35.c| 2 +-
 hw/intc/imx_avic.c  | 2 +-
 hw/usb/host-linux.c | 4 ++--
 qga/channel-win32.c | 2 +-
 7 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/block/nbd.c b/block/nbd.c
index fab114b..30e3b78 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -609,7 +609,7 @@ static int nbd_co_discard(BlockDriverState *bs, int64_t 
sector_num,
 return 0;
 }
 request.type = NBD_CMD_TRIM;
-request.from = sector_num * 512;;
+request.from = sector_num * 512;
 request.len = nb_sectors * 512;
 
 nbd_coroutine_start(s, request);
diff --git a/fsdev/virtfs-proxy-helper.c b/fsdev/virtfs-proxy-helper.c
index 36f6616..713a7b2 100644
--- a/fsdev/virtfs-proxy-helper.c
+++ b/fsdev/virtfs-proxy-helper.c
@@ -248,7 +248,7 @@ static int send_fd(int sockfd, int fd)
 static int send_status(int sockfd, struct iovec *iovec, int status)
 {
 ProxyHeader header;
-int retval, msg_size;;
+int retval, msg_size;
 
 if (status  0) {
 header.type = T_ERROR;
@@ -381,7 +381,7 @@ static int send_response(int sock, struct iovec *iovec, int 
size)
 proxy_marshal(iovec, 0, dd, header.type, header.size);
 retval = socket_write(sock, iovec-iov_base, header.size + PROXY_HDR_SZ);
 if (retval  0) {
-return retval;;
+return retval;
 }
 return 0;
 }
diff --git a/hw/9pfs/virtio-9p-local.c b/hw/9pfs/virtio-9p-local.c
index be898ec..6ece6f7 100644
--- a/hw/9pfs/virtio-9p-local.c
+++ b/hw/9pfs/virtio-9p-local.c
@@ -878,7 +878,7 @@ static int local_remove(FsContext *ctx, const char *path)
  * Now remove the name from parent directory
  * .virtfs_metadata directory
  */
-err = remove(local_mapped_attr_path(ctx, path, buffer));;
+err = remove(local_mapped_attr_path(ctx, path, buffer));
 if (err  0  errno != ENOENT) {
 /*
  * We didn't had the .virtfs_metadata file. May be file created
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 4160e2b..6825380 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -128,7 +128,7 @@ static void pc_q35_init(QEMUMachineInitArgs *args)
 q35_host-mch.ram_memory = ram_memory;
 q35_host-mch.pci_address_space = pci_memory;
 q35_host-mch.system_memory = get_system_memory();
-q35_host-mch.address_space_io = get_system_io();;
+q35_host-mch.address_space_io = get_system_io();
 q35_host-mch.below_4g_mem_size = below_4g_mem_size;
 q35_host-mch.above_4g_mem_size = above_4g_mem_size;
 /* pci */
diff --git a/hw/intc/imx_avic.c b/hw/intc/imx_avic.c
index 4e280b6..ff45dcd 100644
--- a/hw/intc/imx_avic.c
+++ b/hw/intc/imx_avic.c
@@ -370,7 +370,7 @@ static void imx_avic_reset(DeviceState *dev)
 
 static int imx_avic_init(SysBusDevice *dev)
 {
-IMXAVICState *s = FROM_SYSBUS(IMXAVICState, dev);;
+IMXAVICState *s = FROM_SYSBUS(IMXAVICState, dev);
 
 memory_region_init_io(s-iomem, imx_avic_ops, s, imx_avic, 0x1000);
 sysbus_init_mmio(dev, s-iomem);
diff --git a/hw/usb/host-linux.c b/hw/usb/host-linux.c
index 8994668..ca09a89 100644
--- a/hw/usb/host-linux.c
+++ b/hw/usb/host-linux.c
@@ -651,7 +651,7 @@ static void usb_host_handle_reset(USBDevice *dev)
 
 trace_usb_host_reset(s-bus_num, s-addr);
 
-usb_host_do_reset(s);;
+usb_host_do_reset(s);
 
 usb_host_claim_interfaces(s, 0);
 usb_linux_update_endp_table(s);
@@ -1429,7 +1429,7 @@ static void usb_host_exit_notifier(struct Notifier *n, 
void *data)
 
 usb_host_release_port(s);
 if (s-fd != -1) {
-usb_host_do_reset(s);;
+usb_host_do_reset(s);
 }
 }
 
diff --git a/qga/channel-win32.c b/qga/channel-win32.c
index 7ed98d7..8a303f3 100644
--- a/qga/channel-win32.c
+++ b/qga/channel-win32.c
@@ -268,7 +268,7 @@ static GIOStatus ga_channel_write(GAChannel *c, const char 
*buf, size_t size,
 
 GIOStatus ga_channel_write_all(GAChannel *c, const char *buf, size_t size)
 {
-GIOStatus status = G_IO_STATUS_NORMAL;;
+GIOStatus status = G_IO_STATUS_NORMAL;
 size_t count;
 
 while (size) {
-- 
1.7.11.7




Re: [Qemu-devel] [PATCH 0/3] qemu-iotests: fix for vmdk

2013-05-08 Thread Kevin Wolf
Am 07.05.2013 um 13:13 hat Fam Zheng geschrieben:
 When testing vmdk, qemu-iotests fails on 017, 018, 042 and 043 for trivial
 reasons. These patches try to fix those cases to pass tests on all four
 subformats of vmdk {monolithicSparse monolithicFlat twoGbMaxExtentSparse
 twoGbMaxExtentFlat}.
 
 Fam Zheng (3):
   qemu-iotests: exclude vmdk for test 042
   qemu-iotests: exclude vmdk from 043
   qemu-iotests: fix 017 018 for vmdk

Thanks, applied all to the block branch.

I extended patch 2 to also remove qcow1, which doesn't support changing
the backing file either.

Kevin



Re: [Qemu-devel] [Qemu-ppc] Incorrect handling of more PPC64 insns (PATCH)

2013-05-08 Thread Alexander Graf

On 08.05.2013, at 11:32, Alexander Graf wrote:

 
 On 08.05.2013, at 11:20, Torbjorn Granlund wrote:
 
 Aurelien Jarno aurel...@aurel32.net writes:
 
 64-bit CPUs check for the L bit of comparison instruction to determine
 if the instruction is 32-bit wide, and not to the MSR SF bit.
 
 L=1 on a 32-bit CPU should generate an invalid instruction exception.
 
 No.  See my previous post.
 
 The L bit is to be ignored for 32-bit CPUs, just like the original code
 did.
 
 I see. So if the target is 64bit capable, then we distinguish by the 
 instruction bit, but for 32bit targets we always call the 32bit variant 
 regardless of the bit?

Ok, so the real problem here is that NARROW_MODE is not set, but is used to 
differentiate whether to use the 32bit cmp only or not.

Richard, there are 2 ways out of this:

  1) get rid of NARROW_MODE and always check ctx-sf
  2) add a new 32bit only insns flag and create separate functions for 32bit 
cmp calls

I have a patch set ready for 2, but I think 1 would be the better alternative. 
The only cases I could spot where things could break is in the add/sub corner 
case. Let me try to cook up something.


Alex




[Qemu-devel] [PATCH 1.5 0/5] ide: Test cases and a corner case fix

2013-05-08 Thread Kevin Wolf
Kevin Wolf (5):
  ide: Reset BMIDEA bit when the bus master is stopped
  libqos/pci: Enable bus mastering
  qtest: Add IDE test case
  qtest/ide-test: Add simple DMA read/write test case
  qtest/ide-test: Test short and long PRDTs

 hw/ide/pci.c   |   1 +
 tests/Makefile |   2 +
 tests/ide-test.c   | 440 +
 tests/libqos/pci.c |   2 +-
 4 files changed, 444 insertions(+), 1 deletion(-)
 create mode 100644 tests/ide-test.c

-- 
1.8.1.4




[Qemu-devel] [PATCH] PPC: Fix cmp on 32bit only targets

2013-05-08 Thread Alexander Graf
When running 32bit cmp instructions on a TARGET_PPC without 64bit support,
we generate incorrect comparisons. This patch set fixes this issue.


Alex

Alexander Graf (2):
  PPC: Add 32bit instruction flag
  PPC: Introduce 32bit only cmp ops

 target-ppc/cpu.h|5 ++-
 target-ppc/translate.c  |   48 +++
 target-ppc/translate_init.c |   88 +-
 3 files changed, 88 insertions(+), 53 deletions(-)




[Qemu-devel] [PATCH] PPC: Introduce 32bit only cmp ops

2013-05-08 Thread Alexander Graf
When running a 32bit target CPU with qemu-(system-)-ppc, NARROW_MODE
is not set, so we never get to leverage the 32bit only code path in
the compare op handlers.

Introduce new handlers based on the 32bit only flag. That way we can
have 2 separate functions for 32bit mode and 64bit mode, which can
handle NARROW_MODE.

Reported-by: Torbjorn Granlund t...@gmplib.org
Signed-off-by: Alexander Graf ag...@suse.de
---
 target-ppc/translate.c |   48 
 1 files changed, 40 insertions(+), 8 deletions(-)

diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index a018616..002f9ae 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -675,7 +675,7 @@ static inline void gen_set_Rc0(DisasContext *ctx, TCGv reg)
 /* cmp */
 static void gen_cmp(DisasContext *ctx)
 {
-if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
+if (!(ctx-opcode  0x0020)) {
 gen_op_cmp32(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
  1, crfD(ctx-opcode));
 } else {
@@ -684,10 +684,17 @@ static void gen_cmp(DisasContext *ctx)
 }
 }
 
+/* cmp 32bit only */
+static void gen_cmp32(DisasContext *ctx)
+{
+gen_op_cmp32(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
+ 1, crfD(ctx-opcode));
+}
+
 /* cmpi */
 static void gen_cmpi(DisasContext *ctx)
 {
-if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
+if (!(ctx-opcode  0x0020)) {
 gen_op_cmpi32(cpu_gpr[rA(ctx-opcode)], SIMM(ctx-opcode),
   1, crfD(ctx-opcode));
 } else {
@@ -696,10 +703,17 @@ static void gen_cmpi(DisasContext *ctx)
 }
 }
 
+/* cmpi 32bit only */
+static void gen_cmpi32(DisasContext *ctx)
+{
+gen_op_cmpi32(cpu_gpr[rA(ctx-opcode)], SIMM(ctx-opcode),
+  1, crfD(ctx-opcode));
+}
+
 /* cmpl */
 static void gen_cmpl(DisasContext *ctx)
 {
-if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
+if (!(ctx-opcode  0x0020)) {
 gen_op_cmp32(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
  0, crfD(ctx-opcode));
 } else {
@@ -708,10 +722,17 @@ static void gen_cmpl(DisasContext *ctx)
 }
 }
 
+/* cmpl 32bit only */
+static void gen_cmpl32(DisasContext *ctx)
+{
+gen_op_cmp32(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
+ 0, crfD(ctx-opcode));
+}
+
 /* cmpli */
 static void gen_cmpli(DisasContext *ctx)
 {
-if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
+if (!(ctx-opcode  0x0020)) {
 gen_op_cmpi32(cpu_gpr[rA(ctx-opcode)], UIMM(ctx-opcode),
   0, crfD(ctx-opcode));
 } else {
@@ -720,6 +741,13 @@ static void gen_cmpli(DisasContext *ctx)
 }
 }
 
+/* cmpli 32bit only */
+static void gen_cmpli32(DisasContext *ctx)
+{
+gen_op_cmpi32(cpu_gpr[rA(ctx-opcode)], UIMM(ctx-opcode),
+  0, crfD(ctx-opcode));
+}
+
 /* isel (PowerPC 2.03 specification) */
 static void gen_isel(DisasContext *ctx)
 {
@@ -8638,10 +8666,14 @@ GEN_SPE(efdtsteq,  speundef,  0x1F, 0x0B, 0x0060, 
0x, PPC_SPE_DOUBLE
 
 static opcode_t opcodes[] = {
 GEN_HANDLER(invalid, 0x00, 0x00, 0x00, 0x, PPC_NONE),
-GEN_HANDLER(cmp, 0x1F, 0x00, 0x00, 0x0040, PPC_INTEGER),
-GEN_HANDLER(cmpi, 0x0B, 0xFF, 0xFF, 0x0040, PPC_INTEGER),
-GEN_HANDLER(cmpl, 0x1F, 0x00, 0x01, 0x0040, PPC_INTEGER),
-GEN_HANDLER(cmpli, 0x0A, 0xFF, 0xFF, 0x0040, PPC_INTEGER),
+GEN_HANDLER(cmp, 0x1F, 0x00, 0x00, 0x0040, PPC_64B),
+GEN_HANDLER_E(cmp32, 0x1F, 0x00, 0x00, 0x0040, PPC_NONE, PPC2_32B),
+GEN_HANDLER(cmpi, 0x0B, 0xFF, 0xFF, 0x0040, PPC_64B),
+GEN_HANDLER_E(cmpi32, 0x0B, 0xFF, 0xFF, 0x0040, PPC_NONE, PPC2_32B),
+GEN_HANDLER(cmpl, 0x1F, 0x00, 0x01, 0x0040, PPC_64B),
+GEN_HANDLER_E(cmpl32, 0x1F, 0x00, 0x01, 0x0040, PPC_NONE, PPC2_32B),
+GEN_HANDLER(cmpli, 0x0A, 0xFF, 0xFF, 0x0040, PPC_64B),
+GEN_HANDLER_E(cmpli32, 0x0A, 0xFF, 0xFF, 0x0040, PPC_NONE, PPC2_32B),
 GEN_HANDLER_E(cmpb, 0x1F, 0x1C, 0x0F, 0x0001, PPC_NONE, PPC2_ISA205),
 GEN_HANDLER(isel, 0x1F, 0x0F, 0xFF, 0x0001, PPC_ISEL),
 GEN_HANDLER(addi, 0x0E, 0xFF, 0xFF, 0x, PPC_INTEGER),
-- 
1.6.0.2




Re: [Qemu-devel] [Qemu-ppc] Incorrect handling of more PPC64 insns (PATCH)

2013-05-08 Thread Torbjorn Granlund
Alexander Graf ag...@suse.de writes:

  Ok, so the real problem here is that NARROW_MODE is not set, but is
  used to differentiate whether to use the 32bit cmp only or not.
  
Eh?

  Richard, there are 2 ways out of this:
  
1) get rid of NARROW_MODE and always check ctx-sf

No!

The cmp insn with L set should NOT be affected by SF.  That's the entire
point of my change.

I reviewed the other uses of NARROW_MODE and didn't spot any errors.
(But I must confess that I would need to red the PPC manuals better inn
order to tell for sure.)

2) add a new 32bit only insns flag and create separate functions for 32bit 
cmp calls
  
Aurelien's patch looked promising, if one removes the exception casting.

-- 
Torbjörn



[Qemu-devel] [PATCH 4/5] qtest/ide-test: Add simple DMA read/write test case

2013-05-08 Thread Kevin Wolf
This tests that single sectors can be successfully written and correctly
read back.

Signed-off-by: Kevin Wolf kw...@redhat.com
---
 tests/ide-test.c | 221 +++
 1 file changed, 221 insertions(+)

diff --git a/tests/ide-test.c b/tests/ide-test.c
index 45036e3..5fc496f 100644
--- a/tests/ide-test.c
+++ b/tests/ide-test.c
@@ -29,8 +29,12 @@
 #include glib.h
 
 #include libqtest.h
+#include libqos/pci-pc.h
+#include libqos/malloc-pc.h
 
 #include qemu-common.h
+#include hw/pci/pci_ids.h
+#include hw/pci/pci_regs.h
 
 #define TEST_IMAGE_SIZE 64 * 1024 * 1024
 
@@ -60,12 +64,42 @@ enum {
 };
 
 enum {
+LBA = 0x40,
+};
+
+enum {
+bmreg_cmd   = 0x0,
+bmreg_status= 0x2,
+bmreg_prdt  = 0x4,
+};
+
+enum {
+CMD_READ_DMA= 0xc8,
+CMD_WRITE_DMA   = 0xca,
 CMD_IDENTIFY= 0xec,
 };
 
+enum {
+BM_CMD_START=  0x1,
+BM_CMD_WRITE=  0x8, /* write = from device to memory */
+};
+
+enum {
+BM_STS_ACTIVE   =  0x1,
+BM_STS_ERROR=  0x2,
+BM_STS_INTR =  0x4,
+};
+
+enum {
+PRDT_EOT= 0x8000,
+};
+
 #define assert_bit_set(data, mask) g_assert_cmphex((data)  (mask), ==, (mask))
 #define assert_bit_clear(data, mask) g_assert_cmphex((data)  (mask), ==, 0)
 
+static QPCIBus *pcibus = NULL;
+static QGuestAllocator *guest_malloc;
+
 static char tmp_path[] = /tmp/qtest.XX;
 
 static void ide_test_start(const char *cmdline_fmt, ...)
@@ -79,6 +113,7 @@ static void ide_test_start(const char *cmdline_fmt, ...)
 
 qtest_start(cmdline);
 qtest_irq_intercept_in(global_qtest, ioapic);
+guest_malloc = pc_alloc_init();
 }
 
 static void ide_test_quit(void)
@@ -86,6 +121,188 @@ static void ide_test_quit(void)
 qtest_quit(global_qtest);
 }
 
+static QPCIDevice *get_pci_device(uint16_t *bmdma_base)
+{
+QPCIDevice *dev;
+uint16_t vendor_id, device_id;
+
+if (!pcibus) {
+pcibus = qpci_init_pc();
+}
+
+/* Find PCI device and verify it's the right one */
+dev = qpci_device_find(pcibus, QPCI_DEVFN(IDE_PCI_DEV, IDE_PCI_FUNC));
+g_assert(dev != NULL);
+
+vendor_id = qpci_config_readw(dev, PCI_VENDOR_ID);
+device_id = qpci_config_readw(dev, PCI_DEVICE_ID);
+g_assert(vendor_id == PCI_VENDOR_ID_INTEL);
+g_assert(device_id == PCI_DEVICE_ID_INTEL_82371SB_1);
+
+/* Map bmdma BAR */
+*bmdma_base = (uint16_t)(uintptr_t) qpci_iomap(dev, 4);
+
+qpci_device_enable(dev);
+
+return dev;
+}
+
+static void free_pci_device(QPCIDevice *dev)
+{
+/* libqos doesn't have a function for this, so free it manually */
+g_free(dev);
+}
+
+typedef struct PrdtEntry {
+uint32_t addr;
+uint32_t size;
+} QEMU_PACKED PrdtEntry;
+
+#define assert_bit_set(data, mask) g_assert_cmphex((data)  (mask), ==, (mask))
+#define assert_bit_clear(data, mask) g_assert_cmphex((data)  (mask), ==, 0)
+
+static int send_dma_request(int cmd, uint64_t sector, int nb_sectors,
+PrdtEntry *prdt, int prdt_entries)
+{
+QPCIDevice *dev;
+uint16_t bmdma_base;
+uintptr_t guest_prdt;
+size_t len;
+bool from_dev;
+uint8_t status;
+
+dev = get_pci_device(bmdma_base);
+
+switch (cmd) {
+case CMD_READ_DMA:
+from_dev = true;
+break;
+case CMD_WRITE_DMA:
+from_dev = false;
+break;
+default:
+g_assert_not_reached();
+}
+
+/* Select device 0 */
+outb(IDE_BASE + reg_device, 0 | LBA);
+
+/* Stop any running transfer, clear any pending interrupt */
+outb(bmdma_base + bmreg_cmd, 0);
+outb(bmdma_base + bmreg_status, BM_STS_INTR);
+
+/* Setup PRDT */
+len = sizeof(*prdt) * prdt_entries;
+guest_prdt = guest_alloc(guest_malloc, len);
+memwrite(guest_prdt, prdt, len);
+outl(bmdma_base + bmreg_prdt, guest_prdt);
+
+/* ATA DMA command */
+outb(IDE_BASE + reg_nsectors, nb_sectors);
+
+outb(IDE_BASE + reg_lba_low,sector  0xff);
+outb(IDE_BASE + reg_lba_middle, (sector  8)  0xff);
+outb(IDE_BASE + reg_lba_high,   (sector  16)  0xff);
+
+outb(IDE_BASE + reg_command, cmd);
+
+/* Start DMA transfer */
+outb(bmdma_base + bmreg_cmd, BM_CMD_START | (from_dev ? BM_CMD_WRITE : 0));
+
+/* Wait for the DMA transfer to complete */
+do {
+status = inb(bmdma_base + bmreg_status);
+} while ((status  (BM_STS_ACTIVE | BM_STS_INTR)) == BM_STS_ACTIVE);
+
+g_assert_cmpint(get_irq(IDE_PRIMARY_IRQ), ==, !!(status  BM_STS_INTR));
+
+/* Check IDE status code */
+assert_bit_set(inb(IDE_BASE + reg_status), DRDY);
+assert_bit_clear(inb(IDE_BASE + reg_status), BSY | DRQ);
+
+/* Reading the status register clears the IRQ */
+g_assert(!get_irq(IDE_PRIMARY_IRQ));
+
+/* Stop DMA transfer if still active */
+if (status  BM_STS_ACTIVE) {
+outb(bmdma_base + bmreg_cmd, 0);
+}
+
+free_pci_device(dev);
+
+return status;
+}
+
+static void test_bmdma_simple_rw(void)

[Qemu-devel] [PATCH] PPC: Add 32bit instruction flag

2013-05-08 Thread Alexander Graf
Some instructions behave differently depending on whether the CPU is
64bit capable or not, regardless of the mode the CPU is in.

Add a new instruction flag that indicates that we're running on a CPU
that can not execute 64bit code.

Signed-off-by: Alexander Graf ag...@suse.de
---
 target-ppc/cpu.h|5 ++-
 target-ppc/translate_init.c |   88 +-
 2 files changed, 48 insertions(+), 45 deletions(-)

diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index aa1d013..09a28e1 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -1875,8 +1875,11 @@ enum {
 PPC2_DBRX  = 0x0010ULL,
 /* Book I 2.05 PowerPC specification */
 PPC2_ISA205= 0x0020ULL,
+/* 32bit instructions (!PPC_64B  PPC_INTEGER)  */
+PPC2_32B   = 0x0040ULL,
 
-#define PPC_TCG_INSNS2 (PPC2_BOOKE206 | PPC2_PRCNTL | PPC2_DBRX | PPC2_ISA205)
+#define PPC_TCG_INSNS2 (PPC2_BOOKE206 | PPC2_PRCNTL | PPC2_DBRX | PPC2_ISA205 \
+  | PPC2_32B)
 };
 
 /*/
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 021a31e..dece4c5 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -3147,7 +3147,7 @@ POWERPC_FAMILY(401)(ObjectClass *oc, void *data)
PPC_CACHE_DCBZ |
PPC_MEM_SYNC | PPC_MEM_EIEIO |
PPC_4xx_COMMON | PPC_40x_EXCP;
-pcc-insns_flags2 = PPC_NONE;
+pcc-insns_flags2 = PPC2_32B;
 pcc-msr_mask = 0x000FD201ULL;
 pcc-mmu_model = POWERPC_MMU_REAL;
 pcc-excp_model = POWERPC_EXCP_40x;
@@ -3195,7 +3195,7 @@ POWERPC_FAMILY(401x2)(ObjectClass *oc, void *data)
PPC_MEM_SYNC | PPC_MEM_EIEIO |
PPC_40x_TLB | PPC_MEM_TLBIA | PPC_MEM_TLBSYNC |
PPC_4xx_COMMON | PPC_40x_EXCP;
-pcc-insns_flags2 = PPC_NONE;
+pcc-insns_flags2 = PPC2_32B;
 pcc-msr_mask = 0x001FD231ULL;
 pcc-mmu_model = POWERPC_MMU_SOFT_4xx_Z;
 pcc-excp_model = POWERPC_EXCP_40x;
@@ -3237,7 +3237,7 @@ POWERPC_FAMILY(401x3)(ObjectClass *oc, void *data)
PPC_MEM_SYNC | PPC_MEM_EIEIO |
PPC_40x_TLB | PPC_MEM_TLBIA | PPC_MEM_TLBSYNC |
PPC_4xx_COMMON | PPC_40x_EXCP;
-pcc-insns_flags2 = PPC_NONE;
+pcc-insns_flags2 = PPC2_32B;
 pcc-msr_mask = 0x001FD631ULL;
 pcc-mmu_model = POWERPC_MMU_SOFT_4xx_Z;
 pcc-excp_model = POWERPC_EXCP_40x;
@@ -3285,7 +3285,7 @@ POWERPC_FAMILY(IOP480)(ObjectClass *oc, void *data)
PPC_MEM_SYNC | PPC_MEM_EIEIO |
PPC_40x_TLB | PPC_MEM_TLBIA | PPC_MEM_TLBSYNC |
PPC_4xx_COMMON | PPC_40x_EXCP;
-pcc-insns_flags2 = PPC_NONE;
+pcc-insns_flags2 = PPC2_32B;
 pcc-msr_mask = 0x001FD231ULL;
 pcc-mmu_model = POWERPC_MMU_SOFT_4xx_Z;
 pcc-excp_model = POWERPC_EXCP_40x;
@@ -3325,7 +3325,7 @@ POWERPC_FAMILY(403)(ObjectClass *oc, void *data)
PPC_CACHE_DCBZ |
PPC_MEM_SYNC | PPC_MEM_EIEIO |
PPC_4xx_COMMON | PPC_40x_EXCP;
-pcc-insns_flags2 = PPC_NONE;
+pcc-insns_flags2 = PPC2_32B;
 pcc-msr_mask = 0x0007D00DULL;
 pcc-mmu_model = POWERPC_MMU_REAL;
 pcc-excp_model = POWERPC_EXCP_40x;
@@ -3385,7 +3385,7 @@ POWERPC_FAMILY(403GCX)(ObjectClass *oc, void *data)
PPC_MEM_SYNC | PPC_MEM_EIEIO |
PPC_40x_TLB | PPC_MEM_TLBIA | PPC_MEM_TLBSYNC |
PPC_4xx_COMMON | PPC_40x_EXCP;
-pcc-insns_flags2 = PPC_NONE;
+pcc-insns_flags2 = PPC2_32B;
 pcc-msr_mask = 0x0007D00DULL;
 pcc-mmu_model = POWERPC_MMU_SOFT_4xx_Z;
 pcc-excp_model = POWERPC_EXCP_40x;
@@ -3444,7 +3444,7 @@ POWERPC_FAMILY(405)(ObjectClass *oc, void *data)
PPC_MEM_SYNC | PPC_MEM_EIEIO |
PPC_40x_TLB | PPC_MEM_TLBIA | PPC_MEM_TLBSYNC |
PPC_4xx_COMMON | PPC_405_MAC | PPC_40x_EXCP;
-pcc-insns_flags2 = PPC_NONE;
+pcc-insns_flags2 = PPC2_32B;
 pcc-msr_mask = 0x0006E630ULL;
 pcc-mmu_model = POWERPC_MMU_SOFT_4xx;
 pcc-excp_model = POWERPC_EXCP_40x;
@@ -3538,7 +3538,7 @@ POWERPC_FAMILY(440EP)(ObjectClass *oc, void *data)
PPC_MEM_TLBSYNC | PPC_MFTB |
PPC_BOOKE | PPC_4xx_COMMON | PPC_405_MAC |
PPC_440_SPEC;
-pcc-insns_flags2 = PPC_NONE;
+pcc-insns_flags2 = PPC2_32B;
 pcc-msr_mask = 0x0006FF30ULL;
 pcc-mmu_model = POWERPC_MMU_BOOKE;
 pcc-excp_model = POWERPC_EXCP_BOOKE;
@@ -3611,7 +3611,7 @@ POWERPC_FAMILY(440GP)(ObjectClass *oc, void *data)
PPC_MEM_TLBSYNC 

Re: [Qemu-devel] (i386) TCG is broken in 1.5-rc0 with guest kernel 3.2?

2013-05-08 Thread Richard W.M. Jones
On Wed, May 08, 2013 at 12:22:01PM +0400, Michael Tokarev wrote:
[...]

There is a long term (since 1.4), but different, bug in i386 / tcg
which causes processes to segfault very rarely and randomly.  In fact
it sounds a bit like what you describe here:

 This happened when CarlFK (Cc'd) mentioned that he has issues with
 installing ubuntu precise in a 1.5 virtual machine.  But in his
 case, the prob was different, -- his installer does not configure
 NIC properly due to dhclient segfaulting, which, again, does not
 happen with previous versions of qemu.  This may be related or
 not, I don't know yet.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)



Re: [Qemu-devel] Makefile: Dependency problem

2013-05-08 Thread Paolo Bonzini
Il 08/05/2013 11:00, Kevin Wolf ha scritto:
 Am 08.05.2013 um 10:44 hat Paolo Bonzini geschrieben:

 I just had a failing build like this (make -j3, so these are running in
 parallel):

 lt LINK libcacard.la
 ARlibqemuutil.a
 CCstubs/mon-printf.o
 CCstubs/mon-print-filename.o
 ar: stubs/mon-printf.o: No such file or directory
 make: *** [libcacard.la] Fehler 1
 make: *** Warte auf noch nicht beendete Prozesse...

 Restarting make obviously fixed the problem, but I thought I'd mention it
 here so that the dependencies can be fixed.

 Please try to reproduce it with make V=1.
 
 Doesn't seem to be reproducable now.
 
 Did you have an lt CC  stubs/mon-printf.lo before?
 
 Nope, neither before this, nor during the following make run. So I guess
 it left an old version of it?

Yeah, it's possible that you have the .lo file, but deleted the .o file.
 libtool actually needs both, but the Makefile rule only has the .lo
file (if you try %.lo %.o: %.c, Make starts using libtool to build
everything!).

Paolo

 Would explain why it doesn't reproduce after a make clean.
 
 What version of Make is this?
 
 make-3.82-13.fc18.x86_64
 
 Kevin
 
 




[Qemu-devel] [PATCH 5/5] qtest/ide-test: Test short and long PRDTs

2013-05-08 Thread Kevin Wolf
This tests the behaviour of the DMA engine when the given PRDT contains
physical region descriptors for either more or less bytes than the
IDE request is for.

Signed-off-by: Kevin Wolf kw...@redhat.com
---
 tests/ide-test.c | 54 ++
 1 file changed, 54 insertions(+)

diff --git a/tests/ide-test.c b/tests/ide-test.c
index 5fc496f..bdc1da7 100644
--- a/tests/ide-test.c
+++ b/tests/ide-test.c
@@ -77,6 +77,8 @@ enum {
 CMD_READ_DMA= 0xc8,
 CMD_WRITE_DMA   = 0xca,
 CMD_IDENTIFY= 0xec,
+
+CMDF_ABORT  = 0x100,
 };
 
 enum {
@@ -170,9 +172,13 @@ static int send_dma_request(int cmd, uint64_t sector, int 
nb_sectors,
 size_t len;
 bool from_dev;
 uint8_t status;
+int flags;
 
 dev = get_pci_device(bmdma_base);
 
+flags = cmd  ~0xff;
+cmd = 0xff;
+
 switch (cmd) {
 case CMD_READ_DMA:
 from_dev = true;
@@ -209,6 +215,10 @@ static int send_dma_request(int cmd, uint64_t sector, int 
nb_sectors,
 /* Start DMA transfer */
 outb(bmdma_base + bmreg_cmd, BM_CMD_START | (from_dev ? BM_CMD_WRITE : 0));
 
+if (flags  CMDF_ABORT) {
+outb(bmdma_base + bmreg_cmd, 0);
+}
+
 /* Wait for the DMA transfer to complete */
 do {
 status = inb(bmdma_base + bmreg_status);
@@ -289,6 +299,48 @@ static void test_bmdma_simple_rw(void)
 g_free(cmpbuf);
 }
 
+static void test_bmdma_short_prdt(void)
+{
+uint8_t status;
+
+PrdtEntry prdt[] = {
+{ .addr = 0, .size = 0x10 | PRDT_EOT },
+};
+
+/* Normal request */
+status = send_dma_request(CMD_READ_DMA, 0, 1,
+  prdt, ARRAY_SIZE(prdt));
+g_assert_cmphex(status, ==, 0);
+assert_bit_clear(inb(IDE_BASE + reg_status), DF | ERR);
+
+/* Abort the request before it completes */
+status = send_dma_request(CMD_READ_DMA | CMDF_ABORT, 0, 1,
+  prdt, ARRAY_SIZE(prdt));
+g_assert_cmphex(status, ==, 0);
+assert_bit_clear(inb(IDE_BASE + reg_status), DF | ERR);
+}
+
+static void test_bmdma_long_prdt(void)
+{
+uint8_t status;
+
+PrdtEntry prdt[] = {
+{ .addr = 0, .size = 0x1000 | PRDT_EOT },
+};
+
+/* Normal request */
+status = send_dma_request(CMD_READ_DMA, 0, 1,
+  prdt, ARRAY_SIZE(prdt));
+g_assert_cmphex(status, ==, BM_STS_ACTIVE | BM_STS_INTR);
+assert_bit_clear(inb(IDE_BASE + reg_status), DF | ERR);
+
+/* Abort the request before it completes */
+status = send_dma_request(CMD_READ_DMA | CMDF_ABORT, 0, 1,
+  prdt, ARRAY_SIZE(prdt));
+g_assert_cmphex(status, ==, BM_STS_INTR);
+assert_bit_clear(inb(IDE_BASE + reg_status), DF | ERR);
+}
+
 static void test_bmdma_setup(void)
 {
 ide_test_start(
@@ -375,6 +427,8 @@ int main(int argc, char **argv)
 
 qtest_add_func(/ide/bmdma/setup, test_bmdma_setup);
 qtest_add_func(/ide/bmdma/simple_rw, test_bmdma_simple_rw);
+qtest_add_func(/ide/bmdma/short_prdt, test_bmdma_short_prdt);
+qtest_add_func(/ide/bmdma/long_prdt, test_bmdma_long_prdt);
 qtest_add_func(/ide/bmdma/teardown, test_bmdma_teardown);
 
 ret = g_test_run();
-- 
1.8.1.4




Re: [Qemu-devel] Reporting Heisenbugs in qemu

2013-05-08 Thread Paolo Bonzini

 Paolo Bonzini pbonz...@redhat.com writes:
 
   I guess that's the register windows.  There's only so much you can do to
   optimize them, and heavily recursive workloads (like Perl, or the RTL
   half of GCC) pay a hefty price.
   
 Two qemu targets stand out for slowness, sparc (32 and 64) and mips (64,
 don't know about 32).
 
 x86 (32 and 64), arm, and ppc run with a slowdown of  30 for my bogus
 benchmark of GMP configure+make.
 
 With FreeBSD x86_64 I see a slowdown of just 13.  (My reference system
 runs FreeBSD, so running FreeBSD under qemu is only far.)
 
 My claimed slowdown factors are affected by kernel, libraries, and
 unfortunately very much by gcc speed, which vary with target.
 
 If the sparc emulation speed is due to register windows, then why does
 mips seem just as slow?

No idea. :)  Of all the architectures you listed, MIPS is really the one
that I have no inkling of...

 If register windows shortage is a problem, it should be easy to pretend
 to have lots of them, right?

That can help to avoid trapping to the kernel.  But you still have to
spill the whole window to the stack on every call to a non-leaf function,
which can be expensive even if you do it in the translated code.

Paolo



[Qemu-devel] [PATCH V5 0/5] block: make qmp_transaction extendable

2013-05-08 Thread Wenchao Xia
  This serial will package backing chain snapshot code as one case, to make it
possible adding more operations later.

v2:
  Address Kevin's comments:
  Use the same prototype prepare, commit, rollback model in original code,
commit should never fail.

v3:
  Address Stefan's comments:
  3/5, 4/5: remove *action parameter since later only BlkTransactionStates* is
needed.
  5/5: embbed BlkTransactionStates in ExternalSnapshotStates, *opaque is
removed, related call back function format change for external snapshot.
  Address Kevin's comments:
  removed all indention in commit message.
  1/5: return void for prepare() function, *errp plays the role as error
checker.
  5/5: mark *commit callback must exist, *rollback callback can be NULL. Align
callback = in const BdrvActionOps external_snapshot_ops to the same colum.
  Address Eric's comments:
  1/5: better commit message.
  5/5: better commit message and comments in code that only one of rollback()
or commit() will be called.

v4:
  5/5: document clean() callback will always be called if it present, declare
static for global variable actions, use array plus .instance_size to remove
switch checking code according to caller input.

v5:
  better commit message and comments, switch callback function name rollback
to abort.

Wenchao Xia (5):
  1 block: package preparation code in qmp_transaction()
  2 block: move input parsing code in qmp_transaction()
  3 block: package committing code in qmp_transaction()
  4 block: package rollback code in qmp_transaction()
  5 block: make all steps in qmp_transaction() as callback

 blockdev.c |  266 ++--
 1 files changed, 169 insertions(+), 97 deletions(-)





[Qemu-devel] [PATCH V5 3/5] block: package committing code in qmp_transaction()

2013-05-08 Thread Wenchao Xia
The code is simply moved into a separate function.

Signed-off-by: Wenchao Xia xiaw...@linux.vnet.ibm.com
Reviewed-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
---
 blockdev.c |   19 ---
 1 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 0115f46..76f0532 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -871,6 +871,17 @@ static void external_snapshot_prepare(BlockdevAction 
*action,
 }
 }
 
+static void external_snapshot_commit(BlkTransactionStates *states)
+{
+/* This removes our old bs from the bdrv_states, and adds the new bs */
+bdrv_append(states-new_bs, states-old_bs);
+/* We don't need (or want) to use the transactional
+ * bdrv_reopen_multiple() across all the entries at once, because we
+ * don't want to abort all of them if one of them fails the reopen */
+bdrv_reopen(states-new_bs, states-new_bs-open_flags  ~BDRV_O_RDWR,
+NULL);
+}
+
 /*
  * 'Atomic' group snapshots.  The snapshots are taken as a set, and if any fail
  *  then we do not pivot any of the devices in the group, and abandon the
@@ -916,13 +927,7 @@ void qmp_transaction(BlockdevActionList *dev_list, Error 
**errp)
 /* Now we are going to do the actual pivot.  Everything up to this point
  * is reversible, but we are committed at this point */
 QSIMPLEQ_FOREACH(states, snap_bdrv_states, entry) {
-/* This removes our old bs from the bdrv_states, and adds the new bs */
-bdrv_append(states-new_bs, states-old_bs);
-/* We don't need (or want) to use the transactional
- * bdrv_reopen_multiple() across all the entries at once, because we
- * don't want to abort all of them if one of them fails the reopen */
-bdrv_reopen(states-new_bs, states-new_bs-open_flags  ~BDRV_O_RDWR,
-NULL);
+external_snapshot_commit(states);
 }
 
 /* success */
-- 
1.7.1





[Qemu-devel] [PATCH V5 5/5] block: make all steps in qmp_transaction() as callback

2013-05-08 Thread Wenchao Xia
Make it easier to add other operations to qmp_transaction() by using
callbacks, with external snapshots serving as an example implementation
of the callbacks.

Signed-off-by: Wenchao Xia xiaw...@linux.vnet.ibm.com
Reviewed-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
---
 blockdev.c |   95 ---
 1 files changed, 71 insertions(+), 24 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 2131e13..617501c 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -779,14 +779,43 @@ void qmp_blockdev_snapshot_sync(const char *device, const 
char *snapshot_file,
 
 
 /* New and old BlockDriverState structs for group snapshots */
-typedef struct BlkTransactionStates {
+
+typedef struct BlkTransactionStates BlkTransactionStates;
+
+/* Only prepare() may fail. In a single transaction, only one of commit() or
+   abort() will be called, clean() will always be called if it present. */
+typedef struct BdrvActionOps {
+/* Size of state struct, in bytes. */
+size_t instance_size;
+/* Prepare the work, must NOT be NULL. */
+void (*prepare)(BlkTransactionStates *common, Error **errp);
+/* Commit the changes, must NOT be NULL. */
+void (*commit)(BlkTransactionStates *common);
+/* Abort the changes on fail, can be NULL. */
+void (*abort)(BlkTransactionStates *common);
+/* Clean up resource in the end, can be NULL. */
+void (*clean)(BlkTransactionStates *common);
+} BdrvActionOps;
+
+/*
+ * This structure must be arranged as first member in child type, assuming
+ * that compiler will also arrange it to the same address with parent instance.
+ * Later it will be used in free().
+ */
+struct BlkTransactionStates {
+BlockdevAction *action;
+const BdrvActionOps *ops;
+QSIMPLEQ_ENTRY(BlkTransactionStates) entry;
+};
+
+/* external snapshot private data */
+typedef struct ExternalSnapshotStates {
+BlkTransactionStates common;
 BlockDriverState *old_bs;
 BlockDriverState *new_bs;
-QSIMPLEQ_ENTRY(BlkTransactionStates) entry;
-} BlkTransactionStates;
+} ExternalSnapshotStates;
 
-static void external_snapshot_prepare(BlockdevAction *action,
-  BlkTransactionStates *states,
+static void external_snapshot_prepare(BlkTransactionStates *common,
   Error **errp)
 {
 BlockDriver *proto_drv;
@@ -797,6 +826,9 @@ static void external_snapshot_prepare(BlockdevAction 
*action,
 const char *new_image_file;
 const char *format = qcow2;
 enum NewImageMode mode = NEW_IMAGE_MODE_ABSOLUTE_PATHS;
+ExternalSnapshotStates *states =
+ DO_UPCAST(ExternalSnapshotStates, common, common);
+BlockdevAction *action = common-action;
 
 /* get parameters */
 g_assert(action-kind == BLOCKDEV_ACTION_KIND_BLOCKDEV_SNAPSHOT_SYNC);
@@ -871,8 +903,11 @@ static void external_snapshot_prepare(BlockdevAction 
*action,
 }
 }
 
-static void external_snapshot_commit(BlkTransactionStates *states)
+static void external_snapshot_commit(BlkTransactionStates *common)
 {
+ExternalSnapshotStates *states =
+ DO_UPCAST(ExternalSnapshotStates, common, common);
+
 /* This removes our old bs from the bdrv_states, and adds the new bs */
 bdrv_append(states-new_bs, states-old_bs);
 /* We don't need (or want) to use the transactional
@@ -882,13 +917,24 @@ static void external_snapshot_commit(BlkTransactionStates 
*states)
 NULL);
 }
 
-static void external_snapshot_abort(BlkTransactionStates *states)
+static void external_snapshot_abort(BlkTransactionStates *common)
 {
+ExternalSnapshotStates *states =
+ DO_UPCAST(ExternalSnapshotStates, common, common);
 if (states-new_bs) {
 bdrv_delete(states-new_bs);
 }
 }
 
+static const BdrvActionOps actions[] = {
+[BLOCKDEV_ACTION_KIND_BLOCKDEV_SNAPSHOT_SYNC] = {
+.instance_size = sizeof(ExternalSnapshotStates),
+.prepare  = external_snapshot_prepare,
+.commit   = external_snapshot_commit,
+.abort = external_snapshot_abort,
+},
+};
+
 /*
  * 'Atomic' group snapshots.  The snapshots are taken as a set, and if any fail
  *  then we do not pivot any of the devices in the group, and abandon the
@@ -909,32 +955,28 @@ void qmp_transaction(BlockdevActionList *dev_list, Error 
**errp)
 /* We don't do anything in this loop that commits us to the snapshot */
 while (NULL != dev_entry) {
 BlockdevAction *dev_info = NULL;
+const BdrvActionOps *ops;
 
 dev_info = dev_entry-value;
 dev_entry = dev_entry-next;
 
-states = g_malloc0(sizeof(BlkTransactionStates));
+assert(dev_info-kind  ARRAY_SIZE(actions));
+
+ops = actions[dev_info-kind];
+states = g_malloc0(ops-instance_size);
+states-ops = ops;
+states-action 

[Qemu-devel] [PATCH V5 2/5] block: move input parsing code in qmp_transaction()

2013-05-08 Thread Wenchao Xia
The code is moved into preparation function, and changed
a bit to tip more clearly what it is doing.

Signed-off-by: Wenchao Xia xiaw...@linux.vnet.ibm.com
Reviewed-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
---
 blockdev.c |   38 +++---
 1 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 1cb9640..0115f46 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -785,10 +785,7 @@ typedef struct BlkTransactionStates {
 QSIMPLEQ_ENTRY(BlkTransactionStates) entry;
 } BlkTransactionStates;
 
-static void external_snapshot_prepare(const char *device,
-  const char *format,
-  const char *new_image_file,
-  enum NewImageMode mode,
+static void external_snapshot_prepare(BlockdevAction *action,
   BlkTransactionStates *states,
   Error **errp)
 {
@@ -796,7 +793,24 @@ static void external_snapshot_prepare(const char *device,
 BlockDriver *drv;
 int flags, ret;
 Error *local_err = NULL;
+const char *device;
+const char *new_image_file;
+const char *format = qcow2;
+enum NewImageMode mode = NEW_IMAGE_MODE_ABSOLUTE_PATHS;
 
+/* get parameters */
+g_assert(action-kind == BLOCKDEV_ACTION_KIND_BLOCKDEV_SNAPSHOT_SYNC);
+
+device = action-blockdev_snapshot_sync-device;
+new_image_file = action-blockdev_snapshot_sync-snapshot_file;
+if (action-blockdev_snapshot_sync-has_format) {
+format = action-blockdev_snapshot_sync-format;
+}
+if (action-blockdev_snapshot_sync-has_mode) {
+mode = action-blockdev_snapshot_sync-mode;
+}
+
+/* start processing */
 drv = bdrv_find_format(format);
 if (!drv) {
 error_set(errp, QERR_INVALID_BLOCK_FORMAT, format);
@@ -877,10 +891,6 @@ void qmp_transaction(BlockdevActionList *dev_list, Error 
**errp)
 /* We don't do anything in this loop that commits us to the snapshot */
 while (NULL != dev_entry) {
 BlockdevAction *dev_info = NULL;
-enum NewImageMode mode;
-const char *new_image_file;
-const char *device;
-const char *format = qcow2;
 
 dev_info = dev_entry-value;
 dev_entry = dev_entry-next;
@@ -890,17 +900,7 @@ void qmp_transaction(BlockdevActionList *dev_list, Error 
**errp)
 
 switch (dev_info-kind) {
 case BLOCKDEV_ACTION_KIND_BLOCKDEV_SNAPSHOT_SYNC:
-device = dev_info-blockdev_snapshot_sync-device;
-if (!dev_info-blockdev_snapshot_sync-has_mode) {
-dev_info-blockdev_snapshot_sync-mode = 
NEW_IMAGE_MODE_ABSOLUTE_PATHS;
-}
-new_image_file = dev_info-blockdev_snapshot_sync-snapshot_file;
-if (dev_info-blockdev_snapshot_sync-has_format) {
-format = dev_info-blockdev_snapshot_sync-format;
-}
-mode = dev_info-blockdev_snapshot_sync-mode;
-external_snapshot_prepare(device, format, new_image_file,
-  mode, states, local_err);
+external_snapshot_prepare(dev_info, states, errp);
 if (error_is_set(local_err)) {
 error_propagate(errp, local_err);
 goto delete_and_fail;
-- 
1.7.1





Re: [Qemu-devel] [PATCH RFC 0/3] seabios: move acpi table formatting out of bios

2013-05-08 Thread Michael S. Tsirkin
On Wed, May 08, 2013 at 12:31:50PM +0300, Gleb Natapov wrote:
 On Tue, May 07, 2013 at 07:01:13PM -0400, Kevin O'Connor wrote:
  On Tue, May 07, 2013 at 09:00:48PM +0300, Michael S. Tsirkin wrote:
   On Thu, Apr 25, 2013 at 12:02:20PM +0300, Michael S. Tsirkin wrote:
Untested yet, but I thought I'd share the
BIOS bits so we can agree on direction.

In particular check out ROM sizes:
- Before patchset with DSDT enabled
Total size: 127880  Fixed: 59060  Free: 3192 (used 97.6% of 128KiB 
rom)
- Before patchset with DSDT disabled
Total size: 122844  Fixed: 58884  Free: 8228 (used 93.7% of 128KiB 
rom)
- After patchset:
Total size: 128776  Fixed: 59100  Free: 2296 (used 98.2% of 128KiB 
rom)
- Legacy disabled at build time:
Total size: 119836  Fixed: 58996  Free: 11236 (used 91.4% of 128KiB 
rom)

As can be seen from this, most size savings come
from dropping DSDT, but we do save a bit by removing
other tables. Of course the real reason to move tables to QEMU
is so that ACPI can better match hardware.

This patchset adds an option to move all code for formatting acpi tables
out of BIOS. With this, QEMU has full control over the table layout.
All tables are loaded from the new /etc/acpi/ directory.
Any entries in this directory cause BIOS to disable
ACPI table generation completely.
A generic linker script, controlled by QEMU, is
loaded from /etc/linker-script. It is used to
patch in table pointers and checksums.
   
   After some thought, there are two additional
   options worth considering, in that they simplify
   bios code somewhat:
   
   - bios could get size from qemu, allocate a buffer
 (e.g. could be one buffer for all tables)
 and pass the address to qemu.
 qemu does all the patching
   
   - further, qemu could do the copy of tables into
 that address directly
  
  This seems more complex than necessary to me.
  
  The important task is to get the tables generated in QEMU - I'd focus
  on getting the tables generated in QEMU (one table per fw_cfg file).
  Once that is done, the SeaBIOS side can be easily implemented, and we
  can add any enhancements on top if we feel it is necessary.
  
 +1. This copy of tables into that address directly is just an ad-hoc PV
 isa DMA device in disguise. Such device was refused when libguestfs
 asked for it, and they wanted it for much better reason - performance.
 There is existing mechanism to pass data into firmware. Use it please.

Yes I can code it up using FW_CFG for now.

One issue with QEMU_CFG_FILE_DIR is that it's broken wrt migration,
unless we pass in very small bits of data which we
can guarantee never changes across qemu versions.

Off-list, I suggested fixing it and migrating file
content, but Anthony thinks it's a bad idea.

I don't care much.

 --
   Gleb.



[Qemu-devel] [PATCH V5 4/5] block: package rollback code in qmp_transaction()

2013-05-08 Thread Wenchao Xia
Signed-off-by: Wenchao Xia xiaw...@linux.vnet.ibm.com
Reviewed-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
---
 blockdev.c |   11 ---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 76f0532..2131e13 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -882,6 +882,13 @@ static void external_snapshot_commit(BlkTransactionStates 
*states)
 NULL);
 }
 
+static void external_snapshot_abort(BlkTransactionStates *states)
+{
+if (states-new_bs) {
+bdrv_delete(states-new_bs);
+}
+}
+
 /*
  * 'Atomic' group snapshots.  The snapshots are taken as a set, and if any fail
  *  then we do not pivot any of the devices in the group, and abandon the
@@ -939,9 +946,7 @@ delete_and_fail:
 * the original bs for all images
 */
 QSIMPLEQ_FOREACH(states, snap_bdrv_states, entry) {
-if (states-new_bs) {
- bdrv_delete(states-new_bs);
-}
+external_snapshot_abort(states);
 }
 exit:
 QSIMPLEQ_FOREACH_SAFE(states, snap_bdrv_states, entry, next) {
-- 
1.7.1





Re: [Qemu-devel] [PATCH] PPC: Introduce 32bit only cmp ops

2013-05-08 Thread Aurelien Jarno
On Wed, May 08, 2013 at 12:06:52PM +0200, Alexander Graf wrote:
 When running a 32bit target CPU with qemu-(system-)-ppc, NARROW_MODE
 is not set, so we never get to leverage the 32bit only code path in
 the compare op handlers.
 
 Introduce new handlers based on the 32bit only flag. That way we can
 have 2 separate functions for 32bit mode and 64bit mode, which can
 handle NARROW_MODE.
 
 Reported-by: Torbjorn Granlund t...@gmplib.org
 Signed-off-by: Alexander Graf ag...@suse.de
 ---
  target-ppc/translate.c |   48 
 
  1 files changed, 40 insertions(+), 8 deletions(-)
 
 diff --git a/target-ppc/translate.c b/target-ppc/translate.c
 index a018616..002f9ae 100644
 --- a/target-ppc/translate.c
 +++ b/target-ppc/translate.c
 @@ -675,7 +675,7 @@ static inline void gen_set_Rc0(DisasContext *ctx, TCGv 
 reg)
  /* cmp */
  static void gen_cmp(DisasContext *ctx)
  {
 -if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
 +if (!(ctx-opcode  0x0020)) {
  gen_op_cmp32(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
   1, crfD(ctx-opcode));
  } else {
 @@ -684,10 +684,17 @@ static void gen_cmp(DisasContext *ctx)
  }
  }
  
 +/* cmp 32bit only */
 +static void gen_cmp32(DisasContext *ctx)
 +{
 +gen_op_cmp32(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
 + 1, crfD(ctx-opcode));
 +}
 +
  /* cmpi */
  static void gen_cmpi(DisasContext *ctx)
  {
 -if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
 +if (!(ctx-opcode  0x0020)) {
  gen_op_cmpi32(cpu_gpr[rA(ctx-opcode)], SIMM(ctx-opcode),
1, crfD(ctx-opcode));
  } else {
 @@ -696,10 +703,17 @@ static void gen_cmpi(DisasContext *ctx)
  }
  }
  
 +/* cmpi 32bit only */
 +static void gen_cmpi32(DisasContext *ctx)
 +{
 +gen_op_cmpi32(cpu_gpr[rA(ctx-opcode)], SIMM(ctx-opcode),
 +  1, crfD(ctx-opcode));
 +}
 +
  /* cmpl */
  static void gen_cmpl(DisasContext *ctx)
  {
 -if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
 +if (!(ctx-opcode  0x0020)) {
  gen_op_cmp32(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
   0, crfD(ctx-opcode));
  } else {
 @@ -708,10 +722,17 @@ static void gen_cmpl(DisasContext *ctx)
  }
  }
  
 +/* cmpl 32bit only */
 +static void gen_cmpl32(DisasContext *ctx)
 +{
 +gen_op_cmp32(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
 + 0, crfD(ctx-opcode));
 +}
 +
  /* cmpli */
  static void gen_cmpli(DisasContext *ctx)
  {
 -if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
 +if (!(ctx-opcode  0x0020)) {
  gen_op_cmpi32(cpu_gpr[rA(ctx-opcode)], UIMM(ctx-opcode),
0, crfD(ctx-opcode));
  } else {
 @@ -720,6 +741,13 @@ static void gen_cmpli(DisasContext *ctx)
  }
  }
  
 +/* cmpli 32bit only */
 +static void gen_cmpli32(DisasContext *ctx)
 +{
 +gen_op_cmpi32(cpu_gpr[rA(ctx-opcode)], UIMM(ctx-opcode),
 +  0, crfD(ctx-opcode));
 +}
 +
  /* isel (PowerPC 2.03 specification) */
  static void gen_isel(DisasContext *ctx)
  {
 @@ -8638,10 +8666,14 @@ GEN_SPE(efdtsteq,  speundef,  0x1F, 0x0B, 0x0060, 
 0x, PPC_SPE_DOUBLE
  
  static opcode_t opcodes[] = {
  GEN_HANDLER(invalid, 0x00, 0x00, 0x00, 0x, PPC_NONE),
 -GEN_HANDLER(cmp, 0x1F, 0x00, 0x00, 0x0040, PPC_INTEGER),
 -GEN_HANDLER(cmpi, 0x0B, 0xFF, 0xFF, 0x0040, PPC_INTEGER),
 -GEN_HANDLER(cmpl, 0x1F, 0x00, 0x01, 0x0040, PPC_INTEGER),
 -GEN_HANDLER(cmpli, 0x0A, 0xFF, 0xFF, 0x0040, PPC_INTEGER),
 +GEN_HANDLER(cmp, 0x1F, 0x00, 0x00, 0x0040, PPC_64B),
 +GEN_HANDLER_E(cmp32, 0x1F, 0x00, 0x00, 0x0040, PPC_NONE, PPC2_32B),

You have to declare the L bit as invalid, so that trying to execute a
64-bit cmp* instruction on a 32-bit CPU causes an invalid instruction
exception.

 +GEN_HANDLER(cmpi, 0x0B, 0xFF, 0xFF, 0x0040, PPC_64B),
 +GEN_HANDLER_E(cmpi32, 0x0B, 0xFF, 0xFF, 0x0040, PPC_NONE, PPC2_32B),
 +GEN_HANDLER(cmpl, 0x1F, 0x00, 0x01, 0x0040, PPC_64B),
 +GEN_HANDLER_E(cmpl32, 0x1F, 0x00, 0x01, 0x0040, PPC_NONE, PPC2_32B),
 +GEN_HANDLER(cmpli, 0x0A, 0xFF, 0xFF, 0x0040, PPC_64B),
 +GEN_HANDLER_E(cmpli32, 0x0A, 0xFF, 0xFF, 0x0040, PPC_NONE, PPC2_32B),
  GEN_HANDLER_E(cmpb, 0x1F, 0x1C, 0x0F, 0x0001, PPC_NONE, PPC2_ISA205),
  GEN_HANDLER(isel, 0x1F, 0x0F, 0xFF, 0x0001, PPC_ISEL),
  GEN_HANDLER(addi, 0x0E, 0xFF, 0xFF, 0x, PPC_INTEGER),
 -- 
 1.6.0.2
 
 
 

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net



[Qemu-devel] [PATCH] linux-user: handle /proc/$$ like /proc/self

2013-05-08 Thread Andreas Schwab
Some applications use /proc/$$/... (where $$ is the own pid) instead of
/proc/self/... to refer to their own proc files.  Extend the interception
for open and readlink to handle this case.  Also, do the same interception
in readlinkat.

Signed-off-by: Andreas Schwab sch...@suse.de
---
 linux-user/syscall.c | 63 +---
 1 file changed, 45 insertions(+), 18 deletions(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 84dfbf5..d5db6bf 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -5157,6 +5157,30 @@ static int open_self_auxv(void *cpu_env, int fd)
 return 0;
 }
 
+static int is_proc_myself(const char *filename, const char *entry)
+{
+if (!strncmp(filename, /proc/, strlen(/proc/))) {
+filename += strlen(/proc/);
+if (!strncmp(filename, self/, strlen(self/))) {
+filename += strlen(self/);
+} else if (*filename = '1'  *filename = '9') {
+char myself[80];
+snprintf(myself, sizeof(myself), %d/, getpid());
+if (!strncmp(filename, myself, strlen(myself))) {
+filename += strlen(myself);
+} else {
+return 0;
+}
+} else {
+return 0;
+}
+if (!strcmp(filename, entry)) {
+return 1;
+}
+}
+return 0;
+}
+
 static int do_open(void *cpu_env, const char *pathname, int flags, mode_t mode)
 {
 struct fake_open {
@@ -5165,15 +5189,14 @@ static int do_open(void *cpu_env, const char *pathname, 
int flags, mode_t mode)
 };
 const struct fake_open *fake_open;
 static const struct fake_open fakes[] = {
-{ /proc/self/maps, open_self_maps },
-{ /proc/self/stat, open_self_stat },
-{ /proc/self/auxv, open_self_auxv },
+{ maps, open_self_maps },
+{ stat, open_self_stat },
+{ auxv, open_self_auxv },
 { NULL, NULL }
 };
 
 for (fake_open = fakes; fake_open-filename; fake_open++) {
-if (!strncmp(pathname, fake_open-filename,
- strlen(fake_open-filename))) {
+if (is_proc_myself(pathname, fake_open-filename)) {
 break;
 }
 }
@@ -6468,20 +6491,18 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
arg1,
 #endif
 case TARGET_NR_readlink:
 {
-void *p2, *temp;
+void *p2;
 p = lock_user_string(arg1);
 p2 = lock_user(VERIFY_WRITE, arg2, arg3, 0);
-if (!p || !p2)
+if (!p || !p2) {
 ret = -TARGET_EFAULT;
-else {
-if (strncmp((const char *)p, /proc/self/exe, 14) == 0) {
-char real[PATH_MAX];
-temp = realpath(exec_path,real);
-ret = (temp==NULL) ? get_errno(-1) : strlen(real) ;
-snprintf((char *)p2, arg3, %s, real);
-}
-else
-ret = get_errno(readlink(path(p), p2, arg3));
+} else if (is_proc_myself((const char *)p, exe)) {
+char real[PATH_MAX], *temp;
+temp = realpath(exec_path, real);
+ret = temp == NULL ? get_errno(-1) : strlen(real) ;
+snprintf((char *)p2, arg3, %s, real);
+} else {
+ret = get_errno(readlink(path(p), p2, arg3));
 }
 unlock_user(p2, arg2, ret);
 unlock_user(p, arg1, 0);
@@ -6493,10 +6514,16 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
arg1,
 void *p2;
 p  = lock_user_string(arg2);
 p2 = lock_user(VERIFY_WRITE, arg3, arg4, 0);
-if (!p || !p2)
+if (!p || !p2) {
ret = -TARGET_EFAULT;
-else
+} else if (is_proc_myself((const char *)p, exe)) {
+char real[PATH_MAX], *temp;
+temp = realpath(exec_path, real);
+ret = temp == NULL ? get_errno(-1) : strlen(real) ;
+snprintf((char *)p2, arg4, %s, real);
+} else {
 ret = get_errno(sys_readlinkat(arg1, path(p), p2, arg4));
+}
 unlock_user(p2, arg3, ret);
 unlock_user(p, arg2, 0);
 }
-- 
1.8.2.2

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
And now for something completely different.



Re: [Qemu-devel] [PATCH] PPC: Introduce 32bit only cmp ops

2013-05-08 Thread Alexander Graf

On 08.05.2013, at 12:29, Aurelien Jarno wrote:

 On Wed, May 08, 2013 at 12:06:52PM +0200, Alexander Graf wrote:
 When running a 32bit target CPU with qemu-(system-)-ppc, NARROW_MODE
 is not set, so we never get to leverage the 32bit only code path in
 the compare op handlers.
 
 Introduce new handlers based on the 32bit only flag. That way we can
 have 2 separate functions for 32bit mode and 64bit mode, which can
 handle NARROW_MODE.
 
 Reported-by: Torbjorn Granlund t...@gmplib.org
 Signed-off-by: Alexander Graf ag...@suse.de
 ---
 target-ppc/translate.c |   48 
 
 1 files changed, 40 insertions(+), 8 deletions(-)
 
 diff --git a/target-ppc/translate.c b/target-ppc/translate.c
 index a018616..002f9ae 100644
 --- a/target-ppc/translate.c
 +++ b/target-ppc/translate.c
 @@ -675,7 +675,7 @@ static inline void gen_set_Rc0(DisasContext *ctx, TCGv 
 reg)
 /* cmp */
 static void gen_cmp(DisasContext *ctx)
 {
 -if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
 +if (!(ctx-opcode  0x0020)) {
 gen_op_cmp32(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
  1, crfD(ctx-opcode));
 } else {
 @@ -684,10 +684,17 @@ static void gen_cmp(DisasContext *ctx)
 }
 }
 
 +/* cmp 32bit only */
 +static void gen_cmp32(DisasContext *ctx)
 +{
 +gen_op_cmp32(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
 + 1, crfD(ctx-opcode));
 +}
 +
 /* cmpi */
 static void gen_cmpi(DisasContext *ctx)
 {
 -if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
 +if (!(ctx-opcode  0x0020)) {
 gen_op_cmpi32(cpu_gpr[rA(ctx-opcode)], SIMM(ctx-opcode),
   1, crfD(ctx-opcode));
 } else {
 @@ -696,10 +703,17 @@ static void gen_cmpi(DisasContext *ctx)
 }
 }
 
 +/* cmpi 32bit only */
 +static void gen_cmpi32(DisasContext *ctx)
 +{
 +gen_op_cmpi32(cpu_gpr[rA(ctx-opcode)], SIMM(ctx-opcode),
 +  1, crfD(ctx-opcode));
 +}
 +
 /* cmpl */
 static void gen_cmpl(DisasContext *ctx)
 {
 -if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
 +if (!(ctx-opcode  0x0020)) {
 gen_op_cmp32(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
  0, crfD(ctx-opcode));
 } else {
 @@ -708,10 +722,17 @@ static void gen_cmpl(DisasContext *ctx)
 }
 }
 
 +/* cmpl 32bit only */
 +static void gen_cmpl32(DisasContext *ctx)
 +{
 +gen_op_cmp32(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
 + 0, crfD(ctx-opcode));
 +}
 +
 /* cmpli */
 static void gen_cmpli(DisasContext *ctx)
 {
 -if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
 +if (!(ctx-opcode  0x0020)) {
 gen_op_cmpi32(cpu_gpr[rA(ctx-opcode)], UIMM(ctx-opcode),
   0, crfD(ctx-opcode));
 } else {
 @@ -720,6 +741,13 @@ static void gen_cmpli(DisasContext *ctx)
 }
 }
 
 +/* cmpli 32bit only */
 +static void gen_cmpli32(DisasContext *ctx)
 +{
 +gen_op_cmpi32(cpu_gpr[rA(ctx-opcode)], UIMM(ctx-opcode),
 +  0, crfD(ctx-opcode));
 +}
 +
 /* isel (PowerPC 2.03 specification) */
 static void gen_isel(DisasContext *ctx)
 {
 @@ -8638,10 +8666,14 @@ GEN_SPE(efdtsteq,  speundef,  0x1F, 0x0B, 
 0x0060, 0x, PPC_SPE_DOUBLE
 
 static opcode_t opcodes[] = {
 GEN_HANDLER(invalid, 0x00, 0x00, 0x00, 0x, PPC_NONE),
 -GEN_HANDLER(cmp, 0x1F, 0x00, 0x00, 0x0040, PPC_INTEGER),
 -GEN_HANDLER(cmpi, 0x0B, 0xFF, 0xFF, 0x0040, PPC_INTEGER),
 -GEN_HANDLER(cmpl, 0x1F, 0x00, 0x01, 0x0040, PPC_INTEGER),
 -GEN_HANDLER(cmpli, 0x0A, 0xFF, 0xFF, 0x0040, PPC_INTEGER),
 +GEN_HANDLER(cmp, 0x1F, 0x00, 0x00, 0x0040, PPC_64B),
 +GEN_HANDLER_E(cmp32, 0x1F, 0x00, 0x00, 0x0040, PPC_NONE, PPC2_32B),
 
 You have to declare the L bit as invalid, so that trying to execute a
 64-bit cmp* instruction on a 32-bit CPU causes an invalid instruction
 exception.

You're right. I wanted to verify it against a real 32bit system first. It does 
indeed treat the L bit as reserved. Then we can simply remove the 32bit only 
variant handlers and only use the opcode table for the reserved bits.


Alex




Re: [Qemu-devel] [PATCH] PPC: Introduce 32bit only cmp ops

2013-05-08 Thread Torbjorn Granlund
Aurelien Jarno aurel...@aurel32.net writes:

  You have to declare the L bit as invalid, so that trying to execute a
  64-bit cmp* instruction on a 32-bit CPU causes an invalid instruction
  exception.
  
Don't people read what I write?

I give up.

Goodbye.

-- 
Torbjörn



Re: [Qemu-devel] [PATCH RFC 0/3] seabios: move acpi table formatting out of bios

2013-05-08 Thread Gleb Natapov
On Wed, May 08, 2013 at 01:29:12PM +0300, Michael S. Tsirkin wrote:
 On Wed, May 08, 2013 at 12:31:50PM +0300, Gleb Natapov wrote:
  On Tue, May 07, 2013 at 07:01:13PM -0400, Kevin O'Connor wrote:
   On Tue, May 07, 2013 at 09:00:48PM +0300, Michael S. Tsirkin wrote:
On Thu, Apr 25, 2013 at 12:02:20PM +0300, Michael S. Tsirkin wrote:
 Untested yet, but I thought I'd share the
 BIOS bits so we can agree on direction.
 
 In particular check out ROM sizes:
 - Before patchset with DSDT enabled
 Total size: 127880  Fixed: 59060  Free: 3192 (used 97.6% of 
 128KiB rom)
 - Before patchset with DSDT disabled
 Total size: 122844  Fixed: 58884  Free: 8228 (used 93.7% of 
 128KiB rom)
 - After patchset:
 Total size: 128776  Fixed: 59100  Free: 2296 (used 98.2% of 
 128KiB rom)
 - Legacy disabled at build time:
 Total size: 119836  Fixed: 58996  Free: 11236 (used 91.4% of 
 128KiB rom)
 
 As can be seen from this, most size savings come
 from dropping DSDT, but we do save a bit by removing
 other tables. Of course the real reason to move tables to QEMU
 is so that ACPI can better match hardware.
 
 This patchset adds an option to move all code for formatting acpi 
 tables
 out of BIOS. With this, QEMU has full control over the table layout.
 All tables are loaded from the new /etc/acpi/ directory.
 Any entries in this directory cause BIOS to disable
 ACPI table generation completely.
 A generic linker script, controlled by QEMU, is
 loaded from /etc/linker-script. It is used to
 patch in table pointers and checksums.

After some thought, there are two additional
options worth considering, in that they simplify
bios code somewhat:

- bios could get size from qemu, allocate a buffer
  (e.g. could be one buffer for all tables)
  and pass the address to qemu.
  qemu does all the patching

- further, qemu could do the copy of tables into
  that address directly
   
   This seems more complex than necessary to me.
   
   The important task is to get the tables generated in QEMU - I'd focus
   on getting the tables generated in QEMU (one table per fw_cfg file).
   Once that is done, the SeaBIOS side can be easily implemented, and we
   can add any enhancements on top if we feel it is necessary.
   
  +1. This copy of tables into that address directly is just an ad-hoc PV
  isa DMA device in disguise. Such device was refused when libguestfs
  asked for it, and they wanted it for much better reason - performance.
  There is existing mechanism to pass data into firmware. Use it please.
 
 Yes I can code it up using FW_CFG for now.
 
 One issue with QEMU_CFG_FILE_DIR is that it's broken wrt migration,
 unless we pass in very small bits of data which we
 can guarantee never changes across qemu versions.
 
Shouldn't we guaranty that ACPI tables do not change for the same
machine type anyway?

 Off-list, I suggested fixing it and migrating file
 content, but Anthony thinks it's a bad idea.
 
Why is this a bad idea to fix device migration?

 I don't care much.
 
  --
  Gleb.

--
Gleb.



Re: [Qemu-devel] Reporting Heisenbugs in qemu

2013-05-08 Thread Aurelien Jarno
On Wed, May 08, 2013 at 11:45:45AM +0200, Torbjorn Granlund wrote:
 Paolo Bonzini pbonz...@redhat.com writes:
 
   I guess that's the register windows.  There's only so much you can do to
   optimize them, and heavily recursive workloads (like Perl, or the RTL
   half of GCC) pay a hefty price.
   
 Two qemu targets stand out for slowness, sparc (32 and 64) and mips (64,
 don't know about 32).
 
 x86 (32 and 64), arm, and ppc run with a slowdown of  30 for my bogus
 benchmark of GMP configure+make.
 
 With FreeBSD x86_64 I see a slowdown of just 13.  (My reference system
 runs FreeBSD, so running FreeBSD under qemu is only far.)
 
 My claimed slowdown factors are affected by kernel, libraries, and
 unfortunately very much by gcc speed, which vary with target.
 
 If the sparc emulation speed is due to register windows, then why does
 mips seem just as slow?

I guess it's related to your benchmark, as it is not something really
observed (though not scientifically) on other loads. How much memory do
you need for it, couldn't it be that building GMP needs more than 256MB
of RAM at some point and that the system starts swapping?

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net



Re: [Qemu-devel] [PATCH] PPC: Introduce 32bit only cmp ops

2013-05-08 Thread Alexander Graf

On 08.05.2013, at 12:34, Torbjorn Granlund wrote:

 Aurelien Jarno aurel...@aurel32.net writes:
 
  You have to declare the L bit as invalid, so that trying to execute a
  64-bit cmp* instruction on a 32-bit CPU causes an invalid instruction
  exception.
 
 Don't people read what I write?

At least on my e500mc machine I happen to have handy, the following instruction 
gives me an illegal instruction exception:

  1320: 2f a0 00 00 cmpicr7,1,r0,0

So for 32bit CPU types we have to mark the L bit invalid which means we always 
get into the branches that take us to cmp32. For 64bit capable CPUs we 
obviously want to honor the L bit even when running in 32bit mode (MSR.SF=0), 
as that's what real CPUs do.


Alex




Re: [Qemu-devel] [Qemu-ppc] QEMU powerpc embedded architecture base address problem

2013-05-08 Thread Alexander Graf

On 08.05.2013, at 12:34, 李思嘉 wrote:

 Hi,
 
 I am a new QEMU user who is developing a new low cost embedded system. 
 Recently I was implementing NE2000 network card driver for the QEMU. The 
 running configuration is sudo qemu-system-ppcemb -S -gdb tcp:: -L 
 orcos/tools/BootRomFile -nographic -M taihu

Please note that the taihu target is basically unmaintained.

 -cpu 401100c4 -kernel 
 orcos/configurations/qemu/newlib/output/orcos_kernel_and_tasks.bin 
 orcos/configurations/qemu/newlib/output/empty.bin -monitor 
 telnet:127.0.0.1:5524,server,nowait. The embedded system can't detect the 
 base address automatically since the embedded system is not very mature. The 
 only way is to set the base address manually. Is there any ways I can get the 
 base address of all devices in the virtual machine?

Sure! You can go to the QEMU monitor and call info mtree to see the internal 
memory maps as well as info qtree to receive a list of devices attached to 
the virtual system.

 BTW,Right now, I'm trying to use QEMU 0.14.0 instead of QEMU 0.9.1 because 
 0.9.1 is very old. In 0.9.1, the console can output the information  
 correctly. I noticed the serial part has been changed to some new hardware 
 which makes the serial not working any more. And I also have the new serial 
 driver. But the problem is also as the same as before. I need the base 
 address of serial. 
 
 Is anyone familiar with this problem?

It doesn't sound at all familiar to me, but then again taihu really is not an 
actively maintained target which means there is a certain likelyhood it breaks.


Alex



Re: [Qemu-devel] [PATCH RFC 0/3] seabios: move acpi table formatting out of bios

2013-05-08 Thread Michael S. Tsirkin
On Wed, May 08, 2013 at 01:34:59PM +0300, Gleb Natapov wrote:
 On Wed, May 08, 2013 at 01:29:12PM +0300, Michael S. Tsirkin wrote:
  On Wed, May 08, 2013 at 12:31:50PM +0300, Gleb Natapov wrote:
   On Tue, May 07, 2013 at 07:01:13PM -0400, Kevin O'Connor wrote:
On Tue, May 07, 2013 at 09:00:48PM +0300, Michael S. Tsirkin wrote:
 On Thu, Apr 25, 2013 at 12:02:20PM +0300, Michael S. Tsirkin wrote:
  Untested yet, but I thought I'd share the
  BIOS bits so we can agree on direction.
  
  In particular check out ROM sizes:
  - Before patchset with DSDT enabled
  Total size: 127880  Fixed: 59060  Free: 3192 (used 97.6% of 
  128KiB rom)
  - Before patchset with DSDT disabled
  Total size: 122844  Fixed: 58884  Free: 8228 (used 93.7% of 
  128KiB rom)
  - After patchset:
  Total size: 128776  Fixed: 59100  Free: 2296 (used 98.2% of 
  128KiB rom)
  - Legacy disabled at build time:
  Total size: 119836  Fixed: 58996  Free: 11236 (used 91.4% of 
  128KiB rom)
  
  As can be seen from this, most size savings come
  from dropping DSDT, but we do save a bit by removing
  other tables. Of course the real reason to move tables to QEMU
  is so that ACPI can better match hardware.
  
  This patchset adds an option to move all code for formatting acpi 
  tables
  out of BIOS. With this, QEMU has full control over the table layout.
  All tables are loaded from the new /etc/acpi/ directory.
  Any entries in this directory cause BIOS to disable
  ACPI table generation completely.
  A generic linker script, controlled by QEMU, is
  loaded from /etc/linker-script. It is used to
  patch in table pointers and checksums.
 
 After some thought, there are two additional
 options worth considering, in that they simplify
 bios code somewhat:
 
 - bios could get size from qemu, allocate a buffer
   (e.g. could be one buffer for all tables)
   and pass the address to qemu.
   qemu does all the patching
 
 - further, qemu could do the copy of tables into
   that address directly

This seems more complex than necessary to me.

The important task is to get the tables generated in QEMU - I'd focus
on getting the tables generated in QEMU (one table per fw_cfg file).
Once that is done, the SeaBIOS side can be easily implemented, and we
can add any enhancements on top if we feel it is necessary.

   +1. This copy of tables into that address directly is just an ad-hoc PV
   isa DMA device in disguise. Such device was refused when libguestfs
   asked for it, and they wanted it for much better reason - performance.
   There is existing mechanism to pass data into firmware. Use it please.
  
  Yes I can code it up using FW_CFG for now.
  
  One issue with QEMU_CFG_FILE_DIR is that it's broken wrt migration,
  unless we pass in very small bits of data which we
  can guarantee never changes across qemu versions.
  
 Shouldn't we guaranty that ACPI tables do not change for the same
 machine type anyway?

That's not practical. They are too big to stay completely unchanged.

  Off-list, I suggested fixing it and migrating file
  content, but Anthony thinks it's a bad idea.
  
 Why is this a bad idea to fix device migration?

You misunderstand I think.
Question is whether we should be putting so much info in fw_cfg.
If we keep fw_cfg for small things we don't need to
migrate it. In that case ACPI tables have to be passed in
using some other mechanism.

  I don't care much.
  
   --
 Gleb.
 
 --
   Gleb.



Re: [Qemu-devel] [Qemu-ppc] Incorrect handling of more PPC64 insns (PATCH)

2013-05-08 Thread Alexander Graf

On 08.05.2013, at 12:07, Torbjorn Granlund wrote:

 Alexander Graf ag...@suse.de writes:
 
  Ok, so the real problem here is that NARROW_MODE is not set, but is
  used to differentiate whether to use the 32bit cmp only or not.
 
 Eh?
 
  Richard, there are 2 ways out of this:
 
1) get rid of NARROW_MODE and always check ctx-sf
 
 No!
 
 The cmp insn with L set should NOT be affected by SF.  That's the entire
 point of my change.

You're right. I got confused there :).

 
 I reviewed the other uses of NARROW_MODE and didn't spot any errors.
 (But I must confess that I would need to red the PPC manuals better inn
 order to tell for sure.)
 
2) add a new 32bit only insns flag and create separate functions for 32bit 
 cmp calls
 
 Aurelien's patch looked promising, if one removes the exception casting.

His exception casting is actually correct. You can use qemu-(system-)ppc64, but 
run it with a CPU definition that is 32bit only, like a G3. These old CPUs did 
not know the instruction with L yet, so they do throw an illegal instruction 
exception, which we have to model.


Alex




[Qemu-devel] [PATCH V5 1/5] block: package preparation code in qmp_transaction()

2013-05-08 Thread Wenchao Xia
The code before really committing is moved into a function. Most
code is simply moved from qmp_transaction(), except that on fail it
just returns now. Other code such as input parsing is not touched,
to make it easier in review.

Signed-off-by: Wenchao Xia xiaw...@linux.vnet.ibm.com
Reviewed-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
---
 blockdev.c |  139 +---
 1 files changed, 77 insertions(+), 62 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 7c9d8dd..1cb9640 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -785,6 +785,78 @@ typedef struct BlkTransactionStates {
 QSIMPLEQ_ENTRY(BlkTransactionStates) entry;
 } BlkTransactionStates;
 
+static void external_snapshot_prepare(const char *device,
+  const char *format,
+  const char *new_image_file,
+  enum NewImageMode mode,
+  BlkTransactionStates *states,
+  Error **errp)
+{
+BlockDriver *proto_drv;
+BlockDriver *drv;
+int flags, ret;
+Error *local_err = NULL;
+
+drv = bdrv_find_format(format);
+if (!drv) {
+error_set(errp, QERR_INVALID_BLOCK_FORMAT, format);
+return;
+}
+
+states-old_bs = bdrv_find(device);
+if (!states-old_bs) {
+error_set(errp, QERR_DEVICE_NOT_FOUND, device);
+return;
+}
+
+if (!bdrv_is_inserted(states-old_bs)) {
+error_set(errp, QERR_DEVICE_HAS_NO_MEDIUM, device);
+return;
+}
+
+if (bdrv_in_use(states-old_bs)) {
+error_set(errp, QERR_DEVICE_IN_USE, device);
+return;
+}
+
+if (!bdrv_is_read_only(states-old_bs)) {
+if (bdrv_flush(states-old_bs)) {
+error_set(errp, QERR_IO_ERROR);
+return;
+}
+}
+
+flags = states-old_bs-open_flags;
+
+proto_drv = bdrv_find_protocol(new_image_file);
+if (!proto_drv) {
+error_set(errp, QERR_INVALID_BLOCK_FORMAT, format);
+return;
+}
+
+/* create new image w/backing file */
+if (mode != NEW_IMAGE_MODE_EXISTING) {
+bdrv_img_create(new_image_file, format,
+states-old_bs-filename,
+states-old_bs-drv-format_name,
+NULL, -1, flags, local_err, false);
+if (error_is_set(local_err)) {
+error_propagate(errp, local_err);
+return;
+}
+}
+
+/* We will manually add the backing_hd field to the bs later */
+states-new_bs = bdrv_new();
+/* TODO Inherit bs-options or only take explicit options with an
+ * extended QMP command? */
+ret = bdrv_open(states-new_bs, new_image_file, NULL,
+flags | BDRV_O_NO_BACKING, drv);
+if (ret != 0) {
+error_set(errp, QERR_OPEN_FILE_FAILED, new_image_file);
+}
+}
+
 /*
  * 'Atomic' group snapshots.  The snapshots are taken as a set, and if any fail
  *  then we do not pivot any of the devices in the group, and abandon the
@@ -792,7 +864,6 @@ typedef struct BlkTransactionStates {
  */
 void qmp_transaction(BlockdevActionList *dev_list, Error **errp)
 {
-int ret = 0;
 BlockdevActionList *dev_entry = dev_list;
 BlkTransactionStates *states, *next;
 Error *local_err = NULL;
@@ -806,9 +877,6 @@ void qmp_transaction(BlockdevActionList *dev_list, Error 
**errp)
 /* We don't do anything in this loop that commits us to the snapshot */
 while (NULL != dev_entry) {
 BlockdevAction *dev_info = NULL;
-BlockDriver *proto_drv;
-BlockDriver *drv;
-int flags;
 enum NewImageMode mode;
 const char *new_image_file;
 const char *device;
@@ -831,70 +899,17 @@ void qmp_transaction(BlockdevActionList *dev_list, Error 
**errp)
 format = dev_info-blockdev_snapshot_sync-format;
 }
 mode = dev_info-blockdev_snapshot_sync-mode;
-break;
-default:
-abort();
-}
-
-drv = bdrv_find_format(format);
-if (!drv) {
-error_set(errp, QERR_INVALID_BLOCK_FORMAT, format);
-goto delete_and_fail;
-}
-
-states-old_bs = bdrv_find(device);
-if (!states-old_bs) {
-error_set(errp, QERR_DEVICE_NOT_FOUND, device);
-goto delete_and_fail;
-}
-
-if (!bdrv_is_inserted(states-old_bs)) {
-error_set(errp, QERR_DEVICE_HAS_NO_MEDIUM, device);
-goto delete_and_fail;
-}
-
-if (bdrv_in_use(states-old_bs)) {
-error_set(errp, QERR_DEVICE_IN_USE, device);
-goto delete_and_fail;
-}
-
-if (!bdrv_is_read_only(states-old_bs)) {
-if (bdrv_flush(states-old_bs)) {
-error_set(errp, QERR_IO_ERROR);
- 

Re: [Qemu-devel] [PATCH RFC 0/3] seabios: move acpi table formatting out of bios

2013-05-08 Thread Gleb Natapov
On Wed, May 08, 2013 at 01:43:25PM +0300, Michael S. Tsirkin wrote:
 On Wed, May 08, 2013 at 01:34:59PM +0300, Gleb Natapov wrote:
  On Wed, May 08, 2013 at 01:29:12PM +0300, Michael S. Tsirkin wrote:
   On Wed, May 08, 2013 at 12:31:50PM +0300, Gleb Natapov wrote:
On Tue, May 07, 2013 at 07:01:13PM -0400, Kevin O'Connor wrote:
 On Tue, May 07, 2013 at 09:00:48PM +0300, Michael S. Tsirkin wrote:
  On Thu, Apr 25, 2013 at 12:02:20PM +0300, Michael S. Tsirkin wrote:
   Untested yet, but I thought I'd share the
   BIOS bits so we can agree on direction.
   
   In particular check out ROM sizes:
   - Before patchset with DSDT enabled
   Total size: 127880  Fixed: 59060  Free: 3192 (used 97.6% of 
   128KiB rom)
   - Before patchset with DSDT disabled
   Total size: 122844  Fixed: 58884  Free: 8228 (used 93.7% of 
   128KiB rom)
   - After patchset:
   Total size: 128776  Fixed: 59100  Free: 2296 (used 98.2% of 
   128KiB rom)
   - Legacy disabled at build time:
   Total size: 119836  Fixed: 58996  Free: 11236 (used 91.4% of 
   128KiB rom)
   
   As can be seen from this, most size savings come
   from dropping DSDT, but we do save a bit by removing
   other tables. Of course the real reason to move tables to QEMU
   is so that ACPI can better match hardware.
   
   This patchset adds an option to move all code for formatting acpi 
   tables
   out of BIOS. With this, QEMU has full control over the table 
   layout.
   All tables are loaded from the new /etc/acpi/ directory.
   Any entries in this directory cause BIOS to disable
   ACPI table generation completely.
   A generic linker script, controlled by QEMU, is
   loaded from /etc/linker-script. It is used to
   patch in table pointers and checksums.
  
  After some thought, there are two additional
  options worth considering, in that they simplify
  bios code somewhat:
  
  - bios could get size from qemu, allocate a buffer
(e.g. could be one buffer for all tables)
and pass the address to qemu.
qemu does all the patching
  
  - further, qemu could do the copy of tables into
that address directly
 
 This seems more complex than necessary to me.
 
 The important task is to get the tables generated in QEMU - I'd focus
 on getting the tables generated in QEMU (one table per fw_cfg file).
 Once that is done, the SeaBIOS side can be easily implemented, and we
 can add any enhancements on top if we feel it is necessary.
 
+1. This copy of tables into that address directly is just an ad-hoc 
PV
isa DMA device in disguise. Such device was refused when libguestfs
asked for it, and they wanted it for much better reason - performance.
There is existing mechanism to pass data into firmware. Use it please.
   
   Yes I can code it up using FW_CFG for now.
   
   One issue with QEMU_CFG_FILE_DIR is that it's broken wrt migration,
   unless we pass in very small bits of data which we
   can guarantee never changes across qemu versions.
   
  Shouldn't we guaranty that ACPI tables do not change for the same
  machine type anyway?
 
 That's not practical. They are too big to stay completely unchanged.
 
I will not be surprised if this will cause us problem somehow. Guest
will see new tables only after reboot/resume from S4 so damage is
limited, but one thing that comes to mind is table's size change. If
they grow from one version to the other after resuming a guest from S4
on new QEMU version part of the tables may be corrupted.

   Off-list, I suggested fixing it and migrating file
   content, but Anthony thinks it's a bad idea.
   
  Why is this a bad idea to fix device migration?
 
 You misunderstand I think.
 Question is whether we should be putting so much info in fw_cfg.
 If we keep fw_cfg for small things we don't need to
 migrate it. In that case ACPI tables have to be passed in
 using some other mechanism.
 
Where this notion that fw_cfg is only for a small things is coming
from? I can assure you this was not the case when the device was
introduced. In fact it is used today for not so small things like
bootindex splash screen bitmaps, option rom loading and kernel/initrd
loading. Some of those are bigger then ACPI tables will ever be.
And they all should be migrated, so fw_cfg should be fixed anyway.

--
Gleb.



Re: [Qemu-devel] [PATCH RFC 0/3] seabios: move acpi table formatting out of bios

2013-05-08 Thread Michael S. Tsirkin
On Wed, May 08, 2013 at 01:59:12PM +0300, Gleb Natapov wrote:
 On Wed, May 08, 2013 at 01:43:25PM +0300, Michael S. Tsirkin wrote:
  On Wed, May 08, 2013 at 01:34:59PM +0300, Gleb Natapov wrote:
   On Wed, May 08, 2013 at 01:29:12PM +0300, Michael S. Tsirkin wrote:
On Wed, May 08, 2013 at 12:31:50PM +0300, Gleb Natapov wrote:
 On Tue, May 07, 2013 at 07:01:13PM -0400, Kevin O'Connor wrote:
  On Tue, May 07, 2013 at 09:00:48PM +0300, Michael S. Tsirkin wrote:
   On Thu, Apr 25, 2013 at 12:02:20PM +0300, Michael S. Tsirkin 
   wrote:
Untested yet, but I thought I'd share the
BIOS bits so we can agree on direction.

In particular check out ROM sizes:
- Before patchset with DSDT enabled
Total size: 127880  Fixed: 59060  Free: 3192 (used 97.6% of 
128KiB rom)
- Before patchset with DSDT disabled
Total size: 122844  Fixed: 58884  Free: 8228 (used 93.7% of 
128KiB rom)
- After patchset:
Total size: 128776  Fixed: 59100  Free: 2296 (used 98.2% of 
128KiB rom)
- Legacy disabled at build time:
Total size: 119836  Fixed: 58996  Free: 11236 (used 91.4% 
of 128KiB rom)

As can be seen from this, most size savings come
from dropping DSDT, but we do save a bit by removing
other tables. Of course the real reason to move tables to QEMU
is so that ACPI can better match hardware.

This patchset adds an option to move all code for formatting 
acpi tables
out of BIOS. With this, QEMU has full control over the table 
layout.
All tables are loaded from the new /etc/acpi/ directory.
Any entries in this directory cause BIOS to disable
ACPI table generation completely.
A generic linker script, controlled by QEMU, is
loaded from /etc/linker-script. It is used to
patch in table pointers and checksums.
   
   After some thought, there are two additional
   options worth considering, in that they simplify
   bios code somewhat:
   
   - bios could get size from qemu, allocate a buffer
 (e.g. could be one buffer for all tables)
 and pass the address to qemu.
 qemu does all the patching
   
   - further, qemu could do the copy of tables into
 that address directly
  
  This seems more complex than necessary to me.
  
  The important task is to get the tables generated in QEMU - I'd 
  focus
  on getting the tables generated in QEMU (one table per fw_cfg 
  file).
  Once that is done, the SeaBIOS side can be easily implemented, and 
  we
  can add any enhancements on top if we feel it is necessary.
  
 +1. This copy of tables into that address directly is just an 
 ad-hoc PV
 isa DMA device in disguise. Such device was refused when libguestfs
 asked for it, and they wanted it for much better reason - performance.
 There is existing mechanism to pass data into firmware. Use it please.

Yes I can code it up using FW_CFG for now.

One issue with QEMU_CFG_FILE_DIR is that it's broken wrt migration,
unless we pass in very small bits of data which we
can guarantee never changes across qemu versions.

   Shouldn't we guaranty that ACPI tables do not change for the same
   machine type anyway?
  
  That's not practical. They are too big to stay completely unchanged.
  
 I will not be surprised if this will cause us problem somehow. Guest
 will see new tables only after reboot/resume from S4 so damage is
 limited, but one thing that comes to mind is table's size change. If
 they grow from one version to the other after resuming a guest from S4
 on new QEMU version part of the tables may be corrupted.

Why would it be corrupted?

In any case, FACS has a hardware signature value for
just such a case. If we know VM can not be resumed on new QEMU,
we can change the signature and it will cold-boot instead.

Off-list, I suggested fixing it and migrating file
content, but Anthony thinks it's a bad idea.

   Why is this a bad idea to fix device migration?
  
  You misunderstand I think.
  Question is whether we should be putting so much info in fw_cfg.
  If we keep fw_cfg for small things we don't need to
  migrate it. In that case ACPI tables have to be passed in
  using some other mechanism.
  
 Where this notion that fw_cfg is only for a small things is coming
 from? I can assure you this was not the case when the device was
 introduced. In fact it is used today for not so small things like
 bootindex splash screen bitmaps, option rom loading and kernel/initrd
 loading. Some of those are bigger then ACPI tables will ever be.
 And they all should be migrated, so fw_cfg should be fixed anyway.
 
 --
   Gleb.

I'm not arguing with that. Convince Anthony please.

-- 
MST



[Qemu-devel] [PATCH 0/2] PPC: Fix cmp on 32bit only targets v2

2013-05-08 Thread Alexander Graf
When running 32bit cmp instructions on a TARGET_PPC without 64bit support,
we generate incorrect comparisons. This patch set fixes this issue.

v1 - v2:

  - treat L bit as reserved on 32bit targets

Alex

Alexander Graf (2):
  PPC: Add 32bit instruction flag
  PPC: Introduce 32bit only cmp ops

 target-ppc/cpu.h|5 ++-
 target-ppc/translate.c  |   20 ++
 target-ppc/translate_init.c |   88 +-
 3 files changed, 60 insertions(+), 53 deletions(-)




[Qemu-devel] [PATCH 2/2] PPC: Introduce 32bit only cmp ops

2013-05-08 Thread Alexander Graf
When running a 32bit target CPU with qemu-(system-)-ppc, NARROW_MODE
is not set, so we never get to leverage the 32bit only code path in
the compare op handlers.

Introduce new handlers based on the 32bit only flag. That way we can
have 2 separate functions for 32bit mode and 64bit mode, which can
handle NARROW_MODE.

Reported-by: Torbjorn Granlund t...@gmplib.org
Signed-off-by: Alexander Graf ag...@suse.de

---

v1 - v2:

  - treat L bit as reserved for 32bit
---
 target-ppc/translate.c |   20 
 1 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index a018616..feca162 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -675,7 +675,7 @@ static inline void gen_set_Rc0(DisasContext *ctx, TCGv reg)
 /* cmp */
 static void gen_cmp(DisasContext *ctx)
 {
-if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
+if (!(ctx-opcode  0x0020)) {
 gen_op_cmp32(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
  1, crfD(ctx-opcode));
 } else {
@@ -687,7 +687,7 @@ static void gen_cmp(DisasContext *ctx)
 /* cmpi */
 static void gen_cmpi(DisasContext *ctx)
 {
-if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
+if (!(ctx-opcode  0x0020)) {
 gen_op_cmpi32(cpu_gpr[rA(ctx-opcode)], SIMM(ctx-opcode),
   1, crfD(ctx-opcode));
 } else {
@@ -699,7 +699,7 @@ static void gen_cmpi(DisasContext *ctx)
 /* cmpl */
 static void gen_cmpl(DisasContext *ctx)
 {
-if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
+if (!(ctx-opcode  0x0020)) {
 gen_op_cmp32(cpu_gpr[rA(ctx-opcode)], cpu_gpr[rB(ctx-opcode)],
  0, crfD(ctx-opcode));
 } else {
@@ -711,7 +711,7 @@ static void gen_cmpl(DisasContext *ctx)
 /* cmpli */
 static void gen_cmpli(DisasContext *ctx)
 {
-if (NARROW_MODE(ctx) || !(ctx-opcode  0x0020)) {
+if (!(ctx-opcode  0x0020)) {
 gen_op_cmpi32(cpu_gpr[rA(ctx-opcode)], UIMM(ctx-opcode),
   0, crfD(ctx-opcode));
 } else {
@@ -8638,10 +8638,14 @@ GEN_SPE(efdtsteq,  speundef,  0x1F, 0x0B, 0x0060, 
0x, PPC_SPE_DOUBLE
 
 static opcode_t opcodes[] = {
 GEN_HANDLER(invalid, 0x00, 0x00, 0x00, 0x, PPC_NONE),
-GEN_HANDLER(cmp, 0x1F, 0x00, 0x00, 0x0040, PPC_INTEGER),
-GEN_HANDLER(cmpi, 0x0B, 0xFF, 0xFF, 0x0040, PPC_INTEGER),
-GEN_HANDLER(cmpl, 0x1F, 0x00, 0x01, 0x0040, PPC_INTEGER),
-GEN_HANDLER(cmpli, 0x0A, 0xFF, 0xFF, 0x0040, PPC_INTEGER),
+GEN_HANDLER(cmp, 0x1F, 0x00, 0x00, 0x0040, PPC_64B),
+GEN_HANDLER_E(cmp, 0x1F, 0x00, 0x00, 0x0060, PPC_NONE, PPC2_32B),
+GEN_HANDLER(cmpi, 0x0B, 0xFF, 0xFF, 0x0040, PPC_64B),
+GEN_HANDLER_E(cmpi, 0x0B, 0xFF, 0xFF, 0x0060, PPC_NONE, PPC2_32B),
+GEN_HANDLER(cmpl, 0x1F, 0x00, 0x01, 0x0040, PPC_64B),
+GEN_HANDLER_E(cmpl, 0x1F, 0x00, 0x01, 0x0060, PPC_NONE, PPC2_32B),
+GEN_HANDLER(cmpli, 0x0A, 0xFF, 0xFF, 0x0040, PPC_64B),
+GEN_HANDLER_E(cmpli, 0x0A, 0xFF, 0xFF, 0x0060, PPC_NONE, PPC2_32B),
 GEN_HANDLER_E(cmpb, 0x1F, 0x1C, 0x0F, 0x0001, PPC_NONE, PPC2_ISA205),
 GEN_HANDLER(isel, 0x1F, 0x0F, 0xFF, 0x0001, PPC_ISEL),
 GEN_HANDLER(addi, 0x0E, 0xFF, 0xFF, 0x, PPC_INTEGER),
-- 
1.6.0.2




[Qemu-devel] [PATCH 1/2] PPC: Add 32bit instruction flag

2013-05-08 Thread Alexander Graf
Some instructions behave differently depending on whether the CPU is
64bit capable or not, regardless of the mode the CPU is in.

Add a new instruction flag that indicates that we're running on a CPU
that can not execute 64bit code.

Signed-off-by: Alexander Graf ag...@suse.de
---
 target-ppc/cpu.h|5 ++-
 target-ppc/translate_init.c |   88 +-
 2 files changed, 48 insertions(+), 45 deletions(-)

diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index aa1d013..09a28e1 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -1875,8 +1875,11 @@ enum {
 PPC2_DBRX  = 0x0010ULL,
 /* Book I 2.05 PowerPC specification */
 PPC2_ISA205= 0x0020ULL,
+/* 32bit instructions (!PPC_64B  PPC_INTEGER)  */
+PPC2_32B   = 0x0040ULL,
 
-#define PPC_TCG_INSNS2 (PPC2_BOOKE206 | PPC2_PRCNTL | PPC2_DBRX | PPC2_ISA205)
+#define PPC_TCG_INSNS2 (PPC2_BOOKE206 | PPC2_PRCNTL | PPC2_DBRX | PPC2_ISA205 \
+  | PPC2_32B)
 };
 
 /*/
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 021a31e..dece4c5 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -3147,7 +3147,7 @@ POWERPC_FAMILY(401)(ObjectClass *oc, void *data)
PPC_CACHE_DCBZ |
PPC_MEM_SYNC | PPC_MEM_EIEIO |
PPC_4xx_COMMON | PPC_40x_EXCP;
-pcc-insns_flags2 = PPC_NONE;
+pcc-insns_flags2 = PPC2_32B;
 pcc-msr_mask = 0x000FD201ULL;
 pcc-mmu_model = POWERPC_MMU_REAL;
 pcc-excp_model = POWERPC_EXCP_40x;
@@ -3195,7 +3195,7 @@ POWERPC_FAMILY(401x2)(ObjectClass *oc, void *data)
PPC_MEM_SYNC | PPC_MEM_EIEIO |
PPC_40x_TLB | PPC_MEM_TLBIA | PPC_MEM_TLBSYNC |
PPC_4xx_COMMON | PPC_40x_EXCP;
-pcc-insns_flags2 = PPC_NONE;
+pcc-insns_flags2 = PPC2_32B;
 pcc-msr_mask = 0x001FD231ULL;
 pcc-mmu_model = POWERPC_MMU_SOFT_4xx_Z;
 pcc-excp_model = POWERPC_EXCP_40x;
@@ -3237,7 +3237,7 @@ POWERPC_FAMILY(401x3)(ObjectClass *oc, void *data)
PPC_MEM_SYNC | PPC_MEM_EIEIO |
PPC_40x_TLB | PPC_MEM_TLBIA | PPC_MEM_TLBSYNC |
PPC_4xx_COMMON | PPC_40x_EXCP;
-pcc-insns_flags2 = PPC_NONE;
+pcc-insns_flags2 = PPC2_32B;
 pcc-msr_mask = 0x001FD631ULL;
 pcc-mmu_model = POWERPC_MMU_SOFT_4xx_Z;
 pcc-excp_model = POWERPC_EXCP_40x;
@@ -3285,7 +3285,7 @@ POWERPC_FAMILY(IOP480)(ObjectClass *oc, void *data)
PPC_MEM_SYNC | PPC_MEM_EIEIO |
PPC_40x_TLB | PPC_MEM_TLBIA | PPC_MEM_TLBSYNC |
PPC_4xx_COMMON | PPC_40x_EXCP;
-pcc-insns_flags2 = PPC_NONE;
+pcc-insns_flags2 = PPC2_32B;
 pcc-msr_mask = 0x001FD231ULL;
 pcc-mmu_model = POWERPC_MMU_SOFT_4xx_Z;
 pcc-excp_model = POWERPC_EXCP_40x;
@@ -3325,7 +3325,7 @@ POWERPC_FAMILY(403)(ObjectClass *oc, void *data)
PPC_CACHE_DCBZ |
PPC_MEM_SYNC | PPC_MEM_EIEIO |
PPC_4xx_COMMON | PPC_40x_EXCP;
-pcc-insns_flags2 = PPC_NONE;
+pcc-insns_flags2 = PPC2_32B;
 pcc-msr_mask = 0x0007D00DULL;
 pcc-mmu_model = POWERPC_MMU_REAL;
 pcc-excp_model = POWERPC_EXCP_40x;
@@ -3385,7 +3385,7 @@ POWERPC_FAMILY(403GCX)(ObjectClass *oc, void *data)
PPC_MEM_SYNC | PPC_MEM_EIEIO |
PPC_40x_TLB | PPC_MEM_TLBIA | PPC_MEM_TLBSYNC |
PPC_4xx_COMMON | PPC_40x_EXCP;
-pcc-insns_flags2 = PPC_NONE;
+pcc-insns_flags2 = PPC2_32B;
 pcc-msr_mask = 0x0007D00DULL;
 pcc-mmu_model = POWERPC_MMU_SOFT_4xx_Z;
 pcc-excp_model = POWERPC_EXCP_40x;
@@ -3444,7 +3444,7 @@ POWERPC_FAMILY(405)(ObjectClass *oc, void *data)
PPC_MEM_SYNC | PPC_MEM_EIEIO |
PPC_40x_TLB | PPC_MEM_TLBIA | PPC_MEM_TLBSYNC |
PPC_4xx_COMMON | PPC_405_MAC | PPC_40x_EXCP;
-pcc-insns_flags2 = PPC_NONE;
+pcc-insns_flags2 = PPC2_32B;
 pcc-msr_mask = 0x0006E630ULL;
 pcc-mmu_model = POWERPC_MMU_SOFT_4xx;
 pcc-excp_model = POWERPC_EXCP_40x;
@@ -3538,7 +3538,7 @@ POWERPC_FAMILY(440EP)(ObjectClass *oc, void *data)
PPC_MEM_TLBSYNC | PPC_MFTB |
PPC_BOOKE | PPC_4xx_COMMON | PPC_405_MAC |
PPC_440_SPEC;
-pcc-insns_flags2 = PPC_NONE;
+pcc-insns_flags2 = PPC2_32B;
 pcc-msr_mask = 0x0006FF30ULL;
 pcc-mmu_model = POWERPC_MMU_BOOKE;
 pcc-excp_model = POWERPC_EXCP_BOOKE;
@@ -3611,7 +3611,7 @@ POWERPC_FAMILY(440GP)(ObjectClass *oc, void *data)
PPC_MEM_TLBSYNC 

Re: [Qemu-devel] [PATCH] PPC: Introduce 32bit only cmp ops

2013-05-08 Thread Aurelien Jarno
On Wed, May 08, 2013 at 12:34:26PM +0200, Torbjorn Granlund wrote:
 Aurelien Jarno aurel...@aurel32.net writes:
 
   You have to declare the L bit as invalid, so that trying to execute a
   64-bit cmp* instruction on a 32-bit CPU causes an invalid instruction
   exception.
   
 Don't people read what I write?
 

Quoting the IBM PowerPC Microprocessor Family: The Programming
Environments Manual for 32 and 64-bit Microprocessors:

| Note: In 32-bit implementations, if L = 1 the instruction form is invalid.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net



Re: [Qemu-devel] [PATCH V5 0/5] block: make qmp_transaction extendable

2013-05-08 Thread Kevin Wolf
Am 08.05.2013 um 12:25 hat Wenchao Xia geschrieben:
   This serial will package backing chain snapshot code as one case, to make it
 possible adding more operations later.
 
 v2:
   Address Kevin's comments:
   Use the same prototype prepare, commit, rollback model in original code,
 commit should never fail.
 
 v3:
   Address Stefan's comments:
   3/5, 4/5: remove *action parameter since later only BlkTransactionStates* is
 needed.
   5/5: embbed BlkTransactionStates in ExternalSnapshotStates, *opaque is
 removed, related call back function format change for external snapshot.
   Address Kevin's comments:
   removed all indention in commit message.
   1/5: return void for prepare() function, *errp plays the role as error
 checker.
   5/5: mark *commit callback must exist, *rollback callback can be NULL. Align
 callback = in const BdrvActionOps external_snapshot_ops to the same colum.
   Address Eric's comments:
   1/5: better commit message.
   5/5: better commit message and comments in code that only one of rollback()
 or commit() will be called.
 
 v4:
   5/5: document clean() callback will always be called if it present, declare
 static for global variable actions, use array plus .instance_size to remove
 switch checking code according to caller input.
 
 v5:
   better commit message and comments, switch callback function name rollback
 to abort.
 
 Wenchao Xia (5):
   1 block: package preparation code in qmp_transaction()
   2 block: move input parsing code in qmp_transaction()
   3 block: package committing code in qmp_transaction()
   4 block: package rollback code in qmp_transaction()
   5 block: make all steps in qmp_transaction() as callback
 
  blockdev.c |  266 
 ++--
  1 files changed, 169 insertions(+), 97 deletions(-)

Thanks, applied all to block-next for 1.6.

Kevin



Re: [Qemu-devel] [PATCH 2/9] qom: add object_property_add_unnamed_child

2013-05-08 Thread Stefan Hajnoczi
On Mon, May 06, 2013 at 01:48:34PM -0500, mdroth wrote:
 On Mon, May 06, 2013 at 09:44:13AM +0200, Paolo Bonzini wrote:
  Il 03/05/2013 18:03, Michael Roth ha scritto:
   This interface allows us to add a child property without specifying a
   name. Instead, a unique name is created and passed back after adding
   the property.
   
   Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
   ---
include/qom/object.h |   16 
qom/object.c |   25 +
2 files changed, 41 insertions(+)
   
   diff --git a/include/qom/object.h b/include/qom/object.h
   index 86f1e2e..ca0fce8 100644
   --- a/include/qom/object.h
   +++ b/include/qom/object.h
   @@ -1041,6 +1041,22 @@ void object_property_add_child(Object *obj, const 
   char *name,
   Object *child, struct Error **errp);

/**
   + * object_property_add_unnamed_child:
   + *
   + * @obj: the object to add a property to
   + * @name: the name of the property
   + * @child: the child object
   + * @errp: if an error occurs, a pointer to an area to store the area
   + *
   + * Same as object_property_add_child, but will allocate a unique name to
   + * identify the child property.
   + *
   + * Returns: The name assigned to the child property, or NULL on failure.
   + */
   +char *object_property_add_unnamed_child(Object *obj, Object *child,
   +struct Error **errp);
   +
   +/**
 * object_property_add_link:
 * @obj: the object to add a property to
 * @name: the name of the property
   diff --git a/qom/object.c b/qom/object.c
   index c932f64..229a9a7 100644
   --- a/qom/object.c
   +++ b/qom/object.c
   @@ -926,6 +926,31 @@ static void object_finalize_child_property(Object 
   *obj, const char *name,
object_unref(child);
}

   +char *object_property_add_unnamed_child(Object *obj, Object *child, 
   Error **errp)
   +{
   +int idx = 0;
   +bool next_idx_found = false;
   +char name[64];
   +ObjectProperty *prop;
   +
   +while (!next_idx_found) {
   +sprintf(name, unnamed[%d], idx);
   +QTAILQ_FOREACH(prop, obj-properties, node) {
   +if (strcmp(name, prop-name) == 0) {
   +idx++;
   +break;
   +}
   +}
   +if (!prop) {
   +next_idx_found = true;
   +}
   +}
   +
   +object_property_add_child(obj, name, child, errp);
   +
   +return error_is_set(errp) ? NULL : g_strdup(name);
   +}
  
  This is O(n^3) for adding N children.  O(n^2) would be not-that-great
  but fine; can you take the occasion to convert the properties list to a
  hashtable?
 
 Sure, I'll look into it.

Given that we already have the child pointer, perhaps just use the
uintptr_t child memory address as a unique name.  It's guaranteed to be
unique unless you add the same child twice.

Stefan



Re: [Qemu-devel] [PATCH RFC 0/3] seabios: move acpi table formatting out of bios

2013-05-08 Thread Gleb Natapov
On Wed, May 08, 2013 at 02:07:24PM +0300, Michael S. Tsirkin wrote:
 On Wed, May 08, 2013 at 01:59:12PM +0300, Gleb Natapov wrote:
  On Wed, May 08, 2013 at 01:43:25PM +0300, Michael S. Tsirkin wrote:
   On Wed, May 08, 2013 at 01:34:59PM +0300, Gleb Natapov wrote:
On Wed, May 08, 2013 at 01:29:12PM +0300, Michael S. Tsirkin wrote:
 On Wed, May 08, 2013 at 12:31:50PM +0300, Gleb Natapov wrote:
  On Tue, May 07, 2013 at 07:01:13PM -0400, Kevin O'Connor wrote:
   On Tue, May 07, 2013 at 09:00:48PM +0300, Michael S. Tsirkin 
   wrote:
On Thu, Apr 25, 2013 at 12:02:20PM +0300, Michael S. Tsirkin 
wrote:
 Untested yet, but I thought I'd share the
 BIOS bits so we can agree on direction.
 
 In particular check out ROM sizes:
 - Before patchset with DSDT enabled
 Total size: 127880  Fixed: 59060  Free: 3192 (used 97.6% 
 of 128KiB rom)
 - Before patchset with DSDT disabled
 Total size: 122844  Fixed: 58884  Free: 8228 (used 93.7% 
 of 128KiB rom)
 - After patchset:
 Total size: 128776  Fixed: 59100  Free: 2296 (used 98.2% 
 of 128KiB rom)
 - Legacy disabled at build time:
 Total size: 119836  Fixed: 58996  Free: 11236 (used 91.4% 
 of 128KiB rom)
 
 As can be seen from this, most size savings come
 from dropping DSDT, but we do save a bit by removing
 other tables. Of course the real reason to move tables to QEMU
 is so that ACPI can better match hardware.
 
 This patchset adds an option to move all code for formatting 
 acpi tables
 out of BIOS. With this, QEMU has full control over the table 
 layout.
 All tables are loaded from the new /etc/acpi/ directory.
 Any entries in this directory cause BIOS to disable
 ACPI table generation completely.
 A generic linker script, controlled by QEMU, is
 loaded from /etc/linker-script. It is used to
 patch in table pointers and checksums.

After some thought, there are two additional
options worth considering, in that they simplify
bios code somewhat:

- bios could get size from qemu, allocate a buffer
  (e.g. could be one buffer for all tables)
  and pass the address to qemu.
  qemu does all the patching

- further, qemu could do the copy of tables into
  that address directly
   
   This seems more complex than necessary to me.
   
   The important task is to get the tables generated in QEMU - I'd 
   focus
   on getting the tables generated in QEMU (one table per fw_cfg 
   file).
   Once that is done, the SeaBIOS side can be easily implemented, 
   and we
   can add any enhancements on top if we feel it is necessary.
   
  +1. This copy of tables into that address directly is just an 
  ad-hoc PV
  isa DMA device in disguise. Such device was refused when libguestfs
  asked for it, and they wanted it for much better reason - 
  performance.
  There is existing mechanism to pass data into firmware. Use it 
  please.
 
 Yes I can code it up using FW_CFG for now.
 
 One issue with QEMU_CFG_FILE_DIR is that it's broken wrt migration,
 unless we pass in very small bits of data which we
 can guarantee never changes across qemu versions.
 
Shouldn't we guaranty that ACPI tables do not change for the same
machine type anyway?
   
   That's not practical. They are too big to stay completely unchanged.
   
  I will not be surprised if this will cause us problem somehow. Guest
  will see new tables only after reboot/resume from S4 so damage is
  limited, but one thing that comes to mind is table's size change. If
  they grow from one version to the other after resuming a guest from S4
  on new QEMU version part of the tables may be corrupted.
 
 Why would it be corrupted?
 
Because ACPI tables are stored in the memory marked as ACPI data (IIRC
seabios mark them as reserved). Guests do not save reserved memory during
S4 (don't know about ACPI data, but if guest does not copy tables from
it to another location I doubt it saves the memory, anyway ACPI spec does
not mandate it), so what happens on resume if the memory grows? Part
of it, that was not marked as reserved before S4, is re-written with
whatever data guest had there and rest contains now corrupted ACPI tables
that BIOS put there during boot. We can hope that guest is smart enough
to see that memory map changed and refuse to resume or we can put ACPI
tables into NVS memory which has to be saved and restored during S4 by
OSPM.

 In any case, FACS has a hardware signature value for
 just such a case. If we know VM can not be resumed on new QEMU,
 we can change the signature and it will cold-boot instead.
 
Nice, does Linux 

[Qemu-devel] [PATCH] Remove OSS support for OpenBSD

2013-05-08 Thread Brad Smith
Remove the OSS support for OpenBSD. The OSS API has not been usable
for quite some time.

Signed-off-by: Brad Smith b...@comstyle.com

diff --git a/audio/ossaudio.c b/audio/ossaudio.c
index 00be9c9..007c641 100644
--- a/audio/ossaudio.c
+++ b/audio/ossaudio.c
@@ -25,11 +25,7 @@
 #include sys/mman.h
 #include sys/types.h
 #include sys/ioctl.h
-#ifdef __OpenBSD__
-#include soundcard.h
-#else
 #include sys/soundcard.h
-#endif
 #include qemu-common.h
 #include qemu/main-loop.h
 #include qemu/host-utils.h
diff --git a/configure b/configure
index 9439f1c..89dda5b 100755
--- a/configure
+++ b/configure
@@ -468,8 +468,7 @@ OpenBSD)
   bsd=yes
   make=${MAKE-gmake}
   audio_drv_list=oss
-  audio_possible_drivers=oss sdl esd
-  oss_lib=-lossaudio
+  audio_possible_drivers=sdl esd
 ;;
 Darwin)
   bsd=yes

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




Re: [Qemu-devel] [RFC 0/9] QContext: QOM class to support multiple event loops

2013-05-08 Thread Stefan Hajnoczi
On Mon, May 06, 2013 at 01:17:53PM -0500, mdroth wrote:
 On Mon, May 06, 2013 at 09:54:14AM +0200, Paolo Bonzini wrote:
  Il 03/05/2013 18:03, Michael Roth ha scritto:
   These patches apply on top of qemu.git master, and can also be obtained 
   from:
   git://github.com/mdroth/qemu.git qcontext
   
   OVERVIEW
   
   This series introduces a set of QOM classes/interfaces for event
   registration/handling: QContext and QSource, which are based closely on
   their GMainContext/GSource GLib counterparts.
   
   QContexts can be created via the command-line via -object, and can also be
   intructed (via -object params/properties) to automatically start a
   thread/event-loop to handle QSources we attach to them.
  
  This is an awesome idea.
  
  However, it seems a bit overengineered.  Why do we need QSource at all?
   In my opinion, we should first change dataplane to use AioContext as a
  GSource, and benchmark it thoroughly.  If it is fast enough, we can
 
 I think it would be great to just stick with GSources. I didn't want to
 rely too heavily on GLib for the RFC since there seems to be some
 reservations about relying too heavily on GLib for our
 OneTrueEventLoop interface (mainly, lack of PI mutexes in the context of
 real-time device threads, or other performance considerations that might
 pop up and cause us to rethink our use of glib).
 
 However, knowing that we *could* do something like porting to QSources and
 using a different QContext implementation if the need ever became
 evident is enough for me, and I'm happy to drop QSources until we
 actually need them. The GSource-QSource conversions would be mostly
 mechanical.
 
  GSource, and benchmark it thoroughly.  If it is fast enough, we can
  just introduce a glib-based QContext and be done with it.  Hopefully
  that is the case...
 
 Sounds good to me. I'll look into that more, and talk to some of our
 performance folks who were involved with the virtio-blk dataplane
 testing.

Great.  I see value in QOM, it allows event loop threads to be specified
on the command-line and monitor.  But it would be nice to drop QSource
as well as the QContext inheritance hierarchy.

BTW there should be a command analogous to query-cpus that lists the
QContexts and their thread IDs.  This way CPU affinity can be set
similar to how we do it for vcpu threads today.

Stefan



Re: [Qemu-devel] [PATCH RFC 0/3] seabios: move acpi table formatting out of bios

2013-05-08 Thread Michael S. Tsirkin
On Wed, May 08, 2013 at 02:35:44PM +0300, Gleb Natapov wrote:
 On Wed, May 08, 2013 at 02:07:24PM +0300, Michael S. Tsirkin wrote:
  On Wed, May 08, 2013 at 01:59:12PM +0300, Gleb Natapov wrote:
   On Wed, May 08, 2013 at 01:43:25PM +0300, Michael S. Tsirkin wrote:
On Wed, May 08, 2013 at 01:34:59PM +0300, Gleb Natapov wrote:
 On Wed, May 08, 2013 at 01:29:12PM +0300, Michael S. Tsirkin wrote:
  On Wed, May 08, 2013 at 12:31:50PM +0300, Gleb Natapov wrote:
   On Tue, May 07, 2013 at 07:01:13PM -0400, Kevin O'Connor wrote:
On Tue, May 07, 2013 at 09:00:48PM +0300, Michael S. Tsirkin 
wrote:
 On Thu, Apr 25, 2013 at 12:02:20PM +0300, Michael S. Tsirkin 
 wrote:
  Untested yet, but I thought I'd share the
  BIOS bits so we can agree on direction.
  
  In particular check out ROM sizes:
  - Before patchset with DSDT enabled
  Total size: 127880  Fixed: 59060  Free: 3192 (used 
  97.6% of 128KiB rom)
  - Before patchset with DSDT disabled
  Total size: 122844  Fixed: 58884  Free: 8228 (used 
  93.7% of 128KiB rom)
  - After patchset:
  Total size: 128776  Fixed: 59100  Free: 2296 (used 
  98.2% of 128KiB rom)
  - Legacy disabled at build time:
  Total size: 119836  Fixed: 58996  Free: 11236 (used 
  91.4% of 128KiB rom)
  
  As can be seen from this, most size savings come
  from dropping DSDT, but we do save a bit by removing
  other tables. Of course the real reason to move tables to 
  QEMU
  is so that ACPI can better match hardware.
  
  This patchset adds an option to move all code for 
  formatting acpi tables
  out of BIOS. With this, QEMU has full control over the 
  table layout.
  All tables are loaded from the new /etc/acpi/ directory.
  Any entries in this directory cause BIOS to disable
  ACPI table generation completely.
  A generic linker script, controlled by QEMU, is
  loaded from /etc/linker-script. It is used to
  patch in table pointers and checksums.
 
 After some thought, there are two additional
 options worth considering, in that they simplify
 bios code somewhat:
 
 - bios could get size from qemu, allocate a buffer
   (e.g. could be one buffer for all tables)
   and pass the address to qemu.
   qemu does all the patching
 
 - further, qemu could do the copy of tables into
   that address directly

This seems more complex than necessary to me.

The important task is to get the tables generated in QEMU - I'd 
focus
on getting the tables generated in QEMU (one table per fw_cfg 
file).
Once that is done, the SeaBIOS side can be easily implemented, 
and we
can add any enhancements on top if we feel it is necessary.

   +1. This copy of tables into that address directly is just an 
   ad-hoc PV
   isa DMA device in disguise. Such device was refused when 
   libguestfs
   asked for it, and they wanted it for much better reason - 
   performance.
   There is existing mechanism to pass data into firmware. Use it 
   please.
  
  Yes I can code it up using FW_CFG for now.
  
  One issue with QEMU_CFG_FILE_DIR is that it's broken wrt migration,
  unless we pass in very small bits of data which we
  can guarantee never changes across qemu versions.
  
 Shouldn't we guaranty that ACPI tables do not change for the same
 machine type anyway?

That's not practical. They are too big to stay completely unchanged.

   I will not be surprised if this will cause us problem somehow. Guest
   will see new tables only after reboot/resume from S4 so damage is
   limited, but one thing that comes to mind is table's size change. If
   they grow from one version to the other after resuming a guest from S4
   on new QEMU version part of the tables may be corrupted.
  
  Why would it be corrupted?
  
 Because ACPI tables are stored in the memory marked as ACPI data (IIRC
 seabios mark them as reserved). Guests do not save reserved memory during
 S4 (don't know about ACPI data, but if guest does not copy tables from
 it to another location I doubt it saves the memory, anyway ACPI spec does
 not mandate it), so what happens on resume if the memory grows? Part
 of it, that was not marked as reserved before S4, is re-written with
 whatever data guest had there and rest contains now corrupted ACPI tables
 that BIOS put there during boot. We can hope that guest is smart enough
 to see that memory map changed and refuse to resume or we can put ACPI
 tables into NVS memory which has to be saved and restored during S4 by
 OSPM.

This easily 

Re: [Qemu-devel] [PATCH v2 1/3] block: add basic backup support to block driver

2013-05-08 Thread Kevin Wolf
Am 29.04.2013 um 09:42 hat Stefan Hajnoczi geschrieben:
 From: Dietmar Maurer diet...@proxmox.com
 
 backup_start() creates a block job that copies a point-in-time snapshot
 of a block device to a target block device.
 
 We call backup_do_cow() for each write during backup. That function
 reads the original data from the block device before it gets
 overwritten.  The data is then written to the target device.
 
 The tracked_request infrastructure is used to serialize access.  Both
 reads and writes are serialized if they overlap.
 
 Currently backup cluster size is hardcoded to 65536 bytes.
 
 [I made a number of changes to Dietmar's original patch and folded them
 in to make code review easy.  Here is the full list:
 
  * Drop BackupDumpFunc interface in favor of a target block device
  * Detect zero clusters with buffer_is_zero()
  * Don't write zero clusters to the target
  * Use 0 delay instead of 1us, like other block jobs
  * Unify creation/start functions into backup_start()
  * Simplify cleanup, free bitmap in backup_run() instead of cb function
  * Use HBitmap to avoid duplicating bitmap code
  * Use bdrv_getlength() instead of accessing -total_sectors directly
  * Delete the backup.h header file, it is no longer necessary
  * Move ./backup.c to block/backup.c
  * Remove #ifdefed out code
  * Coding style and whitespace cleanups
 
 -- stefanha]
 
 Signed-off-by: Dietmar Maurer diet...@proxmox.com
 Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
 ---
  block.c   |  69 -
  block/Makefile.objs   |   1 +
  block/backup.c| 252 
 ++
  include/block/block.h |   2 +
  include/block/block_int.h |  16 +++
  include/block/blockjob.h  |  10 ++
  6 files changed, 345 insertions(+), 5 deletions(-)
  create mode 100644 block/backup.c

(Moving some hunks around so I can comment on the headers first.)

 diff --git a/include/block/blockjob.h b/include/block/blockjob.h
 index c290d07..6f42495 100644
 --- a/include/block/blockjob.h
 +++ b/include/block/blockjob.h
 @@ -50,6 +50,13 @@ typedef struct BlockJobType {
   * manually.
   */
  void (*complete)(BlockJob *job, Error **errp);
 +
 +/** tracked requests */
 +int coroutine_fn (*before_read)(BlockDriverState *bs, int64_t sector_num,
 +int nb_sectors, QEMUIOVector *qiov);
 +int coroutine_fn (*before_write)(BlockDriverState *bs, int64_t 
 sector_num,
 + int nb_sectors, QEMUIOVector *qiov);
 +
  } BlockJobType;

This is actually a sign that a block job isn't the right tool. Jobs are
something that runs in the background and doesn't have callbacks. You
really want to have a filter here (that happens to be coupled to a job).
Need the BlockBackend split before we can do this right.

The second thing that this conflicts with is generalising block jobs to
generic background jobs.

Each hack like this that we accumulate makes it harder to get the real
thing eventually.

  
  /**
 @@ -103,6 +110,9 @@ struct BlockJob {
  /** Speed that was set with @block_job_set_speed.  */
  int64_t speed;
  
 +/** tracked requests */
 +int cluster_size;

Sure that this is the right comment here?

Does really every job need a cluster size?

 diff --git a/block.c b/block.c
 index aa9a533..c5c09b7 100644
 --- a/block.c
 +++ b/block.c
 @@ -54,6 +54,7 @@
  typedef enum {
  BDRV_REQ_COPY_ON_READ = 0x1,
  BDRV_REQ_ZERO_WRITE   = 0x2,
 +BDRV_REQ_BACKUP_ONLY  = 0x4,
  } BdrvRequestFlags;

Without having read the rest of the code, it's unclear to me what this
new flag means. Could use a comment. (Though it has backup in its name,
so I suspect having this in generic block layer is wrong.)

  static void bdrv_dev_change_media_cb(BlockDriverState *bs, bool load);
 @@ -1902,6 +1903,22 @@ void bdrv_round_to_clusters(BlockDriverState *bs,
  }
  }
  
 +/**
 + * Round a region to job cluster boundaries
 + */
 +static void round_to_job_clusters(BlockDriverState *bs,
 +  int64_t sector_num, int nb_sectors,
 +  int job_cluster_size,
 +  int64_t *cluster_sector_num,
 +  int *cluster_nb_sectors)
 +{
 +int64_t c = job_cluster_size / BDRV_SECTOR_SIZE;
 +
 +*cluster_sector_num = QEMU_ALIGN_DOWN(sector_num, c);
 +*cluster_nb_sectors = QEMU_ALIGN_UP(sector_num - *cluster_sector_num +
 +nb_sectors, c);
 +}

This function has really nothing to do with jobs except that it happens
to be useful in some function actually related to jobs.

It should probably be renamed and bdrv_round_to_clusters() should call
into it.

 +
  static bool tracked_request_overlaps(BdrvTrackedRequest *req,
   int64_t sector_num, int nb_sectors) {
  /*    */
 @@ -1916,7 +1933,9 @@ static bool 

Re: [Qemu-devel] [PATCH RFC 0/3] seabios: move acpi table formatting out of bios

2013-05-08 Thread Gleb Natapov
On Wed, May 08, 2013 at 03:35:46PM +0300, Michael S. Tsirkin wrote:
 On Wed, May 08, 2013 at 02:35:44PM +0300, Gleb Natapov wrote:
  On Wed, May 08, 2013 at 02:07:24PM +0300, Michael S. Tsirkin wrote:
   On Wed, May 08, 2013 at 01:59:12PM +0300, Gleb Natapov wrote:
On Wed, May 08, 2013 at 01:43:25PM +0300, Michael S. Tsirkin wrote:
 On Wed, May 08, 2013 at 01:34:59PM +0300, Gleb Natapov wrote:
  On Wed, May 08, 2013 at 01:29:12PM +0300, Michael S. Tsirkin wrote:
   On Wed, May 08, 2013 at 12:31:50PM +0300, Gleb Natapov wrote:
On Tue, May 07, 2013 at 07:01:13PM -0400, Kevin O'Connor wrote:
 On Tue, May 07, 2013 at 09:00:48PM +0300, Michael S. Tsirkin 
 wrote:
  On Thu, Apr 25, 2013 at 12:02:20PM +0300, Michael S. 
  Tsirkin wrote:
   Untested yet, but I thought I'd share the
   BIOS bits so we can agree on direction.
   
   In particular check out ROM sizes:
   - Before patchset with DSDT enabled
   Total size: 127880  Fixed: 59060  Free: 3192 (used 
   97.6% of 128KiB rom)
   - Before patchset with DSDT disabled
   Total size: 122844  Fixed: 58884  Free: 8228 (used 
   93.7% of 128KiB rom)
   - After patchset:
   Total size: 128776  Fixed: 59100  Free: 2296 (used 
   98.2% of 128KiB rom)
   - Legacy disabled at build time:
   Total size: 119836  Fixed: 58996  Free: 11236 (used 
   91.4% of 128KiB rom)
   
   As can be seen from this, most size savings come
   from dropping DSDT, but we do save a bit by removing
   other tables. Of course the real reason to move tables to 
   QEMU
   is so that ACPI can better match hardware.
   
   This patchset adds an option to move all code for 
   formatting acpi tables
   out of BIOS. With this, QEMU has full control over the 
   table layout.
   All tables are loaded from the new /etc/acpi/ directory.
   Any entries in this directory cause BIOS to disable
   ACPI table generation completely.
   A generic linker script, controlled by QEMU, is
   loaded from /etc/linker-script. It is used to
   patch in table pointers and checksums.
  
  After some thought, there are two additional
  options worth considering, in that they simplify
  bios code somewhat:
  
  - bios could get size from qemu, allocate a buffer
(e.g. could be one buffer for all tables)
and pass the address to qemu.
qemu does all the patching
  
  - further, qemu could do the copy of tables into
that address directly
 
 This seems more complex than necessary to me.
 
 The important task is to get the tables generated in QEMU - 
 I'd focus
 on getting the tables generated in QEMU (one table per fw_cfg 
 file).
 Once that is done, the SeaBIOS side can be easily 
 implemented, and we
 can add any enhancements on top if we feel it is necessary.
 
+1. This copy of tables into that address directly is just an 
ad-hoc PV
isa DMA device in disguise. Such device was refused when 
libguestfs
asked for it, and they wanted it for much better reason - 
performance.
There is existing mechanism to pass data into firmware. Use it 
please.
   
   Yes I can code it up using FW_CFG for now.
   
   One issue with QEMU_CFG_FILE_DIR is that it's broken wrt 
   migration,
   unless we pass in very small bits of data which we
   can guarantee never changes across qemu versions.
   
  Shouldn't we guaranty that ACPI tables do not change for the same
  machine type anyway?
 
 That's not practical. They are too big to stay completely unchanged.
 
I will not be surprised if this will cause us problem somehow. Guest
will see new tables only after reboot/resume from S4 so damage is
limited, but one thing that comes to mind is table's size change. If
they grow from one version to the other after resuming a guest from S4
on new QEMU version part of the tables may be corrupted.
   
   Why would it be corrupted?
   
  Because ACPI tables are stored in the memory marked as ACPI data (IIRC
  seabios mark them as reserved). Guests do not save reserved memory during
  S4 (don't know about ACPI data, but if guest does not copy tables from
  it to another location I doubt it saves the memory, anyway ACPI spec does
  not mandate it), so what happens on resume if the memory grows? Part
  of it, that was not marked as reserved before S4, is re-written with
  whatever data guest had there and rest contains now corrupted ACPI tables
  that BIOS put there during boot. We can hope that guest 

Re: [Qemu-devel] [Qemu-trivial] [PATCH] target-mips: fix incorrect behaviour for INSV

2013-05-08 Thread Michael Tokarev
08.05.2013 15:17, Petar Jovanovic wrote:
 From: Petar Jovanovic petar.jovano...@imgtec.com
 
 Corner case for INSV instruction when size=32 has not been correctly
 implemented. The mask for size should be one bit wider, and preparing the
 filter variable should be aware of this case too.
 
 The test for INSV has been extended to include the case that triggers the
 bug.

This isn't really a good fit for a trivial patch.  Cc'ing qemu-devel
and mips odd-fixes maintainer instead.

Thanks!

/mjt

 Signed-off-by: Petar Jovanovic petar.jovano...@imgtec.com
 ---
  target-mips/dsp_helper.c |4 ++--
  tests/tcg/mips/mips32-dsp/insv.c |   13 +
  2 files changed, 15 insertions(+), 2 deletions(-)
 
 diff --git a/target-mips/dsp_helper.c b/target-mips/dsp_helper.c
 index 805247d..9212789 100644
 --- a/target-mips/dsp_helper.c
 +++ b/target-mips/dsp_helper.c
 @@ -2921,7 +2921,7 @@ target_ulong helper_##name(CPUMIPSState *env, 
 target_ulong rs,  \
  return rt;  \
  }   \
  \
 -filter = ((int32_t)0x01  size) - 1;   \
 +filter = ((int64_t)0x01  size) - 1;   \
  filter = filter  pos; \
  temprs = (rs  pos)  filter;  \
  temprt = rt  ~filter;  \
 @@ -2930,7 +2930,7 @@ target_ulong helper_##name(CPUMIPSState *env, 
 target_ulong rs,  \
  return (target_long)(ret_type)temp; \
  }
  
 -BIT_INSV(insv, 0x1F, 0x1F, int32_t);
 +BIT_INSV(insv, 0x1F, 0x3F, int32_t);
  #ifdef TARGET_MIPS64
  BIT_INSV(dinsv, 0x7F, 0x3F, target_long);
  #endif
 diff --git a/tests/tcg/mips/mips32-dsp/insv.c 
 b/tests/tcg/mips/mips32-dsp/insv.c
 index 243b007..9d67469 100644
 --- a/tests/tcg/mips/mips32-dsp/insv.c
 +++ b/tests/tcg/mips/mips32-dsp/insv.c
 @@ -19,5 +19,18 @@ int main()
  );
  assert(rt == result);
  
 +dsp= 0x1000;
 +rt = 0xF0F0F0F0;
 +rs = 0xA5A5A5A5;
 +result = 0xA5A5A5A5;
 +
 +__asm
 +(wrdsp %2\n\t
 + insv  %0, %1\n\t
 + : +r(rt)
 + : r(rs), r(dsp)
 +);
 +assert(rt == result);
 +
  return 0;
  }
 




Re: [Qemu-devel] [Qemu-trivial] [PATCH 1/2] clean unnecessary code

2013-05-08 Thread Michael Tokarev
08.05.2013 13:46, Trival wrote:
 Duplicates a string. If str is NULL it returns NULL, so
 can make code simple.

Thanks, applied to the trivial queue.  I renamed this patch:
clean unnecessary code: don't check g_strdup arg for NULL
to better describe what's going on.

/mjt



  1   2   3   >