Re: [Qemu-devel] [PULL] Memory core space reduction

2012-02-29 Thread Avi Kivity 
On 02/29/2012 12:58 AM, Michael S. Tsirkin wrote:

 What I did, to allow bisect, is rebase Avi's patches on top
 of my bridge implementation, then run qemu with a bridge.
 bridge without Avi's patches at least starts booting, with
 Avi's patches crashes before guest start.

 If you want to play with that, take it from branch bisectme
 on my qemu tree on github.


How do you reproduce it?

I tried

   qemu-system-x86_64 -device pci-bridge,chassis_nr=23

but that boots.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PULL] Memory core space reduction

2012-02-29 Thread Michael S. Tsirkin 
On Wed, Feb 29, 2012 at 12:09:14PM +0200, Avi Kivity wrote:
 On 02/29/2012 12:58 AM, Michael S. Tsirkin wrote:
 
  What I did, to allow bisect, is rebase Avi's patches on top
  of my bridge implementation, then run qemu with a bridge.
  bridge without Avi's patches at least starts booting, with
  Avi's patches crashes before guest start.
 
  If you want to play with that, take it from branch bisectme
  on my qemu tree on github.
 
 
 How do you reproduce it?
 
 I tried
 
qemu-system-x86_64 -device pci-bridge,chassis_nr=23
 
 but that boots.

It could be that you need more devices.  This is my command line:
qemu-system-x86_64  -m 1G -drive file=/home/mst/rhel6.qcow2 -netdev
user,id=bar -net nic,netdev=bar,model=e1000,macaddr=52:54:00:12:34:57
-redir tcp:8022::22 -device pci-bridge,id=bog,chassis_nr=1 -netdev
tap,id=foo,ifname=msttap0,script=/home/mst/ifup,downscript=no,vhost=on
-nographic 

 -- 
 error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PULL] Memory core space reduction

2012-02-29 Thread Avi Kivity 
On 02/29/2012 12:23 PM, Michael S. Tsirkin wrote:
 On Wed, Feb 29, 2012 at 12:09:14PM +0200, Avi Kivity wrote:
  On 02/29/2012 12:58 AM, Michael S. Tsirkin wrote:
  
   What I did, to allow bisect, is rebase Avi's patches on top
   of my bridge implementation, then run qemu with a bridge.
   bridge without Avi's patches at least starts booting, with
   Avi's patches crashes before guest start.
  
   If you want to play with that, take it from branch bisectme
   on my qemu tree on github.
  
  
  How do you reproduce it?
  
  I tried
  
 qemu-system-x86_64 -device pci-bridge,chassis_nr=23
  
  but that boots.

 It could be that you need more devices.  This is my command line:
 qemu-system-x86_64  -m 1G -drive file=/home/mst/rhel6.qcow2 -netdev
 user,id=bar -net nic,netdev=bar,model=e1000,macaddr=52:54:00:12:34:57
 -redir tcp:8022::22 -device pci-bridge,id=bog,chassis_nr=1 -netdev
 tap,id=foo,ifname=msttap0,script=/home/mst/ifup,downscript=no,vhost=on
 -nographic 


Boots too, even after supplying a peer to foo.

I did get an abort with -enable-kvm, but that looks like the old issue,
no?  Looking into it.

Suggest a valgrind run.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PULL] Memory core space reduction

2012-02-29 Thread Michael S. Tsirkin 
On Wed, Feb 29, 2012 at 12:53:50PM +0200, Avi Kivity wrote:
 On 02/29/2012 12:23 PM, Michael S. Tsirkin wrote:
  On Wed, Feb 29, 2012 at 12:09:14PM +0200, Avi Kivity wrote:
   On 02/29/2012 12:58 AM, Michael S. Tsirkin wrote:
   
What I did, to allow bisect, is rebase Avi's patches on top
of my bridge implementation, then run qemu with a bridge.
bridge without Avi's patches at least starts booting, with
Avi's patches crashes before guest start.
   
If you want to play with that, take it from branch bisectme
on my qemu tree on github.
   
   
   How do you reproduce it?
   
   I tried
   
  qemu-system-x86_64 -device pci-bridge,chassis_nr=23
   
   but that boots.
 
  It could be that you need more devices.  This is my command line:
  qemu-system-x86_64  -m 1G -drive file=/home/mst/rhel6.qcow2 -netdev
  user,id=bar -net nic,netdev=bar,model=e1000,macaddr=52:54:00:12:34:57
  -redir tcp:8022::22 -device pci-bridge,id=bog,chassis_nr=1 -netdev
  tap,id=foo,ifname=msttap0,script=/home/mst/ifup,downscript=no,vhost=on
  -nographic 
 
 
 Boots too, even after supplying a peer to foo.
 
 I did get an abort with -enable-kvm, but that looks like the old issue,
 no?  Looking into it.
 
 Suggest a valgrind run.

It does not crash under valgrind :)
But valgrid did show some info:

==9202== Invalid write of size 8
==9202==at 0x2F313D: portio_list_add_1 (ioport.c:379)
==9202==by 0x224473: parallel_isa_initfn (parallel.c:505)
==9202==by 0x274839: qdev_init (qdev.c:150)
==9202==by 0x3357F0: pc_basic_device_init (pc.h:53)
==9202==by 0x337DB2: pc_init1 (pc_piix.c:240)
==9202==by 0x3383E7: pc_init_pci (pc_piix.c:319)
==9202==by 0x24EFE7: main (vl.c:3397)
==9202==  Address 0x27b202b8 is 0 bytes after a block of size 8 alloc'd
==9202==at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==9202==by 0x24D4C5: malloc_and_trace (vl.c:2156)
==9202==by 0x506334D: ??? (in /lib64/libglib-2.0.so.0.2200.5)
==9202==by 0x5063707: g_malloc0 (in /lib64/libglib-2.0.so.0.2200.5)
==9202==by 0x2F2FBC: portio_list_init (ioport.c:331)
==9202==by 0x21A545: isa_register_portio_list (isa-bus.c:109)
==9202==by 0x224473: parallel_isa_initfn (parallel.c:505)
==9202==by 0x274839: qdev_init (qdev.c:150)
==9202==by 0x3357F0: pc_basic_device_init (pc.h:53)
==9202==by 0x337DB2: pc_init1 (pc_piix.c:240)
==9202==by 0x3383E7: pc_init_pci (pc_piix.c:319)
==9202==by 0x24EFE7: main (vl.c:3397)
==9202== 
==9202== Invalid write of size 8
==9202==at 0x2F312F: portio_list_add_1 (ioport.c:378)
==9202==by 0x2064FA: isabus_fdc_init1 (fdc.c:1893)
==9202==by 0x274839: qdev_init (qdev.c:150)
==9202==by 0x27491C: qdev_init_nofail (qdev.c:243)
==9202==by 0x3358ED: pc_basic_device_init (fdc.h:25)
==9202==by 0x337DB2: pc_init1 (pc_piix.c:240)
==9202==by 0x3383E7: pc_init_pci (pc_piix.c:319)
==9202==by 0x24EFE7: main (vl.c:3397)
==9202==  Address 0x28f54d20 is 0 bytes after a block of size 16 alloc'd
==9202==at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==9202==by 0x24D4C5: malloc_and_trace (vl.c:2156)
==9202==by 0x506334D: ??? (in /lib64/libglib-2.0.so.0.2200.5)
==9202==by 0x5063707: g_malloc0 (in /lib64/libglib-2.0.so.0.2200.5)
==9202==by 0x2F2FAB: portio_list_init (ioport.c:330)
==9202==by 0x21A545: isa_register_portio_list (isa-bus.c:109)
==9202==by 0x2064FA: isabus_fdc_init1 (fdc.c:1893)
==9202==by 0x274839: qdev_init (qdev.c:150)
==9202==by 0x27491C: qdev_init_nofail (qdev.c:243)
==9202==by 0x3358ED: pc_basic_device_init (fdc.h:25)
==9202==by 0x337DB2: pc_init1 (pc_piix.c:240)
==9202==by 0x3383E7: pc_init_pci (pc_piix.c:319)
==9202== 
==9202== Invalid write of size 8
==9202==at 0x2F313D: portio_list_add_1 (ioport.c:379)
==9202==by 0x2064FA: isabus_fdc_init1 (fdc.c:1893)
==9202==by 0x274839: qdev_init (qdev.c:150)
==9202==by 0x27491C: qdev_init_nofail (qdev.c:243)
==9202==by 0x3358ED: pc_basic_device_init (fdc.h:25)
==9202==by 0x337DB2: pc_init1 (pc_piix.c:240)
==9202==by 0x3383E7: pc_init_pci (pc_piix.c:319)
==9202==by 0x24EFE7: main (vl.c:3397)
==9202==  Address 0x27b2ec78 is 8 bytes after a block of size 16 alloc'd
==9202==at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==9202==by 0x24D4C5: malloc_and_trace (vl.c:2156)
==9202==by 0x506334D: ??? (in /lib64/libglib-2.0.so.0.2200.5)
==9202==by 0x5063707: g_malloc0 (in /lib64/libglib-2.0.so.0.2200.5)
==9202==by 0x2F2FBC: portio_list_init (ioport.c:331)
==9202==by 0x21A545: isa_register_portio_list (isa-bus.c:109)
==9202==by 0x2064FA: isabus_fdc_init1 (fdc.c:1893)
==9202==by 0x274839: qdev_init (qdev.c:150)
==9202==by 0x27491C: qdev_init_nofail (qdev.c:243)
==9202==by 0x3358ED: pc_basic_device_init (fdc.h:25)
==9202==by 0x337DB2: pc_init1 (pc_piix.c:240)
==9202==by 0x3383E7: pc_init_pci (pc_piix.c:319)
==9202== 
==9202== Invalid write of size 8
==9202==at 0x2F313D:

Re: [Qemu-devel] [PULL] Memory core space reduction

