Patchwork [PULL] Memory core space reduction

login
register
mail settings
Submitter Michael S. Tsirkin
Date Feb. 28, 2012, 5:59 p.m.
Message ID <20120228175914.GA28479@redhat.com>
Download mbox | patch
Permalink /patch/143521/
State New
Headers show

Comments

Michael S. Tsirkin - Feb. 28, 2012, 5:59 p.m.
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  0x00007ffff5fc4155 in malloc_consolidate () from /lib64/libc.so.6
#1  0x00007ffff5fc71c2 in _int_malloc () from /lib64/libc.so.6
#2  0x00007ffff5fc85ed in malloc () from /lib64/libc.so.6
#3  0x00007ffff7e00496 in malloc_and_trace (n_bytes=8392) at /home/mst/scm/qemu/vl.c:2156
#4  0x00007ffff73e834e in ?? () from /lib64/libglib-2.0.so.0
#5  0x00007ffff73e8708 in g_malloc0 () from /lib64/libglib-2.0.so.0
#6  0x00007ffff7e88d52 in subpage_init (section=0x7fffffffd9a0) at /home/mst/scm/qemu/exec.c:3483
#7  register_subpage (section=0x7fffffffd9a0) at /home/mst/scm/qemu/exec.c:2643
#8  0x00007ffff7e88fa6 in cpu_register_physical_memory_log (section=<value optimized out>, 
    readonly=<value optimized out>) at /home/mst/scm/qemu/exec.c:2680
#9  0x00007ffff7eb2d68 in address_space_update_topology_pass (as=0x7ffff8ae4b80, old_view=..., new_view=..., adding=
    true) at /home/mst/scm/qemu/memory.c:679
#10 0x00007ffff7eb4c66 in address_space_update_topology (as=0x7ffff8ae4b80) at /home/mst/scm/qemu/memory.c:708
#11 0x00007ffff7eb5444 in memory_region_update_topology (mr=<value optimized out>) at /home/mst/scm/qemu/memory.c:729
#12 0x00007ffff7dc98d7 in bmdma_setup_bar (dev=0x7ffff8d52500) at /home/mst/scm/qemu/hw/ide/piix.c:97
#13 pci_piix_ide_initfn (dev=0x7ffff8d52500) at /home/mst/scm/qemu/hw/ide/piix.c:157
#14 0x00007ffff7dd998e in pci_qdev_init (qdev=0x7ffff8d52500) at /home/mst/scm/qemu/hw/pci.c:1492
#15 0x00007ffff7e277ba in qdev_init (dev=0x7ffff8d52500) at /home/mst/scm/qemu/hw/qdev.c:150
#16 0x00007ffff7e2789d in qdev_init_nofail (dev=0x7ffff8d52500) at /home/mst/scm/qemu/hw/qdev.c:243
#17 0x00007ffff7dd8d88 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 0x00007ffff7dc9c2f in pci_piix3_ide_init (bus=<value optimized out>, hd_table=0x7fffffffdfd0, 
    devfn=<value optimized out>) at /home/mst/scm/qemu/hw/ide/piix.c:224
#19 0x00007ffff7eeafb7 in pc_init1 (system_memory=0x7ffff8d0e6c0, system_io=0x7ffff8b61d40, ram_size=1073741824, 
    boot_device=0x7fffffffe320 "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 0x00007ffff7eeb368 in pc_init_pci (ram_size=1073741824, boot_device=0x7fffffffe320 "cad", kernel_filename=0x0, 
    kernel_cmdline=0x7ffff7f669e5 "", initrd_filename=0x0, cpu_model=<value optimized out>)
    at /home/mst/scm/qemu/hw/pc_piix.c:319
#21 0x00007ffff7e01fb8 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 <mst@redhat.com>
Anthony Liguori - Feb. 28, 2012, 6:13 p.m.
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  0x00007ffff5fc4155 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
Avi Kivity - Feb. 28, 2012, 6:15 p.m.
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?
Anthony Liguori - Feb. 28, 2012, 6:31 p.m.
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

>
Anthony Liguori - Feb. 28, 2012, 6:56 p.m.
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  0x00007f031caf9b5d in malloc_consolidate (av=0x7f031ce111c0)
     at malloc.c:5169
#1  0x00007f031cafb472 in _int_malloc (av=0x7f031ce111c0, bytes=16512)
     at malloc.c:4373
#2  0x00007f031cafe31e in __libc_malloc (bytes=16512) at malloc.c:3660
#3  0x00007f03202f47ae in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007f03202f4aba in g_malloc0 ()
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007f0320d23f62 in qmp_input_visitor_new (obj=0x7f03223afc50)
     at /home/anthony/git/qemu/qapi/qmp-input-visitor.c:250
#6  0x00007f0320d41469 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  0x00007f0320d404ee 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  0x00007f0320d29496 in qdev_prop_set_defaults (dev=0x7f0322337f00,
     props=0x7f03211f0d80) at /home/anthony/git/qemu/hw/qdev-properties.c:1101
#9  0x00007f0320d3f52d in object_init_with_type (obj=0x7f0322337f00,
     ti=0x7f03223130b0) at /home/anthony/git/qemu/qom/object.c:250
