date:20110123


Hi all,

I have configured and built qemu with device tree support.
qemu-version: 0.13.50
I have built kernel image (uImage) for bamboo using powerpc-440 toolchain.
kernel-version: 2.6.37-rc6+

When  I try to run this command,
# qemu-system-ppcemb -nographic -m 128 -M bamboo -kernel uImage  -append 

I get the following output and qemu just hangs there:
Trying to read privileged spr 947 3b3 at 1028
Trying to read invalid spr 62 03e at 0778

Has anyone tried to emulate bamboo with qemu before ?

Thanks,
Dushyant

Re: [Qemu-devel] [PATCH 2/3] FVD: Added the simulated 'blksim' driver


Am 21.01.2011 um 23:19 schrieb Chunqiang Tang:


diff --git a/block/blksim.c b/block/blksim.c
new file mode 100644
index 000..a92ba11
--- /dev/null
+++ b/block/blksim.c


Some formal comments, since you're introducing a new file:


@@ -0,0 +1,752 @@
+/*


Headers usually start with a one-line summary, QEMU simulated block  
driver maybe?



+ * Copyright (c) 2010-2011 IBM
+ *
+ * Authors:
+ * Chunqiang Tang ct...@us.ibm.com
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.
+ * See the COPYING file in the top-level directory.


Can you make this GPLv2-or-later to avoid future hassles?


+#ifndef TRUE
+# define TRUE 1
+#endif
+
+#ifndef FALSE
+# define FALSE 0
+#endif


I don't think these two belong here.

stdbool.h defines true and false with identical values.
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdbool.h.html

Not sure about TRUE and FALSE.
If we want them as local definitions, they should rather go to qemu- 
common.h than to individual source files.


Regards,
Andreas

Re: [Qemu-devel] [PATCH 2/3] ppc405: Fix memory leak


Am 22.01.2011 um 13:02 schrieb Stefan Weil:


Signed-off-by: Stefan Weil w...@mail.berlios.de


Acked-by: Andreas Färber andreas.faer...@web.de


---
hw/ppc405_boards.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/ppc405_boards.c b/hw/ppc405_boards.c
index b1d2b94..912757b 100644
--- a/hw/ppc405_boards.c
+++ b/hw/ppc405_boards.c
@@ -560,6 +560,7 @@ static void taihu_405ep_init(ram_addr_t ram_size,
filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
if (filename) {
bios_size = load_image(filename,  
qemu_get_ram_ptr(bios_offset));

+qemu_free(filename);
} else {
bios_size = -1;
}


Untested but matches the 405 reference board and New World / Old  
World / PReP then.


Andreas

Re: [Qemu-devel] Re: [PATCH] audio: consolidate audio_init()


Am 21.01.2011 um 23:27 schrieb malc:


On Fri, 21 Jan 2011, Blue Swirl wrote:

On Fri, Jan 21, 2011 at 10:53 AM, Isaku Yamahata yamah...@valinux.co.jp 
 wrote:

consolidate audio_init() and remove references to shoundhw.

Cc: Blue Swirl blauwir...@gmail.com
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp


Don't see the point of first hunk. No objections otherwise.


I guess the point is to limit use of 'soundhw' to arch_init.c rather  
than to anyone including sysemu.h?
The definition of the struct is moved there and the variable is made  
static.




Acked-by: Blue Swirl blauwir...@gmail.com

[Qemu-devel] Re: [PATCH] pci/pcie: make pci_find_device() ARI aware.

2011-01-23 Thread Michael S. Tsirkin

On Sat, Jan 22, 2011 at 01:39:57AM +0900, Isaku Yamahata wrote:
 On Fri, Jan 21, 2011 at 04:29:41PM +0200, Michael S. Tsirkin wrote:
  On Fri, Jan 21, 2011 at 07:44:16PM +0900, Isaku Yamahata wrote:
   On Thu, Jan 20, 2011 at 04:15:48PM +0200, Michael S. Tsirkin wrote:
On Thu, Jan 20, 2011 at 03:57:39PM +0900, Isaku Yamahata wrote:
 make pci_find_device() ARI aware.
 
 Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
 ---
  hw/pci.c |7 +++
  1 files changed, 7 insertions(+), 0 deletions(-)
 
 diff --git a/hw/pci.c b/hw/pci.c
 index 8d0e3df..851f350 100644
 --- a/hw/pci.c
 +++ b/hw/pci.c
 @@ -1596,11 +1596,18 @@ PCIBus *pci_find_bus(PCIBus *bus, int bus_num)
  
  PCIDevice *pci_find_device(PCIBus *bus, int bus_num, int slot, int 
 function)
  {
 +PCIDevice *d;
  bus = pci_find_bus(bus, bus_num);
  
  if (!bus)
  return NULL;
  
 +d = bus-parent_dev;
 +if (d  pci_is_express(d) 
 +pcie_cap_get_type(d) == PCI_EXP_TYPE_DOWNSTREAM 
 +!pcie_cap_is_ari_enabled(d)  slot  0) {
 +return NULL;
 +}
  return bus-devices[PCI_DEVFN(slot, function)];
  }

I'd like to split this express-specific code out in some way.
Further, the downstream port always has a single slot.
Maybe it shouldn't be a bus at all, but this needs some thought.
   
   Yes, it needs consideration.
   
   
How about we put flag in PCIBus that says that a single
slot is supported? Downstream ports would just set it.
   
   So such a flag must be set/clear by something like 
   pcie_cap_ari_write_config()
   depending on ARI bit at runtime.
  
  Well, to figure it out, could you please describe what is the situation
  your patch tries to fix? I would generally would like a reason for the
  change to be given in commit logs, please try to avoid just restating
  what the patch does.
 
 It seems that I should have added the comment to refer the spec.
 I'd like to implement ARI enable bit correctly.
 
 Downstream port(and root port) doesn't forward pci transaction for
 function  7 by default for compatibility, 
 Only when ARI forwarding enable bit of downstream/root port is set,
 the virtual p2p bridge forwards pci transaction for
 function  7 (i.e. slot  0).

Oh, I see, yes, function  7 gets described as slot 0.
I think this is what I missed.
Hmm, it'd pretty confusing. Should we fix this,
pass devfn all over?

I now understand what the code does, it just needs
a good comment that explains that at the moment
slot encodes the high bits of the device id.

Also, let's replace pcie_cap_is_ari_enabled
with an inline that does all the relevant logic
E.g.

/* With PCI Express Endpoints, there's a single device behind
   each downstream port bus, and bits 3:7 of the function number get
   encoded in the slot number (the Express spec calls it the Device
   Number). This allows  8 functions, but
   these extended functions are only accessible when the
   Alternative routing-ID Interpretation (ARI)
   capability is enabled in the downstream port. With that capability
   disabled the port enforces the Device Number field being 0.*/
static inline
bool pcie_check_slot(PCIDevice *dev)
{
return !pci_is_express(dev) || !slot ||
pcie_cap_get_type(dev) != PCI_EXP_TYPE_DOWNSTREAM ||
(pci_get_long(dev-config + dev-exp.exp_cap + PCI_EXP_DEVCTL2) 

PCI_EXP_DEVCTL2_ARI);
}




   6.13 Alternative routing-ID Interpretation(ARI)
   7.8.15 Device capabilites 2 register
   ARI forwarding supproted
   7.8.16 Device control 2 register
   ARI forwarding Enable
 5 ARI Forwarding Enable When set, the Downstream Port
 disables its traditional Device Number field being 0 enforcement
 when turning a Type 1 Configuration Request into a Type 0
 Configuration Request, permitting access to Extended Functions
 in an ARI Device immediately below the Port. See Section 6.13.
 Default value of this bit is 0b. Must be hardwired to 0b if the ARI
 Forwarding Supported bit is 0b.
 Oh, the patch should check root port in addition to downstream port.

It should? Where does it say so?

  Are you trying to create a device with  8 functions?
  If that is the case I suspect this is not the best way
  to do this at all.
 
   pcie device can have 256 functions instead of 8.
  
  Only if it's an ARI device. And note that if you have a device with
  256 functions and disable ARI in the port, it appears as
  multiple devices.
  
   Maybe we'd like to emulate how p2p bridge transfers pci transaction
   to child pci bus somehow.
  
  To support  8 functions per device, some refactoring would be needed:
  you can not figure out slot and function from the root bus,
  it depends on ARI along the way. So APIs that pass in
  decoded slot/function do not make sense anymore,
  you must pass in devfn all the way.
  
  But

Re: [Qemu-devel] Emulating powerpc 440EP with qemu-system-ppcemb

On 01/23/2011 06:59 AM, Dushyant Bansal wrote:
 Hi all,
 
 I have configured and built qemu with device tree support.
 qemu-version: 0.13.50
 I have built kernel image (uImage) for bamboo using powerpc-440 toolchain.
 kernel-version: 2.6.37-rc6+
 
 When  I try to run this command,
 # qemu-system-ppcemb -nographic -m 128 -M bamboo -kernel uImage  -append 
 
 I get the following output and qemu just hangs there:
 Trying to read privileged spr 947 3b3 at 1028
 Trying to read invalid spr 62 03e at 0778
 
 Has anyone tried to emulate bamboo with qemu before ?
 
 Thanks,
 Dushyant

In my Aboriginal Linux project (http://landley.net/aboriginal) I have a
config that builds a ppc440 cross compiler and builds a root filesystem
and kernel with it, but the kernel .config is bog standard 32 bit PPC
(mac99 board I think).  It boots and runs, gives you a shell prompt, but
occasionally misbehaves you try to do anything fancy with it.

Last I checked, the bamboo board was implemented for KVM not QEMU, and
QEMU didn't have a ppc440 processor emulation.  But that was over a year
ago, things could easily have changed...

What kernel .config are you using for the bamboo kernel?

Rob

Re: [Qemu-devel] Emulating powerpc 440EP with qemu-system-ppcemb


On Monday 24 January 2011 12:12 AM, Rob Landley wrote:

On 01/23/2011 06:59 AM, Dushyant Bansal wrote:
   

Hi all,

I have configured and built qemu with device tree support.
qemu-version: 0.13.50
I have built kernel image (uImage) for bamboo using powerpc-440 toolchain.
kernel-version: 2.6.37-rc6+

When  I try to run this command,
# qemu-system-ppcemb -nographic -m 128 -M bamboo -kernel uImage  -append 

I get the following output and qemu just hangs there:
Trying to read privileged spr 947 3b3 at 1028
Trying to read invalid spr 62 03e at 0778

Has anyone tried to emulate bamboo with qemu before ?

Thanks,
Dushyant
 

In my Aboriginal Linux project (http://landley.net/aboriginal) I have a
config that builds a ppc440 cross compiler and builds a root filesystem
and kernel with it, but the kernel .config is bog standard 32 bit PPC
(mac99 board I think).  It boots and runs, gives you a shell prompt, but
occasionally misbehaves you try to do anything fancy with it.

   
I am also using 
http://www.landley.net/aboriginal/downloads/binaries/cross-compiler-powerpc-440fp.tar.bz2cross-compiler-powerpc-440fp 
from the aboriginal project 
(http://www.landley.net/aboriginal/downloads/binaries/) to build the 
kernel image :).

Last I checked, the bamboo board was implemented for KVM not QEMU, and
QEMU didn't have a ppc440 processor emulation.  But that was over a year
ago, things could easily have changed...
   

Yes, qemu supports ppc440(bamboo).

$ qemu-system-ppcemb -M ?
Supported machines are:
mpc8544ds  mpc8544ds
bamboo bamboo
ref405ep   ref405ep
taihu  taihu
mac99  Mac99 based PowerMAC
g3beigeHeathrow based PowerMAC (default)
prep   PowerPC PREP platform


What kernel .config are you using for the bamboo kernel?

Rob

   

I am using arch/powerpc/configs/44x/bamboo_defconfig.

Thanks,
Dushyant

Re: [Qemu-devel] Emulating powerpc 440EP with qemu-system-ppcemb

On 01/23/2011 01:01 PM, Dushyant Bansal wrote:
I am also using
http://www.landley.net/aboriginal/downloads/binaries/cross-compiler-powerpc-440fp.tar.bz2cross-compiler-powerpc-440fp
from the aboriginal project
(http://www.landley.net/aboriginal/downloads/binaries/) to build the
kernel image :).

Heh. :)

Note that I don't have any actual ppc440 hardware. Somebody else once
tested this on real hardware for me and said it worked (their interest
was why i added the platform in the first place), and I haven't changed
the compiler config since then, but I can't prove anything if QEMU won't
cooperate.

Yes, qemu supports ppc440(bamboo).

$ qemu-system-ppcemb -M ?
Supported machines are:
mpc8544ds mpc8544ds
bamboo bamboo
ref405ep ref405ep
taihu taihu
mac99 Mac99 based PowerMAC
g3beigeHeathrow based PowerMAC (default)
prep PowerPC PREP platform

Those are board emulations. Does it have a 440 _cpu_ emulation?

./qemu-system-ppc -cpu ? | grep 440

(Don't ask me why qemu-system-ppc lists every single powerpc stepping
ever as a separate interesting CPU emulation. Seems kind of crazy to
me, but eh...)

What kernel .config are you using for the bamboo kernel?
I am using arch/powerpc/configs/44x/bamboo_defconfig.

Reasonable.

Note that beating a usable console out of the thing so you can see
output is the second hard step. (The first hard step is getting
everything set up so that the kernel will actually build and boot on the
hardware. Without a console, you can't prove it did.)

I prefer serial console to pop-up window because it's scriptable with
expect or similar, I can log the output via tee, and cut and paste
works without further effort. But if you're just trying to see boot
messages, a SDL frame buffer window (or vnc) is fine.

Rob

[Qemu-devel] Playing with virtfs.

Using yesterday's -git, following the instructions in
http://wiki.qemu.org/Documentation/9psetup (which is missing a kernel
symbol, you need to add CONFIG_VIRTIO_PCI to your kernel too), I managed
to mount a read-only virtfs filesystem, adding this to the
qemu-system-x86_64 command line:

-virtfs
local,security_model=passthrough,mount_tag=kvm,path=/home/landley/9ptest

And then in the emulated Linux:

  root@kvm:~# mount -t 9p -o trans=virtio,version=9p2000.L kvm woot
  root@kvm:~# ls -l woot
  total 80
  -rw-r--r-- 1 1000 1000 77874 Jan 22 23:33 config-linux
  root@kvm:~# cd woot
  root@kvm:~/woot# touch fred
  touch: setting times of `fred': No such file or directory
  root@kvm:~/woot#

I.E. It seems to work fine read only, but changes are discarded.

Am I doing something wrong, or is this expected?  (If so, when is write
support likely to go in?)

Rob

[Qemu-devel] [PATCH] linux-user/FLAT: allow targets to override FLAT reloc processing

This brings flatload.c more in line with the current Linux FLAT loader
which allows targets to handle FLAT relocations in their own way.  For
the common behavior, the new functions get stubbed out.

Signed-off-by: Mike Frysinger vap...@gentoo.org
---
 Makefile.target  |2 +-
 linux-user/flatload.c|   19 ---
 linux-user/target_flat.h |9 +
 3 files changed, 18 insertions(+), 12 deletions(-)
 create mode 100644 linux-user/target_flat.h

diff --git a/Makefile.target b/Makefile.target
index e15b1c4..906cf77 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -107,7 +107,7 @@ ifdef CONFIG_LINUX_USER
 
 $(call set-vpath, 
$(SRC_PATH)/linux-user:$(SRC_PATH)/linux-user/$(TARGET_ABI_DIR))
 
-QEMU_CFLAGS+=-I$(SRC_PATH)/linux-user 
-I$(SRC_PATH)/linux-user/$(TARGET_ABI_DIR)
+QEMU_CFLAGS+=-I$(SRC_PATH)/linux-user/$(TARGET_ABI_DIR) 
-I$(SRC_PATH)/linux-user
 obj-y = main.o syscall.o strace.o mmap.o signal.o thunk.o \
   elfload.o linuxload.o uaccess.o gdbstub.o cpu-uname.o \
   qemu-malloc.o $(oslib-obj-y)
diff --git a/linux-user/flatload.c b/linux-user/flatload.c
index 8f9f4a5..df42eae 100644
--- a/linux-user/flatload.c
+++ b/linux-user/flatload.c
@@ -41,6 +41,8 @@
 
 #include qemu.h
 #include flat.h
+#define ntohl(x) be32_to_cpu(x)
+#include target_flat.h
 
 //#define DEBUG
 
@@ -50,14 +52,6 @@
 #defineDBG_FLT(...)
 #endif
 
-#define flat_reloc_valid(reloc, size) ((reloc) = (size))
-#define flat_old_ram_flag(flag)   (flag)
-#ifdef TARGET_WORDS_BIGENDIAN
-#define flat_get_relocate_addr(relval)(relval)
-#else
-#define flat_get_relocate_addr(relval)bswap32(relval)
-#endif
-
 #define RELOC_FAILED 0xff00ff01/* Relocation incorrect 
somewhere */
 #define UNLOADED_LIB 0x7ff000ff/* Placeholder for unused 
library */
 
@@ -78,8 +72,6 @@ static int load_flat_shared_library(int id, struct lib_info 
*p);
 
 struct linux_binprm;
 
-#define ntohl(x) be32_to_cpu(x)
-
 //
 /*
  * create_flat_tables() parses the env- and arg-strings in new user
@@ -625,6 +617,7 @@ static int load_flat_file(struct linux_binprm * bprm,
  * __start to address 4 so that is okay).
  */
 if (rev  OLD_FLAT_VERSION) {
+abi_ulong persistent = 0;
 for (i = 0; i  relocs; i++) {
 abi_ulong addr, relval;
 
@@ -633,6 +626,9 @@ static int load_flat_file(struct linux_binprm * bprm,
relocated first).  */
 if (get_user_ual(relval, reloc + i * sizeof(abi_ulong)))
 return -EFAULT;
+relval = ntohl(relval);
+if (flat_set_persistent(relval, persistent))
+continue;
 addr = flat_get_relocate_addr(relval);
 rp = calc_reloc(addr, libinfo, id, 1);
 if (rp == RELOC_FAILED)
@@ -641,6 +637,8 @@ static int load_flat_file(struct linux_binprm * bprm,
 /* Get the pointer's value.  */
 if (get_user_ual(addr, rp))
 return -EFAULT;
+addr = flat_get_addr_from_rp(rp, relval, flags,
+ persistent);
 if (addr != 0) {
 /*
  * Do the relocation.  PIC relocs in the data section are
@@ -656,7 +653,7 @@ static int load_flat_file(struct linux_binprm * bprm,
 return -ENOEXEC;
 
 /* Write back the relocated pointer.  */
-if (put_user_ual(addr, rp))
+if (flat_put_addr_at_rp(rp, addr, relval))
 return -EFAULT;
 }
 }
diff --git a/linux-user/target_flat.h b/linux-user/target_flat.h
new file mode 100644
index 000..332b6e3
--- /dev/null
+++ b/linux-user/target_flat.h
@@ -0,0 +1,9 @@
+/* If your arch needs to do custom stuff, create your own target_flat.h
+ * header file in linux-user/your arch/
+ */
+#define flat_reloc_valid(reloc, size)((reloc) = 
(size))
+#define flat_old_ram_flag(flag)  (flag)
+#define flat_get_relocate_addr(relval)   (relval)
+#define flat_get_addr_from_rp(rp, relval, flags, persistent) (rp)
+#define flat_set_persistent(relval, persistent)  (*persistent)
+#define flat_put_addr_at_rp(rp, addr, relval)
put_user_ual(addr, rp)
-- 
1.7.4.rc2

[Qemu-devel] [PATCH v2] linux-user/elfload: add FDPIC support

Signed-off-by: Mike Frysinger vap...@gentoo.org
---
v2
- tweaked loadseg order
- fixed pt_dynamic addresses
- verified to actually work with FDPIC ELFs

 elf.h|   19 +
 linux-user/elfload.c |   71 ++
 linux-user/qemu.h|8 +
 3 files changed, 98 insertions(+), 0 deletions(-)

diff --git a/elf.h b/elf.h
index 7067c90..d2f24f4 100644
--- a/elf.h
+++ b/elf.h
@@ -1191,6 +1191,25 @@ typedef struct elf64_note {
   Elf64_Word n_type;   /* Content type */
 } Elf64_Nhdr;
 
+
+/* This data structure represents a PT_LOAD segment.  */
+struct elf32_fdpic_loadseg {
+  /* Core address to which the segment is mapped.  */
+  Elf32_Addr addr;
+  /* VMA recorded in the program header.  */
+  Elf32_Addr p_vaddr;
+  /* Size of this segment in memory.  */
+  Elf32_Word p_memsz;
+};
+struct elf32_fdpic_loadmap {
+  /* Protocol version number, must be zero.  */
+  Elf32_Half version;
+  /* Number of segments in this map.  */
+  Elf32_Half nsegs;
+  /* The actual memory map.  */
+  struct elf32_fdpic_loadseg segs[/*nsegs*/];
+};
+
 #ifdef ELF_CLASS
 #if ELF_CLASS == ELFCLASS32
 
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 33d776d..8c6d448 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -1075,6 +1075,33 @@ static void zero_bss(abi_ulong elf_bss, abi_ulong 
last_bss, int prot)
 }
 }
 
+#ifdef CONFIG_USE_FDPIC
+static abi_ulong loader_build_fdpic_loadmap(struct image_info *info, abi_ulong 
sp)
+{
+uint16_t n;
+struct elf32_fdpic_loadseg *loadsegs = info-loadsegs;
+
+/* elf32_fdpic_loadseg */
+n = info-nsegs;
+while (n--) {
+sp -= 12;
+put_user_u32(loadsegs[n].addr, sp+0);
+put_user_u32(loadsegs[n].p_vaddr, sp+4);
+put_user_u32(loadsegs[n].p_memsz, sp+8);
+}
+
+/* elf32_fdpic_loadmap */
+sp -= 4;
+put_user_u16(0, sp+0); /* version */
+put_user_u16(info-nsegs, sp+2); /* nsegs */
+
+info-personality = PER_LINUX_FDPIC;
+info-loadmap_addr = sp;
+
+return sp;
+}
+#endif
+
 static abi_ulong create_elf_tables(abi_ulong p, int argc, int envc,
struct elfhdr *exec,
struct image_info *info,
@@ -1087,6 +1114,21 @@ static abi_ulong create_elf_tables(abi_ulong p, int 
argc, int envc,
 const int n = sizeof(elf_addr_t);
 
 sp = p;
+
+#ifdef CONFIG_USE_FDPIC
+/* Needs to be before we load the env/argc/... */
+if (elf_is_fdpic(exec)) {
+/* Need 4 byte alignment for these structs */
+sp = ~3;
+sp = loader_build_fdpic_loadmap(info, sp);
+info-other_info = interp_info;
+if (interp_info) {
+interp_info-other_info = info;
+sp = loader_build_fdpic_loadmap(interp_info, sp);
+}
+}
+#endif
+
 u_platform = 0;
 k_platform = ELF_PLATFORM;
 if (k_platform) {
@@ -1197,6 +1239,11 @@ static void load_elf_image(const char *image_name, int 
image_fd,
 }
 bswap_phdr(phdr, ehdr-e_phnum);
 
+#ifdef CONFIG_USE_FDPIC
+info-nsegs = 0;
+info-pt_dynamic_addr = 0;
+#endif
+
 /* Find the maximum size of the image and allocate an appropriate
amount of memory to handle that.  */
 loaddr = -1, hiaddr = 0;
@@ -1210,6 +1257,9 @@ static void load_elf_image(const char *image_name, int 
image_fd,
 if (a  hiaddr) {
 hiaddr = a;
 }
+#ifdef CONFIG_USE_FDPIC
+++info-nsegs;
+#endif
 }
 }
 
@@ -1290,6 +1340,27 @@ static void load_elf_image(const char *image_name, int 
image_fd,
 }
 load_bias = load_addr - loaddr;
 
+#ifdef CONFIG_USE_FDPIC
+{
+struct elf32_fdpic_loadseg *loadsegs = info-loadsegs =
+qemu_malloc(sizeof(*loadsegs) * info-nsegs);
+
+for (i = 0; i  ehdr-e_phnum; ++i) {
+switch (phdr[i].p_type) {
+case PT_DYNAMIC:
+info-pt_dynamic_addr = phdr[i].p_vaddr + load_bias;
+break;
+case PT_LOAD:
+loadsegs-addr = phdr[i].p_vaddr + load_bias;
+loadsegs-p_vaddr = phdr[i].p_vaddr;
+loadsegs-p_memsz = phdr[i].p_memsz;
+++loadsegs;
+break;
+}
+}
+}
+#endif
+
 info-load_bias = load_bias;
 info-load_addr = load_addr;
 info-entry = ehdr-e_entry + load_bias;
diff --git a/linux-user/qemu.h b/linux-user/qemu.h
index 32de241..0924a1a 100644
--- a/linux-user/qemu.h
+++ b/linux-user/qemu.h
@@ -51,6 +51,14 @@ struct image_info {
 abi_ulong   arg_start;
 abi_ulong   arg_end;
int personality;
+#ifdef CONFIG_USE_FDPIC
+#define FDPIC_MAX_LOAD_SEGS 4
+abi_ulong   loadmap_addr;
+uint16_tnsegs;
+void   *loadsegs;
+abi_ulong   pt_dynamic_addr;
+struct image_info *other_info;
+#endif
 };

Re: [Qemu-devel] Emulating powerpc 440EP with qemu-system-ppcemb


Am 23.01.2011 um 19:42 schrieb Rob Landley:


On 01/23/2011 06:59 AM, Dushyant Bansal wrote:

When  I try to run this command,
# qemu-system-ppcemb -nographic -m 128 -M bamboo -kernel uImage  - 
append 


I get the following output and qemu just hangs there:
Trying to read privileged spr 947 3b3 at 1028
Trying to read invalid spr 62 03e at 0778


Last I checked, the bamboo board was implemented for KVM not QEMU, and
QEMU didn't have a ppc440 processor emulation.  But that was over a  
year

ago, things could easily have changed...


Matches my info. No ppc440 series since then.

Andreas

Re: [Qemu-devel] Emulating powerpc 440EP with qemu-system-ppcemb




Those are board emulations.  Does it have a 440 _cpu_ emulation?

./qemu-system-ppc -cpu ? | grep 440
   

This is the output.
PowerPC 440-Xilinx   PVR 7ff21910

Is this right for my requirement?
This is qemu version 0.13.50. And, it seems this support has been added 
recently. It is missing in qemu version 0.12.5.
I have one more query. You said 440 was supported in kvm. But kvm also 
uses qemu as its userspace component. So, 440 was supported through kvm 
kernel module?


--
Dushyant

Re: [Qemu-devel] [PATCH] linux-user/FLAT: allow targets to override FLAT reloc processing

On Sun, Jan 23, 2011 at 14:51, Mike Frysinger wrote:
 This brings flatload.c more in line with the current Linux FLAT loader
 which allows targets to handle FLAT relocations in their own way.  For
 the common behavior, the new functions get stubbed out.

please ignore this for now (it's not working 100% yet).  i meant to
send out the FDPIC patch and not this one.
-mike

[Qemu-devel] [PATCH] linux-user: add ppoll syscall support

Some architectures (like Blackfin) only implement ppoll (and skip poll).
So add support for it using existing poll code.

Signed-off-by: Mike Frysinger vap...@gentoo.org
---
 linux-user/syscall.c |   29 -
 1 files changed, 28 insertions(+), 1 deletions(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 6116ab5..5382662 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -6230,18 +6230,42 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
arg1,
 ret = do_select(arg1, arg2, arg3, arg4, arg5);
 break;
 #endif
-#ifdef TARGET_NR_poll
+#if defined(TARGET_NR_poll) || defined(TARGET_NR_ppoll)
+# ifdef TARGET_NR_poll
 case TARGET_NR_poll:
+# endif
+# ifdef TARGET_NR_ppoll
+case TARGET_NR_ppoll:
+# endif
 {
 struct target_pollfd *target_pfd;
 unsigned int nfds = arg2;
 int timeout = arg3;
 struct pollfd *pfd;
 unsigned int i;
+sigset_t origmask;
 
 target_pfd = lock_user(VERIFY_WRITE, arg1, sizeof(struct 
target_pollfd) * nfds, 1);
 if (!target_pfd)
 goto efault;
+
+if (num == TARGET_NR_ppoll) {
+sigset_t set;
+abi_ulong mask;
+
+if (arg3) {
+struct timespec timeout_ts;
+target_to_host_timespec(timeout_ts, arg3);
+timeout = timeout_ts.tv_sec * 1000 +
+  timeout_ts.tv_nsec / 100;
+} else
+timeout = -1;
+
+mask = arg4;
+target_to_host_old_sigset(set, mask);
+sigprocmask(SIG_SETMASK, set, origmask);
+}
+
 pfd = alloca(sizeof(struct pollfd) * nfds);
 for(i = 0; i  nfds; i++) {
 pfd[i].fd = tswap32(target_pfd[i].fd);
@@ -6256,6 +6280,9 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
- sizeof(struct pollfd));
 }
 unlock_user(target_pfd, arg1, ret);
+
+if (num == TARGET_NR_ppoll)
+sigprocmask(SIG_SETMASK, origmask, NULL);
 }
 break;
 #endif
-- 
1.7.4.rc2

Re: [Qemu-devel] Emulating powerpc 440EP with qemu-system-ppcemb


On Monday 24 January 2011 01:22 AM, Andreas Färber wrote:

Am 23.01.2011 um 19:42 schrieb Rob Landley:


On 01/23/2011 06:59 AM, Dushyant Bansal wrote:

When  I try to run this command,
# qemu-system-ppcemb -nographic -m 128 -M bamboo -kernel uImage  
-append 


I get the following output and qemu just hangs there:
Trying to read privileged spr 947 3b3 at 1028
Trying to read invalid spr 62 03e at 0778


Last I checked, the bamboo board was implemented for KVM not QEMU, and
QEMU didn't have a ppc440 processor emulation.  But that was over a year
ago, things could easily have changed...


Matches my info. No ppc440 series since then.

Andreas


$ ./qemu-system-ppc -cpu ? | grep 440
   This is the output.
PowerPC 440-Xilinx   PVR 7ff21910

qemu version: 0.13.50.
Will it work for ppc440 processor emulation?

Dushyant

Re: [Qemu-devel] [PATCH] linux-user: add ppoll syscall support

2011-01-23 Thread Peter Maydell

On 23 January 2011 19:56, Mike Frysinger vap...@gentoo.org wrote:
 Some architectures (like Blackfin) only implement ppoll (and skip poll).
 So add support for it using existing poll code.

This looks wrong -- ppoll() is supposed to be atomic, but
your implementation isn't. Why can't we just implement this
by calling the host ppoll? (might need a configure test, but
that's straightforward.)

-- PMM

Re: [Qemu-devel] [PATCH] linux-user: add ppoll syscall support

On Sun, Jan 23, 2011 at 16:25, Peter Maydell wrote:
 On 23 January 2011 19:56, Mike Frysinger wrote:
 Some architectures (like Blackfin) only implement ppoll (and skip poll).
 So add support for it using existing poll code.

 This looks wrong -- ppoll() is supposed to be atomic, but
 your implementation isn't. Why can't we just implement this
 by calling the host ppoll? (might need a configure test, but
 that's straightforward.)

it's atomic from the apps' point of view, so what does it matter ?
-mike

Re: [Qemu-devel] TCG flow vs dyngen

On 01/16/2011 10:01 AM, Raphaël Lefèvre wrote:
 On Sun, Jan 16, 2011 at 11:21 PM, Stefano Bonifazi
 stefboombas...@gmail.com wrote:
 2. how can I check the number of target cpu cycles or target
 instructions executed inside qemu-user (i.e. qemu-ppc)?
 Is there any variable I can inspect for such informations? at Dec, 2010

Keep in mind I'm a bit rusty and not an expert, but I'll give a stab at
answering:

You can't, because QEMU doesn't work that way.  QEMU isn't an
instruction level emulator, it's closer to a Java JIT.  It doesn't
translate one instruction at a time but instead translates large blocks
of code all at once, and keeps a cache of translated blocks around.
Execution jumps into each block and either waits for it to exit again
(meaning it jumped out of that page and QEMU's main execution loop has
to look up what page to execute next, possibly translating it first if
it's not in the cache yet), or else QEMU interrupts it after while to
fake an IRQ of some kind (such as a timer interrupt).

You may want to read Fabrice Bellard's original paper on the QEMU design:

http://www.usenix.org/event/usenix05/tech/freenix/full_papers/bellard/bellard.pdf

Since that was written, dyngen was replaced with tcg, but that does the
same thing in a slightly different way.

Building a QEMU with dyngen support used to use the host compiler to
compile chunks of code corresponding to the target operations it would
see at runtime, and then strip the machine language out of the resulting
.o files and save them in a table.  Then at runtime dyngen could
generate translated pages by gluing together the resulting saved machine
language snippets the host compiler had produced when qemu was built.
The problem was, beating the right kind of machine language snippets out
of the .o files the compiler produced from the example code turned out
to be VERY COMPILER DEPENDENT.  This is why you couldn't build qemu with
gcc 4.x for the longest time, gcc's code generator and the layout of the
.o files changed in a bunch of subtle ways which broke dyngen's ability
to extract usable machine code snippets to put 'em into the table so it
could translate pages at runtime.

TCG stands for Tiny Code Generator.  It just hardwires a code
generator into QEMU.  They wrote a mini-compiler in C, which knows what
instructions to output for each host qemu supports.  If QEMU understands
target instructions well enough to _read_ them, it's not a big stretch
to be able to _write_ them when running on that kind of host.  (It's
more or less the same operation in reverse.)  This means that QEMU can
no longer run on a type of host it can't execute target code for, but
the solution is to just add support for all the interesting machines out
there, on both sides.

So, when QEMU executes code, the virtual MMU faults a new page into the
virtual TLB, and goes I can't execute this, fix it up!  And the fixup
handler looks for a translation of the page in the cache of translated
pages, and if it can't find it it calls the translator to convert the
target code into a page of corresponding host code.  Which may involve
discarding an existing entry out of the cache, but this is how
instruction caches work on real hardware anyway so the delays in QEMU
are where they'd be on real hardware anyway, and optimizing for one is
pretty close to optimizing for the other, so life is good.

The chunk you found earlier is a function pointer typecast:

#define tcg_qemu_tb_exec(tb_ptr) \
  ((long REGPARM (*)(void *))code_gen_prologue)(tb_ptr)

Which looks like it's calling code_gen_prologue() with tp_ptr as its
argument (typecast to a void *), and it returns a long.  That calls a
translated page, and when the function returns that means the page of
code needs to jump to code somewhere outside of that page, and we go
back to the main loop to figure out where to go next.

The reason QEMU is as fast as it is is because once it has a page of
translated code, actually _running_ it is entirely native.  It jumps
into the page, and executes natively until it leaves the page.   Control
only goes back to QEMU to switch pages or to handle I/O and interrupts
and such.  So when you ask how many clock cycles did that instruction
take, the answer is it doesn't work that way.  QEMU emulates at
memory page level (generally 4k of target code), not at individual
instruction level.

(Oh, and the worst thing you can do to QEMU from a performance
perspective is self-modifying code.  Because the virtual MMU has to
strip the executable bit off the TLB entry and re-translate the entire
page next time something tries to execute it.  It _works_, it's just
slow.  But again, real hardware can hiccup a bit on this too.)

Does that answer your question?

Rob

Re: [Qemu-devel] [PATCH] multiboot: Fix upper memory size in multiboot info

2011-01-23 Thread Aurelien Jarno

On Tue, Jan 04, 2011 at 02:03:30PM +0100, Kevin Wolf wrote:
 The upper memory size field should exclude the first MB of RAM.
 
 Signed-off-by: Kevin Wolf m...@kevin-wolf.de
 ---
  hw/multiboot.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/hw/multiboot.c b/hw/multiboot.c
 index 7cc3055..0d2bfb4 100644
 --- a/hw/multiboot.c
 +++ b/hw/multiboot.c
 @@ -306,7 +306,7 @@ int load_multiboot(void *fw_cfg,
  | MULTIBOOT_FLAGS_MODULES
  | MULTIBOOT_FLAGS_MMAP);
  stl_p(bootinfo + MBI_MEM_LOWER,   640);
 -stl_p(bootinfo + MBI_MEM_UPPER,   ram_size / 1024);
 +stl_p(bootinfo + MBI_MEM_UPPER,   (ram_size / 1024) - 1024);
  stl_p(bootinfo + MBI_BOOT_DEVICE, 0x8001); /* XXX: use the -boot 
 switch? */
  stl_p(bootinfo + MBI_MMAP_ADDR,   ADDR_E820_MAP);
  

Thanks, applied.


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

Re: [Qemu-devel] Emulating powerpc 440EP with qemu-system-ppcemb

2011-01-23 Thread Alexander Graf


On 23.01.2011, at 20:52, Andreas Färber wrote:

 Am 23.01.2011 um 19:42 schrieb Rob Landley:
 
 On 01/23/2011 06:59 AM, Dushyant Bansal wrote:
 When  I try to run this command,
 # qemu-system-ppcemb -nographic -m 128 -M bamboo -kernel uImage  -append 
 
 I get the following output and qemu just hangs there:
 Trying to read privileged spr 947 3b3 at 1028
 Trying to read invalid spr 62 03e at 0778
 
 Last I checked, the bamboo board was implemented for KVM not QEMU, and
 QEMU didn't have a ppc440 processor emulation.  But that was over a year
 ago, things could easily have changed...
 
 Matches my info. No ppc440 series since then.

Edgar did some work on 440 emulation, but not with bamboo IIRC.


Alex

Re: [Qemu-devel] Emulating powerpc 440EP with qemu-system-ppcemb

On 01/23/2011 01:52 PM, Dushyant Bansal wrote:
 
 Those are board emulations.  Does it have a 440 _cpu_ emulation?

 ./qemu-system-ppc -cpu ? | grep 440

 This is the output.
 PowerPC 440-Xilinx   PVR 7ff21910
 
 Is this right for my requirement?

I have no idea?  Sounds worth a try...

 This is qemu version 0.13.50. And, it seems this support has been added
 recently. It is missing in qemu version 0.12.5.
 I have one more query. You said 440 was supported in kvm.

KVM runs on powerpc systems, including PPC 440.

KVM doesn't do CPU emulation, it does CPU virtualization.  IT can't do
PowerPC on an x86 host, it does PowerPC on a PowerPC host.  (It only
uses QEMU to attach I/O devices to the virtual CPUs the hardware
provides.  It needs a CPU that can do nested page tables, things like
the Intel VT extensions.)

So KVM can run PowerPC 440 code when running on a PowerPC 440 host.
That's where the Bamboo board emulation came from: somebody was running
KVM on a PowerPC 440 host, and wanted a board emulation for the virtual
systems to do I/O through.

 But kvm also
 uses qemu as its userspace component. So, 440 was supported through kvm
 kernel module?

KVM just uses the QEMU code to attach virtual I/O devices to a CPU
context that's provided by the hardware.

So in order to get KVM to emulate a PowerPC 440, you have to run it on a
PowerPC 440 host.  (If you do so, QEMU will happily emulate a bamboo
board for it.)

I suspect the problem is that the kernel's actual bamboo drivers have
inline assembly instructions snippets, and QEMU isn't emulating those
instructions.

Note that the powerpc 440 is mostly a subset of normal 32 bit powerpc
(um, 405?).  Specifically, powerpc 440 userspace code should run on a
full-fledged PPC just fine, at least with software floating point.  It's
the protected mode instructions (mmu management and such) that differ,
stuff that only really happens in the kernel.

My fuzzy understanding is that the 440 happened when IBM tried to strip
down the PowerPC for the embedded market, mostly by removing several
instructions.  (So 405 code won't run on it, but 440 code will mostly
run on a 405, except for the priviledged instructions which of course
are all wildly different, but that should only get used inside the
kernel.  Don't ask me about floating point.)

Motorola did the same thing by the way, except they removed a DIFFERENT
set of instructions so the two were incompatible.  You can find traces
of that in kernel under arch/powerpc/platforms/8xx if you're curious,
but I think that died even before they spun off Freescale.  (Maybe it
just doesn't get used on Linux?  They tried to revive it as the
PowerQUIC SOC line a few years ago but I dunno if it went anywhere.)

Of course wikipedia will have an opinion.  (A subset of it might even be
correct, who knows?  It's the best source of anecdotal evidence on the net.)

  http://en.wikipedia.org/wiki/List_of_PowerPC_processors

Rob

Re: [Qemu-devel] TCG flow vs dyngen

2011-01-23 Thread Stefano Bonifazi


On 01/23/2011 10:50 PM, Rob Landley wrote:

On 01/16/2011 10:01 AM, Raphaël Lefèvre wrote:

On Sun, Jan 16, 2011 at 11:21 PM, Stefano Bonifazi
stefboombas...@gmail.com  wrote:
2. how can I check the number of target cpu cycles or target
instructions executed inside qemu-user (i.e. qemu-ppc)?
Is there any variable I can inspect for such informations? at Dec, 2010

Keep in mind I'm a bit rusty and not an expert, but I'll give a stab at
answering:

You can't, because QEMU doesn't work that way.  QEMU isn't an
instruction level emulator, it's closer to a Java JIT.  It doesn't
translate one instruction at a time but instead translates large blocks
of code all at once, and keeps a cache of translated blocks around.
Execution jumps into each block and either waits for it to exit again
(meaning it jumped out of that page and QEMU's main execution loop has
to look up what page to execute next, possibly translating it first if
it's not in the cache yet), or else QEMU interrupts it after while to
fake an IRQ of some kind (such as a timer interrupt).

You may want to read Fabrice Bellard's original paper on the QEMU design:

http://www.usenix.org/event/usenix05/tech/freenix/full_papers/bellard/bellard.pdf

Since that was written, dyngen was replaced with tcg, but that does the
same thing in a slightly different way.

Building a QEMU with dyngen support used to use the host compiler to
compile chunks of code corresponding to the target operations it would
see at runtime, and then strip the machine language out of the resulting
.o files and save them in a table.  Then at runtime dyngen could
generate translated pages by gluing together the resulting saved machine
language snippets the host compiler had produced when qemu was built.
The problem was, beating the right kind of machine language snippets out
of the .o files the compiler produced from the example code turned out
to be VERY COMPILER DEPENDENT.  This is why you couldn't build qemu with
gcc 4.x for the longest time, gcc's code generator and the layout of the
.o files changed in a bunch of subtle ways which broke dyngen's ability
to extract usable machine code snippets to put 'em into the table so it
could translate pages at runtime.

TCG stands for Tiny Code Generator.  It just hardwires a code
generator into QEMU.  They wrote a mini-compiler in C, which knows what
instructions to output for each host qemu supports.  If QEMU understands
target instructions well enough to _read_ them, it's not a big stretch
to be able to _write_ them when running on that kind of host.  (It's
more or less the same operation in reverse.)  This means that QEMU can
no longer run on a type of host it can't execute target code for, but
the solution is to just add support for all the interesting machines out
there, on both sides.

So, when QEMU executes code, the virtual MMU faults a new page into the
virtual TLB, and goes I can't execute this, fix it up!  And the fixup
handler looks for a translation of the page in the cache of translated
pages, and if it can't find it it calls the translator to convert the
target code into a page of corresponding host code.  Which may involve
discarding an existing entry out of the cache, but this is how
instruction caches work on real hardware anyway so the delays in QEMU
are where they'd be on real hardware anyway, and optimizing for one is
pretty close to optimizing for the other, so life is good.

The chunk you found earlier is a function pointer typecast:

#define tcg_qemu_tb_exec(tb_ptr) \
   ((long REGPARM (*)(void *))code_gen_prologue)(tb_ptr)

Which looks like it's calling code_gen_prologue() with tp_ptr as its
argument (typecast to a void *), and it returns a long.  That calls a
translated page, and when the function returns that means the page of
code needs to jump to code somewhere outside of that page, and we go
back to the main loop to figure out where to go next.

The reason QEMU is as fast as it is is because once it has a page of
translated code, actually _running_ it is entirely native.  It jumps
into the page, and executes natively until it leaves the page.   Control
only goes back to QEMU to switch pages or to handle I/O and interrupts
and such.  So when you ask how many clock cycles did that instruction
take, the answer is it doesn't work that way.  QEMU emulates at
memory page level (generally 4k of target code), not at individual
instruction level.

(Oh, and the worst thing you can do to QEMU from a performance
perspective is self-modifying code.  Because the virtual MMU has to
strip the executable bit off the TLB entry and re-translate the entire
page next time something tries to execute it.  It _works_, it's just
slow.  But again, real hardware can hiccup a bit on this too.)

Does that answer your question?

Rob

Wow! Thank you! That's an ANSWER!
Gold for who's studying all of that! Though at the stage of my work I 
had to understand almost all of it, your perfect summary make 
everything much clearer..
About counting

Re: [Qemu-devel] [PATCH] linux-user: add ppoll syscall support

2011-01-23 Thread Peter Maydell

On 23 January 2011 21:35, Mike Frysinger vap...@gentoo.org wrote:
 On Sun, Jan 23, 2011 at 16:25, Peter Maydell wrote:
 This looks wrong -- ppoll() is supposed to be atomic, but
 your implementation isn't. Why can't we just implement this
 by calling the host ppoll? (might need a configure test, but
 that's straightforward.)

 it's atomic from the apps' point of view, so what does it matter ?

It's not atomic because signals can arrive in the gaps
between your calls to sigaction and poll (even if qemu doesn't
deliver them to the guest until we're done). ppoll() is supposed
to return EINTR if interrupted by a signal, but if a signal arrives
before you call poll() then you won't notice it so you won't
return, and the app might hang.

Looks like this same issue came up with a proposed pselect
patch last year:
http://www.mail-archive.com/qemu-devel@nongnu.org/msg28339.html
(together with some remarks about it being better not to
trust buggy libcs and go straight for the host syscall.)

-- PMM

Re: [Qemu-devel] [PATCH] linux-user: add ppoll syscall support

On Sun, Jan 23, 2011 at 17:35, Peter Maydell wrote:
 On 23 January 2011 21:35, Mike Frysinger wrote:
 On Sun, Jan 23, 2011 at 16:25, Peter Maydell wrote:
 This looks wrong -- ppoll() is supposed to be atomic, but
 your implementation isn't. Why can't we just implement this
 by calling the host ppoll? (might need a configure test, but
 that's straightforward.)

 it's atomic from the apps' point of view, so what does it matter ?

 It's not atomic because signals can arrive in the gaps
 between your calls to sigaction and poll (even if qemu doesn't
 deliver them to the guest until we're done). ppoll() is supposed
 to return EINTR if interrupted by a signal, but if a signal arrives
 before you call poll() then you won't notice it so you won't
 return, and the app might hang.

i know how host signals work, but my limited understanding of how qemu
works is that its guest signal handling would make this a non-issue.
if that isnt the case, then i can trivially convert it to ppoll.

 Looks like this same issue came up with a proposed pselect
 patch last year:
 http://www.mail-archive.com/qemu-devel@nongnu.org/msg28339.html
 (together with some remarks about it being better not to
 trust buggy libcs and go straight for the host syscall.)

i also need pselect, and i have a local patch to support it (the same
way i've implemented ppoll).  returning ENOSYS is unacceptable as it
assumes the port in question can fall back to another select variant.
but if the arch *only* supports pselect6, then there is nothing to
fall back to if select/newselect are not supported by the arch.
-mike

Re: [Qemu-devel] [PATCH 1/5] Fast Virtual Disk (FVD) Proposal Part 1

2011-01-23 Thread Anthony Liguori


On 01/21/2011 08:51 PM, Chunqiang Tang wrote:

-void qemu_bh_schedule(QEMUBH *bh)
-{
-bh-cb(bh-opaque);
-}
-
-void qemu_bh_cancel(QEMUBH *bh)
-{
-}
-
-void qemu_bh_delete(QEMUBH *bh)
-{
-qemu_free(bh);
-}
-
   int qemu_set_fd_handler2(int fd,
IOCanReadHandler *fd_read_poll,
IOHandler *fd_read,

   

These functions surely cannot just be deleted like this.
 

These functions were not deleted but instead moved into a separate file
qemu-tool-time.c, because those functions are time related and the
implementations are different in the simulation mode and in the real mode.
In the latest patches, these functions are kept in qemu-tool.c but their
implementations support both cases based on a switch.
   


I think the root of the problem is that your series didn't maintain 
bisectability.


IOW, each patch needs to be able to be applied one at a time such that 
at each point, the build doesn't break and functionality doesn't break.


Otherwise, tools like git bisect don't work.

Regards,

Anthony Liguori

Re: [Qemu-devel] [RFC][PATCH 00/12] qcow2: Convert qcow2 to use coroutines for async I/O

2011-01-23 Thread Anthony Liguori


On 01/22/2011 03:29 AM, Stefan Hajnoczi wrote:

This patch series prototypes making QCOW2 fully asynchronous to eliminate the
timing jitter and poor performance that has been observed.  QCOW2 has
asynchronous I/O code paths for some of the read/write common cases but
metadata access is always synchronous.

One solution is to rewrite QCOW2 to be fully asynchronous by splitting all
functions that perform blocking I/O into a series of callbacks.  Due to the
complexity of QCOW2, this conversion and the maintenance prospects are
unattractive.

This patch series prototypes an alternative solution to make QCOW2
asynchronous.  It introduces coroutines, cooperative userspace threads of
control, so that each QCOW2 request has its own call stack.  To perform I/O,
the coroutine submits an asynchronous I/O request and then yields back to QEMU.
The coroutine stays suspended while the I/O operation is being processed by
lower layers of the stack.  When the asynchronous I/O completes, the coroutine
is resumed.

The upshot of this is that QCOW2 can be implemented in a sequential fashion
without explicit callbacks but all I/O actually happens asynchronously under
the covers.

This prototype implements reads, writes, and flushes.  Should install or boot
VMs successfully.  However, it has the following limitations:

1. QCOW2 requests are serialized because the code is not yet safe for
concurrent requests.  See the last patch for details.

2. Coroutines are unoptimized.  We should pool coroutines (and their mmapped
stacks) to avoid the cost of coroutine creation.

3. The qcow2_aio_read_cb() and qcow2_aoi_write_cb() functions should be
refactored into sequential code now that callbacks are no longer needed.

I think this approach can solve the performance and functional problems of the
current QCOW2 implementation.  It does not require invasive changes, much of
QCOW2 works unmodified.

Kevin: Do you like this approach and do you want to develop it further?
   


Couple of additional comments:

1) The coroutine code is copied in a number of projects.  I plan on 
splitting it into a shared library.


2) Coroutines are really just a way of working with threads.  The 
implementation Stefan posted happens to take advantage of it's 
characteristics to optimize the implementation but the original 
coroutine implementation also has a thread based version for compatibility.


3) Essentially, coroutines are threads that 1) run in lock step 2) 
transfer control explicitly to one another via yieldto() and 3) performs 
message passing as part of the yield process.


They are very similar to yield-based generators in Python except a bit 
more flexible.  Think of coroutines as a way to introduce threading into 
QEMU without requiring that all of QEMU's core infrastructure be 
re-entrant to start out with (because of property (1)).


Regards,

Anthony Liguori


Stefan

[Qemu-devel] [PATCH v2] linux-user: add ppoll syscall support

Some architectures (like Blackfin) only implement ppoll (and skip poll).
So add support for it using existing poll code.

Signed-off-by: Mike Frysinger vap...@gentoo.org
---
v2
- call host ppoll() directly

 linux-user/syscall.c |   28 ++--
 1 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 6116ab5..690ee44 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -6230,8 +6230,13 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
arg1,
 ret = do_select(arg1, arg2, arg3, arg4, arg5);
 break;
 #endif
-#ifdef TARGET_NR_poll
+#if defined(TARGET_NR_poll) || defined(TARGET_NR_ppoll)
+# ifdef TARGET_NR_poll
 case TARGET_NR_poll:
+# endif
+# ifdef TARGET_NR_ppoll
+case TARGET_NR_ppoll:
+# endif
 {
 struct target_pollfd *target_pfd;
 unsigned int nfds = arg2;
@@ -6242,12 +6247,31 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
arg1,
 target_pfd = lock_user(VERIFY_WRITE, arg1, sizeof(struct 
target_pollfd) * nfds, 1);
 if (!target_pfd)
 goto efault;
+
 pfd = alloca(sizeof(struct pollfd) * nfds);
 for(i = 0; i  nfds; i++) {
 pfd[i].fd = tswap32(target_pfd[i].fd);
 pfd[i].events = tswap16(target_pfd[i].events);
 }
-ret = get_errno(poll(pfd, nfds, timeout));
+
+# ifdef TARGET_NR_ppoll
+if (num == TARGET_NR_ppoll) {
+struct timespec _timeout_ts, *timeout_ts = _timeout_ts;
+abi_ulong mask = arg4;
+sigset_t sigmask;
+
+if (arg3)
+target_to_host_timespec(timeout_ts, arg3);
+else
+timeout_ts = NULL;
+
+target_to_host_old_sigset(sigmask, mask);
+
+ret = get_errno(ppoll(pfd, nfds, timeout_ts, sigmask));
+} else
+# endif
+ret = get_errno(poll(pfd, nfds, timeout));
+
 if (!is_error(ret)) {
 for(i = 0; i  nfds; i++) {
 target_pfd[i].revents = tswap16(pfd[i].revents);
-- 
1.7.4.rc2

Re: [Qemu-devel] TCG flow vs dyngen

On 01/23/2011 04:25 PM, Stefano Bonifazi wrote:
 I am trying to shift in memory the target executable .. now the code is
 supposed to be loaded by the elfloader at the exact start address set
 at link time ..

Ah, elf loading.  That's a whole 'nother bag of worms.

Oddly enough, I was deling with this last year trying to debug the
uClibc dynamic linker.  I blogged a bit about it at the time:

  http://landley.net/notes-2010.html#12-07-2010

(And the next few days.  Sigh, I never did go back and fill in the
holes, did I?)

 Inside elfloader there is even a check for verifying whether that
 address range is busy.. but no action is taken in that case o.O
 Maybe I'll post a new thread about this problem (bug?) .. anyway if you
 think you can help me anyway I'll give you further details..

Tired right now, but if you post a clearer question (what are you trying
to _do_) and cc: me on it I'll try to respond.

Maybe I can find some decent documentation to point you at, or maybe
I'll write some...

Rob

Re: [Qemu-devel] [RFC][PATCH 11/12] qcow2: Convert qcow2 to use coroutines for async I/O

2011-01-23 Thread Anthony Liguori


On 01/22/2011 03:29 AM, Stefan Hajnoczi wrote:

Converting qcow2 to use coroutines is fairly simple since most of qcow2
is synchronous.  The synchronous I/O functions likes bdrv_pread() now
transparently work when called from a coroutine, so all the synchronous
code just works.

The explicitly asynchronous code is adjusted to repeatedly call
qcow2_aio_read_cb() or qcow2_aio_write_cb() until the request completes.
At that point the coroutine will return from its entry function and its
resources are freed.

The bdrv_aio_readv() and bdrv_aio_writev() user callback is now invoked
from a BH.  This is necessary since the user callback code does not
expect to be executed from a coroutine.

This conversion is not completely correct because the safety the
synchronous code does not carry over to the coroutine version.
Previously, a synchronous code path could assume that it will never be
interleaved with another request executing.  This is no longer true
because bdrv_pread() and bdrv_pwrite() cause the coroutine to yield and
other requests can be processed during that time.

The solution is to carefully introduce checks so that pending requests
do not step on each other's toes.  That is left for a future patch...

Signed-off-by: Stefan Hajnoczistefa...@linux.vnet.ibm.com
   


As an alternative approach, could we trap async calls from the block 
device, implement them in a synchronous fashion, then issue the callback 
immediately?


This would mean that qcow_aio_write() would become fully synchronous 
which also means that you can track when the operation is completed 
entirely within the block layer.  IOW, it should be possible to do this 
with almost no change to qcow2.


I think this is the right approach too.  If we're using coroutines, we 
shouldn't do anything asynchronous in the image formats.  The good bit 
about this is that we can probably dramatically simplify the block layer 
API but eliminating the sync/async versions of everything.


Regards,

Anthony Liguori


---
  block/qcow2.c |  160 ++---
  1 files changed, 85 insertions(+), 75 deletions(-)

diff --git a/block/qcow2.c b/block/qcow2.c
index b6b094c..4b33ef3 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -361,19 +361,20 @@ typedef struct QCowAIOCB {
  uint64_t bytes_done;
  uint64_t cluster_offset;
  uint8_t *cluster_data;
-BlockDriverAIOCB *hd_aiocb;
  QEMUIOVector hd_qiov;
  QEMUBH *bh;
  QCowL2Meta l2meta;
  QLIST_ENTRY(QCowAIOCB) next_depend;
+Coroutine *coroutine;
+int ret; /* return code for user callback */
  } QCowAIOCB;

  static void qcow2_aio_cancel(BlockDriverAIOCB *blockacb)
  {
  QCowAIOCB *acb = container_of(blockacb, QCowAIOCB, common);
-if (acb-hd_aiocb)
-bdrv_aio_cancel(acb-hd_aiocb);
  qemu_aio_release(acb);
+/* XXX This function looks broken, we could be in the middle of a request
+ * and releasing the acb is not a good idea */
  }

  static AIOPool qcow2_aio_pool = {
@@ -381,13 +382,14 @@ static AIOPool qcow2_aio_pool = {
  .cancel = qcow2_aio_cancel,
  };

-static void qcow2_aio_read_cb(void *opaque, int ret);
-static void qcow2_aio_read_bh(void *opaque)
+static void qcow2_aio_bh(void *opaque)
  {
  QCowAIOCB *acb = opaque;
  qemu_bh_delete(acb-bh);
  acb-bh = NULL;
-qcow2_aio_read_cb(opaque, 0);
+acb-common.cb(acb-common.opaque, acb-ret);
+qemu_iovec_destroy(acb-hd_qiov);
+qemu_aio_release(acb);
  }

  static int qcow2_schedule_bh(QEMUBHFunc *cb, QCowAIOCB *acb)
@@ -404,14 +406,13 @@ static int qcow2_schedule_bh(QEMUBHFunc *cb, QCowAIOCB 
*acb)
  return 0;
  }

-static void qcow2_aio_read_cb(void *opaque, int ret)
+static int coroutine_fn qcow2_aio_read_cb(void *opaque, int ret)
  {
  QCowAIOCB *acb = opaque;
  BlockDriverState *bs = acb-common.bs;
  BDRVQcowState *s = bs-opaque;
  int index_in_cluster, n1;

-acb-hd_aiocb = NULL;
  if (ret  0)
  goto done;

@@ -469,22 +470,13 @@ static void qcow2_aio_read_cb(void *opaque, int ret)
  acb-sector_num, acb-cur_nr_sectors);
  if (n1  0) {
  BLKDBG_EVENT(bs-file, BLKDBG_READ_BACKING_AIO);
-acb-hd_aiocb = bdrv_aio_readv(bs-backing_hd, acb-sector_num,
-acb-hd_qiov, acb-cur_nr_sectors,
-   qcow2_aio_read_cb, acb);
-if (acb-hd_aiocb == NULL)
-goto done;
-} else {
-ret = qcow2_schedule_bh(qcow2_aio_read_bh, acb);
-if (ret  0)
+ret = bdrv_co_readv(bs-backing_hd, 
acb-sector_num,acb-hd_qiov, acb-cur_nr_sectors);
+if (ret  0) {
  goto done;
+}
  }
  } else {
-/* Note: in this case, no need to wait */
  qemu_iovec_memset(acb-hd_qiov, 0, 512 * acb-cur_nr_sectors);
-ret =

Re: [Qemu-devel] [PATCH v2] linux-user: add ppoll syscall support

2011-01-23 Thread Peter Maydell

On 23 January 2011 23:32, Mike Frysinger vap...@gentoo.org wrote:
 +                if (arg3)
 +                    target_to_host_timespec(timeout_ts, arg3);
 +                else
 +                    timeout_ts = NULL;

Coding style mandates braces here. Also, target_to_host_timespec()
can return non-zero if the user handed us a bad pointer, which
you need to handle. (No, none of the other users of the
function do this; yes, I think they're all broken :-))

 +                target_to_host_old_sigset(sigmask, mask);

Are you sure this is right?
http://lxr.linux.no/#linux+v2.6.37/fs/select.c#L950
suggests the syscall takes a new sigset, not an old one.

You also need to lock_user() the memory for the sigset.
(target_to_host_timespec() does lock_user/unlock_user for
you but the target_to_host_*sigset() don't).

 +                ret = get_errno(ppoll(pfd, nfds, timeout_ts, sigmask));
 +            } else
 +# endif
 +                ret = get_errno(poll(pfd, nfds, timeout));
 +
             if (!is_error(ret)) {
                 for(i = 0; i  nfds; i++) {
                     target_pfd[i].revents = tswap16(pfd[i].revents);

The ppoll() manpage says
The Linux ppoll() system call modifies its timeout argument.

Your implementation doesn't do this. Also, this means you
really do need to call the host ppoll syscall directly, because
glibc deliberately hides this behaviour and would prevent
us from implementing it.

thanks
-- PMM

Re: [Qemu-devel] Re: [PATCH] audio: consolidate audio_init()

2011-01-23 Thread Isaku Yamahata

On Sun, Jan 23, 2011 at 04:50:34PM +0100, Andreas Färber wrote:
 Am 21.01.2011 um 23:27 schrieb malc:

 On Fri, 21 Jan 2011, Blue Swirl wrote:

 On Fri, Jan 21, 2011 at 10:53 AM, Isaku Yamahata 
 yamah...@valinux.co.jp wrote:
 consolidate audio_init() and remove references to shoundhw.

 Cc: Blue Swirl blauwir...@gmail.com
 Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp

 Don't see the point of first hunk. No objections otherwise.

 I guess the point is to limit use of 'soundhw' to arch_init.c rather  
 than to anyone including sysemu.h?
 The definition of the struct is moved there and the variable is made  
 static.

That's right. Thank you for explanation. I didn't see any reason
why the definition of struct soundhw is used anywhere else.



 Acked-by: Blue Swirl blauwir...@gmail.com


-- 
yamahata

[Qemu-devel] [Bug 706766] [NEW] [Qemu-kvm] qemu-img fail to create qcow image

2011-01-23 Thread xudong

Public bug reported:

On qemu-kvm tree 6f32e3d09d990fd50008756fcb446b55e0c0af79, complier it.
Then try to create a qcow image with a exist raw image, create fail.

reproduce steps:
1) build qemu-kvm
2) ./qemu-img create -b ./ia32e_fc10.img -f qcow2 ./qcow.img
3) Fail to create qcow image, it show error qemu-img: Could not open 
'./qcow.img' 

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  [Qemu-kvm] qemu-img fail to create qcow image

Status in QEMU:
  New

Bug description:
  On qemu-kvm tree 6f32e3d09d990fd50008756fcb446b55e0c0af79, complier
  it. Then try to create a qcow image with a exist raw image, create
  fail.

  reproduce steps:
  1) build qemu-kvm
  2) ./qemu-img create -b ./ia32e_fc10.img -f qcow2 ./qcow.img
  3) Fail to create qcow image, it show error qemu-img: Could not open 
'./qcow.img'

[Qemu-devel] [Bug 706766] Re: [Qemu-kvm] qemu-img fail to create qcow image

2011-01-23 Thread xudong

The latest qemu tree e10990c3f0c39e92ab5f74004b89a24fcc36fa14 also has
this issue.

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

Title:
  [Qemu-kvm] qemu-img fail to create qcow image

Status in QEMU:
  New

Bug description:
  On qemu-kvm tree 6f32e3d09d990fd50008756fcb446b55e0c0af79, complier
  it. Then try to create a qcow image with a exist raw image, create
  fail.

  reproduce steps:
  1) build qemu-kvm
  2) ./qemu-img create -b ./ia32e_fc10.img -f qcow2 ./qcow.img
  3) Fail to create qcow image, it show error qemu-img: Could not open 
'./qcow.img'

[Qemu-devel] [PATCH v3] linux-user: add ppoll syscall support

Some architectures (like Blackfin) only implement ppoll (and skip poll).
So add support for it using existing poll code.

Signed-off-by: Mike Frysinger vap...@gentoo.org
---
v3
- call ppoll syscall directly so timespec updates get passed back
- tweak style
- use new sigsets

 linux-user/syscall.c |   52 -
 1 files changed, 50 insertions(+), 2 deletions(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 6116ab5..02aab0f 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -529,6 +529,15 @@ static int sys_inotify_init1(int flags)
 #undef TARGET_NR_inotify_rm_watch
 #endif /* CONFIG_INOTIFY  */
 
+#if defined(TARGET_NR_ppoll)
+#ifndef __NR_ppoll
+# define __NR_ppoll -1
+#endif
+#define __NR_sys_ppoll __NR_ppoll
+_syscall5(int, sys_ppoll, struct pollfd *, fds, nfds_t, nfds,
+  struct timespec *, timeout, const __sigset_t *, sigmask,
+  size_t, sigsetsize)
+#endif
 
 extern int personality(int);
 extern int flock(int, int);
@@ -6230,8 +6239,13 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
arg1,
 ret = do_select(arg1, arg2, arg3, arg4, arg5);
 break;
 #endif
-#ifdef TARGET_NR_poll
+#if defined(TARGET_NR_poll) || defined(TARGET_NR_ppoll)
+# ifdef TARGET_NR_poll
 case TARGET_NR_poll:
+# endif
+# ifdef TARGET_NR_ppoll
+case TARGET_NR_ppoll:
+# endif
 {
 struct target_pollfd *target_pfd;
 unsigned int nfds = arg2;
@@ -6242,12 +6256,46 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
arg1,
 target_pfd = lock_user(VERIFY_WRITE, arg1, sizeof(struct 
target_pollfd) * nfds, 1);
 if (!target_pfd)
 goto efault;
+
 pfd = alloca(sizeof(struct pollfd) * nfds);
 for(i = 0; i  nfds; i++) {
 pfd[i].fd = tswap32(target_pfd[i].fd);
 pfd[i].events = tswap16(target_pfd[i].events);
 }
-ret = get_errno(poll(pfd, nfds, timeout));
+
+# ifdef TARGET_NR_ppoll
+if (num == TARGET_NR_ppoll) {
+struct timespec _timeout_ts, *timeout_ts = _timeout_ts;
+target_sigset_t *target_set;
+sigset_t set;
+
+if (arg3) {
+if (target_to_host_timespec(timeout_ts, arg3)) {
+unlock_user(target_pfd, arg1, 0);
+goto efault;
+}
+} else {
+timeout_ts = NULL;
+}
+
+target_set = lock_user(VERIFY_READ, arg4, 
sizeof(target_sigset_t), 1);
+if (!target_set) {
+unlock_user(target_pfd, arg1, 0);
+goto efault;
+}
+target_to_host_sigset(set, target_set);
+
+ret = get_errno(sys_ppoll(pfd, nfds, timeout_ts, set, 
_NSIG/8));
+
+if (!is_error(ret)  arg3) {
+host_to_target_timespec(arg3, timeout_ts);
+}
+
+unlock_user(target_set, arg4, 0);
+} else
+# endif
+ret = get_errno(poll(pfd, nfds, timeout));
+
 if (!is_error(ret)) {
 for(i = 0; i  nfds; i++) {
 target_pfd[i].revents = tswap16(pfd[i].revents);
-- 
1.7.4.rc2

[Qemu-devel] qemu snapshot

2011-01-23 Thread chandra shekar

hi everyone i have 2 systems each installed with qemu and for each guest os
is windows and host is ubuntu
i tried to load snapshot of one guest os onto other it loads successfully
but immediately it gives error as memory
fault and shuts down can anyone help me with this,thanks

-- 
chandra

[Qemu-devel] [PULL] virtio-serial: Fixes, flow control

2011-01-23 Thread Amit Shah

Hello,

Please pull for fixes to the virtio-serial code:
- Don't copy over guest buffer to host (prevents potential DoS
  scenarios, pointed out by Paul Brook)
- Add support for flow control
- A couple of trivial fixes to virtio-console code

The patches were sent out to the list on 19 Jan 2011, subject
[PATCH 0/7] virtio-serial: Don't copy guest buf to host, flow control

The following changes since commit
b646968336d4180bdd7d2e24209708dcee6ba400:

  checkpatch: adjust to QEMUisms (2011-01-20 20:58:56 +)

are available in the git repository at:
  git://git.kernel.org/pub/scm/virt/qemu/amit/virtio-serial.git
for-anthony

Amit Shah (7):
  virtio-console: Factor out common init between console and generic ports
  virtio-console: Remove unnecessary braces
  virtio-serial: move out discard logic in a separate function
  virtio-serial: Don't copy over guest buffer to host
  virtio-serial: Let virtio-serial-bus know if all data was consumed
  virtio-serial: Add support for flow control
  virtio-serial: save/restore new fields in port struct

 hw/virtio-console.c|   38 +++
 hw/virtio-serial-bus.c |  123
+++-
 hw/virtio-serial.h |   24 -
 3 files changed, 139 insertions(+), 46 deletions(-)


Amit

[Qemu-devel] [Bug 706766] Re: [Qemu-kvm] qemu-img fail to create qcow image

2011-01-23 Thread Stefan Hajnoczi

** Changed in: qemu
   Status: New = Confirmed

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

Title:
  [Qemu-kvm] qemu-img fail to create qcow image

Status in QEMU:
  Confirmed

Bug description:
  On qemu-kvm tree 6f32e3d09d990fd50008756fcb446b55e0c0af79, complier
  it. Then try to create a qcow image with a exist raw image, create
  fail.

  reproduce steps:
  1) build qemu-kvm
  2) ./qemu-img create -b ./ia32e_fc10.img -f qcow2 ./qcow.img
  3) Fail to create qcow image, it show error qemu-img: Could not open 
'./qcow.img'

[Qemu-devel] Re: [RFC][PATCH v6 03/23] Make qemu timers available for tools

2011-01-23 Thread Jes Sorensen

On 01/21/11 18:26, Michael Roth wrote:
 On 01/21/2011 10:30 AM, Jes Sorensen wrote:
 On 01/17/11 14:14, Michael Roth wrote:
 diff --git a/qemu-ioh.c b/qemu-ioh.c
 index cc71470..001e7a2 100644
 --- a/qemu-ioh.c
 +++ b/qemu-ioh.c
 @@ -22,7 +22,11 @@
* THE SOFTWARE.
*/
   #include qemu-ioh.h
 +#include qemu-char.h
   #include qlist.h
 +#ifdef CONFIG_EVENTFD
 +#includesys/eventfd.h
 +#endif

   /* XXX: fd_read_poll should be suppressed, but an API change is
  necessary in the character devices to suppress fd_can_read(). */
 @@ -113,3 +117,92 @@ void qemu_process_fd_handlers2(void
 *ioh_record_list, const fd_set *rfds,
   }
   }
   }
 +
 +#ifndef _WIN32
 +void iothread_event_increment(int *io_thread_fd)

 Please split the WIN32 stuff into it's own file, similar to oslib-posix
 and oslib-win32.c etc.
 
 Will look into this, but qemu-ioh.c has common code too so we'd end up
 with qemu-ioh/qemu-ioh-posix/qemu-ioh-win2.c. We could alternatively
 have a #ifndef _WIN32 around functions in qemu-ioh.c that would be
 replaced by win32-specific ones from qemu-ioh-win32. No strong
 preference either way, but sometimes I find navigating across too many
 files more annoying that #ifdefs, and there's not a whole lot in these.

No problem having the three files - it is far better than having
#ifdefs. Having the #ifndef that is overloaded by a win32 specific file
is bad, it will make it very confusing for anyone reading the code.

Cheers,
Jes

[Qemu-devel] [PATCH] linux-user: fix sizeof handling for getsockopt

Signed-off-by: Mike Frysinger vap...@gentoo.org
---
 linux-user/syscall.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 499c4d7..6116ab5 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -1448,7 +1448,7 @@ static abi_long do_getsockopt(int sockfd, int level, int 
optname,
 return -TARGET_EFAULT;
 if (len  0)
 return -TARGET_EINVAL;
-lv = sizeof(int);
+lv = sizeof(lv);
 ret = get_errno(getsockopt(sockfd, level, optname, val, lv));
 if (ret  0)
 return ret;
@@ -1485,7 +1485,7 @@ static abi_long do_getsockopt(int sockfd, int level, int 
optname,
 return -TARGET_EFAULT;
 if (len  0)
 return -TARGET_EINVAL;
-lv = sizeof(int);
+lv = sizeof(lv);
 ret = get_errno(getsockopt(sockfd, level, optname, val, lv));
 if (ret  0)
 return ret;
-- 
1.7.4.rc2

[Qemu-devel] [PATCH] linux-user: decode MAP_{UNINITIALIZED, EXECUTABLE} in strace