2012-02-29 Thread Avi Kivity 
On 02/29/2012 12:53 PM, Avi Kivity wrote:
 I did get an abort with -enable-kvm, but that looks like the old issue,
 no?  Looking into it.



-- 
error compiling committee.c: too many arguments to function

From 4fa865c7086e2f287c91f4372df6eb5ddf40a48c Mon Sep 17 00:00:00 2001
From: Avi Kivity a...@redhat.com
Date: Wed, 29 Feb 2012 13:22:12 +0200
Subject: [PATCH] kvm: fix unaligned slots

kvm_set_phys_mem() may be passed sections that are not aligned to a page
boundary.  The current code simply brute-forces the alignment which leads
to an inconsistency and an abort().

Fix by aligning the start and the end of the section correctly, discarding
and unaligned head or tail.

This was triggered by a guest sizing a 64-bit BAR that is smaller than a page
with PCI_COMMAND_MEMORY enabled and the upper dword clear.

Signed-off-by: Avi Kivity a...@redhat.com
---
 kvm-all.c |   15 ---
 1 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/kvm-all.c b/kvm-all.c
index 839b1dd..c58c77b 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -542,17 +542,26 @@ static void kvm_set_phys_mem(MemoryRegionSection *section, bool add)
 target_phys_addr_t start_addr = section-offset_within_address_space;
 ram_addr_t size = section-size;
 void *ram = NULL;
+unsigned delta;
 
 /* kvm works in page size chunks, but the function may be called
with sub-page size and unaligned start address. */
-size = TARGET_PAGE_ALIGN(size);
-start_addr = TARGET_PAGE_ALIGN(start_addr);
+delta = TARGET_PAGE_ALIGN(size) - size;
+if (delta  size) {
+return;
+}
+start_addr += delta;
+size -= delta;
+size = TARGET_PAGE_MASK;
+if (!size || (start_addr  ~TARGET_PAGE_MASK)) {
+return;
+}
 
 if (!memory_region_is_ram(mr)) {
 return;
 }
 
-ram = memory_region_get_ram_ptr(mr) + section-offset_within_region;
+ram = memory_region_get_ram_ptr(mr) + section-offset_within_region + delta;
 
 while (1) {
 mem = kvm_lookup_overlapping_slot(s, start_addr, start_addr + size);
-- 
1.7.9

Re: [Qemu-devel] [PULL] Memory core space reduction

2012-02-29 Thread Avi Kivity 
On 02/29/2012 01:25 PM, Michael S. Tsirkin wrote:
 It does not crash under valgrind :)
 But valgrid did show some info:

 ==9202== Invalid write of size 8
 ==9202==at 0x2F313D: portio_list_add_1 (ioport.c:379)


Anthony, your bad bisect was in fact good - it was the very first
patch that was bad:

piolist-regions[piolist-nr++] = region;
piolist-aliases[piolist-nr++] = alias;

will fix.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PULL] Memory core space reduction

2012-02-29 Thread Avi Kivity 
On 02/29/2012 01:31 PM, Avi Kivity wrote:
 On 02/29/2012 01:25 PM, Michael S. Tsirkin wrote:
  It does not crash under valgrind :)
  But valgrid did show some info:
 
  ==9202== Invalid write of size 8
  ==9202==at 0x2F313D: portio_list_add_1 (ioport.c:379)
 

 Anthony, your bad bisect was in fact good - it was the very first
 patch that was bad:

 piolist-regions[piolist-nr++] = region;
 piolist-aliases[piolist-nr++] = alias;

 will fix.


Please retry with the new memory/core branch I just pushed.  If using
kvm, also apply the patch I posted elsewhere in this thread.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PULL] Memory core space reduction

2012-02-29 Thread Michael S. Tsirkin 
On Wed, Feb 29, 2012 at 01:45:49PM +0200, Avi Kivity wrote:
 On 02/29/2012 01:31 PM, Avi Kivity wrote:
  On 02/29/2012 01:25 PM, Michael S. Tsirkin wrote:
   It does not crash under valgrind :)
   But valgrid did show some info:
  
   ==9202== Invalid write of size 8
   ==9202==at 0x2F313D: portio_list_add_1 (ioport.c:379)
  
 
  Anthony, your bad bisect was in fact good - it was the very first
  patch that was bad:
 
  piolist-regions[piolist-nr++] = region;
  piolist-aliases[piolist-nr++] = alias;
 
  will fix.
 
 
 Please retry with the new memory/core branch I just pushed.  If using
 kvm, also apply the patch I posted elsewhere in this thread.

Yes, seems to boot now.

 -- 
 error compiling committee.c: too many arguments to function

[Qemu-devel] [PULL] Memory core space reduction

2012-02-28 Thread Avi Kivity 
This is the current memory queue (posted as two separate series before
my vacation).  When applied, the overhead of 16 bytes/page is reduced to
basically nil.


Avi Kivity (30):
  ioport: change portio_list not to use memory_region_set_offset()
  memory: remove memory_region_set_offset()
  memory: add shorthand for invoking a callback on all listeners
  memory: switch memory listeners to a QTAILQ
  memory: code motion: move MEMORY_LISTENER_CALL()
  memory: move ioeventfd ops to MemoryListener
  memory: add a readonly attribute to MemoryRegionSection
  memory: don't pass -readable attribute to
cpu_register_physical_memory_log
  memory: use a MemoryListener for core memory map updates too
  memory: drop AddressSpaceOps
  memory: allow MemoryListeners to observe a specific address space
  xen: ignore I/O memory regions
  memory: split memory listener for the two address spaces
  memory: support stateless memory listeners
  memory: change memory registration to rebuild the memory map on
each change
  memory: remove first level of l1_phys_map
  memory: unify phys_map last level with intermediate levels
  memory: store MemoryRegionSection pointers in phys_map
  memory: compress phys_map node pointers to 16 bits
  memory: fix RAM subpages in newly initialized pages
  memory: unify the two branches of cpu_register_physical_memory_log()
  memory: move tlb flush to MemoryListener commit callback
  memory: make phys_page_find() return a MemoryRegionSection
  memory: give phys_page_find() its own tree search loop
  memory: simplify multipage/subpage registration
  memory: replace phys_page_find_alloc() with phys_page_set()
  memory: switch phys_page_set() to a recursive implementation
  memory: change phys_page_set() to set multiple pages
  memory: unify PhysPageEntry::node and ::leaf
  memory: allow phys_map tree paths to terminate early

 exec-obsolete.h |5 +-
 exec.c  |  875
---
 hw/vhost.c  |   33 ++-
 ioport.c|   25 ++-
 ioport.h|1 +
 kvm-all.c   |   97 ++-
 memory.c|  328 +-
 memory.h|   26 +-
 xen-all.c   |   33 ++-
 9 files changed, 910 insertions(+), 513 deletions(-)

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] [PULL] Memory core space reduction

2012-02-28 Thread Avi Kivity 
[repost with pull info, brain not yet back up to speed]

This is the current memory queue (posted as two separate series before
my vacation).  When applied, the overhead of 16 bytes/page is reduced to
basically nil.

Please pull from:

  git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/core



Avi Kivity (30):
  ioport: change portio_list not to use memory_region_set_offset()
  memory: remove memory_region_set_offset()
  memory: add shorthand for invoking a callback on all listeners
  memory: switch memory listeners to a QTAILQ
  memory: code motion: move MEMORY_LISTENER_CALL()
  memory: move ioeventfd ops to MemoryListener
  memory: add a readonly attribute to MemoryRegionSection
  memory: don't pass -readable attribute to
cpu_register_physical_memory_log
  memory: use a MemoryListener for core memory map updates too
  memory: drop AddressSpaceOps
  memory: allow MemoryListeners to observe a specific address space
  xen: ignore I/O memory regions
  memory: split memory listener for the two address spaces
  memory: support stateless memory listeners
  memory: change memory registration to rebuild the memory map on
each change
  memory: remove first level of l1_phys_map
  memory: unify phys_map last level with intermediate levels
  memory: store MemoryRegionSection pointers in phys_map
  memory: compress phys_map node pointers to 16 bits
  memory: fix RAM subpages in newly initialized pages
  memory: unify the two branches of cpu_register_physical_memory_log()
  memory: move tlb flush to MemoryListener commit callback
  memory: make phys_page_find() return a MemoryRegionSection
  memory: give phys_page_find() its own tree search loop
  memory: simplify multipage/subpage registration
  memory: replace phys_page_find_alloc() with phys_page_set()
  memory: switch phys_page_set() to a recursive implementation
  memory: change phys_page_set() to set multiple pages
  memory: unify PhysPageEntry::node and ::leaf
  memory: allow phys_map tree paths to terminate early

 exec-obsolete.h |5 +-
 exec.c  |  875
---
 hw/vhost.c  |   33 ++-
 ioport.c|   25 ++-
 ioport.h|1 +
 kvm-all.c   |   97 ++-
 memory.c|  328 +-
 memory.h|   26 +-
 xen-all.c   |   33 ++-
 9 files changed, 910 insertions(+), 513 deletions(-)

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PULL] Memory core space reduction

2012-02-28 Thread Avi Kivity 
On 02/28/2012 02:25 PM, Avi Kivity wrote:
 [repost with pull info, brain not yet back up to speed]

 This is the current memory queue (posted as two separate series before
 my vacation).  When applied, the overhead of 16 bytes/page is reduced to
 basically nil.

 Please pull from:

   git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/core


Michael, this may fix your issues with 64-bit BARs.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PULL] Memory core space reduction

2012-02-28 Thread Michael S. Tsirkin 
On Tue, Feb 28, 2012 at 02:25:42PM +0200, Avi Kivity wrote:
 [repost with pull info, brain not yet back up to speed]
 
 This is the current memory queue (posted as two separate series before
 my vacation).  When applied, the overhead of 16 bytes/page is reduced to
 basically nil.
 
 Please pull from:
 
   git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/core
 