#10 0x00007f0320d3f52d in object_init_with_type (obj=0x7f0322337f00,
     ti=0x7f032230c7d0) at /home/anthony/git/qemu/qom/object.c:250
#11 0x00007f0320d3f70d in object_new_with_type (type=0x7f032230c7d0)
     at /home/anthony/git/qemu/qom/object.c:361
#12 0x00007f0320d2adb8 in qdev_try_create (bus=0x7f0322341e10,
     name=0x7f0320e7fa14 "virtio-net-pci")
     at /home/anthony/git/qemu/hw/qdev.c:123
#13 0x00007f0320d2ae29 in qdev_create (bus=0x7f0322341e10,
     name=0x7f0320e7fa14 "virtio-net-pci")
     at /home/anthony/git/qemu/hw/qdev.c:103
#14 0x00007f0320cde89f 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 0x00007f0320cdea0a 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 0x00007f0320cdeade in pci_nic_init_nofail (nd=0x7f03219afc80,
     default_model=0x7f0320e79e67 "e1000", default_devaddr=0x0)
     at /home/anthony/git/qemu/hw/pci.c:1407
#17 0x00007f0320df4ed4 in pc_init1 (system_memory=<value optimized out>,
     system_io=0x7f0321c30000, 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 0x00007f0320df55a8 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 0x00007f0320d04b80 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
Anthony Liguori - Feb. 28, 2012, 7:14 p.m.
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 <avi@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 <avi@redhat.com>
     Reviewed-by: Richard Henderson <rth@twiddle.net>

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

Regards,

Anthony Liguori
Avi Kivity - Feb. 28, 2012, 7:17 p.m.
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 <avi@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 <avi@redhat.com>
>     Reviewed-by: Richard Henderson <rth@twiddle.net>
>
> :100644 100644 36fa3a477ebde72de4745bf4e13ad5146f4686fd
> 505b252491d1d4e618a5059d75f3cb560a24c61f M    ioport.c
> :100644 100644 ae3e9da0b5487e68a16f28c459889496160e8e16
> ab29c89fb3ac6bbe72b2b622172cb9ef7c462e62 M    ioport.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?
Anthony Liguori - Feb. 28, 2012, 7:20 p.m.
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 Kivity<avi@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<avi@redhat.com>
>>      Reviewed-by: Richard Henderson<rth@twiddle.net>
>>
>> :100644 100644 36fa3a477ebde72de4745bf4e13ad5146f4686fd
>> 505b252491d1d4e618a5059d75f3cb560a24c61f M    ioport.c
>> :100644 100644 ae3e9da0b5487e68a16f28c459889496160e8e16
>> ab29c89fb3ac6bbe72b2b622172cb9ef7c462e62 M    ioport.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
Michael S. Tsirkin - Feb. 28, 2012, 10:58 p.m.
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 Kivity<avi@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<avi@redhat.com>
> >>     Reviewed-by: Richard Henderson<rth@twiddle.net>
> >>
> >>:100644 100644 36fa3a477ebde72de4745bf4e13ad5146f4686fd
> >>505b252491d1d4e618a5059d75f3cb560a24c61f M    ioport.c
> >>:100644 100644 ae3e9da0b5487e68a16f28c459889496160e8e16
> >>ab29c89fb3ac6bbe72b2b622172cb9ef7c462e62 M    ioport.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 <avi@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.
Avi Kivity - Feb. 29, 2012, 10:09 a.m.
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.
Michael S. Tsirkin - Feb. 29, 2012, 10:23 a.m.
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
Avi Kivity - Feb. 29, 2012, 10:53 a.m.
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.
Michael S. Tsirkin - Feb. 29, 2012, 11:25 a.m.
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: portio_list_add_1 (ioport.c:379)
==9202==    by 0x2169EF: pci_piix_ide_initfn (piix.c:137)
==9202==    by 0x2269DD: pci_qdev_init (pci.c:1492)
==9202==    by 0x274839: qdev_init (qdev.c:150)
==9202==    by 0x27491C: qdev_init_nofail (qdev.c:243)
==9202==    by 0x225DD7: pci_create_simple_multifunction (pci.c:1552)
==9202==    by 0x216C7E: pci_piix3_ide_init (piix.c:224)
==9202==    by 0x338036: pc_init1 (pc_piix.c:257)
==9202==    by 0x3383E7: pc_init_pci (pc_piix.c:319)
==9202==    by 0x24EFE7: main (vl.c:3397)
==9202==  Address 0x28fc30a8 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 0x2169EF: pci_piix_ide_initfn (piix.c:137)
==9202==    by 0x2269DD: pci_qdev_init (pci.c:1492)
==9202==    by 0x274839: qdev_init (qdev.c:150)
==9202==    by 0x27491C: qdev_init_nofail (qdev.c:243)
==9202==    by 0x225DD7: pci_create_simple_multifunction (pci.c:1552)
==9202==    by 0x216C7E: pci_piix3_ide_init (piix.c:224)
==9202== 
=

Investigating.

> -- 
> error compiling committee.c: too many arguments to function
Avi Kivity - Feb. 29, 2012, 11:31 a.m.
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.
Avi Kivity - Feb. 29, 2012, 11:45 a.m.
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.
Michael S. Tsirkin - Feb. 29, 2012, 2:15 p.m.
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

Patch

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: