Re: [Qemu-devel] [PATCH] PPC: Fail configure when libfdt is not available

2011-10-17 Thread Paolo Bonzini

On 10/18/2011 02:18 AM, Alexander Graf wrote:

We have several targets in the PPC tree now that basically require libfdt
to function properly, namely the pseries and the e500 targets. This dependency
will rather increase than decrease in the future, so I want to make sure
that people building shiny new 1.0 actually have libfdt installed to get
rid of a few ifdefs in the code.

Warning: This patch will likely make configure fail for people who don't
select their own --target-list, but don't have libfdt development packages
installed. However, we really need this new dependency to move on.

Signed-off-by: Alexander Graf


F15 has them, and they install also on older Fedoras if you pick them 
from Koji.


Acked-by: Paolo Bonzini 

Paolo




Re: [Qemu-devel] [PATCH] hw/9pfs: Fix missing parentheses

2011-10-17 Thread Aneesh Kumar K.V
On Mon, 17 Oct 2011 21:20:59 +0200, Stefan Weil  wrote:
> cppcheck report:
> hw/9pfs/virtio-9p.c:2385:
>  style: Boolean result is used in bitwise operation.
>  Clarify expression with parentheses
> hw/9pfs/virtio-9p.c:2531:
>  style: Boolean result is used in bitwise operation.
>  Clarify expression with parentheses
> 
> Cc: Aneesh Kumar K.V 
> Signed-off-by: Stefan Weil 
> ---
>  hw/9pfs/virtio-9p.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
> index c01c31a..df0b22a 100644
> --- a/hw/9pfs/virtio-9p.c
> +++ b/hw/9pfs/virtio-9p.c
> @@ -2382,7 +2382,7 @@ static void v9fs_remove(void *opaque)
>  goto out_nofid;
>  }
>  /* if fs driver is not path based, return EOPNOTSUPP */
> -if (!pdu->s->ctx.flags & PATHNAME_FSCONTEXT) {
> +if (!(pdu->s->ctx.flags & PATHNAME_FSCONTEXT)) {
>  err = -EOPNOTSUPP;
>  goto out_err;
>  }
> @@ -2528,7 +2528,7 @@ static void v9fs_rename(void *opaque)
>  }
>  BUG_ON(fidp->fid_type != P9_FID_NONE);
>  /* if fs driver is not path based, return EOPNOTSUPP */
> -if (!pdu->s->ctx.flags & PATHNAME_FSCONTEXT) {
> +if (!(pdu->s->ctx.flags & PATHNAME_FSCONTEXT)) {
>  err = -EOPNOTSUPP;
>  goto out;
>  }

This is fixed in the new pull request i sent.

http://article.gmane.org/gmane.comp.emulators.qemu/120990
http://repo.or.cz/w/qemu/v9fs.git/commitdiff/c98f1d4a8bb6f779313043d2490093451cf52065?hp=7cca27dfde6435a7846d88e8a1fa927d0ab99919

-aneesh



Re: [Qemu-devel] [PATCH] correctly null terminate the process name

2011-10-17 Thread malc
On Tue, 18 Oct 2011, Stefan Weil wrote:

> Am 18.10.2011 04:06, schrieb Trevor Saunders:
> > strncpy() doesn't garentee the copied string will be null terminated if
> > the original is longer than the length to copy.
> > 
> > Signed-off-by: Trevor Saunders
> > ---
> >   os-posix.c |2 +-
> >   1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/os-posix.c b/os-posix.c
> > index dbf3b24..92dcc97 100644
> > --- a/os-posix.c
> > +++ b/os-posix.c
> > @@ -149,8 +149,8 @@ void os_set_proc_name(const char *s)
> >   char name[16];
> >   if (!s)
> >   return;
> > -name[sizeof(name) - 1] = 0;
> >   strncpy(name, s, sizeof(name));
> > +name[sizeof(name) - 1] = 0;
> >   /* Could rewrite argv[0] too, but that's a bit more complicated.
> >  This simple way is enough for `top'. */
> >   if (prctl(PR_SET_NAME, name)) {
> 
> Reviewed-by: Stefan Weil 

cutils.c has pstrcpy for that.

-- 
mailto:av1...@comtv.ru



Re: [Qemu-devel] [PATCH] virtio-9p: fix QEMU build break

2011-10-17 Thread Aneesh Kumar K.V
On Tue, 18 Oct 2011 14:46:25 +1100, David Gibson  wrote:
> On Mon, Oct 10, 2011 at 10:19:31PM +0530, Aneesh Kumar K.V wrote:
> > On Mon, 10 Oct 2011 22:05:21 +0530, "Aneesh Kumar K.V" 
> >  wrote:
> > > On Mon, 10 Oct 2011 18:30:28 +0800, Zhi Yong Wu 
> > >  wrote:
> > > > qemu build break due to the redefinition of struct file_handle. My 
> > > > qemu.git/HEAD is 8acbc9b21d757a6be4f8492e547b8159703a0547
> > > > 
> > > > Below is the log:
> > > > [root@f15 qemu]# make
> > > >   CCqapi-generated/qga-qapi-types.o
> > > >   LINK  qemu-ga
> > > >   CClibhw64/9pfs/virtio-9p-handle.o
> > > > /home/zwu/work/virt/qemu/hw/9pfs/virtio-9p-handle.c:31:8: error: 
> > > > redefinition of "struct file_handle"
> > > > /usr/include/bits/fcntl.h:254:8: note: originally defined here
> > > > make[1]: *** [9pfs/virtio-9p-handle.o] Error 1
> > > > make: *** [subdir-libhw64] Error 2
> > > > 
> > > > [root@f15 qemu]# rpm -qf /usr/include/bits/fcntl.h
> > > > glibc-headers-2.13.90-9.x86_64
> > > > 
> > > 
> > > Is this a backported glibc ? On my ubuntu system glibc 2.13 doesn't
> > > provide struct file_handle. I also checked glib repo at
> > > http://repo.or.cz/w/glibc.git. The commit introducing struct file_handle
> > > is 
> > > 
> > > $ git describe --contains 158648c0bdda281e252a27c0200dd0ea6f4e0215
> > > glibc-2.14~200
> > > 
> > > 
> > 
> > How about the below patch. This means that handle driver will only work
> > with latest glibc. Even if i have latest kernel, with an older glibc
> > handle fs driver backed will be disabled.
> 
> This looks like the right approach to me, but at least with my
> compiler / libc combinations, the test program isn't quite right:
> because the file_handle pointer is never dereferenced, gcc doesn't
> complain even if it is undefined.
> 
> 
> > diff --git a/configure b/configure
> > index 24b8df4..0216c53 100755
> > --- a/configure
> > +++ b/configure
> > @@ -2551,6 +2551,18 @@ EOF
> >  fi
> >  
> >  ##
> > +# check if we have open_by_handle_at
> > +
> > +open_by_hande_at=no
> > +cat > $TMPC << EOF
> > +#include 
> > +int main(void) { struct file_handle *fh; open_by_handle_at(0, fh, 0); }
> 
> Instead, try this:
> 
> int main(void) { struct file_handle fh; open_by_handle_at(0, &fh, 0); }
> 
> 
> I'd really like to see a patch along these lines merged, so I don't
> have to keep hacking it up manually just to get qemu to compile.

I did send a pull request with the patch 

http://article.gmane.org/gmane.comp.emulators.qemu/120990

I will do a patch on top which will change the configure to what you
suggested above.

-aneesh




[Qemu-devel] [PATCH] RUN_STATE_POSTMIGRATE can be transited from RUN_STATE_PAUSED

2011-10-17 Thread Wen Congyang
The user can run command stop before migration. So the guest's RUN_STATE
can be transisted from RUN_STATE_PAUSED to RUN_STATE_POSTMIGRATE.

Signed-off-by: Wen Congyang 

---
 vl.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/vl.c b/vl.c
index 2dce3ae..efae19c 100644
--- a/vl.c
+++ b/vl.c
@@ -341,6 +341,7 @@ static const RunStateTransition runstate_transitions_def[] 
= {
 { RUN_STATE_IO_ERROR, RUN_STATE_RUNNING },
 
 { RUN_STATE_PAUSED, RUN_STATE_RUNNING },
+{ RUN_STATE_PAUSED, RUN_STATE_POSTMIGRATE },
 
 { RUN_STATE_POSTMIGRATE, RUN_STATE_RUNNING },
 
-- 
1.7.1



[Qemu-devel] how to build RootFS for linux kernel(i386)

2011-10-17 Thread ravikiran borse
Hi All

I need your help to learn linux kernel using QEMU.
I know that there is linux-0.02 Image on your website to download.
It is working fine on my PC. Can u just post me how to make such image from
scratch so that I can use it with GDB.
But I have downloaded my own linux kernel and build it.
But the issue is that it is always giving me an error

Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(1,0)
Is anyone of you can help me to learn how to debug and learn linux kernel
using QEMU(For i386 Processor).
QEMU is the best software for which I am looking for from last 1 year to
learn linux kernel.
Thank Very Muh to all for such good open source software.

Ravikiran D. Borse


Re: [Qemu-devel] [PATCH] correctly null terminate the process name

2011-10-17 Thread Stefan Weil

Am 18.10.2011 04:06, schrieb Trevor Saunders:

strncpy() doesn't garentee the copied string will be null terminated if
the original is longer than the length to copy.

Signed-off-by: Trevor Saunders
---
  os-posix.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/os-posix.c b/os-posix.c
index dbf3b24..92dcc97 100644
--- a/os-posix.c
+++ b/os-posix.c
@@ -149,8 +149,8 @@ void os_set_proc_name(const char *s)
  char name[16];
  if (!s)
  return;
-name[sizeof(name) - 1] = 0;
  strncpy(name, s, sizeof(name));
+name[sizeof(name) - 1] = 0;
  /* Could rewrite argv[0] too, but that's a bit more complicated.
 This simple way is enough for `top'. */
  if (prctl(PR_SET_NAME, name)) {


Reviewed-by: Stefan Weil 




[Qemu-devel] [PATCH] pseries: Correct vmx/dfp handling in both KVM and TCG cases

2011-10-17 Thread David Gibson
Currently, when KVM is enabled, the pseries machine checks if the host
CPU supports VMX, VSX and/or DFP instructions and advertises
accordingly in the guest device tree.  It does this regardless of what
CPU is selected on the command line.  On the other hand, when in TCG
mode, it never advertises any of these facilities, even basic VMX
(Altivec) which is supported in TCG.

Now that we have a -cpu host option for ppc, it is fairly
straightforward to fix both problems.  This patch changes the -cpu
host code to override the basic cpu spec derived from the PVR with
information queried from the host avout VMX, VSX and DFP capability.
The pseries code then uses the instruction availability advertised in
the cpu state to set the guest device tree correctly for both the KVM
and TCG cases.

Signed-off-by: David Gibson 
---
 hw/spapr.c  |   10 +-
 target-ppc/cpu.h|   20 
 target-ppc/kvm.c|   23 ++-
 target-ppc/translate_init.c |   18 ++
 4 files changed, 49 insertions(+), 22 deletions(-)

diff --git a/hw/spapr.c b/hw/spapr.c
index fecfa4a..26333ac 100644
--- a/hw/spapr.c
+++ b/hw/spapr.c
@@ -186,8 +186,6 @@ static void *spapr_create_fdt_skel(const char *cpu_model,
0x, 0x};
 uint32_t tbfreq = kvm_enabled() ? kvmppc_get_tbfreq() : TIMEBASE_FREQ;
 uint32_t cpufreq = kvm_enabled() ? kvmppc_get_clockfreq() : 10;
-uint32_t vmx = kvm_enabled() ? kvmppc_get_vmx() : 0;
-uint32_t dfp = kvm_enabled() ? kvmppc_get_dfp() : 0;
 
 if ((index % smt) != 0) {
 continue;
@@ -239,15 +237,17 @@ static void *spapr_create_fdt_skel(const char *cpu_model,
  *   0 / no property == no vector extensions
  *   1   == VMX / Altivec available
  *   2   == VSX available */
-if (vmx) {
+if (env->insns_flags & PPC_ALTIVEC) {
+uint32_t vmx = (env->insns_flags2 & PPC2_VSX) ? 2 : 1;
+
 _FDT((fdt_property_cell(fdt, "ibm,vmx", vmx)));
 }
 
 /* Advertise DFP (Decimal Floating Point) if available
  *   0 / no property == no DFP
  *   1   == DFP available */
-if (dfp) {
-_FDT((fdt_property_cell(fdt, "ibm,dfp", dfp)));
+if (env->insns_flags2 & PPC2_DFP) {
+_FDT((fdt_property_cell(fdt, "ibm,dfp", 1)));
 }
 
 _FDT((fdt_end_node(fdt)));
diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index 8e5c85c..d177bd4 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -858,6 +858,22 @@ enum {
 /* The whole PowerPC CPU context */
 #define NB_MMU_MODES 3
 
+struct ppc_def_t {
+const char *name;
+uint32_t pvr;
+uint32_t svr;
+uint64_t insns_flags;
+uint64_t insns_flags2;
+uint64_t msr_mask;
+powerpc_mmu_t   mmu_model;
+powerpc_excp_t  excp_model;
+powerpc_input_t bus_model;
+uint32_t flags;
+int bfd_mach;
+void (*init_proc)(CPUPPCState *env);
+int  (*check_pow)(CPUPPCState *env);
+};
+
 struct CPUPPCState {
 /* First are the most commonly used resources
  * during translated code execution
@@ -1844,6 +1860,10 @@ enum {
 
 /* BookE 2.06 PowerPC specification  */
 PPC2_BOOKE206  = 0x0001ULL,
+/* VSX (extensions to Altivec / VMX) */
+PPC2_VSX   = 0x0002ULL,
+/* Decimal Floating Point (DFP)  */
+PPC2_DFP   = 0x0004ULL,
 };
 
 /*/
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 430558b..3d12c5c 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -887,14 +887,35 @@ static inline uint32_t mfpvr(void)
 return pvr;
 }
 
+static void alter_insns(uint64_t *word, uint64_t flags, bool on)
+{
+if (on) {
+*word |= flags;
+} else {
+*word &= ~flags;
+}
+}
+
 const ppc_def_t *kvmppc_host_cpu_def(void)
 {
 uint32_t host_pvr = mfpvr();
 const ppc_def_t *base_spec;
+ppc_def_t *spec;
+uint32_t vmx = kvmppc_get_vmx();
+uint32_t dfp = kvmppc_get_dfp();
 
 base_spec = ppc_find_by_pvr(host_pvr);
 
-return base_spec;
+spec = g_malloc0(sizeof(*spec));
+memcpy(spec, base_spec, sizeof(*spec));
+
+/* Now fix up the spec with information we can query from the host */
+
+alter_insns(&spec->insns_flags, PPC_ALTIVEC, vmx > 0);
+alter_insns(&spec->insns_flags2, PPC2_VSX, vmx > 1);
+alter_insns(&spec->insns_flags2, PPC2_DFP, dfp);
+
+return spec;
 }
 
 bool kvm_arch_stop_on_emulation_error(CPUState *env)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 7de097d..c954192 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -34,22 +34,6 @@
 #define 

[Qemu-devel] buildbot failure in qemu on trivial-patches_i386_debian_6_0

2011-10-17 Thread qemu
The Buildbot has detected a new failure on builder 
trivial-patches_i386_debian_6_0 while building qemu.
Full details are available at:
 
http://buildbot.b1-systems.de/qemu/builders/trivial-patches_i386_debian_6_0/builds/64

Buildbot URL: http://buildbot.b1-systems.de/qemu/

Buildslave for this Build: yuzuki

Build Reason: The Nightly scheduler named 'nightly_trivial-patches' triggered 
this build
Build Source Stamp: [branch trivial-patches] HEAD
Blamelist: 

BUILD FAILED: failed git

sincerely,
 -The Buildbot



Re: [Qemu-devel] [PATCH] virtio-9p: fix QEMU build break

2011-10-17 Thread David Gibson
On Mon, Oct 10, 2011 at 10:19:31PM +0530, Aneesh Kumar K.V wrote:
> On Mon, 10 Oct 2011 22:05:21 +0530, "Aneesh Kumar K.V" 
>  wrote:
> > On Mon, 10 Oct 2011 18:30:28 +0800, Zhi Yong Wu  
> > wrote:
> > > qemu build break due to the redefinition of struct file_handle. My 
> > > qemu.git/HEAD is 8acbc9b21d757a6be4f8492e547b8159703a0547
> > > 
> > > Below is the log:
> > > [root@f15 qemu]# make
> > >   CCqapi-generated/qga-qapi-types.o
> > >   LINK  qemu-ga
> > >   CClibhw64/9pfs/virtio-9p-handle.o
> > > /home/zwu/work/virt/qemu/hw/9pfs/virtio-9p-handle.c:31:8: error: 
> > > redefinition of "struct file_handle"
> > > /usr/include/bits/fcntl.h:254:8: note: originally defined here
> > > make[1]: *** [9pfs/virtio-9p-handle.o] Error 1
> > > make: *** [subdir-libhw64] Error 2
> > > 
> > > [root@f15 qemu]# rpm -qf /usr/include/bits/fcntl.h
> > > glibc-headers-2.13.90-9.x86_64
> > > 
> > 
> > Is this a backported glibc ? On my ubuntu system glibc 2.13 doesn't
> > provide struct file_handle. I also checked glib repo at
> > http://repo.or.cz/w/glibc.git. The commit introducing struct file_handle
> > is 
> > 
> > $ git describe --contains 158648c0bdda281e252a27c0200dd0ea6f4e0215
> > glibc-2.14~200
> > 
> > 
> 
> How about the below patch. This means that handle driver will only work
> with latest glibc. Even if i have latest kernel, with an older glibc
> handle fs driver backed will be disabled.

This looks like the right approach to me, but at least with my
compiler / libc combinations, the test program isn't quite right:
because the file_handle pointer is never dereferenced, gcc doesn't
complain even if it is undefined.


> diff --git a/configure b/configure
> index 24b8df4..0216c53 100755
> --- a/configure
> +++ b/configure
> @@ -2551,6 +2551,18 @@ EOF
>  fi
>  
>  ##
> +# check if we have open_by_handle_at
> +
> +open_by_hande_at=no
> +cat > $TMPC << EOF
> +#include 
> +int main(void) { struct file_handle *fh; open_by_handle_at(0, fh, 0); }

Instead, try this:

int main(void) { struct file_handle fh; open_by_handle_at(0, &fh, 0); }


I'd really like to see a patch along these lines merged, so I don't
have to keep hacking it up manually just to get qemu to compile.


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



[Qemu-devel] buildbot failure in qemu on qmp_x86_64_debian_6_0

2011-10-17 Thread qemu
The Buildbot has detected a new failure on builder qmp_x86_64_debian_6_0 while 
building qemu.
Full details are available at:
 http://buildbot.b1-systems.de/qemu/builders/qmp_x86_64_debian_6_0/builds/64

Buildbot URL: http://buildbot.b1-systems.de/qemu/

Buildslave for this Build: yuzuki

Build Reason: The Nightly scheduler named 'nightly_qmp' triggered this build
Build Source Stamp: [branch queue/qmp] HEAD
Blamelist: 

BUILD FAILED: failed git

sincerely,
 -The Buildbot



Re: [Qemu-devel] Your confirmation is required to leave the Qemu-devel mailing list

2011-10-17 Thread Zhi Yong Wu
confirm c8e639a4a4f5217083c36b0d7184949fb3c420c7
On Mon, Oct 17, 2011 at 10:35:09PM -0400, 
qemu-devel-confirm+c8e639a4a4f5217083c36b0d7184949fb3c42...@nongnu.org wrote:
>Return-Path: 
>Received: from imap.linux.ibm.com ([unix socket])  by imap.linux.ibm.com
> (Cyrus v2.3.16-Fedora-RPM-2.3.16-6.el6_1.3) with LMTPA;  Mon, 17 Oct 2011
> 22:35:24 -0400
>X-Sieve: CMU Sieve 2.3
>Received: from localhost (localhost [127.0.0.1]) by imap.linux.ibm.com
> (Postfix) with ESMTP id 665B6160039F for ; Mon,
> 17 Oct 2011 22:35:24 -0400 (EDT)
>X-Virus-Scanned: amavisd-new at linux.ibm.com
>X-Spam-Flag: NO
>X-Spam-Score: 0.331
>X-Spam-Level:
>X-Spam-Status: No, score=0.331 tagged_above=- required=5
> tests=[FROM_LOCAL_HEX=0.331] autolearn=disabled
>Received: from imap.linux.ibm.com ([127.0.0.1]) by localhost
> (maier.raleigh.ibm.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id
> FLhiwFk6VIOX for ; Mon, 17 Oct 2011 22:35:23
> -0400 (EDT)
>Received: from smtp.linux.ibm.com (smtp.linux.ibm.com [9.26.4.197]) by
> imap.linux.ibm.com (Postfix) with ESMTP id 3298016000D4 for
> ; Mon, 17 Oct 2011 22:35:23 -0400 (EDT)
>Received: from VMSDVMA.POK.IBM.COM (vmsdvma.pok.ibm.com [9.56.231.65]) by
> smtp.linux.ibm.com (Postfix) with ESMTP id F0611C79F7 for
> ; Mon, 17 Oct 2011 22:35:22 -0400 (EDT)
>Received: by VMSDVMA.POK.IBM.COM (IBM VM SMTP Level 540) via spool with SMTP
> id 9604 ; Mon, 17 Oct 2011 22:34:49 EDT
>Received: by vmsdvma.vnet.ibm.com (xagent2 6.3.1) via xagsmtp2 with spool id
> 8769 for wu...@linux.vnet.ibm.com; Mon, 17 Oct 2011 22:34:49 -0400 (EDT)
>Received: from d03relay03.boulder.ibm.com [9.17.195.228] by
> VMSDVMA.POK.IBM.COM (IBM VM SMTP Level 540) via TCP with ESMTP ; Mon, 17
> Oct 2011 22:34:49 EDT
>Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com
> [9.17.195.169])   by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO
> v10.0) with ESMTP id p9I2ZLtL171190   for ; Mon,
> 17 Oct 2011 20:35:21 -0600
>Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1])  by
> d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
> p9I2ZLPD019070for ; Mon, 17 Oct 2011
> 20:35:21 -0600
>Received: from e39.co.us.ibm.com ([9.17.249.49])   by
> d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
> p9I2ZLpI019060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256
> verify=OK)for ; Mon, 17 Oct 2011 20:35:21
> -0600
>Received: from lists.gnu.org (lists.gnu.org [140.186.70.17])   by
> e39.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p9I2JFtc032286
> (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO)for
> ; Mon, 17 Oct 2011 20:19:16 -0600
>Received: from localhost ([::1]:45208 helo=lists.gnu.org)  by
> lists.gnu.org with esmtp (Exim 4.71)  (envelope-from
> ) id
> 1RFzWI-0007v1-9W for wu...@linux.vnet.ibm.com; Mon, 17 Oct 2011 22:35:10
> -0400
>MIME-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"
>Content-Transfer-Encoding: 7bit
>From: qemu-devel-confirm+c8e639a4a4f5217083c36b0d7184949fb3c42...@nongnu.org
>To: wu...@linux.vnet.ibm.com
>Subject: Your confirmation is required to leave the Qemu-devel mailing list
>Reply-To: 
>qemu-devel-confirm+c8e639a4a4f5217083c36b0d7184949fb3c42...@nongnu.org
>Message-ID: 
>Date: Mon, 17 Oct 2011 22:35:09 -0400
>Precedence: bulk
>X-BeenThere: qemu-devel@nongnu.org
>X-Mailman-Version: 2.1.14
>List-Id: 
>X-List-Administrivia: yes
>Errors-To: qemu-devel-bounces+wuzhy=linux.vnet.ibm@nongnu.org
>Sender: qemu-devel-bounces+wuzhy=linux.vnet.ibm@nongnu.org
>X-Brightmail-Tracker: AA==
>X-Xagent-From: 
>qemu-devel-confirm+c8e639a4a4f5217083c36b0d7184949fb3c42...@nongnu.org
>X-Xagent-To: wu...@linux.vnet.ibm.com
>X-Xagent-Gateway: vmsdvma.vnet.ibm.com (XAGENTU2 at VMSDVMA)
>
>Mailing list removal confirmation notice for mailing list Qemu-devel
>
>We have received a request from 202.108.130.153 for the removal of
>your email address, "wu...@linux.vnet.ibm.com" from the
>qemu-devel@nongnu.org mailing list.  To confirm that you want to be
>removed from this mailing list, simply reply to this message, keeping
>the Subject: header intact.  Or visit this web page:
>
>
> https://lists.nongnu.org/mailman/confirm/qemu-devel/c8e639a4a4f5217083c36b0d7184949fb3c420c7
>
>
>Or include the following line -- and only the following line -- in a
>message to qemu-devel-requ...@nongnu.org:
>
>confirm c8e639a4a4f5217083c36b0d7184949fb3c420c7
>
>Note that simply sending a `reply' to this message should work from
>most mail readers, since that usually leaves the Subject: line in the
>right form (additional "Re:" text in the Subject: is okay).
>
>If you do not wish to be removed from this list, please simply
>disregard this message.  If you think you are being maliciously
>removed from the list, or have any other questions, send them to
>qemu-devel-ow...@nongnu.org.




[Qemu-devel] Solution and question: fix for OSX Lion build

2011-10-17 Thread Juan Pineda
Solution: Qemu 0.15 won't run under OS-X Lion because Apple switched to gcc 
LLVM. Actually it will build, but throws a segment fault when run. The cure is 
to build using gcc-4.2 (which is included under Lion.) Additionally darwin-user 
and bsd-user fail to compile. I gather these have been broken for a while now. 
In all, the following command line is required to successfully build and run 
qemu for OS-X Lion:

> ./configure --cc=gcc-4.2 --host-cc=gcc-4.2 --disable-darwin-user 
> --disable-bsd-user

With this configuration I was able to run the test Linux boot images for i386, 
x86_64, sparc32, and coldfire.

Question: In the interest of saving others the pain of debugging this again, I 
though I'd submit a patch. I'm thinking the best fix is to modify the configure 
script to 1) check for the OS revision and availability of gcc-4.2 and then set 
the default compiler to gcc-4.2, and 2) disable the user builds under OSX. 
Sound good? Or is there a more preferred way to fix?

Thanks!
-Juan




[Qemu-devel] [PATCH] correctly null terminate the process name

2011-10-17 Thread Trevor Saunders
strncpy() doesn't garentee the copied string will be null terminated if
the original is longer than the length to copy.

Signed-off-by: Trevor Saunders 
---
 os-posix.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/os-posix.c b/os-posix.c
index dbf3b24..92dcc97 100644
--- a/os-posix.c
+++ b/os-posix.c
@@ -149,8 +149,8 @@ void os_set_proc_name(const char *s)
 char name[16];
 if (!s)
 return;
-name[sizeof(name) - 1] = 0;
 strncpy(name, s, sizeof(name));
+name[sizeof(name) - 1] = 0;
 /* Could rewrite argv[0] too, but that's a bit more complicated.
This simple way is enough for `top'. */
 if (prctl(PR_SET_NAME, name)) {
-- 
1.7.7




Re: [Qemu-devel] [PATCH 1/9] Add stub functions for PCI device models to do PCI DMA

2011-10-17 Thread David Gibson
On Sun, Oct 16, 2011 at 03:15:53PM +0200, Avi Kivity wrote:
> On 10/14/2011 04:14 AM, David Gibson wrote:
> > > Virtio is a very, very special case.  virtio requires coherent RAM access.
> >
> > Right.  Virtio's access to memory is *not* emulated PCI DMA, it's
> > god-like hypervisor access to guest system memory.  It should
> > correctly bypass any IOMMU, and so should remain as
> > cpu_physical_memory_rw() or the atomic accessors, rather than being
> > converted to this new API.
> 
> virtio should definitely not bypass an iommu.

So, I just had a chat with Rusty about this.  Perhaps it shouldn't,
but it does.  The spec is in terms of guest physical addresses, not
bus/DMA addresses, and more to the point the Linux driver does *not*
do the necessary dma_map() and unmap operations to treat this as a PCI
DMA.  So like it or not, god-like hypervisor access rather than
emulated PCI DMA is what it does.

>  A guest may assign a
> virtio device to nested guests, and would wish it confined by the
> emulated iommu.

Well, that would be nice, but it can't be done.  It could be fixed,
but it would be an incompatible change so it would need a new feature
bit corresponding changes in the Linux driver to do the dma map/unmap
if it accepts the "respect IOMMU" feature.

> More generally, a guest sees a virtio device as just another pci device,
> and has no way to tell that it bypasses the iommu.

Well, except the fact that the driver knows its a virtio device,
because it's a virtio driver.  It's not like you can write a driver
that uses PCI DMA without knowing the particulars of the device you're
using.


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




Re: [Qemu-devel] [PATCH] Memory API bugfix - abolish addrrrange_end()

2011-10-17 Thread David Gibson
On Mon, Oct 17, 2011 at 12:34:19PM +0200, Avi Kivity wrote:
> On 10/17/2011 07:31 AM, David Gibson wrote:
> > > 
> > > In terms of how the code looks, it's seriously more ugly (see the
> > > patches I sent out).  Conceptually it's cleaner, since we're not dodging
> > > the issue that we need to deal with a full 64-bit domain.
> >
> > We don't have to dodge that issue.  I know how to remove the
> > requirement for intermediate negative values, I just haven't made up a
> > patch yet.  With that we can change to uint64 and cover the full 64
> > bit range.  In fact I think I can make it so that size==0 represents
> > size=2^64 and even handle the full 64-bit, inclusive range properly.
> 
> That means you can't do a real size == 0.

Yeah... a memory range with size 0 has no effect by definition, I
think we can do without it.

> > > But my main concern is maintainability.  The 64-bit blanket is to short,
> > > if we keep pulling it in various directions we'll just expose ourselves
> > > in new ways.
> >
> > Nonsense, dealing with full X-bit range calculations in X-bit types is
> > a fairly standard problem.  The kernel does it in VMA handling for
> > one.  It just requires thinking about overflow cases.
> 
> We discovered three bugs already (you found two, and I had one during
> development).  Even if it can probably be done with extreme care, but is
> it worth spending all that development time on?
> 
> I'm not sure there is a parallel with vmas, since we're offsetting in
> both the positive and negative directions.

I think the so-called "negative offsetting" is just an artifact of our
implementation.  I don't see that it's any different from having a VMA
whose file offset is larger than its memory address.

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



Re: [Qemu-devel] [PATCH 22/36] migration: Introduce MIG_STATE_SETUP

2011-10-17 Thread Juan Quintela
Anthony Liguori  wrote:
> On 10/11/2011 05:00 AM, Juan Quintela wrote:
> CODING_STYLE.
>
> Regards,
>
> Anthony Liguori

Attached v2 of this patch.  Only change is s/enum migration_state/enum/

>From 990ccd38f0ff916ada859d28831b2be63983c309 Mon Sep 17 00:00:00 2001
Message-Id: 
<990ccd38f0ff916ada859d28831b2be63983c309.1318901257.git.quint...@redhat.com>
In-Reply-To: 
References: 
From: Juan Quintela 
Date: Tue, 11 May 2010 23:01:53 +0200
Subject: [PATCH 22/36] migration: Introduce MIG_STATE_SETUP

Use MIG_STATE_ACTIVE only when migration has really started.  Use this
new state to setup migration parameters.  Change defines for an
anonymous struct.

Signed-off-by: Juan Quintela 
---
 migration.c |6 +-
 migration.h |   11 +++
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/migration.c b/migration.c
index e93f3f7..a01bf4f 100644
--- a/migration.c
+++ b/migration.c
@@ -239,6 +239,9 @@ void do_info_migrate(Monitor *mon, QObject **ret_data)
 MigrationState *s = current_migration;

 switch (s->get_status(current_migration)) {
+case MIG_STATE_SETUP:
+/* no migration has happened ever */
+break;
 case MIG_STATE_ACTIVE:
 qdict = qdict_new();
 qdict_put(qdict, "status", qstring_from_str("active"));
@@ -478,6 +481,7 @@ void migrate_fd_connect(MigrationState *s)
 {
 int ret;

+s->state = MIG_STATE_ACTIVE;
 s->file = qemu_fopen_ops_buffered(s,
   s->bandwidth_limit,
   migrate_fd_put_buffer,
@@ -507,7 +511,7 @@ static MigrationState *migrate_new(Monitor *mon, int64_t 
bandwidth_limit,
 s->shared = inc;
 s->mon = NULL;
 s->bandwidth_limit = bandwidth_limit;
-s->state = MIG_STATE_ACTIVE;
+s->state = MIG_STATE_SETUP;

 if (!detach) {
 migrate_fd_monitor_suspend(s, mon);
diff --git a/migration.h b/migration.h
index 14c3ebc..fed1cf1 100644
--- a/migration.h
+++ b/migration.h
@@ -18,10 +18,13 @@
 #include "qemu-common.h"
 #include "notify.h"

-#define MIG_STATE_ERROR-1
-#define MIG_STATE_COMPLETED0
-#define MIG_STATE_CANCELLED1
-#define MIG_STATE_ACTIVE   2
+enum {
+MIG_STATE_ERROR,
+MIG_STATE_SETUP,
+MIG_STATE_CANCELLED,
+MIG_STATE_ACTIVE,
+MIG_STATE_COMPLETED,
+};

 typedef struct MigrationState MigrationState;

-- 
1.7.6.4




[Qemu-devel] KVM call agenda for October 18

2011-10-17 Thread Juan Quintela

Hi

Please send in any agenda items you are interested in covering.

Thanks, Juan.



[Qemu-devel] Patch for ui/cocoa.m

2011-10-17 Thread Juan Pineda
Hello,

This is my first time submitting a patch, so please let me know if I'm not 
following the correct protocol.

Under OSX Lion the boot volume dialog is not closed and it permanently obscures 
the emulator window since under Lion the dialog cannot be repositioned. The fix 
adds only to add a single line to close the dialog.

Signed-off-by: Juan Pineda 

Thanks!
-Juan


> git diff ui/cocoa.m
diff --git a/ui/cocoa.m b/ui/cocoa.m
index d9e4e3d..4b42462 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -811,6 +811,8 @@ QemuCocoaView *cocoaView;
 
 char **argv = (char**)malloc( sizeof(char*)*3 );
 
+   [sheet close];
+
 asprintf(&argv[0], "%s", bin);
 asprintf(&argv[1], "-hda");
 asprintf(&argv[2], "%s", img);




Re: [Qemu-devel] [PATCH] gdbstub: Fix memory leak

2011-10-17 Thread Stuart Brady
On Mon, Oct 17, 2011 at 10:01:25PM +0200, Stefan Weil wrote:
> 
> The patch also slightly cleans the g_malloc0 statement which was
> touched by that change (no type cast, easier code review).
[...]
> -s = (GDBRegisterState *)g_malloc0(sizeof(GDBRegisterState));
[...]
> +s = g_malloc0(sizeof(*s));

Is this the preferred style, or should we be using:

s = g_new0(GDBRegisterState, 1);

We currently seem to have a mix of the two styles.

I kinda prefer using g_new() (or g_new0()) since provided the 'count'
parameter is correct, it can't really be wrong, whereas using sizeof()
has the potential to be buggy, even if it is still trivial to check
that the code is okay.

I guess I feel g_malloc() would be best reserved for those cases where
we're doing something special which might need a little extra care...

BTW, I've just been experimenting with Coccinelle and produced the
following semantic patch:

   @@ type T; @@
   -(T *)g_malloc(sizeof(T))
   +g_new(T, 1)

   @@ type T; @@
   -(T *)g_malloc0(sizeof(T))
   +g_new0(T, 1)

   @@ type T; expression E; @@
   -(T *)g_malloc(sizeof(T) * E)
   +g_new(T, E)

   @@ type T; expression E; @@
   -(T *)g_malloc0(sizeof(T) * E)
   +g_new0(T, E)

I couldn't get the following working:

   // THIS DOES NOT WORK:
   @@ type T; identifier I; @@
   -T I = g_malloc(sizeof(*I))
   +T I = g_new(T, 1)

I expect this won't work either:

   // THIS PROBABLY DOES NOT WORK EITHER:
   @@ type T; identifier I; @@
   -T I = g_new(T, 1)
   +T I = g_malloc(sizeof(*I))

Cheers,
-- 
Stuart



Re: [Qemu-devel] [RFC][PATCH 11/45] msi: Factor out delivery hook

2011-10-17 Thread Jan Kiszka
On 2011-10-17 14:14, Avi Kivity wrote:
> Can you post a git tree?  It will be easier for me to understand the
> whole thing this way.

Pushed current state to git://git.kiszka.org/qemu-kvm.git queues/msi

Jan



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [RFC][PATCH 06/45] msix: Prevent bogus mask updates on MMIO accesses

2011-10-17 Thread Jan Kiszka
On 2011-10-17 14:50, Michael S. Tsirkin wrote:
> On Mon, Oct 17, 2011 at 02:07:10PM +0200, Jan Kiszka wrote:
>> On 2011-10-17 13:57, Michael S. Tsirkin wrote:
>>> On Mon, Oct 17, 2011 at 01:23:46PM +0200, Jan Kiszka wrote:
 On 2011-10-17 13:10, Michael S. Tsirkin wrote:
> On Mon, Oct 17, 2011 at 11:27:40AM +0200, Jan Kiszka wrote:
>> Only accesses to the MSI-X table must trigger a call to
>> msix_handle_mask_update or a notifier invocation.
>>
>> Signed-off-by: Jan Kiszka 
>
> Why would msix_mmio_write be called on an access
> outside the table?

 Because it handles both the table and the PBA.
>>>
>>> Hmm. Interesting. Is there a bug in how we handle PBA
>>> updates then? If yes I'd like a separate patch for that
>>> to apply to the stable tree.
>>
>> I first thought it was a serious bug, but it just triggers if the guest
>> write to PBA (which is very uncommon) and that actually triggers any
>> spurious out-of-bounds vector injection. Highly unlikely.
> 
> Yes guests don't really use PBA ATM. But is there something
> bad a malicious guest can do? For example, what if
> msix_clr_pending gets invoked with this huge vector value?
> 
> It does seem serious ...

I checked it before and I think it is harmless. The largest vector that
can be miscalculated is 255. But bit 255 in the PBA is still safe inside
our MMIO page.

Jan



signature.asc
Description: OpenPGP digital signature


[Qemu-devel] [PATCH] PPC: Fail configure when libfdt is not available

2011-10-17 Thread Alexander Graf
We have several targets in the PPC tree now that basically require libfdt
to function properly, namely the pseries and the e500 targets. This dependency
will rather increase than decrease in the future, so I want to make sure
that people building shiny new 1.0 actually have libfdt installed to get
rid of a few ifdefs in the code.

Warning: This patch will likely make configure fail for people who don't
select their own --target-list, but don't have libfdt development packages
installed. However, we really need this new dependency to move on.

Signed-off-by: Alexander Graf 
---
 configure |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index 3bdb556..ae0a872 100755
--- a/configure
+++ b/configure
@@ -3389,6 +3389,15 @@ case "$target_arch2" in
   fi
 fi
 esac
+if test "$fdt" != "yes" -a \( "$target_arch2" = "ppc" -o \
+"$target_arch2" = "ppc64" -o "$target_arch2" = "ppcemb" \); then
+  echo
+  echo "Error: libfdt missing"
+  echo "The PowerPC target requires libfdt to work properly."
+  echo "Please make sure to have it and its development packages installed"
+  echo
+  exit 1
+fi
 if test "$target_arch2" = "ppc64" -a "$fdt" = "yes"; then
   echo "CONFIG_PSERIES=y" >> $config_target_mak
 fi
-- 
1.6.0.2




[Qemu-devel] [PATCH] PPC: Disable non-440 CPUs for ppcemb target

2011-10-17 Thread Alexander Graf
The sole reason we have the ppcemb target is to support MMUs that have
less than the usual 4k possible page size. There are very few of these
chips and I don't want to add additional QA and testing burden to everyone
to ensure that code still works when TARGET_PAGE_SIZE is not 4k.

So this patch disables all CPUs except for MMU_BOOKE capable ones from
the ppcemb target.

Signed-off-by: Alexander Graf 
---
 target-ppc/translate_init.c |   24 
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 7de097d..f0ae1d1 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -10047,11 +10047,27 @@ int cpu_ppc_register_internal (CPUPPCState *env, 
const ppc_def_t *def)
 return 0;
 }
 
+static bool ppc_cpu_usable(const ppc_def_t *def)
+{
+#if defined(TARGET_PPCEMB)
+/* When using the ppcemb target, we only support 440 style cores */
+if (def->mmu_model != POWERPC_MMU_BOOKE) {
+return false;
+}
+#endif
+
+return true;
+}
+
 const ppc_def_t *ppc_find_by_pvr(uint32_t pvr)
 {
 int i;
 
 for (i = 0; i < ARRAY_SIZE(ppc_defs); i++) {
+if (!ppc_cpu_usable(&ppc_defs[i])) {
+continue;
+}
+
 /* If we have an exact match, we're done */
 if (pvr == ppc_defs[i].pvr) {
 return &ppc_defs[i];
@@ -10091,6 +10107,10 @@ const ppc_def_t *cpu_ppc_find_by_name (const char 
*name)
 ret = NULL;
 max = ARRAY_SIZE(ppc_defs);
 for (i = 0; i < max; i++) {
+if (!ppc_cpu_usable(&ppc_defs[i])) {
+continue;
+}
+
 if (strcasecmp(name, ppc_defs[i].name) == 0) {
 ret = &ppc_defs[i];
 break;
@@ -10106,6 +10126,10 @@ void ppc_cpu_list (FILE *f, fprintf_function 
cpu_fprintf)
 
 max = ARRAY_SIZE(ppc_defs);
 for (i = 0; i < max; i++) {
+if (!ppc_cpu_usable(&ppc_defs[i])) {
+continue;
+}
+
 (*cpu_fprintf)(f, "PowerPC %-16s PVR %08x\n",
ppc_defs[i].name, ppc_defs[i].pvr);
 }
-- 
1.6.0.2




[Qemu-devel] [PATCH] PPC: Bump qemu-system-ppc to 64-bit physical address space

2011-10-17 Thread Alexander Graf
Some 32-bit PPC CPUs can use up to 36 bit of physicall address space.
Treat them accordingly in the qemu-system-ppc binary type.

Signed-off-by: Alexander Graf 
---
 configure|2 +-
 target-ppc/cpu.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 9b4fe34..3bdb556 100755
--- a/configure
+++ b/configure
@@ -3276,7 +3276,7 @@ case "$target_arch2" in
   ;;
   ppc)
 gdb_xml_files="power-core.xml power-fpu.xml power-altivec.xml 
power-spe.xml"
-target_phys_bits=32
+target_phys_bits=64
 target_nptl="yes"
 target_libs_softmmu="$fdt_libs"
   ;;
diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index 8e5c85c..f36f375 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -66,7 +66,7 @@
 #define TARGET_PAGE_BITS 12
 #endif /* defined(TARGET_PPCEMB) */
 
-#define TARGET_PHYS_ADDR_SPACE_BITS 32
+#define TARGET_PHYS_ADDR_SPACE_BITS 36
 #define TARGET_VIRT_ADDR_SPACE_BITS 32
 
 #endif /* defined (TARGET_PPC64) */
-- 
1.6.0.2




Re: [Qemu-devel] [RFC][PATCH 11/45] msi: Factor out delivery hook

2011-10-17 Thread Jan Kiszka
On 2011-10-17 15:43, Michael S. Tsirkin wrote:
> On Mon, Oct 17, 2011 at 11:27:45AM +0200, Jan Kiszka wrote:
>> diff --git a/hw/msi.c b/hw/msi.c
>> index 3c7ebc3..9055155 100644
>> --- a/hw/msi.c
>> +++ b/hw/msi.c
>> @@ -40,6 +40,14 @@
>>  /* Flag for interrupt controller to declare MSI/MSI-X support */
>>  bool msi_supported;
>>  
>> +static void msi_unsupported(MSIMessage *msg)
>> +{
>> +/* If we get here, the board failed to register a delivery handler. */
>> +abort();
>> +}
>> +
>> +void (*msi_deliver)(MSIMessage *msg) = msi_unsupported;
>> +
> 
> How about we set this to NULL, and check it instead of the bool
> flag?
> 

Yeah. I will introduce

bool msi_supported(void)
{
return msi_deliver != msi_unsupported;
}

OK?

Jan



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp

2011-10-17 Thread Kai Tietz
2011/10/18 Bob Breuer :
> Kai Tietz wrote:
>> 2011/10/17 Bob Breuer :
>>> Richard Henderson wrote:
 On 10/17/2011 07:09 AM, Bob Breuer wrote:
> I don't think this is a free/g_free issue.  If I use the following
> patch, then I at least get the openbios messages:
>
> diff --git a/cpu-exec.c b/cpu-exec.c
> index a9fa608..dfbd6ea 100644
> --- a/cpu-exec.c
> +++ b/cpu-exec.c
> @@ -180,6 +180,7 @@ static void cpu_handle_debug_exception(CPUState
>  /* main execution loop */
>
>  volatile sig_atomic_t exit_request;
> +register void *ebp asm("ebp");
>
>  int cpu_exec(CPUState *env)
>  {
> @@ -233,6 +234,8 @@ int cpu_exec(CPUState *env)
>
>      /* prepare setjmp context for exception handling */
>      for(;;) {
> +        int dummy = 0;
> +        ebp = &dummy;
 See if

   asm("" : : : "ebp");

 also solves the problem.
>>> No, that doesn't fix it.
>>>
> Google finds a mention of longjmp failing with -fomit-frame-pointer:
> http://lua-users.org/lists/lua-l/2005-02/msg00158.html
>
> Looks like gcc 4.6 turns on -fomit-frame-pointer by default.
 Hmm.  This is the first I've heard of a longjmp implementation
 failing without a frame pointer.  Presumably this is with the
 mingw i.e. msvc libc?
>>> Yeah, mingw from www.mingw.org which I believe uses msvcrt.dll, package
>>> gcc-core-4.6.1-2-mingw32-bin.
>>>
 This is something that could be worked around in gcc, I suppose.
 We recognize longjmp for some things, we could force the use of
 a frame pointer for msvc targets too.

 For now it might be best to simply force -fno-omit-frame-pointer
 for mingw host in the configure script.
>>> Here's a testcase that crashes on the longjmp:
>>>
>>> #include 
>>> #include 
>>>
>>> jmp_buf env;
>>>
>>> int test(void)
>>> {
>>>  int i;
>>>
>>>  asm("xor %%ebp,%%ebp" ::: "ebp");
>>>
>>>  i = setjmp(env);
>>>  printf("i = %d\n", i);
>>>
>>>  if (i == 0)
>>>    longjmp(env, 2);
>>>
>>>  return i;
>>> }
>>>
>>> int main(void)
>>> {
>>>  return test();
>>> }
>>>
>>> Remove the asm statement to make it not crash.  Obviously with
>>> omit-frame-pointer, gcc can shove anything into ebp.
>>>
>>> Bob
>>
>> This crash isn'r related to ebp existing, or not. The issue is the
>> hidden argument of setjmp, which is missing.  If you can try the
>> following at top of file after include section.
>>
>> #define setjmp(BUF) _setjmpex((BUF), NULL)
>> int __cdecl __attribute__ ((__nothrow__,__returns_twice__))
>> _setjmp3(jmp_buf _Buf, void *_Ctx);
>> ...
>
> Did you mean _setjmp3 instead of _setjmpex?  With _setjmp3, it works
> without the asm, but still crashes if I zero out ebp before the setjmp.
>  Aren't the function arguments on the stack anyway?

Yes, I mean _setjmp3 (pasto from headers and missed the second line
prototyping _setjmp3).
I repeat myself here.  setjmp() has an hidden arguement, which is
passed on x86 on stack.  By not passing this required argument, setjmp
will take a random-value from stack.  In your case 'i'.  btw if you
would pre-initialize 'i' with zero, I would assume you won't see a
crash, but anyway this is just by chance.
For this I suggest to use here _setjmp3 instead, as here
second-argument is documented as being present.

Btw I tested your code with i686-pc-mingw32 version 4.6.x and 4.7.x
gcc version.  With my suggested pattern, I don't see a crash for your
provide test-code with, or without zero-ing ebp.

Kai



Re: [Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp

2011-10-17 Thread Bob Breuer
Kai Tietz wrote:
> 2011/10/17 Bob Breuer :
>> Richard Henderson wrote:
>>> On 10/17/2011 07:09 AM, Bob Breuer wrote:
 I don't think this is a free/g_free issue.  If I use the following
 patch, then I at least get the openbios messages:

 diff --git a/cpu-exec.c b/cpu-exec.c
 index a9fa608..dfbd6ea 100644
 --- a/cpu-exec.c
 +++ b/cpu-exec.c
 @@ -180,6 +180,7 @@ static void cpu_handle_debug_exception(CPUState
  /* main execution loop */

  volatile sig_atomic_t exit_request;
 +register void *ebp asm("ebp");

  int cpu_exec(CPUState *env)
  {
 @@ -233,6 +234,8 @@ int cpu_exec(CPUState *env)

  /* prepare setjmp context for exception handling */
  for(;;) {
 +int dummy = 0;
 +ebp = &dummy;
>>> See if
>>>
>>>   asm("" : : : "ebp");
>>>
>>> also solves the problem.
>> No, that doesn't fix it.
>>
 Google finds a mention of longjmp failing with -fomit-frame-pointer:
 http://lua-users.org/lists/lua-l/2005-02/msg00158.html

 Looks like gcc 4.6 turns on -fomit-frame-pointer by default.
>>> Hmm.  This is the first I've heard of a longjmp implementation
>>> failing without a frame pointer.  Presumably this is with the
>>> mingw i.e. msvc libc?
>> Yeah, mingw from www.mingw.org which I believe uses msvcrt.dll, package
>> gcc-core-4.6.1-2-mingw32-bin.
>>
>>> This is something that could be worked around in gcc, I suppose.
>>> We recognize longjmp for some things, we could force the use of
>>> a frame pointer for msvc targets too.
>>>
>>> For now it might be best to simply force -fno-omit-frame-pointer
>>> for mingw host in the configure script.
>> Here's a testcase that crashes on the longjmp:
>>
>> #include 
>> #include 
>>
>> jmp_buf env;
>>
>> int test(void)
>> {
>>  int i;
>>
>>  asm("xor %%ebp,%%ebp" ::: "ebp");
>>
>>  i = setjmp(env);
>>  printf("i = %d\n", i);
>>
>>  if (i == 0)
>>longjmp(env, 2);
>>
>>  return i;
>> }
>>
>> int main(void)
>> {
>>  return test();
>> }
>>
>> Remove the asm statement to make it not crash.  Obviously with
>> omit-frame-pointer, gcc can shove anything into ebp.
>>
>> Bob
> 
> This crash isn'r related to ebp existing, or not. The issue is the
> hidden argument of setjmp, which is missing.  If you can try the
> following at top of file after include section.
> 
> #define setjmp(BUF) _setjmpex((BUF), NULL)
> int __cdecl __attribute__ ((__nothrow__,__returns_twice__))
> _setjmp3(jmp_buf _Buf, void *_Ctx);
> ...

Did you mean _setjmp3 instead of _setjmpex?  With _setjmp3, it works
without the asm, but still crashes if I zero out ebp before the setjmp.
 Aren't the function arguments on the stack anyway?

> 
> This will work as expected with or without omit-frame-pointer.
> 
> The issue is that setjmp has a second (undocumented as usual)
> argument, which has a meaning.

So why does my testcase above fail with the asm, but work without the
asm statement?  Compile it with gcc -O2 and try it yourself.

> 
> Regards,
> Kai
> 
> PS:  _setjmp3 is an export from msvcrt.dll.  So if symbol is missing
> on link, simply specify msvcrt.dll as argument to link-line.





[Qemu-devel] [Bug 874038] Re: ARM thumb2 does not propogate carry flag properly

2011-10-17 Thread Peter Maydell
> 0.15.0 fails for me.

Hmm. Works for me:

pm215@canth:/tmp$ wget http://wiki.qemu.org/download/qemu-0.15.0.tar.gz
[...]
pm215@canth:/tmp$ tar xzf qemu-0.15.0.tar.gz 
pm215@canth:/tmp$ cd qemu-0.15.0/
pm215@canth:/tmp/qemu-0.15.0$ ./configure --target-list=arm-linux-user && make 
-j4
[...]
pm215@canth:/tmp/qemu-0.15.0$ ./arm-linux-user/qemu-arm ~/Desktop/mvns_imm.exe 
pm215@canth:/tmp/qemu-0.15.0$ echo $?
0

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

Title:
  ARM thumb2 does not propogate carry flag properly

Status in QEMU:
  New

Bug description:
  information on carry flag is lost if gen_set_CF_bit31(t1) is called
  after logic operation.

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



Re: [Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp

2011-10-17 Thread Kai Tietz
2011/10/17 Bob Breuer :
> Richard Henderson wrote:
>> On 10/17/2011 07:09 AM, Bob Breuer wrote:
>>> I don't think this is a free/g_free issue.  If I use the following
>>> patch, then I at least get the openbios messages:
>>>
>>> diff --git a/cpu-exec.c b/cpu-exec.c
>>> index a9fa608..dfbd6ea 100644
>>> --- a/cpu-exec.c
>>> +++ b/cpu-exec.c
>>> @@ -180,6 +180,7 @@ static void cpu_handle_debug_exception(CPUState
>>>  /* main execution loop */
>>>
>>>  volatile sig_atomic_t exit_request;
>>> +register void *ebp asm("ebp");
>>>
>>>  int cpu_exec(CPUState *env)
>>>  {
>>> @@ -233,6 +234,8 @@ int cpu_exec(CPUState *env)
>>>
>>>      /* prepare setjmp context for exception handling */
>>>      for(;;) {
>>> +        int dummy = 0;
>>> +        ebp = &dummy;
>>
>> See if
>>
>>   asm("" : : : "ebp");
>>
>> also solves the problem.
>
> No, that doesn't fix it.
>
>>
>>> Google finds a mention of longjmp failing with -fomit-frame-pointer:
>>> http://lua-users.org/lists/lua-l/2005-02/msg00158.html
>>>
>>> Looks like gcc 4.6 turns on -fomit-frame-pointer by default.
>>
>> Hmm.  This is the first I've heard of a longjmp implementation
>> failing without a frame pointer.  Presumably this is with the
>> mingw i.e. msvc libc?
>
> Yeah, mingw from www.mingw.org which I believe uses msvcrt.dll, package
> gcc-core-4.6.1-2-mingw32-bin.
>
>> This is something that could be worked around in gcc, I suppose.
>> We recognize longjmp for some things, we could force the use of
>> a frame pointer for msvc targets too.
>>
>> For now it might be best to simply force -fno-omit-frame-pointer
>> for mingw host in the configure script.
>
> Here's a testcase that crashes on the longjmp:
>
> #include 
> #include 
>
> jmp_buf env;
>
> int test(void)
> {
>  int i;
>
>  asm("xor %%ebp,%%ebp" ::: "ebp");
>
>  i = setjmp(env);
>  printf("i = %d\n", i);
>
>  if (i == 0)
>    longjmp(env, 2);
>
>  return i;
> }
>
> int main(void)
> {
>  return test();
> }
>
> Remove the asm statement to make it not crash.  Obviously with
> omit-frame-pointer, gcc can shove anything into ebp.
>
> Bob

This crash isn'r related to ebp existing, or not. The issue is the
hidden argument of setjmp, which is missing.  If you can try the
following at top of file after include section.

#define setjmp(BUF) _setjmpex((BUF), NULL)
int __cdecl __attribute__ ((__nothrow__,__returns_twice__))
_setjmp3(jmp_buf _Buf, void *_Ctx);
...

This will work as expected with or without omit-frame-pointer.

The issue is that setjmp has a second (undocumented as usual)
argument, which has a meaning.

Regards,
Kai

PS:  _setjmp3 is an export from msvcrt.dll.  So if symbol is missing
on link, simply specify msvcrt.dll as argument to link-line.



Re: [Qemu-devel] [PATCH 4/4] qapi-types.py: Drop unused variable

2011-10-17 Thread Michael Roth
Reviewed-by: Michael Roth 

On Mon, 17 Oct 2011 13:29:37 -0200, Luiz Capitulino  
wrote:
> Signed-off-by: Luiz Capitulino 
> ---
>  scripts/qapi-types.py |1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py
> index 4a2ddc4..28d7f01 100644
> --- a/scripts/qapi-types.py
> +++ b/scripts/qapi-types.py
> @@ -65,7 +65,6 @@ def generate_enum_lookup(name, values):
>  const char *%(name)s_lookup[] = {
>  ''',
>   name=name)
> -i = 0
>  for value in values:
>  ret += mcgen('''
>  "%(value)s",
> -- 
> 1.7.7.rc3
> 

-- 
Sincerely,
Mike Roth
IBM Linux Technology Center



Re: [Qemu-devel] [PATCH 3/4] qapi-types.py: Fail gracefully if out dir is not specified

2011-10-17 Thread Michael Roth
On Mon, 17 Oct 2011 13:29:36 -0200, Luiz Capitulino  
wrote:
> Otherwise we get:
> 
> Traceback (most recent call last):
>   File "./scripts/qapi-types.py", line 183, in 
>   os.makedirs(output_dir)
> File "/usr/lib64/python2.7/os.py", line 157, in makedirs
>   mkdir(name, mode)
>   OSError: [Errno 2] No such file or directory: ''
> 
> Signed-off-by: Luiz Capitulino 
> ---
>  scripts/qapi-types.py |6 +-
>  1 files changed, 5 insertions(+), 1 deletions(-)
> 
> diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py
> index 8df4b72..4a2ddc4 100644
> --- a/scripts/qapi-types.py
> +++ b/scripts/qapi-types.py
> @@ -178,7 +178,11 @@ if __name__ == '__main__':
>  prefix = a
>  elif o in ("-o", "--output-dir"):
>  output_dir = a
> -
> +
> +if not output_dir:
> +sys.stdout.write("ouput directory was not specified\n")
> +sys.exit(1)
> +   

We should probably just set output_dir to os.getcwd() here.

>  c_file = os.path.join(output_dir, prefix + c_file)
>  h_file = os.path.join(output_dir, prefix + h_file)
>  
> -- 
> 1.7.7.rc3
> 

-- 
Sincerely,
Mike Roth
IBM Linux Technology Center



Re: [Qemu-devel] [PATCH 2/4] qapi-types.py: Don't build paths by hand

2011-10-17 Thread Michael Roth
Reviewed-by: Michael Roth 

On Mon, 17 Oct 2011 13:29:35 -0200, Luiz Capitulino  
wrote:
> Use os.path.join() instead.
> 
> Signed-off-by: Luiz Capitulino 
> ---
>  scripts/qapi-types.py |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py
> index 986ff1e..8df4b72 100644
> --- a/scripts/qapi-types.py
> +++ b/scripts/qapi-types.py
> @@ -177,10 +177,10 @@ if __name__ == '__main__':
>  if o in ("-p", "--prefix"):
>  prefix = a
>  elif o in ("-o", "--output-dir"):
> -output_dir = a + "/"
> +output_dir = a
>  
> -c_file = output_dir + prefix + c_file
> -h_file = output_dir + prefix + h_file
> +c_file = os.path.join(output_dir, prefix + c_file)
> +h_file = os.path.join(output_dir, prefix + h_file)
>  
>  try:
>  os.makedirs(output_dir)
> -- 
> 1.7.7.rc3
> 

-- 
Sincerely,
Mike Roth
IBM Linux Technology Center



Re: [Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp

2011-10-17 Thread Bob Breuer
Richard Henderson wrote:
> On 10/17/2011 07:09 AM, Bob Breuer wrote:
>> I don't think this is a free/g_free issue.  If I use the following
>> patch, then I at least get the openbios messages:
>>
>> diff --git a/cpu-exec.c b/cpu-exec.c
>> index a9fa608..dfbd6ea 100644
>> --- a/cpu-exec.c
>> +++ b/cpu-exec.c
>> @@ -180,6 +180,7 @@ static void cpu_handle_debug_exception(CPUState
>>  /* main execution loop */
>>
>>  volatile sig_atomic_t exit_request;
>> +register void *ebp asm("ebp");
>>
>>  int cpu_exec(CPUState *env)
>>  {
>> @@ -233,6 +234,8 @@ int cpu_exec(CPUState *env)
>>
>>  /* prepare setjmp context for exception handling */
>>  for(;;) {
>> +int dummy = 0;
>> +ebp = &dummy;
> 
> See if
> 
>   asm("" : : : "ebp");
> 
> also solves the problem.

No, that doesn't fix it.

> 
>> Google finds a mention of longjmp failing with -fomit-frame-pointer:
>> http://lua-users.org/lists/lua-l/2005-02/msg00158.html
>>
>> Looks like gcc 4.6 turns on -fomit-frame-pointer by default.
> 
> Hmm.  This is the first I've heard of a longjmp implementation 
> failing without a frame pointer.  Presumably this is with the
> mingw i.e. msvc libc?

Yeah, mingw from www.mingw.org which I believe uses msvcrt.dll, package
gcc-core-4.6.1-2-mingw32-bin.

> This is something that could be worked around in gcc, I suppose.
> We recognize longjmp for some things, we could force the use of
> a frame pointer for msvc targets too.
> 
> For now it might be best to simply force -fno-omit-frame-pointer
> for mingw host in the configure script.

Here's a testcase that crashes on the longjmp:

#include 
#include 

jmp_buf env;

int test(void)
{
  int i;

  asm("xor %%ebp,%%ebp" ::: "ebp");

  i = setjmp(env);
  printf("i = %d\n", i);

  if (i == 0)
longjmp(env, 2);

  return i;
}

int main(void)
{
  return test();
}

Remove the asm statement to make it not crash.  Obviously with
omit-frame-pointer, gcc can shove anything into ebp.

Bob



Re: [Qemu-devel] [PATCH 1/4] qapi-types.py: Add a main() like function

2011-10-17 Thread Michael Roth
Reviewed-by: Michael Roth 

On Mon, 17 Oct 2011 13:29:34 -0200, Luiz Capitulino  
wrote:
> Makes it easier to read the code.
> 
> Signed-off-by: Luiz Capitulino 
> ---
>  scripts/qapi-types.py |  230 
>  1 files changed, 115 insertions(+), 115 deletions(-)
> 
> diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py
> index f64d84c..986ff1e 100644
> --- a/scripts/qapi-types.py
> +++ b/scripts/qapi-types.py
> @@ -161,118 +161,118 @@ void qapi_free_%(type)s(%(c_type)s obj)
>  c_type=c_type(name),type=name)
>  return ret
> 
> -
> -try:
> -opts, args = getopt.gnu_getopt(sys.argv[1:], "p:o:", ["prefix=", 
> "output-dir="])
> -except getopt.GetoptError, err:
> -print str(err)
> -sys.exit(1)
> -
> -output_dir = ""
> -prefix = ""
> -c_file = 'qapi-types.c'
> -h_file = 'qapi-types.h'
> -
> -for o, a in opts:
> -if o in ("-p", "--prefix"):
> -prefix = a
> -elif o in ("-o", "--output-dir"):
> -output_dir = a + "/"
> -
> -c_file = output_dir + prefix + c_file
> -h_file = output_dir + prefix + h_file
> -
> -try:
> -os.makedirs(output_dir)
> -except os.error, e:
> -if e.errno != errno.EEXIST:
> -raise
> -
> -fdef = open(c_file, 'w')
> -fdecl = open(h_file, 'w')
> -
> -fdef.write(mcgen('''
> -/* AUTOMATICALLY GENERATED, DO NOT MODIFY */
> -
> -/*
> - * deallocation functions for schema-defined QAPI types
> - *
> - * Copyright IBM, Corp. 2011
> - *
> - * Authors:
> - *  Anthony Liguori   
> - *  Michael Roth  
> - *
> - * This work is licensed under the terms of the GNU LGPL, version 2.1 or 
> later.
> - * See the COPYING.LIB file in the top-level directory.
> - *
> - */
> -
> -#include "qapi/qapi-dealloc-visitor.h"
> -#include "%(prefix)sqapi-types.h"
> -#include "%(prefix)sqapi-visit.h"
> -
> -''', prefix=prefix))
> -
> -fdecl.write(mcgen('''
> -/* AUTOMATICALLY GENERATED, DO NOT MODIFY */
> -
> -/*
> - * schema-defined QAPI types
> - *
> - * Copyright IBM, Corp. 2011
> - *
> - * Authors:
> - *  Anthony Liguori   
> - *
> - * This work is licensed under the terms of the GNU LGPL, version 2.1 or 
> later.
> - * See the COPYING.LIB file in the top-level directory.
> - *
> - */
> -
> -#ifndef %(guard)s
> -#define %(guard)s
> -
> -#include "qapi/qapi-types-core.h"
> -''',
> -  guard=guardname(h_file)))
> -
> -exprs = parse_schema(sys.stdin)
> -
> -for expr in exprs:
> -ret = "\n"
> -if expr.has_key('type'):
> -ret += generate_fwd_struct(expr['type'], expr['data'])
> -elif expr.has_key('enum'):
> -ret += generate_enum(expr['enum'], expr['data'])
> -fdef.write(generate_enum_lookup(expr['enum'], expr['data']))
> -elif expr.has_key('union'):
> -ret += generate_fwd_struct(expr['union'], expr['data']) + "\n"
> -ret += generate_enum('%sKind' % expr['union'], expr['data'].keys())
> -else:
> -continue
> -fdecl.write(ret)
> -
> -for expr in exprs:
> -ret = "\n"
> -if expr.has_key('type'):
> -ret += generate_struct(expr['type'], "", expr['data']) + "\n"
> -ret += generate_type_cleanup_decl(expr['type'] + "List")
> -fdef.write(generate_type_cleanup(expr['type'] + "List") + "\n")
> -ret += generate_type_cleanup_decl(expr['type'])
> -fdef.write(generate_type_cleanup(expr['type']) + "\n")
> -elif expr.has_key('union'):
> -ret += generate_union(expr['union'], expr['data'])
> -else:
> -continue
> -fdecl.write(ret)
> -
> -fdecl.write('''
> -#endif
> -''')
> -
> -fdecl.flush()
> -fdecl.close()
> -
> -fdef.flush()
> -fdef.close()
> +if __name__ == '__main__':
> +try:
> +opts, args = getopt.gnu_getopt(sys.argv[1:], "p:o:", ["prefix=", 
> "output-dir="])
> +except getopt.GetoptError, err:
> +print str(err)
> +sys.exit(1)
> +
> +output_dir = ""
> +prefix = ""
> +c_file = 'qapi-types.c'
> +h_file = 'qapi-types.h'
> +
> +for o, a in opts:
> +if o in ("-p", "--prefix"):
> +prefix = a
> +elif o in ("-o", "--output-dir"):
> +output_dir = a + "/"
> +
> +c_file = output_dir + prefix + c_file
> +h_file = output_dir + prefix + h_file
> +
> +try:
> +os.makedirs(output_dir)
> +except os.error, e:
> +if e.errno != errno.EEXIST:
> +raise
> +
> +fdef = open(c_file, 'w')
> +fdecl = open(h_file, 'w')
> +
> +fdef.write(mcgen('''
> +/* AUTOMATICALLY GENERATED, DO NOT MODIFY */
> +
> +/*
> + * deallocation functions for schema-defined QAPI types
> + *
> + * Copyright IBM, Corp. 2011
> + *
> + * Authors:
> + *  Anthony Liguori   
> + *  Michael Roth  
> + *
> + * This work is licensed under the terms of the GNU LGPL, version 2.1 or 
> later.
> + * See the COPYING.LIB file in the top-level directory.
> + *
> + */
> +
> +#include "

Re: [Qemu-devel] [RFC][PATCH 23/45] qemu-kvm: Rework MSI-X mask notifier to generic MSI config notifiers

2011-10-17 Thread Jan Kiszka
On 2011-10-17 14:39, Michael S. Tsirkin wrote:
> On Mon, Oct 17, 2011 at 01:45:04PM +0200, Jan Kiszka wrote:
>> On 2011-10-17 13:40, Michael S. Tsirkin wrote:
>>> On Mon, Oct 17, 2011 at 11:27:57AM +0200, Jan Kiszka wrote:
 MSI config notifiers are supposed to be triggered on every relevant
 configuration change of MSI vectors or if MSI is enabled/disabled.

 Two notifiers are established, one for vector changes and one for general
 enabling. The former notifier additionally passes the currently active
 MSI message.
 This will allow to update potential in-kernel IRQ routes on
 changes. The latter notifier is optional and will only be used by a
 subset of clients.

 These notifiers are currently only available for MSI-X but will be
 extended to legacy MSI as well.

 Signed-off-by: Jan Kiszka 
>>>
>>> Passing message, always, does not seem to make sense: message is only
>>> valid if it is unmasked.
>>
>> If we go from unmasked to masked, the consumer could just ignore the
>> message.
> 
> Why don't we let the consumer get the message if it needs it?

Because most consumer will need and because I want to keep the API simple.

> 
>>> Further, IIRC the spec requires any changes to be done while
>>> message is masked. So mask notifier makes more sense to me:
>>> it does the same thing using one notifier that you do
>>> using two notifiers.
>>
>> That's in fact a possible optimization (only invoke the callback on mask
>> transitions).
> 
> Further, it is one that is already implemented.
> So I would prefer not to add work by removing it :)

Generalization to cover MSI requires some changes. Unneeded behavioral
changes back and forth should and will of course be avoided. I will
rework this.

> 
>> Not sure if that applies to MSI as well, probably not.
> 
> Probably not. However, if per vector masking is
> supported, and while vector is masked, the address/
> data values might not make any sense.
> 
> So I think even msi users needs to know about masked state.

Yes, and they get this information via the config notifier.

> 
>> To
>> have common types, I would prefer to stay with vector config notifiers
>> as name then.
>>
>> Jan
> 
> So we pass in nonsense values and ask all users to know about MSIX rules.
> Ugh.
> 
> I do realize msi might change the vector without masking.
> We can either artificially call mask before value change
> and unmask after, or use 3 notifiers: mask,unmask,config.
> Add a comment that config is invoked when configuration
> for an unmasked vector is changed, and that
> it can only happen for msi, not msix.

I see no need in complicating the API like this. MSI-X still needs the
config information on unmask, so let's just consistently pass it via the
unified config notifier instead of forcing the consumers to create yet
two more handlers. I really do not see the benefit for the consumer.

Jan



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH 18/18] tcx: convert to memory API

2011-10-17 Thread Avi Kivity
On 10/17/2011 09:13 PM, Blue Swirl wrote:
> >
> > -ret = cpu_physical_memory_get_dirty(page, VGA_DIRTY_FLAG);
> > +ret = memory_region_get_dirty(&s->vram_mem, page, DIRTY_MEMORY_VGA);
> > for (off = 0; off < TARGET_PAGE_SIZE * 4; off += TARGET_PAGE_SIZE) {
> > -ret |= cpu_physical_memory_get_dirty(page24 + off, VGA_DIRTY_FLAG);
> > -ret |= cpu_physical_memory_get_dirty(cpage + off, VGA_DIRTY_FLAG);
> > +ret |= memory_region_get_dirty(&s->vram_mem, page24 + off,
> > +   DIRTY_MEMORY_VGA);
> > +ret |= memory_region_get_dirty(&s->vram_mem, cpage + off,
> > +   DIRTY_MEMORY_VGA);
>
> Like memory_region_set_dirty(), this should be changed to take a range
> so that the for loops and PAGE_SIZEs can be dropped.

Agree.  Lets' keep it outside this conversion patchset though.

What would the API look like?  accept a range, return true if any of the
pages in the range are dirty?

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.




Re: [Qemu-devel] GPLv3 troubles

2011-10-17 Thread Avi Kivity
On 10/17/2011 07:46 PM, Stefan Weil wrote:
>
> So let's start. For any of my contributions, I agree to GPL v2 or later.
> Later generations should have the possibility to replace GPL v2 by
> something which matches future requirements.

I expect Red Hat contributions can be relicensed to v2+ as well.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.




Re: [Qemu-devel] [PATCH v2 00/13] allow tools to use the QEMU main loop

2011-10-17 Thread Paolo Bonzini

On 10/17/2011 10:11 PM, Anthony Liguori wrote:

Leftover from RFC. Right now, this is just a chainsaw cleanup.
However, Kevin
has plans to use the main loop everywhere (making qemu-io and qemu-img
one huge
coroutine).


Can you add something to docs that explains how to use the new main loop?


Yes, of course.

Paolo




Re: [Qemu-devel] [Bug 874038] Re: ARM thumb2 does not propogate carry flag properly

2011-10-17 Thread Alexey Starikovskiy
0.15.0 fails for me.

On Mon, Oct 17, 2011 at 10:06 PM, Peter Maydell
 wrote:
> Current git master works for me on that test program without your patch:
> cam-vm-266:maverick:qemu$ ./arm-linux-user/qemu-arm ~/Desktop/mvns_imm.exe
> cam-vm-266:maverick:qemu$ echo $?
> 0
>
> (I tested on qemu-0.14 just to confirm that I'm running the test program
> correctly, and that indeed fails as I would expect it to, exiting with
> status 255.)
>
> Which qemu version have you been testing with?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/874038
>
> Title:
>  ARM thumb2 does not propogate carry flag properly
>
> Status in QEMU:
>  New
>
> Bug description:
>  information on carry flag is lost if gen_set_CF_bit31(t1) is called
>  after logic operation.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/874038/+subscriptions
>

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

Title:
  ARM thumb2 does not propogate carry flag properly

Status in QEMU:
  New

Bug description:
  information on carry flag is lost if gen_set_CF_bit31(t1) is called
  after logic operation.

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



[Qemu-devel] [PATCH] device_tree: Fix potential memory leak

2011-10-17 Thread Stefan Weil
cppcheck error report:

device_tree.c:156: error: Memory leak: dupname

Signed-off-by: Stefan Weil 
---
 device_tree.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/device_tree.c b/device_tree.c
index dc69232..86a694c 100644
--- a/device_tree.c
+++ b/device_tree.c
@@ -153,6 +153,7 @@ int qemu_devtree_add_subnode(void *fdt, const char *name)
 int retval;
 
 if (!basename) {
+g_free(dupname);
 return -1;
 }
 
-- 
1.7.2.5




Re: [Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp

2011-10-17 Thread Richard Henderson
On 10/17/2011 12:14 PM, Blue Swirl wrote:
> IIRC buggy versions of alloca() could also fail without a frame pointer.

(1) GCC always uses a frame pointer for alloca,
(2) Unless you do -fno-builtin-alloca, we always implement it inline.


r~



Re: [Qemu-devel] [PATCH v2 00/13] allow tools to use the QEMU main loop

2011-10-17 Thread Anthony Liguori

On 10/17/2011 03:09 PM, Paolo Bonzini wrote:

On 10/17/2011 09:56 PM, Anthony Liguori wrote:

The series already
starts using the refactored main loop in qemu-nbd.


What patch does this? I don't see any changes to qemu-nbd in this series.


Leftover from RFC. Right now, this is just a chainsaw cleanup. However, Kevin
has plans to use the main loop everywhere (making qemu-io and qemu-img one huge
coroutine).


Can you add something to docs that explains how to use the new main loop?

Regards,

Anthony Liguori


Paolo






Re: [Qemu-devel] [PATCH v2 00/13] allow tools to use the QEMU main loop

2011-10-17 Thread Paolo Bonzini

On 10/17/2011 09:56 PM, Anthony Liguori wrote:

The series already
starts using the refactored main loop in qemu-nbd.


What patch does this?  I don't see any changes to qemu-nbd in this series.


Leftover from RFC.  Right now, this is just a chainsaw cleanup. 
However, Kevin has plans to use the main loop everywhere (making qemu-io 
and qemu-img one huge coroutine).


Paolo



[Qemu-devel] [PATCH] gdbstub: Fix memory leak

2011-10-17 Thread Stefan Weil
cppcheck report:
  gdbstub.c:1781: error: Memory leak: s

Rearranging of the code avoids the leak.

The patch also slightly cleans the g_malloc0 statement which was
touched by that change (no type cast, easier code review).

Signed-off-by: Stefan Weil 
---
 gdbstub.c |   14 --
 1 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/gdbstub.c b/gdbstub.c
index 4009058..34746f2 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -1768,12 +1768,6 @@ void gdb_register_coprocessor(CPUState * env,
 GDBRegisterState **p;
 static int last_reg = NUM_CORE_REGS;
 
-s = (GDBRegisterState *)g_malloc0(sizeof(GDBRegisterState));
-s->base_reg = last_reg;
-s->num_regs = num_regs;
-s->get_reg = get_reg;
-s->set_reg = set_reg;
-s->xml = xml;
 p = &env->gdb_regs;
 while (*p) {
 /* Check for duplicates.  */
@@ -1781,6 +1775,14 @@ void gdb_register_coprocessor(CPUState * env,
 return;
 p = &(*p)->next;
 }
+
+s = g_malloc0(sizeof(*s));
+s->base_reg = last_reg;
+s->num_regs = num_regs;
+s->get_reg = get_reg;
+s->set_reg = set_reg;
+s->xml = xml;
+
 /* Add to end of list.  */
 last_reg += num_regs;
 *p = s;
-- 
1.7.2.5




Re: [Qemu-devel] [PATCH v2 00/13] allow tools to use the QEMU main loop

2011-10-17 Thread Anthony Liguori

On 10/11/2011 06:35 AM, Paolo Bonzini wrote:

This patch series makes the QEMU main loop usable out of the executable,
and especially in tools and possibly unit tests.  The series already
starts using the refactored main loop in qemu-nbd.


What patch does this?  I don't see any changes to qemu-nbd in this series.

Regards,

Anthony Liguori



This is cleaner because it avoids introducing partial transitions to
GIOChannel.  Interfacing with the glib main loop is still possible.

The main loop code is currently split in cpus.c and vl.c.  Moving it
to a new file is easy; the problem is that the main loop depends on the
timer infrastructure in qemu-timer.c, and that file currently contains
the implementation of icount and the vm_clock.  This is bad for the
perspective of linking qemu-timer.c into the tools.  Luckily, it is
relatively easy to untie them and move them out of the way.  This is
what the largest part of the series does (patches 1-9).

Patches 10-13 complete the refactoring and cleanup some surrounding
code.

v1->v2
Rebased

Paolo Bonzini (13):
   remove unused function
   qemu-timer: remove active_timers array
   qemu-timer: move common code to qemu_rearm_alarm_timer
   qemu-timer: more clock functions
   qemu-timer: move icount to cpus.c
   qemu-timer: do not refer to runstate_is_running()
   qemu-timer: use atexit for quit_timers
   qemu-timer: move more stuff out of qemu-timer.c
   qemu-timer: do not use RunState change handlers
   create main-loop.h
   create main-loop.c
   Revert to a hand-made select loop
   simplify main loop functions

  Makefile.objs|2 +-
  async.c  |1 +
  cpus.c   |  496 ++
  cpus.h   |3 +-
  exec-all.h   |   14 ++
  exec.c   |3 -
  hw/mac_dbdma.c   |5 -
  hw/mac_dbdma.h   |1 -
  iohandler.c  |   54 +--
  main-loop.c  |  494 +
  main-loop.h  |   73 
  os-win32.c   |  123 --
  qemu-char.h  |   12 +--
  qemu-common.h|   15 +--
  qemu-os-posix.h  |4 -
  qemu-os-win32.h  |   15 +--
  qemu-timer.c |  489 ++---
  qemu-timer.h |   30 +---
  savevm.c |   25 +++
  slirp/libslirp.h |   11 --
  sysemu.h |3 +-
  vl.c |  189 -
  22 files changed, 1027 insertions(+), 1035 deletions(-)
  create mode 100644 main-loop.c
  create mode 100644 main-loop.h






Re: [Qemu-devel] [PATCH 04/13] qemu-timer: more clock functions

2011-10-17 Thread Anthony Liguori

On 10/11/2011 06:35 AM, Paolo Bonzini wrote:

These will be used when moving icount accounting to cpus.c.

Signed-off-by: Paolo Bonzini


Reviewed-by: Anthony Liguori 

Regards,

Anthony Liguori


---
  qemu-timer.c |   25 +
  qemu-timer.h |3 +++
  2 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index e2551f3..ebb5089 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -495,6 +495,31 @@ void qemu_clock_warp(QEMUClock *clock)
  }
  }

+int64_t qemu_clock_has_timers(QEMUClock *clock)
+{
+return !!clock->active_timers;
+}
+
+int64_t qemu_clock_expired(QEMUClock *clock)
+{
+return (clock->active_timers&&
+clock->active_timers->expire_time<  qemu_get_clock_ns(clock));
+}
+
+int64_t qemu_clock_deadline(QEMUClock *clock)
+{
+/* To avoid problems with overflow limit this to 2^32.  */
+int64_t delta = INT32_MAX;
+
+if (clock->active_timers) {
+delta = clock->active_timers->expire_time - qemu_get_clock_ns(clock);
+}
+if (delta<  0) {
+delta = 0;
+}
+return delta;
+}
+
  QEMUTimer *qemu_new_timer(QEMUClock *clock, int scale,
QEMUTimerCB *cb, void *opaque)
  {
diff --git a/qemu-timer.h b/qemu-timer.h
index 0a43469..4578075 100644
--- a/qemu-timer.h
+++ b/qemu-timer.h
@@ -38,6 +38,9 @@ extern QEMUClock *vm_clock;
  extern QEMUClock *host_clock;

  int64_t qemu_get_clock_ns(QEMUClock *clock);
+int64_t qemu_clock_has_timers(QEMUClock *clock);
+int64_t qemu_clock_expired(QEMUClock *clock);
+int64_t qemu_clock_deadline(QEMUClock *clock);
  void qemu_clock_enable(QEMUClock *clock, int enabled);
  void qemu_clock_warp(QEMUClock *clock);






Re: [Qemu-devel] [PATCH 03/13] qemu-timer: move common code to qemu_rearm_alarm_timer

2011-10-17 Thread Anthony Liguori

On 10/11/2011 06:35 AM, Paolo Bonzini wrote:

Signed-off-by: Paolo Bonzini


Reviewed-by: Anthony Liguori 

Regards,

Anthony Liguori


---
  qemu-timer.c |  129 --
  1 files changed, 53 insertions(+), 76 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index acf7a15..e2551f3 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -153,7 +153,7 @@ struct qemu_alarm_timer {
  char const *name;
  int (*start)(struct qemu_alarm_timer *t);
  void (*stop)(struct qemu_alarm_timer *t);
-void (*rearm)(struct qemu_alarm_timer *t);
+void (*rearm)(struct qemu_alarm_timer *t, int64_t nearest_delta_ns);
  #if defined(__linux__)
  int fd;
  timer_t timer;
@@ -181,12 +181,46 @@ static inline int alarm_has_dynticks(struct 
qemu_alarm_timer *t)
  return !!t->rearm;
  }

+static int64_t qemu_next_alarm_deadline(void)
+{
+int64_t delta;
+int64_t rtdelta;
+
+if (!use_icount&&  vm_clock->active_timers) {
+delta = vm_clock->active_timers->expire_time -
+ qemu_get_clock_ns(vm_clock);
+} else {
+delta = INT32_MAX;
+}
+if (host_clock->active_timers) {
+int64_t hdelta = host_clock->active_timers->expire_time -
+ qemu_get_clock_ns(host_clock);
+if (hdelta<  delta) {
+delta = hdelta;
+}
+}
+if (rt_clock->active_timers) {
+rtdelta = (rt_clock->active_timers->expire_time -
+ qemu_get_clock_ns(rt_clock));
+if (rtdelta<  delta) {
+delta = rtdelta;
+}
+}
+
+return delta;
+}
+
  static void qemu_rearm_alarm_timer(struct qemu_alarm_timer *t)
  {
-if (!alarm_has_dynticks(t))
+int64_t nearest_delta_ns;
+assert(alarm_has_dynticks(t));
+if (!rt_clock->active_timers&&
+!vm_clock->active_timers&&
+!host_clock->active_timers) {
  return;
-
-t->rearm(t);
+}
+nearest_delta_ns = qemu_next_alarm_deadline();
+t->rearm(t, nearest_delta_ns);
  }

  /* TODO: MIN_TIMER_REARM_NS should be optimized */
@@ -196,23 +230,23 @@ static void qemu_rearm_alarm_timer(struct 
qemu_alarm_timer *t)

  static int mm_start_timer(struct qemu_alarm_timer *t);
  static void mm_stop_timer(struct qemu_alarm_timer *t);
-static void mm_rearm_timer(struct qemu_alarm_timer *t);
+static void mm_rearm_timer(struct qemu_alarm_timer *t, int64_t delta);

  static int win32_start_timer(struct qemu_alarm_timer *t);
  static void win32_stop_timer(struct qemu_alarm_timer *t);
-static void win32_rearm_timer(struct qemu_alarm_timer *t);
+static void win32_rearm_timer(struct qemu_alarm_timer *t, int64_t delta);

  #else

  static int unix_start_timer(struct qemu_alarm_timer *t);
  static void unix_stop_timer(struct qemu_alarm_timer *t);
-static void unix_rearm_timer(struct qemu_alarm_timer *t);
+static void unix_rearm_timer(struct qemu_alarm_timer *t, int64_t delta);

  #ifdef __linux__

  static int dynticks_start_timer(struct qemu_alarm_timer *t);
  static void dynticks_stop_timer(struct qemu_alarm_timer *t);
-static void dynticks_rearm_timer(struct qemu_alarm_timer *t);
+static void dynticks_rearm_timer(struct qemu_alarm_timer *t, int64_t delta);

  #endif /* __linux__ */

@@ -715,8 +749,6 @@ void qemu_run_all_timers(void)
  qemu_run_timers(host_clock);
  }

-static int64_t qemu_next_alarm_deadline(void);
-
  #ifdef _WIN32
  static void CALLBACK host_alarm_handler(PVOID lpParam, BOOLEAN unused)
  #else
@@ -781,33 +813,6 @@ int64_t qemu_next_icount_deadline(void)
  return delta;
  }

-static int64_t qemu_next_alarm_deadline(void)
-{
-int64_t delta;
-int64_t rtdelta;
-
-if (!use_icount&&  vm_clock->active_timers) {
-delta = vm_clock->active_timers->expire_time -
- qemu_get_clock_ns(vm_clock);
-} else {
-delta = INT32_MAX;
-}
-if (host_clock->active_timers) {
-int64_t hdelta = host_clock->active_timers->expire_time -
- qemu_get_clock_ns(host_clock);
-if (hdelta<  delta)
-delta = hdelta;
-}
-if (rt_clock->active_timers) {
-rtdelta = (rt_clock->active_timers->expire_time -
- qemu_get_clock_ns(rt_clock));
-if (rtdelta<  delta)
-delta = rtdelta;
-}
-
-return delta;
-}
-
  #if defined(__linux__)

  #include "compatfd.h"
@@ -860,20 +865,13 @@ static void dynticks_stop_timer(struct qemu_alarm_timer 
*t)
  timer_delete(host_timer);
  }

-static void dynticks_rearm_timer(struct qemu_alarm_timer *t)
+static void dynticks_rearm_timer(struct qemu_alarm_timer *t,
+ int64_t nearest_delta_ns)
  {
  timer_t host_timer = t->timer;
  struct itimerspec timeout;
-int64_t nearest_delta_ns = INT64_MAX;
  int64_t current_ns;

-assert(alarm_has_dynticks(t));
-if (!rt_clock->active_timers&&
-!vm_clock->active_timers&&
-!host_clock->active_timers)
-r

Re: [Qemu-devel] [PATCH 02/13] qemu-timer: remove active_timers array

2011-10-17 Thread Anthony Liguori

On 10/11/2011 06:35 AM, Paolo Bonzini wrote:

Embed the list in the QEMUClock instead.

Signed-off-by: Paolo Bonzini


Reviewed-by: Anthony Liguori 

Regards,

Anthony Liguori


---
  qemu-timer.c |   59 +++--
  1 files changed, 28 insertions(+), 31 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index ad1fc8b..acf7a15 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -134,6 +134,7 @@ struct QEMUClock {
  int enabled;

  QEMUTimer *warp_timer;
+QEMUTimer *active_timers;

  NotifierList reset_notifiers;
  int64_t last;
@@ -352,14 +353,10 @@ next:
  }
  }

-#define QEMU_NUM_CLOCKS 3
-
  QEMUClock *rt_clock;
  QEMUClock *vm_clock;
  QEMUClock *host_clock;

-static QEMUTimer *active_timers[QEMU_NUM_CLOCKS];
-
  static QEMUClock *qemu_new_clock(int type)
  {
  QEMUClock *clock;
@@ -403,7 +400,7 @@ static void icount_warp_rt(void *opaque)
  int64_t delta = cur_time - cur_icount;
  qemu_icount_bias += MIN(warp_delta, delta);
  }
-if (qemu_timer_expired(active_timers[QEMU_CLOCK_VIRTUAL],
+if (qemu_timer_expired(vm_clock->active_timers,
 qemu_get_clock_ns(vm_clock))) {
  qemu_notify_event();
  }
@@ -434,7 +431,7 @@ void qemu_clock_warp(QEMUClock *clock)
   * the earliest vm_clock timer.
   */
  icount_warp_rt(NULL);
-if (!all_cpu_threads_idle() || !active_timers[clock->type]) {
+if (!all_cpu_threads_idle() || !clock->active_timers) {
  qemu_del_timer(clock->warp_timer);
  return;
  }
@@ -489,7 +486,7 @@ void qemu_del_timer(QEMUTimer *ts)

  /* NOTE: this code must be signal safe because
 qemu_timer_expired() can be called from a signal. */
-pt =&active_timers[ts->clock->type];
+pt =&ts->clock->active_timers;
  for(;;) {
  t = *pt;
  if (!t)
@@ -513,7 +510,7 @@ static void qemu_mod_timer_ns(QEMUTimer *ts, int64_t 
expire_time)
  /* add the timer in the sorted list */
  /* NOTE: this code must be signal safe because
 qemu_timer_expired() can be called from a signal. */
-pt =&active_timers[ts->clock->type];
+pt =&ts->clock->active_timers;
  for(;;) {
  t = *pt;
  if (!qemu_timer_expired_ns(t, expire_time)) {
@@ -526,7 +523,7 @@ static void qemu_mod_timer_ns(QEMUTimer *ts, int64_t 
expire_time)
  *pt = ts;

  /* Rearm if necessary  */
-if (pt ==&active_timers[ts->clock->type]) {
+if (pt ==&ts->clock->active_timers) {
  if (!alarm_timer->pending) {
  qemu_rearm_alarm_timer(alarm_timer);
  }
@@ -548,7 +545,7 @@ void qemu_mod_timer(QEMUTimer *ts, int64_t expire_time)
  int qemu_timer_pending(QEMUTimer *ts)
  {
  QEMUTimer *t;
-for(t = active_timers[ts->clock->type]; t != NULL; t = t->next) {
+for (t = ts->clock->active_timers; t != NULL; t = t->next) {
  if (t == ts)
  return 1;
  }
@@ -569,7 +566,7 @@ static void qemu_run_timers(QEMUClock *clock)
  return;

  current_time = qemu_get_clock_ns(clock);
-ptimer_head =&active_timers[clock->type];
+ptimer_head =&clock->active_timers;
  for(;;) {
  ts = *ptimer_head;
  if (!qemu_timer_expired_ns(ts, current_time)) {
@@ -773,8 +770,8 @@ int64_t qemu_next_icount_deadline(void)
  int64_t delta = INT32_MAX;

  assert(use_icount);
-if (active_timers[QEMU_CLOCK_VIRTUAL]) {
-delta = active_timers[QEMU_CLOCK_VIRTUAL]->expire_time -
+if (vm_clock->active_timers) {
+delta = vm_clock->active_timers->expire_time -
   qemu_get_clock_ns(vm_clock);
  }

@@ -789,20 +786,20 @@ static int64_t qemu_next_alarm_deadline(void)
  int64_t delta;
  int64_t rtdelta;

-if (!use_icount&&  active_timers[QEMU_CLOCK_VIRTUAL]) {
-delta = active_timers[QEMU_CLOCK_VIRTUAL]->expire_time -
+if (!use_icount&&  vm_clock->active_timers) {
+delta = vm_clock->active_timers->expire_time -
   qemu_get_clock_ns(vm_clock);
  } else {
  delta = INT32_MAX;
  }
-if (active_timers[QEMU_CLOCK_HOST]) {
-int64_t hdelta = active_timers[QEMU_CLOCK_HOST]->expire_time -
+if (host_clock->active_timers) {
+int64_t hdelta = host_clock->active_timers->expire_time -
   qemu_get_clock_ns(host_clock);
  if (hdelta<  delta)
  delta = hdelta;
  }
-if (active_timers[QEMU_CLOCK_REALTIME]) {
-rtdelta = (active_timers[QEMU_CLOCK_REALTIME]->expire_time -
+if (rt_clock->active_timers) {
+rtdelta = (rt_clock->active_timers->expire_time -
   qemu_get_clock_ns(rt_clock));
  if (rtdelta<  delta)
  delta = rtdelta;
@@ -871,9 +868,9 @@ static void dynticks_rearm_timer(struct qemu_alarm_timer *t)
  int64_t current_ns;

  assert(alarm_has_dynticks(t));
-if (!active_timers[QEMU_C

Re: [Qemu-devel] [PATCH 01/13] remove unused function

2011-10-17 Thread Anthony Liguori

On 10/11/2011 06:35 AM, Paolo Bonzini wrote:

Signed-off-by: Paolo Bonzini


Reviewed-by: Anthony Liguori 

Regards,

Anthony Liguori


---
  hw/mac_dbdma.c |5 -
  hw/mac_dbdma.h |1 -
  2 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/hw/mac_dbdma.c b/hw/mac_dbdma.c
index 5affdd1..1791ec1 100644
--- a/hw/mac_dbdma.c
+++ b/hw/mac_dbdma.c
@@ -661,11 +661,6 @@ void DBDMA_register_channel(void *dbdma, int nchan, 
qemu_irq irq,
  ch->io.channel = ch;
  }

-void DBDMA_schedule(void)
-{
-qemu_notify_event();
-}
-
  static void
  dbdma_control_write(DBDMA_channel *ch)
  {
diff --git a/hw/mac_dbdma.h b/hw/mac_dbdma.h
index 933e17c..6d1abe6 100644
--- a/hw/mac_dbdma.h
+++ b/hw/mac_dbdma.h
@@ -41,5 +41,4 @@ struct DBDMA_io {
  void DBDMA_register_channel(void *dbdma, int nchan, qemu_irq irq,
  DBDMA_rw rw, DBDMA_flush flush,
  void *opaque);
-void DBDMA_schedule(void);
  void* DBDMA_init (MemoryRegion **dbdma_mem);





Re: [Qemu-devel] GPLv3 troubles

2011-10-17 Thread Blue Swirl
On Mon, Oct 17, 2011 at 4:51 PM, Anthony Liguori  wrote:
> On 10/17/2011 11:47 AM, Peter Maydell wrote:
>>
>> On 17 October 2011 17:39, Andreas Färber  wrote:
>>>
>>> Am 17.10.2011 13:10, schrieb Paolo Bonzini:

 Making a list of GPLv2 files would be a start, though.
>>>
>>> grep -r version *.c comes up with these:
>>
>> Your rune needs tweaking -- it isn't looking inside any
>> subdirectories.
>
> Including binutils code is just a bad idea.  I know noone wants to hear that
> but it's unfortunately true.

Some targets like Alpha, m68k and Sparc32 are not evolving anymore, so
binutils from 2007 will be fine forever. In other cases, the
manufacturers are adding new instructions (x86, ARM and Sparc64), then
a modern disassembler would be more and more useful over time.

> The FSF does copyright assignment which means it's easy for them to
> relicense. Since we don't do copyright assignment, it's much, much harder
> for us to relicense.  We'd waste huge amounts of man hours trying to chase
> binutils license.

Even with copyright assignment, our relicensing could conflict with theirs.

> We need to stick with the v2 version of binutils and perhaps work toward an
> alternative in the future.  Relicensing is just not practical.
>
> Regards,
>
> Anthony Liguori
>
>>
>> -- PMM
>>
>
>
>



Re: [Qemu-devel] [RFC][PATCH 06/45] msix: Prevent bogus mask updates on MMIO accesses

2011-10-17 Thread Michael S. Tsirkin
On Mon, Oct 17, 2011 at 09:11:29PM +0200, Jan Kiszka wrote:
> On 2011-10-17 14:50, Michael S. Tsirkin wrote:
> > On Mon, Oct 17, 2011 at 02:07:10PM +0200, Jan Kiszka wrote:
> >> On 2011-10-17 13:57, Michael S. Tsirkin wrote:
> >>> On Mon, Oct 17, 2011 at 01:23:46PM +0200, Jan Kiszka wrote:
>  On 2011-10-17 13:10, Michael S. Tsirkin wrote:
> > On Mon, Oct 17, 2011 at 11:27:40AM +0200, Jan Kiszka wrote:
> >> Only accesses to the MSI-X table must trigger a call to
> >> msix_handle_mask_update or a notifier invocation.
> >>
> >> Signed-off-by: Jan Kiszka 
> >
> > Why would msix_mmio_write be called on an access
> > outside the table?
> 
>  Because it handles both the table and the PBA.
> >>>
> >>> Hmm. Interesting. Is there a bug in how we handle PBA
> >>> updates then? If yes I'd like a separate patch for that
> >>> to apply to the stable tree.
> >>
> >> I first thought it was a serious bug, but it just triggers if the guest
> >> write to PBA (which is very uncommon) and that actually triggers any
> >> spurious out-of-bounds vector injection. Highly unlikely.
> > 
> > Yes guests don't really use PBA ATM. But is there something
> > bad a malicious guest can do? For example, what if
> > msix_clr_pending gets invoked with this huge vector value?
> > 
> > It does seem serious ...
> 
> I checked it before and I think it is harmless. The largest vector that
> can be miscalculated is 255. But bit 255 in the PBA is still safe inside
> our MMIO page.
> 
> Jan
> 

you are right. we got lucky.




Re: [Qemu-devel] GPLv3 troubles

2011-10-17 Thread Blue Swirl
On Mon, Oct 17, 2011 at 6:29 PM, Anthony Liguori  wrote:
> On 10/17/2011 01:20 PM, Stefan Weil wrote:
>>
>> Am 17.10.2011 20:16, schrieb Anthony Liguori:
>>>
>>> On 10/17/2011 12:58 PM, Andreas Färber wrote:

 Am 17.10.2011 18:51, schrieb Anthony Liguori:
>
> Including binutils code is just a bad idea.

 Do you see a real alternative? Would it be possible to pipe machine code
 from QEMU into an external disassembler?
>>>
>>> Sure. This is only used in the monitor for interactive debugging, right?
>>
>> The disassembler is also used with -d in_asm or -d out_asm to write
>> qemu.log.
>> I expect that a pipe to an external disassembler would slow down execution
>> with -d
>> significantly.
>
> How difficult would it be to add tracing to tcg-target.c such that you could
> get out_asm that way?
>
> At least with i386, there's just a few instruction forms so it should just
> be a matter of a few trace points with a table of opcode names.
>
> Likewise, we could add tracing to translate.c to achieve the same affect as
> in_asm.
>
> Tracing's probably a far better approach for debugging as you would be able
> to do some very interesting things with SystemTap and such a mechanism.

Disassembly could be moved offline, so performance would also be
better and *_asm generation could be toggled dynamically.

> Regards,
>
> Anthony Liguori
>
>> Regards,
>> Stefan Weil
>>
>>
>
>
>



Re: [Qemu-devel] GPLv3 troubles

2011-10-17 Thread Blue Swirl
On Mon, Oct 17, 2011 at 5:46 PM, Stefan Weil  wrote:
> Am 17.10.2011 18:47, schrieb Anthony Liguori:
>>
>> On 10/17/2011 11:30 AM, Andreas Färber wrote:
>>>
>>> Am 17.10.2011 16:17, schrieb Anthony Liguori:

 On 10/17/2011 07:50 AM, Paolo Bonzini wrote:
>
> On 10/17/2011 02:38 PM, Anthony Liguori wrote:
>>>
>>> Could we please draft some policy on this? This is not a GDB issue,
>>> it's
>>> very general. Whether we like it or not, there is GPLv3-licensed code
>>> and there will probably be a GPLv4 one day.
>>
>> I don't see anything wrong with GPLv2 only. While I don't think
>> there's
>> anything wrong with GPLv3, I think that "or later" is a dangerous
>> clause
>> to add.
>
> License fragmentation with respect to the de facto standard toolchain
> (binutils)
> is wrong.

 Fragmentation with respect to the de factor standard kernel (Linux) is
 wrong.
>>>
>>> Tell that to the GNU and FSF people. :)
>>>
>>> In my personal opinion, Open Source licenses should preserve our
>>> freedom, not make us unnecessarily duplicate code.
>>>
>>> I'm just asking to not make the situation worse than it is.
>>
>> It's not something that any one person can really change.  It would
>> require a very large effort.  To give you an idea of the scope, I ran the
>> following command:
>>
>> $ grep GPL *.c  hw/*.c | grep -v 'or later' | cut -f1 -d: | sort -u |
>> while read i; do echo $i; git log --format="  %an <%ae>" $i | sort -u; done
>>
>> Here's the results.  All of these people would have to explicitly SoB a
>> relicense of that specific file to include a "v2 or later" clause.  In some
>> cases, there's code from Thiemo which cannot be relicensed due to his
>> untimely passing.
>
>
> So let's start. For any of my contributions, I agree to GPL v2 or later.
> Later generations should have the possibility to replace GPL v2 by
> something which matches future requirements.

Me too, I'd also accept any other GPL v2 or v3 compatible licenses.

> I'd appreciate if no new files were published with GPL v2 only.

This could be more difficult.

> Stefan W.
>
> PS. I no longer use my old email address because Berlios
> will be closed on 2011-12-31, see http://www.berlios.de/.
>
>



Re: [Qemu-devel] [PATCH 2/4] pc: Support system flash memory with pflash

2011-10-17 Thread Jordan Justen
On Mon, Oct 17, 2011 at 12:16, Jordan Justen  wrote:
> If a pflash image is found, then it is used for the system
> firmware image.
>
> If a pflash image is not initially found, then a read-only
> pflash device is created using the -bios filename.
>
> Signed-off-by: Jordan Justen 
> Cc: Anthony Liguori 
> ---
>  Makefile.target                    |    1 +
>  default-configs/i386-softmmu.mak   |    1 +
>  default-configs/x86_64-softmmu.mak |    1 +
>  hw/boards.h                        |    1 +
>  hw/pc.c                            |   55 +
>  hw/pc.h                            |    3 +
>  hw/pcflash.c                       |  145 
> 
>  vl.c                               |    2 +-
>  8 files changed, 158 insertions(+), 51 deletions(-)
>  create mode 100644 hw/pcflash.c
>
> diff --git a/Makefile.target b/Makefile.target
> index 417f23e..37a5b56 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -225,6 +225,7 @@ obj-i386-y += vmport.o
>  obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o
>  obj-i386-y += debugcon.o multiboot.o
>  obj-i386-y += pc_piix.o
> +obj-i386-y += pcflash.o
>  obj-i386-$(CONFIG_KVM) += kvmclock.o
>  obj-i386-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
>
> diff --git a/default-configs/i386-softmmu.mak 
> b/default-configs/i386-softmmu.mak
> index e67ebb3..cd407a9 100644
> --- a/default-configs/i386-softmmu.mak
> +++ b/default-configs/i386-softmmu.mak
> @@ -22,3 +22,4 @@ CONFIG_SOUND=y
>  CONFIG_HPET=y
>  CONFIG_APPLESMC=y
>  CONFIG_I8259=y
> +CONFIG_PFLASH_CFI01=y
> diff --git a/default-configs/x86_64-softmmu.mak 
> b/default-configs/x86_64-softmmu.mak
> index b75757e..47734ea 100644
> --- a/default-configs/x86_64-softmmu.mak
> +++ b/default-configs/x86_64-softmmu.mak
> @@ -22,3 +22,4 @@ CONFIG_SOUND=y
>  CONFIG_HPET=y
>  CONFIG_APPLESMC=y
>  CONFIG_I8259=y
> +CONFIG_PFLASH_CFI01=y
> diff --git a/hw/boards.h b/hw/boards.h
> index 716fd7b..45a31a1 100644
> --- a/hw/boards.h
> +++ b/hw/boards.h
> @@ -33,6 +33,7 @@ typedef struct QEMUMachine {
>  } QEMUMachine;
>
>  int qemu_register_machine(QEMUMachine *m);
> +QEMUMachine *find_default_machine(void);
>
>  extern QEMUMachine *current_machine;
>
> diff --git a/hw/pc.c b/hw/pc.c
> index f0802b7..0c9b7ba 100644
> --- a/hw/pc.c
> +++ b/hw/pc.c
> @@ -57,10 +57,6 @@
>  #define DPRINTF(fmt, ...)
>  #endif
>
> -#define BIOS_FILENAME "bios.bin"
> -
> -#define PC_MAX_BIOS_SIZE (4 * 1024 * 1024)
> -
>  /* Leave a chunk of memory at the top of RAM for the BIOS ACPI tables.  */
>  #define ACPI_DATA_SIZE       0x1
>  #define BIOS_CFG_IOPORT 0x510
> @@ -974,11 +970,9 @@ void pc_memory_init(MemoryRegion *system_memory,
>                     MemoryRegion *rom_memory,
>                     MemoryRegion **ram_memory)
>  {
> -    char *filename;
> -    int ret, linux_boot, i;
> -    MemoryRegion *ram, *bios, *isa_bios, *option_rom_mr;
> +    int linux_boot, i;
> +    MemoryRegion *ram, *option_rom_mr;
>     MemoryRegion *ram_below_4g, *ram_above_4g;
> -    int bios_size, isa_bios_size;
>     void *fw_cfg;
>
>     linux_boot = (kernel_filename != NULL);
> @@ -1003,43 +997,9 @@ void pc_memory_init(MemoryRegion *system_memory,
>                                     ram_above_4g);
>     }
>
> -    /* BIOS load */
> -    if (bios_name == NULL)
> -        bios_name = BIOS_FILENAME;
> -    filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
> -    if (filename) {
> -        bios_size = get_image_size(filename);
> -    } else {
> -        bios_size = -1;
> -    }
> -    if (bios_size <= 0 ||
> -        (bios_size % 65536) != 0) {
> -        goto bios_error;
> -    }
> -    bios = g_malloc(sizeof(*bios));
> -    memory_region_init_ram(bios, NULL, "pc.bios", bios_size);
> -    memory_region_set_readonly(bios, true);
> -    ret = rom_add_file_fixed(bios_name, (uint32_t)(-bios_size), -1);
> -    if (ret != 0) {
> -    bios_error:
> -        fprintf(stderr, "qemu: could not load PC BIOS '%s'\n", bios_name);
> -        exit(1);
> -    }
> -    if (filename) {
> -        g_free(filename);
> -    }
> -    /* map the last 128KB of the BIOS in ISA space */
> -    isa_bios_size = bios_size;
> -    if (isa_bios_size > (128 * 1024))
> -        isa_bios_size = 128 * 1024;
> -    isa_bios = g_malloc(sizeof(*isa_bios));
> -    memory_region_init_alias(isa_bios, "isa-bios", bios,
> -                             bios_size - isa_bios_size, isa_bios_size);
> -    memory_region_add_subregion_overlap(rom_memory,
> -                                        0x10 - isa_bios_size,
> -                                        isa_bios,
> -                                        1);
> -    memory_region_set_readonly(isa_bios, true);
> +
> +    /* Initialize ROM or flash ranges for PC firmware */
> +    pc_system_firmware_init(rom_memory);
>
>     option_rom_mr = g_malloc(sizeof(*option_rom_mr));
>     memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE);
> @@ -1048,11 +1008,6 @@ void pc_memor

[Qemu-devel] [PATCH] hw/9pfs: Fix missing parentheses

2011-10-17 Thread Stefan Weil
cppcheck report:
hw/9pfs/virtio-9p.c:2385:
 style: Boolean result is used in bitwise operation.
 Clarify expression with parentheses
hw/9pfs/virtio-9p.c:2531:
 style: Boolean result is used in bitwise operation.
 Clarify expression with parentheses

Cc: Aneesh Kumar K.V 
Signed-off-by: Stefan Weil 
---
 hw/9pfs/virtio-9p.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index c01c31a..df0b22a 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -2382,7 +2382,7 @@ static void v9fs_remove(void *opaque)
 goto out_nofid;
 }
 /* if fs driver is not path based, return EOPNOTSUPP */
-if (!pdu->s->ctx.flags & PATHNAME_FSCONTEXT) {
+if (!(pdu->s->ctx.flags & PATHNAME_FSCONTEXT)) {
 err = -EOPNOTSUPP;
 goto out_err;
 }
@@ -2528,7 +2528,7 @@ static void v9fs_rename(void *opaque)
 }
 BUG_ON(fidp->fid_type != P9_FID_NONE);
 /* if fs driver is not path based, return EOPNOTSUPP */
-if (!pdu->s->ctx.flags & PATHNAME_FSCONTEXT) {
+if (!(pdu->s->ctx.flags & PATHNAME_FSCONTEXT)) {
 err = -EOPNOTSUPP;
 goto out;
 }
-- 
1.7.0.4




[Qemu-devel] [PATCH 4/4] pcflash: Add pc flash to qemu roms

2011-10-17 Thread Jordan Justen
The pflash image is added to the roms using the memory
region buffer and rom_add_file_buf_fixed.

Signed-off-by: Jordan Justen 
---
 hw/pcflash.c |   16 
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/hw/pcflash.c b/hw/pcflash.c
index eece7ec..e28bdb0 100644
--- a/hw/pcflash.c
+++ b/hw/pcflash.c
@@ -65,6 +65,21 @@ static void pc_isa_bios_init(MemoryRegion *rom_memory,
 memory_region_set_readonly(isa_bios, true);
 }
 
+static void pc_flash_add_qemu_rom(DriveInfo *pflash_drv,
+  MemoryRegion *flash_mem)
+{
+const char *filename;
+void *data;
+uint64_t size;
+uint32_t addr;
+
+filename = qemu_opt_get(pflash_drv->opts, "file");
+data = memory_region_get_ram_ptr(flash_mem);
+size = memory_region_size(flash_mem);
+addr = (uint32_t) -((int32_t)size);
+rom_add_file_buf_fixed(filename, data, size, addr, -1);
+}
+
 static void pc_default_system_flash_init(void)
 {
 QemuOpts *opts;
@@ -118,6 +133,7 @@ static void pc_system_flash_init(MemoryRegion *rom_memory,
 flash_mem = pflash_cfi01_get_memory(system_flash);
 
 pc_isa_bios_init(rom_memory, flash_mem, size);
+pc_flash_add_qemu_rom(pflash_drv, flash_mem);
 }
 
 void pc_system_firmware_init(MemoryRegion *rom_memory)
-- 
1.7.1




[Qemu-devel] [PATCH 3/4] loader: Add rom_add_file_buf for adding roms from a buffer

2011-10-17 Thread Jordan Justen
rom_add_file_buf is similar to rom_add_file, except the rom's
contents are provided in a buffer.

rom_add_file is modified to call rom_add_file_buf after
reading the rom's contents from the file.

Signed-off-by: Jordan Justen 
---
 hw/loader.c |   71 +++---
 hw/loader.h |5 
 2 files changed, 53 insertions(+), 23 deletions(-)

diff --git a/hw/loader.c b/hw/loader.c
index 5676c18..d1a4a98 100644
--- a/hw/loader.c
+++ b/hw/loader.c
@@ -557,11 +557,11 @@ static void rom_insert(Rom *rom)
 QTAILQ_INSERT_TAIL(&roms, rom, next);
 }
 
-int rom_add_file(const char *file, const char *fw_dir,
- target_phys_addr_t addr, int32_t bootindex)
+int rom_add_file_buf(const char *file, const void *data, size_t size,
+ const char *fw_dir,
+ target_phys_addr_t addr, int32_t bootindex)
 {
 Rom *rom;
-int rc, fd = -1;
 char devpath[100];
 
 rom = g_malloc0(sizeof(*rom));
@@ -571,28 +571,16 @@ int rom_add_file(const char *file, const char *fw_dir,
 rom->path = g_strdup(file);
 }
 
-fd = open(rom->path, O_RDONLY | O_BINARY);
-if (fd == -1) {
-fprintf(stderr, "Could not open option rom '%s': %s\n",
-rom->path, strerror(errno));
-goto err;
-}
-
 if (fw_dir) {
 rom->fw_dir  = g_strdup(fw_dir);
 rom->fw_file = g_strdup(file);
 }
 rom->addr= addr;
-rom->romsize = lseek(fd, 0, SEEK_END);
+rom->romsize = size;
 rom->data= g_malloc0(rom->romsize);
-lseek(fd, 0, SEEK_SET);
-rc = read(fd, rom->data, rom->romsize);
-if (rc != rom->romsize) {
-fprintf(stderr, "rom: file %-20s: read error: rc=%d (expected %zd)\n",
-rom->name, rc, rom->romsize);
-goto err;
-}
-close(fd);
+
+memcpy(rom->data, data, rom->romsize);
+
 rom_insert(rom);
 if (rom->fw_file && fw_cfg) {
 const char *basename;
@@ -614,14 +602,51 @@ int rom_add_file(const char *file, const char *fw_dir,
 
 add_boot_device_path(bootindex, NULL, devpath);
 return 0;
+}
+
+int rom_add_file(const char *file, const char *fw_dir,
+ target_phys_addr_t addr, int32_t bootindex)
+{
+char *filename;
+void *data = NULL;
+size_t size;
+int rc, fd = -1;
+
+filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, file);
+if (filename == NULL) {
+filename = g_strdup(file);
+}
+
+fd = open(filename, O_RDONLY | O_BINARY);
+if (fd == -1) {
+fprintf(stderr, "Could not open option rom '%s': %s\n",
+filename, strerror(errno));
+goto err;
+}
+
+size = lseek(fd, 0, SEEK_END);
+data = g_malloc0(size);
+lseek(fd, 0, SEEK_SET);
+rc = read(fd, data, size);
+if (rc != size) {
+fprintf(stderr, "rom: file %-20s: read error: rc=%d (expected %zd)\n",
+filename, rc, size);
+goto err;
+}
+close(fd);
+
+rc = rom_add_file_buf(filename, data, size, fw_dir, addr, bootindex);
+if (rc != 0) {
+goto err;
+}
+
+g_free(data);
+return 0;
 
 err:
 if (fd != -1)
 close(fd);
-g_free(rom->data);
-g_free(rom->path);
-g_free(rom->name);
-g_free(rom);
+g_free(data);
 return -1;
 }
 
diff --git a/hw/loader.h b/hw/loader.h
index fc6bdff..9efe64a 100644
--- a/hw/loader.h
+++ b/hw/loader.h
@@ -21,6 +21,9 @@ void pstrcpy_targphys(const char *name,
   const char *source);
 
 
+int rom_add_file_buf(const char *file, const void *data, size_t size,
+ const char *fw_dir,
+ target_phys_addr_t addr, int32_t bootindex);
 int rom_add_file(const char *file, const char *fw_dir,
  target_phys_addr_t addr, int32_t bootindex);
 int rom_add_blob(const char *name, const void *blob, size_t len,
@@ -31,6 +34,8 @@ int rom_copy(uint8_t *dest, target_phys_addr_t addr, size_t 
size);
 void *rom_ptr(target_phys_addr_t addr);
 void do_info_roms(Monitor *mon);
 
+#define rom_add_file_buf_fixed(_f, _d, _s, _a, _i)  \
+rom_add_file_buf(_f, _d, _s, NULL, _a, _i)
 #define rom_add_file_fixed(_f, _a, _i)  \
 rom_add_file(_f, NULL, _a, _i)
 #define rom_add_blob_fixed(_f, _b, _l, _a)  \
-- 
1.7.1




[Qemu-devel] [PATCH 2/4] pc: Support system flash memory with pflash

2011-10-17 Thread Jordan Justen
If a pflash image is found, then it is used for the system
firmware image.

If a pflash image is not initially found, then a read-only
pflash device is created using the -bios filename.

Signed-off-by: Jordan Justen 
Cc: Anthony Liguori 
---
 Makefile.target|1 +
 default-configs/i386-softmmu.mak   |1 +
 default-configs/x86_64-softmmu.mak |1 +
 hw/boards.h|1 +
 hw/pc.c|   55 +
 hw/pc.h|3 +
 hw/pcflash.c   |  145 
 vl.c   |2 +-
 8 files changed, 158 insertions(+), 51 deletions(-)
 create mode 100644 hw/pcflash.c

diff --git a/Makefile.target b/Makefile.target
index 417f23e..37a5b56 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -225,6 +225,7 @@ obj-i386-y += vmport.o
 obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o
 obj-i386-y += debugcon.o multiboot.o
 obj-i386-y += pc_piix.o
+obj-i386-y += pcflash.o
 obj-i386-$(CONFIG_KVM) += kvmclock.o
 obj-i386-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
 
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index e67ebb3..cd407a9 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -22,3 +22,4 @@ CONFIG_SOUND=y
 CONFIG_HPET=y
 CONFIG_APPLESMC=y
 CONFIG_I8259=y
+CONFIG_PFLASH_CFI01=y
diff --git a/default-configs/x86_64-softmmu.mak 
b/default-configs/x86_64-softmmu.mak
index b75757e..47734ea 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -22,3 +22,4 @@ CONFIG_SOUND=y
 CONFIG_HPET=y
 CONFIG_APPLESMC=y
 CONFIG_I8259=y
+CONFIG_PFLASH_CFI01=y
diff --git a/hw/boards.h b/hw/boards.h
index 716fd7b..45a31a1 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -33,6 +33,7 @@ typedef struct QEMUMachine {
 } QEMUMachine;
 
 int qemu_register_machine(QEMUMachine *m);
+QEMUMachine *find_default_machine(void);
 
 extern QEMUMachine *current_machine;
 
diff --git a/hw/pc.c b/hw/pc.c
index f0802b7..0c9b7ba 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -57,10 +57,6 @@
 #define DPRINTF(fmt, ...)
 #endif
 
-#define BIOS_FILENAME "bios.bin"
-
-#define PC_MAX_BIOS_SIZE (4 * 1024 * 1024)
-
 /* Leave a chunk of memory at the top of RAM for the BIOS ACPI tables.  */
 #define ACPI_DATA_SIZE   0x1
 #define BIOS_CFG_IOPORT 0x510
@@ -974,11 +970,9 @@ void pc_memory_init(MemoryRegion *system_memory,
 MemoryRegion *rom_memory,
 MemoryRegion **ram_memory)
 {
-char *filename;
-int ret, linux_boot, i;
-MemoryRegion *ram, *bios, *isa_bios, *option_rom_mr;
+int linux_boot, i;
+MemoryRegion *ram, *option_rom_mr;
 MemoryRegion *ram_below_4g, *ram_above_4g;
-int bios_size, isa_bios_size;
 void *fw_cfg;
 
 linux_boot = (kernel_filename != NULL);
@@ -1003,43 +997,9 @@ void pc_memory_init(MemoryRegion *system_memory,
 ram_above_4g);
 }
 
-/* BIOS load */
-if (bios_name == NULL)
-bios_name = BIOS_FILENAME;
-filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
-if (filename) {
-bios_size = get_image_size(filename);
-} else {
-bios_size = -1;
-}
-if (bios_size <= 0 ||
-(bios_size % 65536) != 0) {
-goto bios_error;
-}
-bios = g_malloc(sizeof(*bios));
-memory_region_init_ram(bios, NULL, "pc.bios", bios_size);
-memory_region_set_readonly(bios, true);
-ret = rom_add_file_fixed(bios_name, (uint32_t)(-bios_size), -1);
-if (ret != 0) {
-bios_error:
-fprintf(stderr, "qemu: could not load PC BIOS '%s'\n", bios_name);
-exit(1);
-}
-if (filename) {
-g_free(filename);
-}
-/* map the last 128KB of the BIOS in ISA space */
-isa_bios_size = bios_size;
-if (isa_bios_size > (128 * 1024))
-isa_bios_size = 128 * 1024;
-isa_bios = g_malloc(sizeof(*isa_bios));
-memory_region_init_alias(isa_bios, "isa-bios", bios,
- bios_size - isa_bios_size, isa_bios_size);
-memory_region_add_subregion_overlap(rom_memory,
-0x10 - isa_bios_size,
-isa_bios,
-1);
-memory_region_set_readonly(isa_bios, true);
+
+/* Initialize ROM or flash ranges for PC firmware */
+pc_system_firmware_init(rom_memory);
 
 option_rom_mr = g_malloc(sizeof(*option_rom_mr));
 memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE);
@@ -1048,11 +1008,6 @@ void pc_memory_init(MemoryRegion *system_memory,
 option_rom_mr,
 1);
 
-/* map all the bios at the top of memory */
-memory_region_add_subregion(rom_memory,
-(uint32_t)(-bios_size),
-

[Qemu-devel] [PATCH 1/4] pflash: Support read-only mode

2011-10-17 Thread Jordan Justen
Read-only mode is indicated by bdrv_is_read_only

When read-only mode is enabled, no changes will be made
to the flash image in memory, and no bdrv_write calls will be
made.

For pflash_cfi01 (Intel), if the flash is in read-only mode
then the status register will signal block erase error or
program error when these operations are attempted.

Signed-off-by: Jordan Justen 
Cc: Jan Kiszka 
---
 blockdev.c|3 +-
 hw/pflash_cfi01.c |   44 +++-
 hw/pflash_cfi02.c |   83 
 3 files changed, 77 insertions(+), 53 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 0827bf7..c94aee5 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -506,7 +506,8 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
 /* CDROM is fine for any interface, don't check.  */
 ro = 1;
 } else if (ro == 1) {
-if (type != IF_SCSI && type != IF_VIRTIO && type != IF_FLOPPY && type 
!= IF_NONE) {
+if (type != IF_SCSI && type != IF_VIRTIO && type != IF_FLOPPY &&
+type != IF_NONE && type != IF_PFLASH) {
 error_report("readonly not supported by this bus type");
 goto err;
 }
diff --git a/hw/pflash_cfi01.c b/hw/pflash_cfi01.c
index 69b8e3d..1e0a053 100644
--- a/hw/pflash_cfi01.c
+++ b/hw/pflash_cfi01.c
@@ -283,8 +283,12 @@ static void pflash_write(pflash_t *pfl, target_phys_addr_t 
offset,
 TARGET_FMT_plx "\n",
 __func__, offset, pfl->sector_len);
 
-memset(p + offset, 0xff, pfl->sector_len);
-pflash_update(pfl, offset, pfl->sector_len);
+if (!pfl->ro) {
+memset(p + offset, 0xff, pfl->sector_len);
+pflash_update(pfl, offset, pfl->sector_len);
+} else {
+pfl->status |= 0x20; /* Block erase error */
+}
 pfl->status |= 0x80; /* Ready! */
 break;
 case 0x50: /* Clear status bits */
@@ -323,8 +327,12 @@ static void pflash_write(pflash_t *pfl, target_phys_addr_t 
offset,
 case 0x10: /* Single Byte Program */
 case 0x40: /* Single Byte Program */
 DPRINTF("%s: Single Byte Program\n", __func__);
-pflash_data_write(pfl, offset, value, width, be);
-pflash_update(pfl, offset, width);
+if (!pfl->ro) {
+pflash_data_write(pfl, offset, value, width, be);
+pflash_update(pfl, offset, width);
+} else {
+pfl->status |= 0x10; /* Programming error */
+}
 pfl->status |= 0x80; /* Ready! */
 pfl->wcycle = 0;
 break;
@@ -372,7 +380,11 @@ static void pflash_write(pflash_t *pfl, target_phys_addr_t 
offset,
 case 2:
 switch (pfl->cmd) {
 case 0xe8: /* Block write */
-pflash_data_write(pfl, offset, value, width, be);
+if (!pfl->ro) {
+pflash_data_write(pfl, offset, value, width, be);
+} else {
+pfl->status |= 0x10; /* Programming error */
+}
 
 pfl->status |= 0x80;
 
@@ -382,8 +394,12 @@ static void pflash_write(pflash_t *pfl, target_phys_addr_t 
offset,
 
 DPRINTF("%s: block write finished\n", __func__);
 pfl->wcycle++;
-/* Flush the entire write buffer onto backing storage.  */
-pflash_update(pfl, offset & mask, pfl->writeblock_size);
+if (!pfl->ro) {
+/* Flush the entire write buffer onto backing storage.  */
+pflash_update(pfl, offset & mask, pfl->writeblock_size);
+} else {
+pfl->status |= 0x10; /* Programming error */
+}
 }
 
 pfl->counter--;
@@ -605,13 +621,13 @@ pflash_t *pflash_cfi01_register(target_phys_addr_t base,
 }
 bdrv_attach_dev_nofail(pfl->bs, pfl);
 }
-#if 0 /* XXX: there should be a bit to set up read-only,
-   *  the same way the hardware does (with WP pin).
-   */
-pfl->ro = 1;
-#else
-pfl->ro = 0;
-#endif
+
+if (pfl->bs) {
+pfl->ro = bdrv_is_read_only(pfl->bs);
+} else {
+pfl->ro = 0;
+}
+
 pfl->timer = qemu_new_timer_ns(vm_clock, pflash_timer, pfl);
 pfl->base = base;
 pfl->sector_len = sector_len;
diff --git a/hw/pflash_cfi02.c b/hw/pflash_cfi02.c
index e5a63da..9e91bdd 100644
--- a/hw/pflash_cfi02.c
+++ b/hw/pflash_cfi02.c
@@ -329,35 +329,37 @@ static void pflash_write (pflash_t *pfl, 
target_phys_addr_t offset,
 DPRINTF("%s: write data offset " TARGET_FMT_plx " %08x %d\n",
 __func__, offset, value, width);
 p = pfl->storage;
-switch (width) {
-case 1:
-p[offset] &= value;
-pflash_update(pfl, offset, 1);
-break;
-case 2:
- 

Re: [Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp

2011-10-17 Thread Blue Swirl
On Mon, Oct 17, 2011 at 5:22 PM, Richard Henderson  wrote:
> On 10/17/2011 07:09 AM, Bob Breuer wrote:
>> I don't think this is a free/g_free issue.  If I use the following
>> patch, then I at least get the openbios messages:
>>
>> diff --git a/cpu-exec.c b/cpu-exec.c
>> index a9fa608..dfbd6ea 100644
>> --- a/cpu-exec.c
>> +++ b/cpu-exec.c
>> @@ -180,6 +180,7 @@ static void cpu_handle_debug_exception(CPUState
>>  /* main execution loop */
>>
>>  volatile sig_atomic_t exit_request;
>> +register void *ebp asm("ebp");
>>
>>  int cpu_exec(CPUState *env)
>>  {
>> @@ -233,6 +234,8 @@ int cpu_exec(CPUState *env)
>>
>>      /* prepare setjmp context for exception handling */
>>      for(;;) {
>> +        int dummy = 0;
>> +        ebp = &dummy;
>
> See if
>
>  asm("" : : : "ebp");
>
> also solves the problem.
>
>> Google finds a mention of longjmp failing with -fomit-frame-pointer:
>> http://lua-users.org/lists/lua-l/2005-02/msg00158.html
>>
>> Looks like gcc 4.6 turns on -fomit-frame-pointer by default.
>
> Hmm.  This is the first I've heard of a longjmp implementation
> failing without a frame pointer.  Presumably this is with the
> mingw i.e. msvc libc?
>
> This is something that could be worked around in gcc, I suppose.
> We recognize longjmp for some things, we could force the use of
> a frame pointer for msvc targets too.
>
> For now it might be best to simply force -fno-omit-frame-pointer
> for mingw host in the configure script.

IIRC buggy versions of alloca() could also fail without a frame pointer.



Re: [Qemu-devel] [PATCH 18/18] tcx: convert to memory API

2011-10-17 Thread Blue Swirl
On Mon, Oct 17, 2011 at 2:02 PM, Avi Kivity  wrote:
> Signed-off-by: Avi Kivity 
> ---
>  hw/tcx.c |  152 ++---
>  1 files changed, 85 insertions(+), 67 deletions(-)
>
> diff --git a/hw/tcx.c b/hw/tcx.c
> index 309600d..cd24100 100644
> --- a/hw/tcx.c
> +++ b/hw/tcx.c
> @@ -40,7 +40,15 @@
>     DisplayState *ds;
>     uint8_t *vram;
>     uint32_t *vram24, *cplane;
> -    ram_addr_t vram_offset, vram24_offset, cplane_offset;
> +    MemoryRegion vram_mem;
> +    MemoryRegion vram_8bit;
> +    MemoryRegion vram_24bit;
> +    MemoryRegion vram_cplane;
> +    MemoryRegion dac;
> +    MemoryRegion tec;
> +    MemoryRegion thc24;
> +    MemoryRegion thc8;
> +    ram_addr_t vram24_offset, cplane_offset;
>     uint32_t vram_size;
>     uint32_t palette[256];
>     uint8_t r[256], g[256], b[256];
> @@ -56,7 +64,7 @@ static void tcx_set_dirty(TCXState *s)
>     unsigned int i;
>
>     for (i = 0; i < MAXX * MAXY; i += TARGET_PAGE_SIZE) {
> -        cpu_physical_memory_set_dirty(s->vram_offset + i);
> +        memory_region_set_dirty(&s->vram_mem, i);
>     }
>  }
>
> @@ -65,8 +73,8 @@ static void tcx24_set_dirty(TCXState *s)
>     unsigned int i;
>
>     for (i = 0; i < MAXX * MAXY * 4; i += TARGET_PAGE_SIZE) {
> -        cpu_physical_memory_set_dirty(s->vram24_offset + i);
> -        cpu_physical_memory_set_dirty(s->cplane_offset + i);
> +        memory_region_set_dirty(&s->vram_mem, s->vram24_offset + i);
> +        memory_region_set_dirty(&s->vram_mem, s->cplane_offset + i);
>     }
>  }
>
> @@ -174,16 +182,18 @@ static inline void tcx24_draw_line32(TCXState *s1, 
> uint8_t *d,
>     }
>  }
>
> -static inline int check_dirty(ram_addr_t page, ram_addr_t page24,
> +static inline int check_dirty(TCXState *s, ram_addr_t page, ram_addr_t 
> page24,
>                               ram_addr_t cpage)
>  {
>     int ret;
>     unsigned int off;
>
> -    ret = cpu_physical_memory_get_dirty(page, VGA_DIRTY_FLAG);
> +    ret = memory_region_get_dirty(&s->vram_mem, page, DIRTY_MEMORY_VGA);
>     for (off = 0; off < TARGET_PAGE_SIZE * 4; off += TARGET_PAGE_SIZE) {
> -        ret |= cpu_physical_memory_get_dirty(page24 + off, VGA_DIRTY_FLAG);
> -        ret |= cpu_physical_memory_get_dirty(cpage + off, VGA_DIRTY_FLAG);
> +        ret |= memory_region_get_dirty(&s->vram_mem, page24 + off,
> +                                       DIRTY_MEMORY_VGA);
> +        ret |= memory_region_get_dirty(&s->vram_mem, cpage + off,
> +                                       DIRTY_MEMORY_VGA);

Like memory_region_set_dirty(), this should be changed to take a range
so that the for loops and PAGE_SIZEs can be dropped.

>     }
>     return ret;
>  }
> @@ -192,16 +202,17 @@ static inline void reset_dirty(TCXState *ts, ram_addr_t 
> page_min,
>                                ram_addr_t page_max, ram_addr_t page24,
>                               ram_addr_t cpage)
>  {
> -    cpu_physical_memory_reset_dirty(page_min, page_max + TARGET_PAGE_SIZE,
> -                                    VGA_DIRTY_FLAG);
> -    page_min -= ts->vram_offset;
> -    page_max -= ts->vram_offset;
> -    cpu_physical_memory_reset_dirty(page24 + page_min * 4,
> -                                    page24 + page_max * 4 + TARGET_PAGE_SIZE,
> -                                    VGA_DIRTY_FLAG);
> -    cpu_physical_memory_reset_dirty(cpage + page_min * 4,
> -                                    cpage + page_max * 4 + TARGET_PAGE_SIZE,
> -                                    VGA_DIRTY_FLAG);
> +    memory_region_reset_dirty(&ts->vram_mem,
> +                              page_min, page_max + TARGET_PAGE_SIZE,
> +                              DIRTY_MEMORY_VGA);
> +    memory_region_reset_dirty(&ts->vram_mem,
> +                              page24 + page_min * 4,
> +                              page24 + page_max * 4 + TARGET_PAGE_SIZE,
> +                              DIRTY_MEMORY_VGA);
> +    memory_region_reset_dirty(&ts->vram_mem,
> +                              cpage + page_min * 4,
> +                              cpage + page_max * 4 + TARGET_PAGE_SIZE,
> +                              DIRTY_MEMORY_VGA);
>  }
>
>  /* Fixed line length 1024 allows us to do nice tricks not possible on
> @@ -216,7 +227,7 @@ static void tcx_update_display(void *opaque)
>
>     if (ds_get_bits_per_pixel(ts->ds) == 0)
>         return;
> -    page = ts->vram_offset;
> +    page = 0;
>     y_start = -1;
>     page_min = -1;
>     page_max = 0;
> @@ -242,7 +253,7 @@ static void tcx_update_display(void *opaque)
>     }
>
>     for(y = 0; y < ts->height; y += 4, page += TARGET_PAGE_SIZE) {
> -        if (cpu_physical_memory_get_dirty(page, VGA_DIRTY_FLAG)) {
> +        if (memory_region_get_dirty(&ts->vram_mem, page, DIRTY_MEMORY_VGA)) {
>             if (y_start < 0)
>                 y_start = y;
>             if (page < page_min)
> @@ -279,8 +290,9 @@ static void tcx_update_display(void *opaque)
>     }
>     /* reset modified pages */
>     if 

Re: [Qemu-devel] [PATCH v3 1/4] vga: make PCI devices optional

2011-10-17 Thread Blue Swirl
On Mon, Oct 17, 2011 at 7:17 AM, Jan Kiszka  wrote:
> On 2011-10-16 23:21, Blue Swirl wrote:
>> Improve VGA selection logic, push check for device availabilty to vl.c.
>> Make PCI VGA devices optional.
>>
>> Signed-off-by: Blue Swirl 
>> ---
>>  hw/cirrus_vga.c |    5 -
>>  hw/pc.c         |    6 +-
>>  hw/pc.h         |   33 +++--
>>  hw/pci.c        |   18 ++
>>  hw/pci.h        |    4 
>>  hw/qdev.c       |    5 +
>>  hw/qdev.h       |    1 +
>>  hw/vga-pci.c    |    6 --
>>  vl.c            |   33 +++--
>>  9 files changed, 83 insertions(+), 28 deletions(-)
>>
>> diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
>> index c7e365b..a11444c 100644
>> --- a/hw/cirrus_vga.c
>> +++ b/hw/cirrus_vga.c
>> @@ -2955,11 +2955,6 @@ static int pci_cirrus_vga_initfn(PCIDevice *dev)
>>       return 0;
>>  }
>>
>> -void pci_cirrus_vga_init(PCIBus *bus)
>> -{
>> -    pci_create_simple(bus, -1, "cirrus-vga");
>> -}
>> -
>>  static PCIDeviceInfo cirrus_vga_info = {
>>      .qdev.name    = "cirrus-vga",
>>      .qdev.desc    = "Cirrus CLGD 54xx VGA",
>> diff --git a/hw/pc.c b/hw/pc.c
>> index f0802b7..057eb9c 100644
>> --- a/hw/pc.c
>> +++ b/hw/pc.c
>> @@ -1080,11 +1080,7 @@ void pc_vga_init(PCIBus *pci_bus)
>>          }
>>      } else if (vmsvga_enabled) {
>>          if (pci_bus) {
>> -            if (!pci_vmsvga_init(pci_bus)) {
>> -                fprintf(stderr, "Warning: vmware_vga not available,"
>> -                        " using standard VGA instead\n");
>> -                pci_vga_init(pci_bus);
>> -            }
>> +            pci_vmsvga_init(pci_bus);
>>          } else {
>>              fprintf(stderr, "%s: vmware_vga: no PCI bus\n", __FUNCTION__);
>>          }
>> diff --git a/hw/pc.h b/hw/pc.h
>> index b8ad9a3..6c951e8 100644
>> --- a/hw/pc.h
>> +++ b/hw/pc.h
>> @@ -9,6 +9,7 @@
>>  #include "net.h"
>>  #include "memory.h"
>>  #include "ioapic.h"
>> +#include "pci.h"
>>
>>  /* PC-style peripherals (also used by other machines).  */
>>
>> @@ -203,26 +204,46 @@ enum vga_retrace_method {
>>
>>  extern enum vga_retrace_method vga_retrace_method;
>>
>> -static inline int isa_vga_init(void)
>> +static inline bool isa_vga_init(void)
>>  {
>>      ISADevice *dev;
>>
>>      dev = isa_try_create("isa-vga");
>>      if (!dev) {
>> -        fprintf(stderr, "Warning: isa-vga not available\n");
>> -        return 0;
>> +        return false;
>>      }
>>      qdev_init_nofail(&dev->qdev);
>> -    return 1;
>> +    return true;
>> +}
>> +
>> +/* vga-pci.c */
>> +static inline bool pci_vga_init(PCIBus *bus)
>> +{
>> +    PCIDevice *dev;
>> +
>> +    dev = pci_try_create_simple(bus, -1, "VGA");
>> +    if (!dev) {
>> +        return false;
>> +    }
>> +    return true;
>>  }
>>
>> -int pci_vga_init(PCIBus *bus);
>>  int isa_vga_mm_init(target_phys_addr_t vram_base,
>>                      target_phys_addr_t ctrl_base, int it_shift,
>>                      MemoryRegion *address_space);
>>
>>  /* cirrus_vga.c */
>> -void pci_cirrus_vga_init(PCIBus *bus);
>> +static inline bool pci_cirrus_vga_init(PCIBus *bus)
>> +{
>> +    PCIDevice *dev;
>> +
>> +    dev = pci_try_create_simple(bus, -1, "cirrus-vga");
>> +    if (!dev) {
>> +        return false;
>> +    }
>> +    return true;
>> +}
>> +
>>  void isa_cirrus_vga_init(MemoryRegion *address_space);
>>
>>  /* ne2000.c */
>> diff --git a/hw/pci.c b/hw/pci.c
>> index 749e8d8..46c01ac 100644
>> --- a/hw/pci.c
>> +++ b/hw/pci.c
>> @@ -1687,6 +1687,19 @@ PCIDevice
>> *pci_create_simple_multifunction(PCIBus *bus, int devfn,
>>      return dev;
>>  }
>>
>> +PCIDevice *pci_try_create_simple_multifunction(PCIBus *bus, int devfn,
>> +                                               bool multifunction,
>> +                                               const char *name)
>> +{
>> +    PCIDevice *dev = pci_try_create_multifunction(bus, devfn, multifunction,
>> +                                                  name);
>> +    if (!dev) {
>> +        return NULL;
>> +    }
>> +    qdev_init_nofail(&dev->qdev);
>> +    return dev;
>> +}
>> +
>>  PCIDevice *pci_create(PCIBus *bus, int devfn, const char *name)
>>  {
>>      return pci_create_multifunction(bus, devfn, false, name);
>> @@ -1702,6 +1715,11 @@ PCIDevice *pci_try_create(PCIBus *bus, int
>> devfn, const char *name)
>>      return pci_try_create_multifunction(bus, devfn, false, name);
>>  }
>>
>> +PCIDevice *pci_try_create_simple(PCIBus *bus, int devfn, const char *name)
>> +{
>> +    return pci_try_create_simple_multifunction(bus, devfn, false, name);
>> +}
>> +
>>  static int pci_find_space(PCIDevice *pdev, uint8_t size)
>>  {
>>      int config_size = pci_config_size(pdev);
>> diff --git a/hw/pci.h b/hw/pci.h
>> index 86a81c8..aa2e040 100644
>> --- a/hw/pci.h
>> +++ b/hw/pci.h
>> @@ -473,9 +473,13 @@ PCIDevice *pci_create_simple_multifunction(PCIBus
>> *bus, int devfn,
>>  PCIDevice *pci_try_create_multifunction(PCIBus *bus, int devfn,
>>       

Re: [Qemu-devel] GPLv3 troubles

2011-10-17 Thread Anthony Liguori

On 10/17/2011 01:34 PM, Peter Maydell wrote:

On 17 October 2011 19:29, Anthony Liguori  wrote:

Likewise, we could add tracing to translate.c to achieve the same affect as
in_asm.


Having the code you're trying to debug be also doing the printing out
of the disassembly seems like a recipe for confusing yourself (because
you lose the independent crosscheck of what's actually going in). I'd
rather have the logging dump plain hex to postprocess with objdump...


Fair enough.

Regards,

Anthony Liguori



-- PMM






Re: [Qemu-devel] GPLv3 troubles

2011-10-17 Thread Peter Maydell
On 17 October 2011 19:29, Anthony Liguori  wrote:
> Likewise, we could add tracing to translate.c to achieve the same affect as
> in_asm.

Having the code you're trying to debug be also doing the printing out
of the disassembly seems like a recipe for confusing yourself (because
you lose the independent crosscheck of what's actually going in). I'd
rather have the logging dump plain hex to postprocess with objdump...

-- PMM



Re: [Qemu-devel] GPLv3 troubles

2011-10-17 Thread Anthony Liguori

On 10/17/2011 01:20 PM, Stefan Weil wrote:

Am 17.10.2011 20:16, schrieb Anthony Liguori:

On 10/17/2011 12:58 PM, Andreas Färber wrote:

Am 17.10.2011 18:51, schrieb Anthony Liguori:

Including binutils code is just a bad idea.


Do you see a real alternative? Would it be possible to pipe machine code
from QEMU into an external disassembler?


Sure. This is only used in the monitor for interactive debugging, right?


The disassembler is also used with -d in_asm or -d out_asm to write qemu.log.
I expect that a pipe to an external disassembler would slow down execution with 
-d
significantly.


How difficult would it be to add tracing to tcg-target.c such that you could get 
out_asm that way?


At least with i386, there's just a few instruction forms so it should just be a 
matter of a few trace points with a table of opcode names.


Likewise, we could add tracing to translate.c to achieve the same affect as 
in_asm.

Tracing's probably a far better approach for debugging as you would be able to 
do some very interesting things with SystemTap and such a mechanism.


Regards,

Anthony Liguori


Regards,
Stefan Weil







[Qemu-devel] [Bug 874038] Re: ARM thumb2 does not propogate carry flag properly

2011-10-17 Thread Peter Maydell
Current git master works for me on that test program without your patch:
cam-vm-266:maverick:qemu$ ./arm-linux-user/qemu-arm ~/Desktop/mvns_imm.exe 
cam-vm-266:maverick:qemu$ echo $?
0

(I tested on qemu-0.14 just to confirm that I'm running the test program
correctly, and that indeed fails as I would expect it to, exiting with
status 255.)

Which qemu version have you been testing with?

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

Title:
  ARM thumb2 does not propogate carry flag properly

Status in QEMU:
  New

Bug description:
  information on carry flag is lost if gen_set_CF_bit31(t1) is called
  after logic operation.

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



Re: [Qemu-devel] GPLv3 troubles

2011-10-17 Thread Stefan Weil

Am 17.10.2011 20:16, schrieb Anthony Liguori:

On 10/17/2011 12:58 PM, Andreas Färber wrote:

Am 17.10.2011 18:51, schrieb Anthony Liguori:

Including binutils code is just a bad idea.


Do you see a real alternative? Would it be possible to pipe machine code
from QEMU into an external disassembler?


Sure.  This is only used in the monitor for interactive debugging, right?


The disassembler is also used with -d in_asm or -d out_asm to write 
qemu.log.
I expect that a pipe to an external disassembler would slow down 
execution with -d

significantly.

Regards,
Stefan Weil




Re: [Qemu-devel] GPLv3 troubles

2011-10-17 Thread Peter Maydell
On 17 October 2011 19:16, Anthony Liguori  wrote:
> On 10/17/2011 12:58 PM, Andreas Färber wrote:
>> Do you see a real alternative? Would it be possible to pipe machine code
>> from QEMU into an external disassembler?
>
> Sure.  This is only used in the monitor for interactive debugging, right?

Also in the -d logs for non-interactive debugging.

-- PMM



Re: [Qemu-devel] GPLv3 troubles

2011-10-17 Thread Anthony Liguori

On 10/17/2011 12:58 PM, Andreas Färber wrote:

Am 17.10.2011 18:51, schrieb Anthony Liguori:

Including binutils code is just a bad idea.


Do you see a real alternative? Would it be possible to pipe machine code
from QEMU into an external disassembler?


Sure.  This is only used in the monitor for interactive debugging, right?

Regards,

Anthony Liguori



Andreas






Re: [Qemu-devel] GPLv3 troubles

2011-10-17 Thread Andreas Färber
Am 17.10.2011 18:51, schrieb Anthony Liguori:
> Including binutils code is just a bad idea.

Do you see a real alternative? Would it be possible to pipe machine code
from QEMU into an external disassembler?

Andreas

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



Re: [Qemu-devel] GPLv3 troubles

2011-10-17 Thread Andreas Färber
Am 17.10.2011 18:47, schrieb Anthony Liguori:
> It's not something that any one person can really change.  It would
> require a very large effort.  To give you an idea of the scope, I ran
> the following command:
> 
> $ grep GPL *.c  hw/*.c | grep -v 'or later' | cut -f1 -d: | sort -u |
> while read i; do echo $i; git log --format="  %an <%ae>" $i | sort -u; done

This fires on "or (at your option) any later version" and variations
thereof, including line breaks after "or" (e.g., blockdev.c).
Also for older files the SVN usernames appear as duplicates.
For SVN and CVS commits we'd additionally have to check the commit
message for whether the committer received the code from another author.

Of the list, 90% seem regular contributors.

I didn't say resolving the issue would be possible in a day. Introducing
more GPLv2-only code will make it even more work though.

Andreas

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



Re: [Qemu-devel] GPLv3 troubles

2011-10-17 Thread Stefan Weil

Am 17.10.2011 18:47, schrieb Anthony Liguori:

On 10/17/2011 11:30 AM, Andreas Färber wrote:

Am 17.10.2011 16:17, schrieb Anthony Liguori:

On 10/17/2011 07:50 AM, Paolo Bonzini wrote:

On 10/17/2011 02:38 PM, Anthony Liguori wrote:

Could we please draft some policy on this? This is not a GDB issue,
it's
very general. Whether we like it or not, there is GPLv3-licensed 
code

and there will probably be a GPLv4 one day.


I don't see anything wrong with GPLv2 only. While I don't think 
there's
anything wrong with GPLv3, I think that "or later" is a dangerous 
clause

to add.


License fragmentation with respect to the de facto standard toolchain
(binutils)
is wrong.


Fragmentation with respect to the de factor standard kernel (Linux) is
wrong.


Tell that to the GNU and FSF people. :)

In my personal opinion, Open Source licenses should preserve our
freedom, not make us unnecessarily duplicate code.

I'm just asking to not make the situation worse than it is.


It's not something that any one person can really change.  It would 
require a very large effort.  To give you an idea of the scope, I ran 
the following command:


$ grep GPL *.c  hw/*.c | grep -v 'or later' | cut -f1 -d: | sort -u | 
while read i; do echo $i; git log --format="  %an <%ae>" $i | sort -u; 
done


Here's the results.  All of these people would have to explicitly SoB 
a relicense of that specific file to include a "v2 or later" clause.  
In some cases, there's code from Thiemo which cannot be relicensed due 
to his untimely passing.



So let's start. For any of my contributions, I agree to GPL v2 or later.
Later generations should have the possibility to replace GPL v2 by
something which matches future requirements.

I'd appreciate if no new files were published with GPL v2 only.

Stefan W.

PS. I no longer use my old email address because Berlios
will be closed on 2011-12-31, see http://www.berlios.de/.




[Qemu-devel] [Bug 874038] Re: ARM thumb2 does not propogate carry flag properly

2011-10-17 Thread Alexey Starikovskiy
MVNS with immediate fails in attached test program at 0x82c0 location.
My patch fixes that.

** Attachment added: "failed test for MVNS.IMM opcode"
   
https://bugs.launchpad.net/qemu/+bug/874038/+attachment/2554573/+files/mvns_imm.exe

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

Title:
  ARM thumb2 does not propogate carry flag properly

Status in QEMU:
  New

Bug description:
  information on carry flag is lost if gen_set_CF_bit31(t1) is called
  after logic operation.

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



Re: [Qemu-devel] [SeaBIOS] [PATCH 0/5] More pci init simplifications

2011-10-17 Thread Isaku Yamahata
On Mon, Oct 17, 2011 at 11:57:09AM +0200, Gerd Hoffmann wrote:
> On 10/15/11 18:25, Kevin O'Connor wrote:
>> This main patch in this series is patch 2 - replacement of the
>> recursive scan with a linear scan.  The other patches are just
>> cosmetic changes.
>
> Looks sane at a quick glance.
>
>> Gerd - can you take a look at patch 2.  Also, what's your test case
>> for confirming multiple bus initialization?  The standard qemu/kvm
>> only has one host bus.
>
> That is a bit tricky.  Early revisions of the code I've tested with  
> Isaku's q35 patches which have quite a bunch of PCI bridges (pci  
> expresss upstream + down stream ports, standard dec bridge, ...) and  
> even bridges behind bridges.
>
> Isaku, what is the state of the q35 work btw?  I havn't seen any pci-e &  
> q35 patches on qemu-devel for quite a while.  It also would be nice to  
> have a recent version of the q35 patches to test this patch set.
>
>
> I've also used with mst's patch which adds a standard pci bridge to qemu  
> (patch attached) to run tests.

At first, I'd like to make it sure that it's not dead and I'm still
working on it.
I've been waiting for stabilizing of other related thing like
memory API(mostly done?), irq routing cleaning up, QOM etc...
I don't want to catch them up so frequently as I don't see any time soon
merge.

I'll push the latest my patches to my git repo, but I can't promise when. 
Sorry for inconvenience.

thanks,
-- 
yamahata



[Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp

2011-10-17 Thread Richard Henderson
On 10/17/2011 07:09 AM, Bob Breuer wrote:
> I don't think this is a free/g_free issue.  If I use the following
> patch, then I at least get the openbios messages:
> 
> diff --git a/cpu-exec.c b/cpu-exec.c
> index a9fa608..dfbd6ea 100644
> --- a/cpu-exec.c
> +++ b/cpu-exec.c
> @@ -180,6 +180,7 @@ static void cpu_handle_debug_exception(CPUState
>  /* main execution loop */
> 
>  volatile sig_atomic_t exit_request;
> +register void *ebp asm("ebp");
> 
>  int cpu_exec(CPUState *env)
>  {
> @@ -233,6 +234,8 @@ int cpu_exec(CPUState *env)
> 
>  /* prepare setjmp context for exception handling */
>  for(;;) {
> +int dummy = 0;
> +ebp = &dummy;

See if

  asm("" : : : "ebp");

also solves the problem.

> Google finds a mention of longjmp failing with -fomit-frame-pointer:
> http://lua-users.org/lists/lua-l/2005-02/msg00158.html
> 
> Looks like gcc 4.6 turns on -fomit-frame-pointer by default.

Hmm.  This is the first I've heard of a longjmp implementation 
failing without a frame pointer.  Presumably this is with the
mingw i.e. msvc libc?

This is something that could be worked around in gcc, I suppose.
We recognize longjmp for some things, we could force the use of
a frame pointer for msvc targets too.

For now it might be best to simply force -fno-omit-frame-pointer
for mingw host in the configure script.


r~



Re: [Qemu-devel] [PATCH 09/36] migration: don't "write" when migration is not active

2011-10-17 Thread Juan Quintela
Anthony Liguori  wrote:
> On 10/11/2011 05:00 AM, Juan Quintela wrote:
>> If migration is not active, just ignore writes.
>>
>> Signed-off-by: Juan Quintela
>> ---
>>   migration.c |4 
>>   1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/migration.c b/migration.c
>> index 7ac1fc2..090c925 100644
>> --- a/migration.c
>> +++ b/migration.c
>> @@ -323,6 +323,10 @@ ssize_t migrate_fd_put_buffer(void *opaque, const void 
>> *data, size_t size)
>>   FdMigrationState *s = opaque;
>>   ssize_t ret;
>>
>> +if (s->state != MIG_STATE_ACTIVE) {
>> +return -EIO;
>> +}
>> +
>
> Buffered file is buffered.  The migration may complete before the
> buffer is completely drained.  That means additional put_buffer calls
> may come after the migration state has moved to complete.

static void migrate_fd_completed(MigrationState *s)
{
DPRINTF("setting completed state\n");
if (migrate_fd_cleanup(s) < 0) {
s->state = MIG_STATE_ERROR;
} else {
s->state = MIG_STATE_COMPLETED;
runstate_set(RUN_STATE_POSTMIGRATE);
}
notifier_list_notify(&migration_state_notifiers, s);
}

After all the changes in this thread, that is the only place that can
change s->state to "MIG_STATE_COMPLETED", as you can see, we do that
after doing a migrate_fd_cleanup(), and that just flush + close the fd.

So, I still think that everything is done as expected. (testing confirms
that both migrate_cancel after one error don't hang and migration
without errors ends as expected.

Later, Juan.

> Regards,
> Anthony Liguori
>
>>   do {
>>   ret = s->write(s, data, size);
>>   } while (ret == -1&&  ((s->get_error(s)) == EINTR));



Re: [Qemu-devel] GPLv3 troubles

2011-10-17 Thread Andreas Färber
Am 17.10.2011 18:47, schrieb Peter Maydell:
> On 17 October 2011 17:39, Andreas Färber  wrote:
>> Am 17.10.2011 13:10, schrieb Paolo Bonzini:
>>> Making a list of GPLv2 files would be a start, though.
>>
>> grep -r version *.c comes up with these:
> 
> Your rune needs tweaking -- it isn't looking inside any
> subdirectories.

I know. I didn't claim it was complete.

Andreas

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



Re: [Qemu-devel] [PATCH 06/36] migration: If there is one error, it makes no sense to continue

2011-10-17 Thread Juan Quintela
Anthony Liguori  wrote:
> On 10/11/2011 05:00 AM, Juan Quintela wrote:
>> Signed-off-by: Juan Quintela
>
> The original intention of returning zero was to force a quick finish
> of the migration.
>
> I think this code makes things more brittle because now if you're not
> doing error checking in the throttling path, you'll just pause the
> migration forever instead of fast forwarding to a point where you're
> actually checking for errors.


This is the only caller:

while (!qemu_file_rate_limit(f)) {
int bytes_sent;

bytes_sent = ram_save_block(f);
bytes_transferred += bytes_sent;
if (bytes_sent == 0) { /* no more blocks */
break;
}
}

The error that I was finding is that whe get one error, we stay on that
loop a lot of time.  This change just made the error be discovered
instantanously.

Later, Juan.


>
> Regards,
>
> Anthony Liguori
>
>> ---
>>   buffered_file.c |6 +++---
>>   1 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/buffered_file.c b/buffered_file.c
>> index 486af57..bcdf04f 100644
>> --- a/buffered_file.c
>> +++ b/buffered_file.c
>> @@ -193,9 +193,9 @@ static int buffered_rate_limit(void *opaque)
>>   {
>>   QEMUFileBuffered *s = opaque;
>>
>> -if (s->has_error)
>> -return 0;
>> -
>> +if (s->has_error) {
>> +return 1;
>> +}
>>   if (s->freeze_output)
>>   return 1;
>>



Re: [Qemu-devel] GPLv3 troubles

2011-10-17 Thread Anthony Liguori

On 10/17/2011 11:47 AM, Peter Maydell wrote:

On 17 October 2011 17:39, Andreas Färber  wrote:

Am 17.10.2011 13:10, schrieb Paolo Bonzini:

Making a list of GPLv2 files would be a start, though.


grep -r version *.c comes up with these:


Your rune needs tweaking -- it isn't looking inside any
subdirectories.


Including binutils code is just a bad idea.  I know noone wants to hear that but 
it's unfortunately true.


The FSF does copyright assignment which means it's easy for them to relicense. 
Since we don't do copyright assignment, it's much, much harder for us to 
relicense.  We'd waste huge amounts of man hours trying to chase binutils license.


We need to stick with the v2 version of binutils and perhaps work toward an 
alternative in the future.  Relicensing is just not practical.


Regards,

Anthony Liguori



-- PMM






Re: [Qemu-devel] GPLv3 troubles

2011-10-17 Thread Peter Maydell
On 17 October 2011 17:39, Andreas Färber  wrote:
> Am 17.10.2011 13:10, schrieb Paolo Bonzini:
>> Making a list of GPLv2 files would be a start, though.
>
> grep -r version *.c comes up with these:

Your rune needs tweaking -- it isn't looking inside any
subdirectories.

-- PMM



Re: [Qemu-devel] GPLv3 troubles

2011-10-17 Thread Andreas Färber
Am 17.10.2011 13:10, schrieb Paolo Bonzini:
> Making a list of GPLv2 files would be a start, though.

grep -r version *.c comes up with these:

v2 only:
aio.c
block-migration.c
buffered_file.c
compatfd.c
error.c
iov.c
kvm-all.c
memory.c
migration.c
migration-exec.c
migration-fd.c
migration-tcp.c
migration-unix.c
module.c
nbd.c
notify.c
pflib.c
posix-aio-compat.c
qemu-nbd.c
qemu-sockets.c
qemu-tool.c
xen-all.c
xen-mapcache.c
xen-stub.c

v2 or v3 only:
bt-host.c
bt-vhci.c


Andreas

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



[Qemu-devel] [PATCH 03/18] pxa2xx: convert to memory API (part I)

2011-10-17 Thread Avi Kivity
Signed-off-by: Avi Kivity 
---
 hw/pxa.h|1 +
 hw/pxa2xx.c |  116 --
 2 files changed, 49 insertions(+), 68 deletions(-)

diff --git a/hw/pxa.h b/hw/pxa.h
index 1204165..3fb070f 100644
--- a/hw/pxa.h
+++ b/hw/pxa.h
@@ -151,6 +151,7 @@ typedef struct {
 } PXA2xxState;
 
 struct PXA2xxI2SState {
+MemoryRegion iomem;
 qemu_irq irq;
 qemu_irq rx_dma;
 qemu_irq tx_dma;
diff --git a/hw/pxa2xx.c b/hw/pxa2xx.c
index 70d7c8a..19ee094 100644
--- a/hw/pxa2xx.c
+++ b/hw/pxa2xx.c
@@ -521,6 +521,7 @@ static void pxa2xx_mm_write(void *opaque, 
target_phys_addr_t addr,
 /* Synchronous Serial Ports */
 typedef struct {
 SysBusDevice busdev;
+MemoryRegion iomem;
 qemu_irq irq;
 int enable;
 SSIBus *bus;
@@ -627,7 +628,8 @@ static void pxa2xx_ssp_fifo_update(PXA2xxSSPState *s)
 pxa2xx_ssp_int_update(s);
 }
 
-static uint32_t pxa2xx_ssp_read(void *opaque, target_phys_addr_t addr)
+static uint64_t pxa2xx_ssp_read(void *opaque, target_phys_addr_t addr,
+unsigned size)
 {
 PXA2xxSSPState *s = (PXA2xxSSPState *) opaque;
 uint32_t retval;
@@ -673,9 +675,10 @@ static uint32_t pxa2xx_ssp_read(void *opaque, 
target_phys_addr_t addr)
 }
 
 static void pxa2xx_ssp_write(void *opaque, target_phys_addr_t addr,
-uint32_t value)
+ uint64_t value64, unsigned size)
 {
 PXA2xxSSPState *s = (PXA2xxSSPState *) opaque;
+uint32_t value = value64;
 
 switch (addr) {
 case SSCR0:
@@ -762,16 +765,10 @@ static void pxa2xx_ssp_write(void *opaque, 
target_phys_addr_t addr,
 }
 }
 
-static CPUReadMemoryFunc * const pxa2xx_ssp_readfn[] = {
-pxa2xx_ssp_read,
-pxa2xx_ssp_read,
-pxa2xx_ssp_read,
-};
-
-static CPUWriteMemoryFunc * const pxa2xx_ssp_writefn[] = {
-pxa2xx_ssp_write,
-pxa2xx_ssp_write,
-pxa2xx_ssp_write,
+static const MemoryRegionOps pxa2xx_ssp_ops = {
+.read = pxa2xx_ssp_read,
+.write = pxa2xx_ssp_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
 };
 
 static void pxa2xx_ssp_save(QEMUFile *f, void *opaque)
@@ -823,15 +820,12 @@ static int pxa2xx_ssp_load(QEMUFile *f, void *opaque, int 
version_id)
 
 static int pxa2xx_ssp_init(SysBusDevice *dev)
 {
-int iomemtype;
 PXA2xxSSPState *s = FROM_SYSBUS(PXA2xxSSPState, dev);
 
 sysbus_init_irq(dev, &s->irq);
 
-iomemtype = cpu_register_io_memory(pxa2xx_ssp_readfn,
-   pxa2xx_ssp_writefn, s,
-   DEVICE_NATIVE_ENDIAN);
-sysbus_init_mmio(dev, 0x1000, iomemtype);
+memory_region_init_io(&s->iomem, &pxa2xx_ssp_ops, s, "pxa2xx-ssp", 0x1000);
+sysbus_init_mmio_region(dev, &s->iomem);
 register_savevm(&dev->qdev, "pxa2xx_ssp", -1, 0,
 pxa2xx_ssp_save, pxa2xx_ssp_load, s);
 
@@ -858,6 +852,7 @@ static int pxa2xx_ssp_init(SysBusDevice *dev)
 
 typedef struct {
 SysBusDevice busdev;
+MemoryRegion iomem;
 uint32_t rttr;
 uint32_t rtsr;
 uint32_t rtar;
@@ -1009,7 +1004,8 @@ static inline void pxa2xx_rtc_pi_tick(void *opaque)
 pxa2xx_rtc_int_update(s);
 }
 
-static uint32_t pxa2xx_rtc_read(void *opaque, target_phys_addr_t addr)
+static uint64_t pxa2xx_rtc_read(void *opaque, target_phys_addr_t addr,
+unsigned size)
 {
 PXA2xxRTCState *s = (PXA2xxRTCState *) opaque;
 
@@ -1055,9 +1051,10 @@ static uint32_t pxa2xx_rtc_read(void *opaque, 
target_phys_addr_t addr)
 }
 
 static void pxa2xx_rtc_write(void *opaque, target_phys_addr_t addr,
-uint32_t value)
+ uint64_t value64, unsigned size)
 {
 PXA2xxRTCState *s = (PXA2xxRTCState *) opaque;
+uint32_t value = value64;
 
 switch (addr) {
 case RTTR:
@@ -1157,16 +1154,10 @@ static void pxa2xx_rtc_write(void *opaque, 
target_phys_addr_t addr,
 }
 }
 
-static CPUReadMemoryFunc * const pxa2xx_rtc_readfn[] = {
-pxa2xx_rtc_read,
-pxa2xx_rtc_read,
-pxa2xx_rtc_read,
-};
-
-static CPUWriteMemoryFunc * const pxa2xx_rtc_writefn[] = {
-pxa2xx_rtc_write,
-pxa2xx_rtc_write,
-pxa2xx_rtc_write,
+static const MemoryRegionOps pxa2xx_rtc_ops = {
+.read = pxa2xx_rtc_read,
+.write = pxa2xx_rtc_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
 };
 
 static int pxa2xx_rtc_init(SysBusDevice *dev)
@@ -1174,7 +1165,6 @@ static int pxa2xx_rtc_init(SysBusDevice *dev)
 PXA2xxRTCState *s = FROM_SYSBUS(PXA2xxRTCState, dev);
 struct tm tm;
 int wom;
-int iomemtype;
 
 s->rttr = 0x7fff;
 s->rtsr = 0;
@@ -1201,9 +1191,8 @@ static int pxa2xx_rtc_init(SysBusDevice *dev)
 
 sysbus_init_irq(dev, &s->rtc_irq);
 
-iomemtype = cpu_register_io_memory(pxa2xx_rtc_readfn,
-pxa2xx_rtc_writefn, s, DEVICE_NATIVE_ENDIAN);
-sysbus_init_mmio(dev, 0x1, iomemtype);
+memory_region_init_io(&s->iomem, &pxa2xx_rtc_ops, s, "pxa2xx-rtc", 
0x1);
+sysbus_init

[Qemu-devel] [RFC 2/6] block: add bdrv_set_copy_on_read()

2011-10-17 Thread Stefan Hajnoczi
The bdrv_set_copy_on_read() function can be used to programmatically
enable or disable copy-on-read for a block device.  Later patches add
the actual copy-on-read logic.

Signed-off-by: Stefan Hajnoczi 
---
 block.c |   17 +
 block.h |3 +++
 block_int.h |1 +
 3 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/block.c b/block.c
index 2d2c62a..e624ac3 100644
--- a/block.c
+++ b/block.c
@@ -464,6 +464,18 @@ int bdrv_parse_cache_flags(const char *mode, int *flags)
 return 0;
 }
 
+void bdrv_set_copy_on_read(BlockDriverState *bs, int enable)
+{
+if (bs->copy_on_read != enable) {
+if (enable) {
+bdrv_start_request_tracking(bs);
+} else {
+bdrv_stop_request_tracking(bs);
+}
+}
+bs->copy_on_read = enable;
+}
+
 /*
  * Common part for opening disk images and files
  */
@@ -483,6 +495,11 @@ static int bdrv_open_common(BlockDriverState *bs, const 
char *filename,
 bs->open_flags = flags;
 bs->buffer_alignment = 512;
 
+bs->copy_on_read = 0;
+if (flags & BDRV_O_RDWR) {
+bdrv_set_copy_on_read(bs, !!(flags & BDRV_O_COPY_ON_READ));
+}
+
 pstrcpy(bs->filename, sizeof(bs->filename), filename);
 
 if (use_bdrv_whitelist && !bdrv_is_whitelisted(drv)) {
diff --git a/block.h b/block.h
index e77988e..cb9832c 100644
--- a/block.h
+++ b/block.h
@@ -61,6 +61,7 @@ typedef struct BlockDevOps {
 #define BDRV_O_NATIVE_AIO  0x0080 /* use native AIO instead of the thread pool 
*/
 #define BDRV_O_NO_BACKING  0x0100 /* don't open the backing file */
 #define BDRV_O_NO_FLUSH0x0200 /* disable flushing on this disk */
+#define BDRV_O_COPY_ON_READ 0x0400 /* copy read backing sectors into image */
 
 #define BDRV_O_CACHE_MASK  (BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NO_FLUSH)
 
@@ -291,6 +292,8 @@ void bdrv_reset_dirty(BlockDriverState *bs, int64_t 
cur_sector,
   int nr_sectors);
 int64_t bdrv_get_dirty_count(BlockDriverState *bs);
 
+void bdrv_set_copy_on_read(BlockDriverState *bs, int enable);
+
 void bdrv_set_in_use(BlockDriverState *bs, int in_use);
 int bdrv_in_use(BlockDriverState *bs);
 
diff --git a/block_int.h b/block_int.h
index 87ce8b4..8eb4795 100644
--- a/block_int.h
+++ b/block_int.h
@@ -160,6 +160,7 @@ struct BlockDriverState {
 int encrypted; /* if true, the media is encrypted */
 int valid_key; /* if true, a valid encryption key has been set */
 int sg;/* if true, the device is a /dev/sg* */
+int copy_on_read; /* if true, copy read backing sectors into image */
 
 BlockDriver *drv; /* NULL means no media */
 void *opaque;
-- 
1.7.6.3




[Qemu-devel] [PATCH 15/18] sun4u: convert to memory API

2011-10-17 Thread Avi Kivity
Signed-off-by: Avi Kivity 
---
 hw/sun4u.c |   22 +-
 1 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/hw/sun4u.c b/hw/sun4u.c
index 96fc3d0..eaaefe3 100644
--- a/hw/sun4u.c
+++ b/hw/sun4u.c
@@ -574,6 +574,11 @@ static void pci_ebus_register(void)
 
 device_init(pci_ebus_register);
 
+typedef struct PROMState {
+SysBusDevice busdev;
+MemoryRegion prom;
+} PROMState;
+
 static uint64_t translate_prom_address(void *opaque, uint64_t addr)
 {
 target_phys_addr_t *base_addr = (target_phys_addr_t *)opaque;
@@ -617,17 +622,18 @@ static void prom_init(target_phys_addr_t addr, const char 
*bios_name)
 
 static int prom_init1(SysBusDevice *dev)
 {
-ram_addr_t prom_offset;
+PROMState *s = FROM_SYSBUS(PROMState, dev);
 
-prom_offset = qemu_ram_alloc(NULL, "sun4u.prom", PROM_SIZE_MAX);
-sysbus_init_mmio(dev, PROM_SIZE_MAX, prom_offset | IO_MEM_ROM);
+memory_region_init_ram(&s->prom, NULL, "sun4u.prom", PROM_SIZE_MAX);
+memory_region_set_readonly(&s->prom, true);
+sysbus_init_mmio_region(dev, &s->prom);
 return 0;
 }
 
 static SysBusDeviceInfo prom_info = {
 .init = prom_init1,
 .qdev.name  = "openprom",
-.qdev.size  = sizeof(SysBusDevice),
+.qdev.size  = sizeof(PROMState),
 .qdev.props = (Property[]) {
 {/* end of property list */}
 }
@@ -644,19 +650,17 @@ static void prom_register_devices(void)
 typedef struct RamDevice
 {
 SysBusDevice busdev;
+MemoryRegion ram;
 uint64_t size;
 } RamDevice;
 
 /* System RAM */
 static int ram_init1(SysBusDevice *dev)
 {
-ram_addr_t RAM_size, ram_offset;
 RamDevice *d = FROM_SYSBUS(RamDevice, dev);
 
-RAM_size = d->size;
-
-ram_offset = qemu_ram_alloc(NULL, "sun4u.ram", RAM_size);
-sysbus_init_mmio(dev, RAM_size, ram_offset);
+memory_region_init_ram(&d->ram, NULL, "sun4u.ram", d->size);
+sysbus_init_mmio_region(dev, &d->ram);
 return 0;
 }
 
-- 
1.7.6.3




[Qemu-devel] [PATCH 4/7] stellaris: convert sys to memory API

2011-10-17 Thread Benoît Canet
Signed-off-by: Benoit Canet 
---
 hw/stellaris.c |   28 +++-
 1 files changed, 11 insertions(+), 17 deletions(-)

diff --git a/hw/stellaris.c b/hw/stellaris.c
index 2bf1c23..6f9146a 100644
--- a/hw/stellaris.c
+++ b/hw/stellaris.c
@@ -327,6 +327,7 @@ static int stellaris_gptm_init(SysBusDevice *dev)
 /* System controller.  */
 
 typedef struct {
+MemoryRegion iomem;
 uint32_t pborctl;
 uint32_t ldopctl;
 uint32_t int_status;
@@ -414,7 +415,8 @@ static int ssys_board_class(const ssys_state *s)
 }
 }
 
-static uint32_t ssys_read(void *opaque, target_phys_addr_t offset)
+static uint64_t ssys_read(void *opaque, target_phys_addr_t offset,
+  unsigned size)
 {
 ssys_state *s = (ssys_state *)opaque;
 
@@ -518,7 +520,8 @@ static void ssys_calculate_system_clock(ssys_state *s)
 }
 }
 
-static void ssys_write(void *opaque, target_phys_addr_t offset, uint32_t value)
+static void ssys_write(void *opaque, target_phys_addr_t offset,
+   uint64_t value, unsigned size)
 {
 ssys_state *s = (ssys_state *)opaque;
 
@@ -602,16 +605,10 @@ static void ssys_write(void *opaque, target_phys_addr_t 
offset, uint32_t value)
 ssys_update(s);
 }
 
-static CPUReadMemoryFunc * const ssys_readfn[] = {
-   ssys_read,
-   ssys_read,
-   ssys_read
-};
-
-static CPUWriteMemoryFunc * const ssys_writefn[] = {
-   ssys_write,
-   ssys_write,
-   ssys_write
+static const MemoryRegionOps ssys_ops = {
+.read = ssys_read,
+.write = ssys_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
 };
 
 static void ssys_reset(void *opaque)
@@ -667,7 +664,6 @@ static int stellaris_sys_init(uint32_t base, qemu_irq irq,
   stellaris_board_info * board,
   uint8_t *macaddr)
 {
-int iomemtype;
 ssys_state *s;
 
 s = (ssys_state *)g_malloc0(sizeof(ssys_state));
@@ -677,10 +673,8 @@ static int stellaris_sys_init(uint32_t base, qemu_irq irq,
 s->user0 = macaddr[0] | (macaddr[1] << 8) | (macaddr[2] << 16);
 s->user1 = macaddr[3] | (macaddr[4] << 8) | (macaddr[5] << 16);
 
-iomemtype = cpu_register_io_memory(ssys_readfn,
-   ssys_writefn, s,
-   DEVICE_NATIVE_ENDIAN);
-cpu_register_physical_memory(base, 0x1000, iomemtype);
+memory_region_init_io(&s->iomem, &ssys_ops, s, "ssys", 0x1000);
+memory_region_add_subregion(get_system_memory(), base, &s->iomem);
 ssys_reset(s);
 vmstate_register(NULL, -1, &vmstate_stellaris_sys, s);
 return 0;
-- 
1.7.5.4




[Qemu-devel] [PATCH 5/7] stellaris: convert i2c to memory API

2011-10-17 Thread Benoît Canet
Signed-off-by: Benoit Canet 
Reviewed-by: Peter Maydell 
---
 hw/stellaris.c |   28 +++-
 1 files changed, 11 insertions(+), 17 deletions(-)

diff --git a/hw/stellaris.c b/hw/stellaris.c
index 6f9146a..f55b1f3 100644
--- a/hw/stellaris.c
+++ b/hw/stellaris.c
@@ -687,6 +687,7 @@ typedef struct {
 SysBusDevice busdev;
 i2c_bus *bus;
 qemu_irq irq;
+MemoryRegion iomem;
 uint32_t msa;
 uint32_t mcs;
 uint32_t mdr;
@@ -704,7 +705,8 @@ typedef struct {
 #define STELLARIS_I2C_MCS_IDLE0x20
 #define STELLARIS_I2C_MCS_BUSBSY  0x40
 
-static uint32_t stellaris_i2c_read(void *opaque, target_phys_addr_t offset)
+static uint64_t stellaris_i2c_read(void *opaque, target_phys_addr_t offset,
+   unsigned size)
 {
 stellaris_i2c_state *s = (stellaris_i2c_state *)opaque;
 
@@ -741,7 +743,7 @@ static void stellaris_i2c_update(stellaris_i2c_state *s)
 }
 
 static void stellaris_i2c_write(void *opaque, target_phys_addr_t offset,
-uint32_t value)
+uint64_t value, unsigned size)
 {
 stellaris_i2c_state *s = (stellaris_i2c_state *)opaque;
 
@@ -832,16 +834,10 @@ static void stellaris_i2c_reset(stellaris_i2c_state *s)
 stellaris_i2c_update(s);
 }
 
-static CPUReadMemoryFunc * const stellaris_i2c_readfn[] = {
-   stellaris_i2c_read,
-   stellaris_i2c_read,
-   stellaris_i2c_read
-};
-
-static CPUWriteMemoryFunc * const stellaris_i2c_writefn[] = {
-   stellaris_i2c_write,
-   stellaris_i2c_write,
-   stellaris_i2c_write
+static const MemoryRegionOps stellaris_i2c_ops = {
+.read = stellaris_i2c_read,
+.write = stellaris_i2c_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
 };
 
 static const VMStateDescription vmstate_stellaris_i2c = {
@@ -865,16 +861,14 @@ static int stellaris_i2c_init(SysBusDevice * dev)
 {
 stellaris_i2c_state *s = FROM_SYSBUS(stellaris_i2c_state, dev);
 i2c_bus *bus;
-int iomemtype;
 
 sysbus_init_irq(dev, &s->irq);
 bus = i2c_init_bus(&dev->qdev, "i2c");
 s->bus = bus;
 
-iomemtype = cpu_register_io_memory(stellaris_i2c_readfn,
-   stellaris_i2c_writefn, s,
-   DEVICE_NATIVE_ENDIAN);
-sysbus_init_mmio(dev, 0x1000, iomemtype);
+memory_region_init_io(&s->iomem, &stellaris_i2c_ops, s,
+  "i2c", 0x1000);
+sysbus_init_mmio_region(dev, &s->iomem);
 /* ??? For now we only implement the master interface.  */
 stellaris_i2c_reset(s);
 vmstate_register(&dev->qdev, -1, &vmstate_stellaris_i2c, s);
-- 
1.7.5.4




[Qemu-devel] [RFC 4/6] block: request overlap detection

2011-10-17 Thread Stefan Hajnoczi
Detect overlapping requests and remember to align to cluster boundaries
if the image format uses them.  This assumes that allocating I/O is
performed in cluster granularity - which is true for qcow2, qed, etc.

Signed-off-by: Stefan Hajnoczi 
---
 block.c |   39 +--
 1 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/block.c b/block.c
index cc3202c..0c22741 100644
--- a/block.c
+++ b/block.c
@@ -1052,21 +1052,56 @@ static BdrvTrackedRequest 
*tracked_request_add(BlockDriverState *bs,
 return req;
 }
 
+/**
+ * Round a region to cluster boundaries
+ */
+static void round_to_clusters(BlockDriverState *bs,
+  int64_t sector_num, int nb_sectors,
+  int64_t *cluster_sector_num,
+  int *cluster_nb_sectors)
+{
+BlockDriverInfo bdi;
+
+if (bdrv_get_info(bs, &bdi) < 0 || bdi.cluster_size == 0) {
+*cluster_sector_num = sector_num;
+*cluster_nb_sectors = nb_sectors;
+} else {
+int64_t c = bdi.cluster_size / BDRV_SECTOR_SIZE;
+*cluster_sector_num = (sector_num / c) * c;
+*cluster_nb_sectors = ((sector_num % c) + nb_sectors + c - 1) / c * c;
+}
+}
+
 static bool tracked_request_overlaps(BdrvTrackedRequest *req,
  int64_t sector_num, int nb_sectors) {
-return false; /* not yet implemented */
+/*    */
+if (sector_num >= req->sector_num + req->nb_sectors) {
+return false;
+}
+/*    */
+if (req->sector_num >= sector_num + nb_sectors) {
+return false;
+}
+return true;
 }
 
 static void coroutine_fn wait_for_overlapping_requests(BlockDriverState *bs,
 int64_t sector_num, int nb_sectors)
 {
 BdrvTrackedRequest *req;
+int64_t cluster_sector_num;
+int cluster_nb_sectors;
 bool retry;
 
+/* If we touch the same cluster it counts as an overlap */
+round_to_clusters(bs, sector_num, nb_sectors,
+  &cluster_sector_num, &cluster_nb_sectors);
+
 do {
 retry = false;
 QLIST_FOREACH(req, &bs->tracked_requests, list) {
-if (tracked_request_overlaps(req, sector_num, nb_sectors)) {
+if (tracked_request_overlaps(req, cluster_sector_num,
+ cluster_nb_sectors)) {
 qemu_co_queue_wait(&req->wait_queue);
 retry = true;
 break;
-- 
1.7.6.3




Re: [Qemu-devel] GPLv3 troubles

2011-10-17 Thread Andreas Färber
Am 17.10.2011 16:17, schrieb Anthony Liguori:
> On 10/17/2011 07:50 AM, Paolo Bonzini wrote:
>> On 10/17/2011 02:38 PM, Anthony Liguori wrote:
 Could we please draft some policy on this? This is not a GDB issue,
 it's
 very general. Whether we like it or not, there is GPLv3-licensed code
 and there will probably be a GPLv4 one day.
>>>
>>> I don't see anything wrong with GPLv2 only. While I don't think there's
>>> anything wrong with GPLv3, I think that "or later" is a dangerous clause
>>> to add.
>>
>> License fragmentation with respect to the de facto standard toolchain
>> (binutils)
>> is wrong.
> 
> Fragmentation with respect to the de factor standard kernel (Linux) is
> wrong.

Tell that to the GNU and FSF people. :)

In my personal opinion, Open Source licenses should preserve our
freedom, not make us unnecessarily duplicate code.

I'm just asking to not make the situation worse than it is.

Regards,
Andreas

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



[Qemu-devel] [PATCH 6/7] stellaris: convert adc to memory API

2011-10-17 Thread Benoît Canet
Signed-off-by: Benoit Canet 
---
 hw/stellaris.c |   30 --
 1 files changed, 12 insertions(+), 18 deletions(-)

diff --git a/hw/stellaris.c b/hw/stellaris.c
index f55b1f3..533d9c1 100644
--- a/hw/stellaris.c
+++ b/hw/stellaris.c
@@ -892,6 +892,7 @@ static int stellaris_i2c_init(SysBusDevice * dev)
 typedef struct
 {
 SysBusDevice busdev;
+MemoryRegion iomem;
 uint32_t actss;
 uint32_t ris;
 uint32_t im;
@@ -992,7 +993,8 @@ static void stellaris_adc_reset(stellaris_adc_state *s)
 }
 }
 
-static uint32_t stellaris_adc_read(void *opaque, target_phys_addr_t offset)
+static uint64_t stellaris_adc_read(void *opaque, target_phys_addr_t offset,
+   unsigned size)
 {
 stellaris_adc_state *s = (stellaris_adc_state *)opaque;
 
@@ -1040,7 +1042,7 @@ static uint32_t stellaris_adc_read(void *opaque, 
target_phys_addr_t offset)
 }
 
 static void stellaris_adc_write(void *opaque, target_phys_addr_t offset,
-uint32_t value)
+uint64_t value, unsigned size)
 {
 stellaris_adc_state *s = (stellaris_adc_state *)opaque;
 
@@ -1054,7 +1056,7 @@ static void stellaris_adc_write(void *opaque, 
target_phys_addr_t offset,
 return;
 case 0x04: /* SSCTL */
 if (value != 6) {
-hw_error("ADC: Unimplemented sequence %x\n",
+hw_error("ADC: Unimplemented sequence %" PRIx64 "\n",
   value);
 }
 s->ssctl[n] = value;
@@ -1097,16 +1099,10 @@ static void stellaris_adc_write(void *opaque, 
target_phys_addr_t offset,
 stellaris_adc_update(s);
 }
 
-static CPUReadMemoryFunc * const stellaris_adc_readfn[] = {
-   stellaris_adc_read,
-   stellaris_adc_read,
-   stellaris_adc_read
-};
-
-static CPUWriteMemoryFunc * const stellaris_adc_writefn[] = {
-   stellaris_adc_write,
-   stellaris_adc_write,
-   stellaris_adc_write
+static const MemoryRegionOps stellaris_adc_ops = {
+.read = stellaris_adc_read,
+.write = stellaris_adc_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
 };
 
 static const VMStateDescription vmstate_stellaris_adc = {
@@ -1147,17 +1143,15 @@ static const VMStateDescription vmstate_stellaris_adc = 
{
 static int stellaris_adc_init(SysBusDevice *dev)
 {
 stellaris_adc_state *s = FROM_SYSBUS(stellaris_adc_state, dev);
-int iomemtype;
 int n;
 
 for (n = 0; n < 4; n++) {
 sysbus_init_irq(dev, &s->irq[n]);
 }
 
-iomemtype = cpu_register_io_memory(stellaris_adc_readfn,
-   stellaris_adc_writefn, s,
-   DEVICE_NATIVE_ENDIAN);
-sysbus_init_mmio(dev, 0x1000, iomemtype);
+memory_region_init_io(&s->iomem, &stellaris_adc_ops, s,
+  "adc", 0x1000);
+sysbus_init_mmio_region(dev, &s->iomem);
 stellaris_adc_reset(s);
 qdev_init_gpio_in(&dev->qdev, stellaris_adc_trigger, 1);
 vmstate_register(&dev->qdev, -1, &vmstate_stellaris_adc, s);
-- 
1.7.5.4




[Qemu-devel] [RFC 1/6] block: add request tracking

2011-10-17 Thread Stefan Hajnoczi
The block layer does not know about pending requests.  This information
is necessary for copy-on-read since overlapping requests must be
serialized to prevent races that corrupt the image.

Add a simple mechanism to enable/disable request tracking.  By default
request tracking is disabled.

The BlockDriverState gets a new tracked_request list field which
contains all pending requests.  Each request is a BdrvTrackedRequest
record with sector_num, nb_sectors, and is_write fields.

Signed-off-by: Stefan Hajnoczi 
---
 block.c |   83 ++-
 block_int.h |8 +
 2 files changed, 90 insertions(+), 1 deletions(-)

diff --git a/block.c b/block.c
index 9873b57..2d2c62a 100644
--- a/block.c
+++ b/block.c
@@ -978,6 +978,77 @@ void bdrv_commit_all(void)
 }
 }
 
+struct BdrvTrackedRequest {
+BlockDriverState *bs;
+int64_t sector_num;
+int nb_sectors;
+bool is_write;
+QLIST_ENTRY(BdrvTrackedRequest) list;
+};
+
+/**
+ * Remove an active request from the tracked requests list
+ *
+ * If req is NULL, no operation is performed.
+ *
+ * This function should be called when a tracked request is completing.
+ */
+static void tracked_request_remove(BdrvTrackedRequest *req)
+{
+if (req) {
+QLIST_REMOVE(req, list);
+g_free(req);
+}
+}
+
+/**
+ * Add an active request to the tracked requests list
+ *
+ * Return NULL if request tracking is disabled, non-NULL otherwise.
+ */
+static BdrvTrackedRequest *tracked_request_add(BlockDriverState *bs,
+   int64_t sector_num,
+   int nb_sectors, bool is_write)
+{
+BdrvTrackedRequest *req;
+
+if (!bs->request_tracking) {
+return NULL;
+}
+
+req = g_malloc(sizeof(*req));
+req->bs = bs;
+req->sector_num = sector_num;
+req->nb_sectors = nb_sectors;
+req->is_write = is_write;
+
+QLIST_INSERT_HEAD(&bs->tracked_requests, req, list);
+
+return req;
+}
+
+/**
+ * Enable tracking of incoming requests
+ *
+ * Request tracking can be safely used by multiple users at the same time,
+ * there is an internal reference count to match start and stop calls.
+ */
+void bdrv_start_request_tracking(BlockDriverState *bs)
+{
+bs->request_tracking++;
+}
+
+/**
+ * Disable tracking of incoming requests
+ *
+ * Note that in-flight requests are still tracked, this function only stops
+ * tracking incoming requests.
+ */
+void bdrv_stop_request_tracking(BlockDriverState *bs)
+{
+bs->request_tracking--;
+}
+
 /*
  * Return values:
  * 0- success
@@ -1262,6 +1333,8 @@ static int coroutine_fn bdrv_co_do_readv(BlockDriverState 
*bs,
 int64_t sector_num, int nb_sectors, QEMUIOVector *qiov)
 {
 BlockDriver *drv = bs->drv;
+BdrvTrackedRequest *req;
+int ret;
 
 if (!drv) {
 return -ENOMEDIUM;
@@ -1270,7 +1343,10 @@ static int coroutine_fn 
bdrv_co_do_readv(BlockDriverState *bs,
 return -EIO;
 }
 
-return drv->bdrv_co_readv(bs, sector_num, nb_sectors, qiov);
+req = tracked_request_add(bs, sector_num, nb_sectors, false);
+ret = drv->bdrv_co_readv(bs, sector_num, nb_sectors, qiov);
+tracked_request_remove(req);
+return ret;
 }
 
 int coroutine_fn bdrv_co_readv(BlockDriverState *bs, int64_t sector_num,
@@ -1288,6 +1364,7 @@ static int coroutine_fn 
bdrv_co_do_writev(BlockDriverState *bs,
 int64_t sector_num, int nb_sectors, QEMUIOVector *qiov)
 {
 BlockDriver *drv = bs->drv;
+BdrvTrackedRequest *req;
 int ret;
 
 if (!bs->drv) {
@@ -1300,6 +1377,8 @@ static int coroutine_fn 
bdrv_co_do_writev(BlockDriverState *bs,
 return -EIO;
 }
 
+req = tracked_request_add(bs, sector_num, nb_sectors, true);
+
 ret = drv->bdrv_co_writev(bs, sector_num, nb_sectors, qiov);
 
 if (bs->dirty_bitmap) {
@@ -1310,6 +1389,8 @@ static int coroutine_fn 
bdrv_co_do_writev(BlockDriverState *bs,
 bs->wr_highest_sector = sector_num + nb_sectors - 1;
 }
 
+tracked_request_remove(req);
+
 return ret;
 }
 
diff --git a/block_int.h b/block_int.h
index f2f4f2d..87ce8b4 100644
--- a/block_int.h
+++ b/block_int.h
@@ -43,6 +43,8 @@
 #define BLOCK_OPT_PREALLOC  "preallocation"
 #define BLOCK_OPT_SUBFMT"subformat"
 
+typedef struct BdrvTrackedRequest BdrvTrackedRequest;
+
 typedef struct AIOPool {
 void (*cancel)(BlockDriverAIOCB *acb);
 int aiocb_size;
@@ -206,6 +208,9 @@ struct BlockDriverState {
 int in_use; /* users other than guest access, eg. block migration */
 QTAILQ_ENTRY(BlockDriverState) list;
 void *private;
+
+int request_tracking;   /* reference count, 0 means off */
+QLIST_HEAD(, BdrvTrackedRequest) tracked_requests;
 };
 
 struct BlockDriverAIOCB {
@@ -216,6 +221,9 @@ struct BlockDriverAIOCB {
 BlockDriverAIOCB *next;
 };
 
+void bdrv_start_request_tracking(BlockDriverState *bs);
+void bdrv_stop_request_tracking(BlockDriverSt

[Qemu-devel] [PATCH 3/7] integratorcp: convert control to memory API

2011-10-17 Thread Benoît Canet
Signed-off-by: Benoit Canet 
---
 hw/integratorcp.c |   31 ++-
 1 files changed, 14 insertions(+), 17 deletions(-)

diff --git a/hw/integratorcp.c b/hw/integratorcp.c
index c7d6596..7f79560 100644
--- a/hw/integratorcp.c
+++ b/hw/integratorcp.c
@@ -392,7 +392,9 @@ static int icp_pic_init(SysBusDevice *dev)
 }
 
 /* CP control registers.  */
-static uint32_t icp_control_read(void *opaque, target_phys_addr_t offset)
+
+static uint64_t icp_control_read(void *opaque, target_phys_addr_t offset,
+ unsigned size)
 {
 switch (offset >> 2) {
 case 0: /* CP_IDFIELD */
@@ -410,7 +412,7 @@ static uint32_t icp_control_read(void *opaque, 
target_phys_addr_t offset)
 }
 
 static void icp_control_write(void *opaque, target_phys_addr_t offset,
-  uint32_t value)
+  uint64_t value, unsigned size)
 {
 switch (offset >> 2) {
 case 1: /* CP_FLASHPROG */
@@ -422,26 +424,21 @@ static void icp_control_write(void *opaque, 
target_phys_addr_t offset,
 hw_error("icp_control_write: Bad offset %x\n", (int)offset);
 }
 }
-static CPUReadMemoryFunc * const icp_control_readfn[] = {
-   icp_control_read,
-   icp_control_read,
-   icp_control_read
-};
 
-static CPUWriteMemoryFunc * const icp_control_writefn[] = {
-   icp_control_write,
-   icp_control_write,
-   icp_control_write
+static const MemoryRegionOps icp_control_ops = {
+.read = icp_control_read,
+.write = icp_control_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
 };
 
-static void icp_control_init(uint32_t base)
+static void icp_control_init(target_phys_addr_t base)
 {
-int iomemtype;
+MemoryRegion *io;
 
-iomemtype = cpu_register_io_memory(icp_control_readfn,
-   icp_control_writefn, NULL,
-   DEVICE_NATIVE_ENDIAN);
-cpu_register_physical_memory(base, 0x0080, iomemtype);
+io = (MemoryRegion *)g_malloc0(sizeof(MemoryRegion));
+memory_region_init_io(io, &icp_control_ops, NULL,
+  "control", 0x0080);
+memory_region_add_subregion(get_system_memory(), base, io);
 /* ??? Save/restore.  */
 }
 
-- 
1.7.5.4




[Qemu-devel] [PATCH 2/7] integratorcp: convert icp pic to memory API

2011-10-17 Thread Benoît Canet
Signed-off-by: Benoit Canet 
---
 hw/integratorcp.c |   27 ++-
 1 files changed, 10 insertions(+), 17 deletions(-)

diff --git a/hw/integratorcp.c b/hw/integratorcp.c
index 0dc84c4..c7d6596 100644
--- a/hw/integratorcp.c
+++ b/hw/integratorcp.c
@@ -279,6 +279,7 @@ static int integratorcm_init(SysBusDevice *dev)
 typedef struct icp_pic_state
 {
   SysBusDevice busdev;
+  MemoryRegion iomem;
   uint32_t level;
   uint32_t irq_enabled;
   uint32_t fiq_enabled;
@@ -306,7 +307,8 @@ static void icp_pic_set_irq(void *opaque, int irq, int 
level)
 icp_pic_update(s);
 }
 
-static uint32_t icp_pic_read(void *opaque, target_phys_addr_t offset)
+static uint64_t icp_pic_read(void *opaque, target_phys_addr_t offset,
+ unsigned size)
 {
 icp_pic_state *s = (icp_pic_state *)opaque;
 
@@ -335,7 +337,7 @@ static uint32_t icp_pic_read(void *opaque, 
target_phys_addr_t offset)
 }
 
 static void icp_pic_write(void *opaque, target_phys_addr_t offset,
-  uint32_t value)
+  uint64_t value, unsigned size)
 {
 icp_pic_state *s = (icp_pic_state *)opaque;
 
@@ -371,30 +373,21 @@ static void icp_pic_write(void *opaque, 
target_phys_addr_t offset,
 icp_pic_update(s);
 }
 
-static CPUReadMemoryFunc * const icp_pic_readfn[] = {
-   icp_pic_read,
-   icp_pic_read,
-   icp_pic_read
-};
-
-static CPUWriteMemoryFunc * const icp_pic_writefn[] = {
-   icp_pic_write,
-   icp_pic_write,
-   icp_pic_write
+static const MemoryRegionOps icp_pic_ops = {
+.read = icp_pic_read,
+.write = icp_pic_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
 };
 
 static int icp_pic_init(SysBusDevice *dev)
 {
 icp_pic_state *s = FROM_SYSBUS(icp_pic_state, dev);
-int iomemtype;
 
 qdev_init_gpio_in(&dev->qdev, icp_pic_set_irq, 32);
 sysbus_init_irq(dev, &s->parent_irq);
 sysbus_init_irq(dev, &s->parent_fiq);
-iomemtype = cpu_register_io_memory(icp_pic_readfn,
-   icp_pic_writefn, s,
-   DEVICE_NATIVE_ENDIAN);
-sysbus_init_mmio(dev, 0x0080, iomemtype);
+memory_region_init_io(&s->iomem, &icp_pic_ops, s, "icp-pic", 0x0080);
+sysbus_init_mmio_region(dev, &s->iomem);
 return 0;
 }
 
-- 
1.7.5.4




[Qemu-devel] [RFC 0/6] block: generic copy-on-read

2011-10-17 Thread Stefan Hajnoczi
The new -drive copy-on-read=on|off feature populates the image file with data
from the backing file on read.  This is useful when accessing images backed
over a slow medium (e.g. http over internet).  All read data will be stored in
the local image file so it does not need to be fetched again in the future.

This series is a prerequisite for the image streaming feature, which uses
copy-on-read to populate the image file in the background while the VM is
running.  However, the copy-on-read feature is useful on its own.

Copy-on-read is implemented by checking whether or not data is allocated in the
image file before reading it.  If data is not allocated then it needs to be
read and written back to the image file.

The tricky bit is avoiding races with other I/O requests.  These patches add
request tracking to BlockDriverState so that the list of pending requests is
available.  Copy-on-read prevents races by serializing overlapping requests.

Finally, there is a performance impact when enabling this feature since an
additional write is performed.  Serializing overlapping requests also means
that I/O patterns where multiple requests access the same cluster will see a
loss in parallelism.  Perhaps we can be smarter about preventing corruption in
the future and win back some performance.

Git repo:
http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/generic-copy-on-read

Stefan Hajnoczi (6):
  block: add request tracking
  block: add bdrv_set_copy_on_read()
  block: wait for overlapping requests
  block: request overlap detection
  block: core copy-on-read logic
  block: add -drive copy-on-read=on|off

 block.c |  243 ++-
 block.h |3 +
 block_int.h |9 ++
 blockdev.c  |6 ++
 hmp-commands.hx |5 +-
 qemu-config.c   |4 +
 qemu-options.hx |9 ++-
 trace-events|1 +
 8 files changed, 276 insertions(+), 4 deletions(-)

-- 
1.7.6.3




[Qemu-devel] [PATCH 1/1 V6] qemu-kvm: fix improper nmi emulation

2011-10-17 Thread Lai Jiangshan
On 10/17/2011 05:49 PM, Avi Kivity wrote:
> On 10/17/2011 11:40 AM, Lai Jiangshan wrote:

>>>
>>> LINT1 may have been programmed as a level -triggered interrupt instead
>>> of edge triggered (NMI or interrupt).  We can use the ioctl argument for
>>> the level (and pressing the NMI button needs to pulse the level to 1 and
>>> back to 0).
>>>
>>
>> Hi, Avi, Jan,
>>
>> Which approach you prefer to?
>> I need to know the result before wasting too much time to respin
>> the approach.
> 
> Yes, sorry about the slow and sometimes conflicting feedback.
> 
>> 1) Fix KVM_NMI emulation approach  (which is v3 patchset)
>>  - It directly fixes the problem and matches the
>>real hard ware more, but it changes KVM_NMI bahavior.
>>  - Require both kernel-site and userspace-site fix.
>>
>> 2) Get the LAPIC state from kernel irqchip, and inject NMI if it is allowed
>>(which is v4 patchset)
>>  - Simple, don't changes any kernel behavior.
>>  - Only need the userspace-site fix
>>
>> 3) Add KVM_SET_LINT1 approach (which is v5 patchset)
>>  - don't changes the kernel's KVM_NMI behavior.
>>  - much complex
>>  - Require both kernel-site and userspace-site fix.
>>  - userspace-site should also handle the !KVM_SET_LINT1
>>condition, it uses all the 2) approach' code. it means
>>this approach equals the 2) approach + KVM_SET_LINT1 ioctl.
>>
>> This is an urgent bug of us, we need to settle it down soo
> 
> While (1) is simple, it overloads a single ioctl with two meanings,
> that's not so good.
> 
> Whether we do (1) or (3), we need (2) as well, for older kernels.
> 
> So I recommend first focusing on (2) and merging it, then doing (3).
> 
> (note an additional issue with 3 is whether to make it a vm or vcpu
> ioctl - we've been assuming vcpu ioctl but it's not necessarily the best
> choice).
> 

It is the 2) approach.
It only changes the user space site, the kernel site is not touched.
It is changed from previous v4 patch, fixed problems found by Jan.


From: Lai Jiangshan 

Currently, NMI interrupt is blindly sent to all the vCPUs when NMI
button event happens. This doesn't properly emulate real hardware on
which NMI button event triggers LINT1. Because of this, NMI is sent to
the processor even when LINT1 is maskied in LVT. For example, this
causes the problem that kdump initiated by NMI sometimes doesn't work
on KVM, because kdump assumes NMI is masked on CPUs other than CPU0.

With this patch, inject-nmi request is handled as follows.

- When in-kernel irqchip is disabled, deliver LINT1 instead of NMI
  interrupt.
- When in-kernel irqchip is enabled, get the in-kernel LAPIC states
  and test the APIC_LVT_MASKED, if LINT1 is unmasked, and then
  delivering the NMI directly. (Suggested by Jan Kiszka)

Changed from old version:
  re-implement it by the Jan's suggestion.
  fix the race found by Jan.

Signed-off-by: Lai Jiangshan 
Reported-by: Kenji Kaneshige 
---
 hw/apic.c |   33 +
 hw/apic.h |1 +
 monitor.c |6 +-
 3 files changed, 39 insertions(+), 1 deletions(-)
diff --git a/hw/apic.c b/hw/apic.c
index 69d6ac5..922796a 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -205,6 +205,39 @@ void apic_deliver_pic_intr(DeviceState *d, int level)
 }
 }
 
+static inline uint32_t kapic_reg(struct kvm_lapic_state *kapic, int reg_id);
+
+static void kvm_irqchip_deliver_nmi(void *p)
+{
+APICState *s = p;
+struct kvm_lapic_state klapic;
+uint32_t lvt;
+
+kvm_get_lapic(s->cpu_env, &klapic);
+lvt = kapic_reg(&klapic, 0x32 + APIC_LVT_LINT1);
+
+if (lvt & APIC_LVT_MASKED) {
+return;
+}
+
+if (((lvt >> 8) & 7) != APIC_DM_NMI) {
+return;
+}
+
+kvm_vcpu_ioctl(s->cpu_env, KVM_NMI);
+}
+
+void apic_deliver_nmi(DeviceState *d)
+{
+APICState *s = DO_UPCAST(APICState, busdev.qdev, d);
+
+if (kvm_irqchip_in_kernel()) {
+run_on_cpu(s->cpu_env, kvm_irqchip_deliver_nmi, s);
+} else {
+apic_local_deliver(s, APIC_LVT_LINT1);
+}
+}
+
 #define foreach_apic(apic, deliver_bitmask, code) \
 {\
 int __i, __j, __mask;\
diff --git a/hw/apic.h b/hw/apic.h
index c857d52..3a4be0a 100644
--- a/hw/apic.h
+++ b/hw/apic.h
@@ -10,6 +10,7 @@ void apic_deliver_irq(uint8_t dest, uint8_t dest_mode,
  uint8_t trigger_mode);
 int apic_accept_pic_intr(DeviceState *s);
 void apic_deliver_pic_intr(DeviceState *s, int level);
+void apic_deliver_nmi(DeviceState *d);
 int apic_get_interrupt(DeviceState *s);
 void apic_reset_irq_delivered(void);
 int apic_get_irq_delivered(void);
diff --git a/monitor.c b/monitor.c
index cb485bf..0b81f17 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2616,7 +2616,11 @@ static int do_inject_nmi(Monitor *mon, const QDict 
*qdict, QObject **ret_data)
 CPUState *env;
 
 for (env = first_cpu; env != NULL; env = env->next_cpu) {
-cpu_interrupt(env, CPU_INTERRUPT_NMI);
+if (!env->apic_state) {

Re: [Qemu-devel] [RFC][PATCH 00/45] qemu-kvm: MSI layer rework for in-kernel irqchip support

2011-10-17 Thread Michael S. Tsirkin
On Mon, Oct 17, 2011 at 11:27:34AM +0200, Jan Kiszka wrote:
> As previously indicated, I was working for quite a while on a major
> refactoring of the MSI "additions" we have in qemu-kvm to support
> in-kernel irqchip, vhost and device assignment. This is now the outcome.
> 
> I'm quite happy with it, things are still working (apparently), and the
> invasiveness of KVM hooks into the MSI layer is significantly reduced.
> Moreover, I was able to port the device assignment code over generic MSI
> support, reducing the size of that file a bit further.
> 
> Some further highlights:
>  - fix for HPET MSI support with in-kernel irqchip
>  - fully configurable MSI-X (allows 1:1 mapping for assigned devices)
>  - refactored KVM core API for device assignment and IRQ routing
> 
> I'm sending the whole series in one chunk so that you can see what the
> result will be. It's RFC as I bet that there are regressions included
> and maybe still room left for improvements. Once all is fine (can be
> broken up into multiple chunks for the merge), I would suggest patching
> qemu-kvm first and then start with porting things over to upstream.
> 
> Comments & review welcome.
> 
> CC: Alexander Graf 
> CC: Gerd Hoffmann 
> CC: Isaku Yamahata 


So the scheme where we lazily update kvm gsi table
on interrupts is interesting. There seems to be
very little point in it for virtio, and it does
seem to make it impossible to detect lack or resources
(at the moment we let guest know if we run out of GSIs
and linux guests can fall back to regular interrupts).

I am guessing the idea is to use it for device assignment
where it does make sense as there is no standard way
to track which vectors are actually used?
But how does it work there? kvm does not
propage unmapped interrupts from an assigned device to qemu, does it?
 

-- 
MST



[Qemu-devel] [PATCH 7/7] stellaris: convert gptm to memory API

2011-10-17 Thread Benoît Canet
Signed-off-by: Benoit Canet 
Reviewed-by: Peter Maydell 
---
 hw/stellaris.c |   29 -
 1 files changed, 12 insertions(+), 17 deletions(-)

diff --git a/hw/stellaris.c b/hw/stellaris.c
index 533d9c1..2ab7ec7 100644
--- a/hw/stellaris.c
+++ b/hw/stellaris.c
@@ -45,6 +45,7 @@ typedef const struct {
 
 typedef struct gptm_state {
 SysBusDevice busdev;
+MemoryRegion iomem;
 uint32_t config;
 uint32_t mode[2];
 uint32_t control;
@@ -140,7 +141,8 @@ static void gptm_tick(void *opaque)
 gptm_update_irq(s);
 }
 
-static uint32_t gptm_read(void *opaque, target_phys_addr_t offset)
+static uint64_t gptm_read(void *opaque, target_phys_addr_t offset,
+  unsigned size)
 {
 gptm_state *s = (gptm_state *)opaque;
 
@@ -188,7 +190,8 @@ static uint32_t gptm_read(void *opaque, target_phys_addr_t 
offset)
 }
 }
 
-static void gptm_write(void *opaque, target_phys_addr_t offset, uint32_t value)
+static void gptm_write(void *opaque, target_phys_addr_t offset,
+   uint64_t value, unsigned size)
 {
 gptm_state *s = (gptm_state *)opaque;
 uint32_t oldval;
@@ -268,16 +271,10 @@ static void gptm_write(void *opaque, target_phys_addr_t 
offset, uint32_t value)
 gptm_update_irq(s);
 }
 
-static CPUReadMemoryFunc * const gptm_readfn[] = {
-   gptm_read,
-   gptm_read,
-   gptm_read
-};
-
-static CPUWriteMemoryFunc * const gptm_writefn[] = {
-   gptm_write,
-   gptm_write,
-   gptm_write
+static const MemoryRegionOps gptm_ops = {
+.read = gptm_read,
+.write = gptm_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
 };
 
 static const VMStateDescription vmstate_stellaris_gptm = {
@@ -305,16 +302,14 @@ static const VMStateDescription vmstate_stellaris_gptm = {
 
 static int stellaris_gptm_init(SysBusDevice *dev)
 {
-int iomemtype;
 gptm_state *s = FROM_SYSBUS(gptm_state, dev);
 
 sysbus_init_irq(dev, &s->irq);
 qdev_init_gpio_out(&dev->qdev, &s->trigger, 1);
 
-iomemtype = cpu_register_io_memory(gptm_readfn,
-   gptm_writefn, s,
-   DEVICE_NATIVE_ENDIAN);
-sysbus_init_mmio(dev, 0x1000, iomemtype);
+memory_region_init_io(&s->iomem, &gptm_ops, s,
+  "gptm", 0x1000);
+sysbus_init_mmio_region(dev, &s->iomem);
 
 s->opaque[0] = s->opaque[1] = s;
 s->timer[0] = qemu_new_timer_ns(vm_clock, gptm_tick, &s->opaque[0]);
-- 
1.7.5.4




Re: [Qemu-devel] [PATCH v8 3/4] block: add block timer and throttling algorithm

2011-10-17 Thread Stefan Hajnoczi
On Mon, Oct 17, 2011 at 11:26 AM, Kevin Wolf  wrote:
> Am 26.09.2011 09:24, schrieb Zhi Yong Wu:
>> On Sat, Sep 24, 2011 at 12:19 AM, Kevin Wolf  wrote:
>>> Am 08.09.2011 12:11, schrieb Zhi Yong Wu:
 Note:
      1.) When bps/iops limits are specified to a small value such as 511 
 bytes/s, this VM will hang up. We are considering how to handle this 
 senario.
      2.) When "dd" command is issued in guest, if its option bs is set to 
 a large value such as "bs=1024K", the result speed will slightly bigger 
 than the limits.

 For these problems, if you have nice thought, pls let us know.:)

 Signed-off-by: Zhi Yong Wu 
 ---
  block.c |  259 
 ---
  block.h |    1 -
  2 files changed, 248 insertions(+), 12 deletions(-)
>>>
>>> One general comment: What about synchronous and/or coroutine I/O
>>> operations? Do you think they are just not important enough to consider
>>> here or were they forgotten?
>> For sync ops, we assume that it will be converse into async mode at
>> some point of future, right?
>> For coroutine I/O, it is introduced in image driver layer, and behind
>> bdrv_aio_readv/writev. I think that we need not consider them, right?
>
> Meanwhile the block layer has been changed to handle all requests in
> terms of coroutines. So you would best move your intercepting code into
> the coroutine functions.

Some additional info: the advantage of handling all requests in
coroutines is that there is now a single place where you can put I/O
throttling.  It will work for bdrv_read(), bdrv_co_readv(), and
bdrv_aio_readv().  There is no code duplication, just put the I/O
throttling logic in bdrv_co_do_readv().

Stefan



Re: [Qemu-devel] [RFC][PATCH 28/45] qemu-kvm: msix: Drop tracking of used vectors

2011-10-17 Thread Michael S. Tsirkin
On Mon, Oct 17, 2011 at 11:28:02AM +0200, Jan Kiszka wrote:
> This optimization was only required to keep KVM route usage low. Now
> that we solve that problem via lazy updates, we can drop the field. We
> still need interfaces to clear pending vectors, though (and we have to
> make use of them more broadly - but that's unrelated to this patch).
> 
> Signed-off-by: Jan Kiszka 

Lazy updates should be an implementation detail.
IMO resource tracking of vectors makes sense
as an API. Making devices deal with pending
vectors as a concept, IMO, does not.

> ---
>  hw/ivshmem.c|   16 ++---
>  hw/msix.c   |   62 +++---
>  hw/msix.h   |5 +--
>  hw/pci.h|2 -
>  hw/virtio-pci.c |   20 +++--
>  5 files changed, 26 insertions(+), 79 deletions(-)
> 
> diff --git a/hw/ivshmem.c b/hw/ivshmem.c
> index 242fbea..a402c98 100644
> --- a/hw/ivshmem.c
> +++ b/hw/ivshmem.c
> @@ -535,10 +535,8 @@ static uint64_t ivshmem_get_size(IVShmemState * s) {
>  return value;
>  }
>  
> -static void ivshmem_setup_msi(IVShmemState * s) {
> -
> -int i;
> -
> +static void ivshmem_setup_msi(IVShmemState *s)
> +{
>  /* allocate the MSI-X vectors */
>  
>  memory_region_init(&s->msix_bar, "ivshmem-msix", 4096);
> @@ -551,11 +549,6 @@ static void ivshmem_setup_msi(IVShmemState * s) {
>  exit(1);
>  }
>  
> -/* 'activate' the vectors */
> -for (i = 0; i < s->vectors; i++) {
> -msix_vector_use(&s->dev, i);
> -}
> -
>  /* allocate Qemu char devices for receiving interrupts */
>  s->eventfd_table = g_malloc0(s->vectors * sizeof(EventfdEntry));
>  }
> @@ -581,7 +574,7 @@ static int ivshmem_load(QEMUFile* f, void *opaque, int 
> version_id)
>  IVSHMEM_DPRINTF("ivshmem_load\n");
>  
>  IVShmemState *proxy = opaque;
> -int ret, i;
> +int ret;
>  
>  if (version_id > 0) {
>  return -EINVAL;
> @@ -599,9 +592,6 @@ static int ivshmem_load(QEMUFile* f, void *opaque, int 
> version_id)
>  
>  if (ivshmem_has_feature(proxy, IVSHMEM_MSI)) {
>  msix_load(&proxy->dev, f);
> -for (i = 0; i < proxy->vectors; i++) {
> -msix_vector_use(&proxy->dev, i);
> -}
>  } else {
>  proxy->intrstatus = qemu_get_be32(f);
>  proxy->intrmask = qemu_get_be32(f);
> diff --git a/hw/msix.c b/hw/msix.c
> index ce3375a..f1b97b5 100644
> --- a/hw/msix.c
> +++ b/hw/msix.c
> @@ -292,9 +292,6 @@ int msix_init(struct PCIDevice *dev, unsigned short 
> nentries,
>  if (nentries > MSIX_MAX_ENTRIES)
>  return -EINVAL;
>  
> -dev->msix_entry_used = g_malloc0(MSIX_MAX_ENTRIES *
> -sizeof *dev->msix_entry_used);
> -
>  dev->msix_table_page = g_malloc0(MSIX_PAGE_SIZE);
>  msix_mask_all(dev, nentries);
>  
> @@ -317,21 +314,9 @@ err_config:
>  memory_region_destroy(&dev->msix_mmio);
>  g_free(dev->msix_table_page);
>  dev->msix_table_page = NULL;
> -g_free(dev->msix_entry_used);
> -dev->msix_entry_used = NULL;
>  return ret;
>  }
>  
> -static void msix_free_irq_entries(PCIDevice *dev)
> -{
> -int vector;
> -
> -for (vector = 0; vector < dev->msix_entries_nr; ++vector) {
> -dev->msix_entry_used[vector] = 0;
> -msix_clr_pending(dev, vector);
> -}
> -}
> -
>  /* Clean up resources for the device. */
>  int msix_uninit(PCIDevice *dev, MemoryRegion *bar)
>  {
> @@ -340,14 +325,11 @@ int msix_uninit(PCIDevice *dev, MemoryRegion *bar)
>  }
>  pci_del_capability(dev, PCI_CAP_ID_MSIX, MSIX_CAP_LENGTH);
>  dev->msix_cap = 0;
> -msix_free_irq_entries(dev);
>  dev->msix_entries_nr = 0;
>  memory_region_del_subregion(bar, &dev->msix_mmio);
>  memory_region_destroy(&dev->msix_mmio);
>  g_free(dev->msix_table_page);
>  dev->msix_table_page = NULL;
> -g_free(dev->msix_entry_used);
> -dev->msix_entry_used = NULL;
>  
>  kvm_msix_free(dev);
>  g_free(dev->msix_cache);
> @@ -376,7 +358,6 @@ void msix_load(PCIDevice *dev, QEMUFile *f)
>  return;
>  }
>  
> -msix_free_irq_entries(dev);
>  qemu_get_buffer(f, dev->msix_table_page, n * PCI_MSIX_ENTRY_SIZE);
>  qemu_get_buffer(f, dev->msix_table_page + MSIX_PAGE_PENDING, (n + 7) / 
> 8);
>  }
> @@ -407,7 +388,7 @@ void msix_notify(PCIDevice *dev, unsigned vector)
>  {
>  MSIMessage msg;
>  
> -if (vector >= dev->msix_entries_nr || !dev->msix_entry_used[vector])
> +if (vector >= dev->msix_entries_nr)
>  return;
>  if (msix_is_masked(dev, vector)) {
>  msix_set_pending(dev, vector);
> @@ -424,48 +405,31 @@ void msix_reset(PCIDevice *dev)
>  if (!msix_present(dev)) {
>  return;
>  }
> -msix_free_irq_entries(dev);
> +msix_clear_all_vectors(dev);
>  dev->config[dev->msix_cap + MSIX_CONTROL_OFFSET] &=
>   ~dev->wmask[dev->msix_cap + MSIX_CONTROL_OFFSET];
>  memset(dev->msix_table_page, 

[Qemu-devel] [RFC 6/6] block: add -drive copy-on-read=on|off

2011-10-17 Thread Stefan Hajnoczi
This patch adds the -drive copy-on-read=on|off command-line option:

  copy-on-read=on|off
  copy-on-read is "on" or "off" and enables whether to copy read backing
  file sectors into the image file.  Copy-on-read avoids accessing the
  same backing file sectors repeatedly and is useful when the backing
  file is over a slow network.  By default copy-on-read is off.

Signed-off-by: Stefan Hajnoczi 
---
 blockdev.c  |6 ++
 hmp-commands.hx |5 +++--
 qemu-config.c   |4 
 qemu-options.hx |9 -
 4 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 0827bf7..1dd0f23 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -236,6 +236,7 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
 const char *devaddr;
 DriveInfo *dinfo;
 int snapshot = 0;
+int copy_on_read;
 int ret;
 
 translation = BIOS_ATA_TRANSLATION_AUTO;
@@ -252,6 +253,7 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
 
 snapshot = qemu_opt_get_bool(opts, "snapshot", 0);
 ro = qemu_opt_get_bool(opts, "readonly", 0);
+copy_on_read = qemu_opt_get_bool(opts, "copy-on-read", 0);
 
 file = qemu_opt_get(opts, "file");
 serial = qemu_opt_get(opts, "serial");
@@ -502,6 +504,10 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
 bdrv_flags |= (BDRV_O_SNAPSHOT|BDRV_O_CACHE_WB|BDRV_O_NO_FLUSH);
 }
 
+if (copy_on_read) {
+bdrv_flags |= BDRV_O_COPY_ON_READ;
+}
+
 if (media == MEDIA_CDROM) {
 /* CDROM is fine for any interface, don't check.  */
 ro = 1;
diff --git a/hmp-commands.hx b/hmp-commands.hx
index ab08d58..05a1498 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -860,9 +860,10 @@ ETEXI
 .args_type  = "pci_addr:s,opts:s",
 .params = "[[:]:]\n"
   "[file=file][,if=type][,bus=n]\n"
-  "[,unit=m][,media=d][index=i]\n"
+  "[,unit=m][,media=d][,index=i]\n"
   "[,cyls=c,heads=h,secs=s[,trans=t]]\n"
-  "[snapshot=on|off][,cache=on|off]",
+  "[,snapshot=on|off][,cache=on|off]\n"
+  "[,readonly=on|off][,copy-on-read=on|off]",
 .help   = "add drive to PCI storage controller",
 .mhandler.cmd = drive_hot_add,
 },
diff --git a/qemu-config.c b/qemu-config.c
index 7a7854f..fbe4f6a 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -85,6 +85,10 @@ static QemuOptsList qemu_drive_opts = {
 .name = "readonly",
 .type = QEMU_OPT_BOOL,
 .help = "open drive file as read-only",
+},{
+.name = "copy-on-read",
+.type = QEMU_OPT_BOOL,
+.help = "copy read data from backing file into image file",
 },
 { /* end of list */ }
 },
diff --git a/qemu-options.hx b/qemu-options.hx
index dfbabd0..c0bf856 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -135,7 +135,7 @@ DEF("drive", HAS_ARG, QEMU_OPTION_drive,
 "   [,cyls=c,heads=h,secs=s[,trans=t]][,snapshot=on|off]\n"
 "   
[,cache=writethrough|writeback|none|directsync|unsafe][,format=f]\n"
 "   [,serial=s][,addr=A][,id=name][,aio=threads|native]\n"
-"   [,readonly=on|off]\n"
+"   [,readonly=on|off][,copy-on-read=on|off]\n"
 "use 'file' as a drive image\n", QEMU_ARCH_ALL)
 STEXI
 @item -drive @var{option}[,@var{option}[,@var{option}[,...]]]
@@ -183,6 +183,9 @@ host disk is full; report the error to the guest otherwise).
 The default setting is @option{werror=enospc} and @option{rerror=report}.
 @item readonly
 Open drive @option{file} as read-only. Guest write attempts will fail.
+@item copy-on-read=@var{copy-on-read}
+@var{copy-on-read} is "on" or "off" and enables whether to copy read backing
+file sectors into the image file.
 @end table
 
 By default, writethrough caching is used for all block device.  This means that
@@ -214,6 +217,10 @@ like your host losing power, the disk storage getting 
disconnected accidently,
 etc. you're image will most probably be rendered unusable.   When using
 the @option{-snapshot} option, unsafe caching is always used.
 
+Copy-on-read avoids accessing the same backing file sectors repeatedly and is
+useful when the backing file is over a slow network.  By default copy-on-read
+is off.
+
 Instead of @option{-cdrom} you can use:
 @example
 qemu -drive file=file,index=2,media=cdrom
-- 
1.7.6.3




  1   2   3   4   >