This seems to make things worse for me: I used to see a crash with kvm when 
using
a 64 bit BAR, now it crashes very early, and without kvm as well:

#0  0x75fc4155 in malloc_consolidate () from /lib64/libc.so.6
#1  0x75fc71c2 in _int_malloc () from /lib64/libc.so.6
#2  0x75fc85ed in malloc () from /lib64/libc.so.6
#3  0x77e00496 in malloc_and_trace (n_bytes=8392) at 
/home/mst/scm/qemu/vl.c:2156
#4  0x773e834e in ?? () from /lib64/libglib-2.0.so.0
#5  0x773e8708 in g_malloc0 () from /lib64/libglib-2.0.so.0
#6  0x77e88d52 in subpage_init (section=0x7fffd9a0) at 
/home/mst/scm/qemu/exec.c:3483
#7  register_subpage (section=0x7fffd9a0) at /home/mst/scm/qemu/exec.c:2643
#8  0x77e88fa6 in cpu_register_physical_memory_log (section=value 
optimized out, 
readonly=value optimized out) at /home/mst/scm/qemu/exec.c:2680
#9  0x77eb2d68 in address_space_update_topology_pass 
(as=0x78ae4b80, old_view=..., new_view=..., adding=
true) at /home/mst/scm/qemu/memory.c:679
#10 0x77eb4c66 in address_space_update_topology (as=0x78ae4b80) at 
/home/mst/scm/qemu/memory.c:708
#11 0x77eb5444 in memory_region_update_topology (mr=value optimized 
out) at /home/mst/scm/qemu/memory.c:729
#12 0x77dc98d7 in bmdma_setup_bar (dev=0x78d52500) at 
/home/mst/scm/qemu/hw/ide/piix.c:97
#13 pci_piix_ide_initfn (dev=0x78d52500) at 
/home/mst/scm/qemu/hw/ide/piix.c:157
#14 0x77dd998e in pci_qdev_init (qdev=0x78d52500) at 
/home/mst/scm/qemu/hw/pci.c:1492
#15 0x77e277ba in qdev_init (dev=0x78d52500) at 
/home/mst/scm/qemu/hw/qdev.c:150
#16 0x77e2789d in qdev_init_nofail (dev=0x78d52500) at 
/home/mst/scm/qemu/hw/qdev.c:243
#17 0x77dd8d88 in pci_create_simple_multifunction (bus=value optimized 
out, devfn=value optimized out, 
multifunction=value optimized out, name=value optimized out) at 
/home/mst/scm/qemu/hw/pci.c:1552
#18 0x77dc9c2f in pci_piix3_ide_init (bus=value optimized out, 
hd_table=0x7fffdfd0, 
devfn=value optimized out) at /home/mst/scm/qemu/hw/ide/piix.c:224
#19 0x77eeafb7 in pc_init1 (system_memory=0x78d0e6c0, 
system_io=0x78b61d40, ram_size=1073741824, 
boot_device=0x7fffe320 cad, kernel_filename=value optimized out, 
kernel_cmdline=value optimized out, 
initrd_filename=0x0, cpu_model=0x0, pci_enabled=1, kvmclock_enabled=1) at 
/home/mst/scm/qemu/hw/pc_piix.c:257
#20 0x77eeb368 in pc_init_pci (ram_size=1073741824, 
boot_device=0x7fffe320 cad, kernel_filename=0x0, 
kernel_cmdline=0x77f669e5 , initrd_filename=0x0, cpu_model=value 
optimized out)
at /home/mst/scm/qemu/hw/pc_piix.c:319
#21 0x77e01fb8 in main (argc=value optimized out, argv=value 
optimized out, envp=value optimized out)
at /home/mst/scm/qemu/vl.c:3397


How to reproduce:
qemu-system-x86_64 -m 1G -drive file=/home/mst/rhel6.qcow2 -netdev user,id=bar 
-net nic,netdev=bar,model=e1000,macaddr=52:54:00:12:34:57 -redir tcp:8022::22 
-device pci-bridge,id=bog,chassis_nr=1 -netdev 
tap,id=foo,ifname=msttap0,script=/home/mst/ifup,downscript=no,vhost=on 
-nographic


The code for this can be found here:

git://github.com/mstsirkin/qemu.git   pci

If I set a 32 bit region - no issue, the last patch to trigger this is:

bridge: make BAR 64 bit

This crashes kvm. Donnu why.

Signed-off-by: Michael S. Tsirkin m...@redhat.com

diff --git a/hw/pci_bridge_dev.c b/hw/pci_bridge_dev.c
index 9a4102a..60d9528 100644
--- a/hw/pci_bridge_dev.c
+++ b/hw/pci_bridge_dev.c
@@ -66,7 +66,8 @@ static int pci_bridge_dev_initfn(PCIDevice *dev)
 }
 /* TODO: spec recommends using 64 bit prefetcheable BAR.
  * Check whether that works well. */
-pci_register_bar(dev, 0, PCI_BASE_ADDRESS_SPACE_MEMORY, bridge_dev-bar);
+pci_register_bar(dev, 0, PCI_BASE_ADDRESS_SPACE_MEMORY |
+PCI_BASE_ADDRESS_MEM_TYPE_64, bridge_dev-bar);
 dev-config[PCI_INTERRUPT_PIN] = 0x1;
 return 0;
 slotid_error:


-- 
MST

Re: [Qemu-devel] [PULL] Memory core space reduction

2012-02-28 Thread Anthony Liguori 

On 02/28/2012 11:59 AM, Michael S. Tsirkin wrote:

On Tue, Feb 28, 2012 at 02:25:42PM +0200, Avi Kivity wrote:

[repost with pull info, brain not yet back up to speed]

This is the current memory queue (posted as two separate series before
my vacation).  When applied, the overhead of 16 bytes/page is reduced to
basically nil.

Please pull from:

   git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/core



This seems to make things worse for me: I used to see a crash with kvm when 
using
a 64 bit BAR, now it crashes very early, and without kvm as well:

#0  0x75fc4155 in malloc_consolidate () from /lib64/libc.so.6


FWIW, I'm processing this PULL request right now and I'm seeing a SEGV too.  The 
backtrace is a malloc failure in QOM.


It's either this pull or Gerd's USB pull.  I'm debugging right now.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PULL] Memory core space reduction

2012-02-28 Thread Avi Kivity 
On 02/28/2012 08:13 PM, Anthony Liguori wrote:

 FWIW, I'm processing this PULL request right now and I'm seeing a SEGV
 too.  The backtrace is a malloc failure in QOM.


How do we reproduce this?

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PULL] Memory core space reduction

2012-02-28 Thread Anthony Liguori 

On 02/28/2012 12:15 PM, Avi Kivity wrote:

On 02/28/2012 08:13 PM, Anthony Liguori wrote:


FWIW, I'm processing this PULL request right now and I'm seeing a SEGV
too.  The backtrace is a malloc failure in QOM.



How do we reproduce this?


It looks like just repeatedly running QEMU with a -device option does it.

It's only about 10% reproducible for me.  I'm thinking it's a heap corruption.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PULL] Memory core space reduction

2012-02-28 Thread Anthony Liguori 

On 02/28/2012 12:15 PM, Avi Kivity wrote:

On 02/28/2012 08:13 PM, Anthony Liguori wrote:


FWIW, I'm processing this PULL request right now and I'm seeing a SEGV
too.  The backtrace is a malloc failure in QOM.



How do we reproduce this?


The guest never gets to run so I don't think the initrd/vmlinuz matter.

/home/anthony/build/qemu/x86_64-softmmu/qemu-system-x86_64 -kernel 
bin/vmlinuz-3.0 -initrd .tmp-11243/initramfs-11243.img.gz -append console=ttyS0 
seed=57279 -nographic -enable-kvm -hda /home/anthony/images/linux.img -M pc-1.0 
-drive file=/home/anthony/images/linux.img,if=virtio,snapshot=on -device 
virtio-balloon-pci -device virtio-serial -net nic,model=virtio -net user -snapshot


#0  0x7f031caf9b5d in malloc_consolidate (av=0x7f031ce111c0)
at malloc.c:5169
#1  0x7f031cafb472 in _int_malloc (av=0x7f031ce111c0, bytes=16512)
at malloc.c:4373
#2  0x7f031cafe31e in __libc_malloc (bytes=16512) at malloc.c:3660
#3  0x7f03202f47ae in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7f03202f4aba in g_malloc0 ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7f0320d23f62 in qmp_input_visitor_new (obj=0x7f03223afc50)
at /home/anthony/git/qemu/qapi/qmp-input-visitor.c:250
#6  0x7f0320d41469 in object_property_set_qobject (obj=0x7f0322337f00,
value=value optimized out, name=0x7f0320e844ed ioeventfd,
errp=0x7fff2beec7b0) at /home/anthony/git/qemu/qom/qom-qobject.c:23
#7  0x7f0320d404ee in object_property_set_bool (obj=0x7f0322337f00,
value=value optimized out, name=0x7f0320e844ed ioeventfd,
errp=0x7fff2beec7b0) at /home/anthony/git/qemu/qom/object.c:729
#8  0x7f0320d29496 in qdev_prop_set_defaults (dev=0x7f0322337f00,
props=0x7f03211f0d80) at /home/anthony/git/qemu/hw/qdev-properties.c:1101
#9  0x7f0320d3f52d in object_init_with_type (obj=0x7f0322337f00,
ti=0x7f03223130b0) at /home/anthony/git/qemu/qom/object.c:250
#10 0x7f0320d3f52d in object_init_with_type (obj=0x7f0322337f00,
ti=0x7f032230c7d0) at /home/anthony/git/qemu/qom/object.c:250
#11 0x7f0320d3f70d in object_new_with_type (type=0x7f032230c7d0)
at /home/anthony/git/qemu/qom/object.c:361
#12 0x7f0320d2adb8 in qdev_try_create (bus=0x7f0322341e10,
name=0x7f0320e7fa14 virtio-net-pci)
at /home/anthony/git/qemu/hw/qdev.c:123
#13 0x7f0320d2ae29 in qdev_create (bus=0x7f0322341e10,
name=0x7f0320e7fa14 virtio-net-pci)
at /home/anthony/git/qemu/hw/qdev.c:103
#14 0x7f0320cde89f in pci_create_multifunction (bus=value optimized out,
devfn=-1, multifunction=false, name=value optimized out)
at /home/anthony/git/qemu/hw/pci.c:1541
#15 0x7f0320cdea0a in pci_nic_init (nd=0x7f03219afc80,
default_model=value optimized out, default_devaddr=value optimized out)
at /home/anthony/git/qemu/hw/pci.c:1391
#16 0x7f0320cdeade in pci_nic_init_nofail (nd=0x7f03219afc80,
default_model=0x7f0320e79e67 e1000, default_devaddr=0x0)
at /home/anthony/git/qemu/hw/pci.c:1407
#17 0x7f0320df4ed4 in pc_init1 (system_memory=value optimized out,
system_io=0x7f0321c3, ram_size=134217728,
boot_device=0x7fff2beecd40 cad, kernel_filename=value optimized out,
kernel_cmdline=value optimized out,
initrd_filename=0x7f0321c2e370 .tmp-11243/initramfs-11243.img.gz,
cpu_model=0x0, pci_enabled=1, kvmclock_enabled=1)
at /home/anthony/git/qemu/hw/pc_piix.c:247
#18 0x7f0320df55a8 in pc_init_pci (ram_size=134217728,
boot_device=0x7fff2beecd40 cad,
kernel_filename=0x7f0321c2e2f0 bin/vmlinuz-3.0,
kernel_cmdline=0x7f0321c2e400 console=ttyS0 seed=57279,
initrd_filename=0x7f0321c2e370 .tmp-11243/initramfs-11243.img.gz,
cpu_model=value optimized out) at /home/anthony/git/qemu/hw/pc_piix.c:313
#19 0x7f0320d04b80 in main (argc=value optimized out,
argv=value optimized out, envp=value optimized out)
at /home/anthony/git/qemu/vl.c:3482

Regards,

Anthony Liguori

Re: [Qemu-devel] [PULL] Memory core space reduction

2012-02-28 Thread Anthony Liguori 

On 02/28/2012 12:15 PM, Avi Kivity wrote:

On 02/28/2012 08:13 PM, Anthony Liguori wrote:


FWIW, I'm processing this PULL request right now and I'm seeing a SEGV
too.  The backtrace is a malloc failure in QOM.



How do we reproduce this?


I don't trust this bisect completely, but here are the results:


 5f0e841a5c8c0bc0663e5582432eb788a3e0f9e3 is the first bad commit
commit 5f0e841a5c8c0bc0663e5582432eb788a3e0f9e3
Author: Avi Kivity a...@redhat.com
Date:   Sun Jan 8 19:46:17 2012 +0200

ioport: change portio_list not to use memory_region_set_offset()

memory_region_set_offset() will be going away soon, so don't use it.
Use an alias instead.

Signed-off-by: Avi Kivity a...@redhat.com
Reviewed-by: Richard Henderson r...@twiddle.net

:100644 100644 36fa3a477ebde72de4745bf4e13ad5146f4686fd 
505b252491d1d4e618a5059d75f3cb560a24c61f M	ioport.c
:100644 100644 ae3e9da0b5487e68a16f28c459889496160e8e16 
ab29c89fb3ac6bbe72b2b622172cb9ef7c462e62 M	ioport.h

bisect run success

Regards,

Anthony Liguori

Re: [Qemu-devel] [PULL] Memory core space reduction

2012-02-28 Thread Avi Kivity 
On 02/28/2012 09:14 PM, Anthony Liguori wrote:
 On 02/28/2012 12:15 PM, Avi Kivity wrote:
 On 02/28/2012 08:13 PM, Anthony Liguori wrote:

 FWIW, I'm processing this PULL request right now and I'm seeing a SEGV
 too.  The backtrace is a malloc failure in QOM.


 How do we reproduce this?

 I don't trust this bisect completely, but here are the results:


  5f0e841a5c8c0bc0663e5582432eb788a3e0f9e3 is the first bad commit
 commit 5f0e841a5c8c0bc0663e5582432eb788a3e0f9e3
 Author: Avi Kivity a...@redhat.com
 Date:   Sun Jan 8 19:46:17 2012 +0200

 ioport: change portio_list not to use memory_region_set_offset()

 memory_region_set_offset() will be going away soon, so don't use it.
 Use an alias instead.

 Signed-off-by: Avi Kivity a...@redhat.com
 Reviewed-by: Richard Henderson r...@twiddle.net

 :100644 100644 36fa3a477ebde72de4745bf4e13ad5146f4686fd
 505b252491d1d4e618a5059d75f3cb560a24c61f Mioport.c
 :100644 100644 ae3e9da0b5487e68a16f28c459889496160e8e16
 ab29c89fb3ac6bbe72b2b622172cb9ef7c462e62 Mioport.h
 bisect run success

That's the very first commit.  You'd get this result if either this was
the bad commit, of if the input to 'git bisect good' was also bad.  Can
you double-check this?

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PULL] Memory core space reduction

2012-02-28 Thread Anthony Liguori 

On 02/28/2012 01:17 PM, Avi Kivity wrote:

On 02/28/2012 09:14 PM, Anthony Liguori wrote:

On 02/28/2012 12:15 PM, Avi Kivity wrote:

On 02/28/2012 08:13 PM, Anthony Liguori wrote:


FWIW, I'm processing this PULL request right now and I'm seeing a SEGV
too.  The backtrace is a malloc failure in QOM.



How do we reproduce this?


I don't trust this bisect completely, but here are the results:


  5f0e841a5c8c0bc0663e5582432eb788a3e0f9e3 is the first bad commit
commit 5f0e841a5c8c0bc0663e5582432eb788a3e0f9e3
Author: Avi Kivitya...@redhat.com
Date:   Sun Jan 8 19:46:17 2012 +0200

 ioport: change portio_list not to use memory_region_set_offset()

 memory_region_set_offset() will be going away soon, so don't use it.
 Use an alias instead.

 Signed-off-by: Avi Kivitya...@redhat.com
 Reviewed-by: Richard Hendersonr...@twiddle.net

:100644 100644 36fa3a477ebde72de4745bf4e13ad5146f4686fd
505b252491d1d4e618a5059d75f3cb560a24c61f Mioport.c
:100644 100644 ae3e9da0b5487e68a16f28c459889496160e8e16
ab29c89fb3ac6bbe72b2b622172cb9ef7c462e62 Mioport.h
bisect run success


That's the very first commit.  You'd get this result if either this was
the bad commit, of if the input to 'git bisect good' was also bad.  Can
you double-check this?


Looks like it was a bad bisect :-(  I thought I had a 100% reproducible test 
case but it turned out not to be.


Regards,

Anthony Liguroi

Re: [Qemu-devel] [PULL] Memory core space reduction

2012-02-28 Thread Michael S. Tsirkin 
On Tue, Feb 28, 2012 at 01:20:47PM -0600, Anthony Liguori wrote:
 On 02/28/2012 01:17 PM, Avi Kivity wrote:
 On 02/28/2012 09:14 PM, Anthony Liguori wrote:
 On 02/28/2012 12:15 PM, Avi Kivity wrote:
 On 02/28/2012 08:13 PM, Anthony Liguori wrote:
 
 FWIW, I'm processing this PULL request right now and I'm seeing a SEGV
 too.  The backtrace is a malloc failure in QOM.
 
 
 How do we reproduce this?
 
 I don't trust this bisect completely, but here are the results:
 
 
   5f0e841a5c8c0bc0663e5582432eb788a3e0f9e3 is the first bad commit
 commit 5f0e841a5c8c0bc0663e5582432eb788a3e0f9e3
 Author: Avi Kivitya...@redhat.com
 Date:   Sun Jan 8 19:46:17 2012 +0200
 
  ioport: change portio_list not to use memory_region_set_offset()
 
  memory_region_set_offset() will be going away soon, so don't use it.
  Use an alias instead.
 
  Signed-off-by: Avi Kivitya...@redhat.com
  Reviewed-by: Richard Hendersonr...@twiddle.net
 
 :100644 100644 36fa3a477ebde72de4745bf4e13ad5146f4686fd
 505b252491d1d4e618a5059d75f3cb560a24c61f Mioport.c
 :100644 100644 ae3e9da0b5487e68a16f28c459889496160e8e16
 ab29c89fb3ac6bbe72b2b622172cb9ef7c462e62 Mioport.h
 bisect run success
 
 That's the very first commit.  You'd get this result if either this was
 the bad commit, of if the input to 'git bisect good' was also bad.  Can
 you double-check this?
 
 Looks like it was a bad bisect :-(  I thought I had a 100%
 reproducible test case but it turned out not to be.
 
 Regards,
 
 Anthony Liguroi
 
 


OK, here it reproduces without issues, so I did a bisect.
This is the 1st bad commit:

memory: allow phys_map tree paths to terminate early

When storing large contiguous ranges in phys_map, all values tend to
be the same pointers to a single MemoryRegionSection.  Collapse them
by marking nodes with level  0 as leaves.  This reduces tree memory
usage dramatically.

Signed-off-by: Avi Kivity a...@redhat.com


What I did, to allow bisect, is rebase Avi's patches on top
of my bridge implementation, then run qemu with a bridge.
bridge without Avi's patches at least starts booting, with
Avi's patches crashes before guest start.

If you want to play with that, take it from branch bisectme
on my qemu tree on github.

-- 
MST