* [Qemu-devel] [PULL] Memory core space reduction
@ 2012-02-28 12:24 Avi Kivity
0 siblings, 0 replies; 20+ messages in thread
From: Avi Kivity @ 2012-02-28 12:24 UTC (permalink / raw)
To: Anthony Liguori; +Cc: qemu-devel, Michael S. Tsirkin
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Qemu-devel] [PULL] Memory core space reduction
@ 2012-02-28 12:25 Avi Kivity
2012-02-28 12:26 ` Avi Kivity
2012-02-28 17:59 ` Michael S. Tsirkin
0 siblings, 2 replies; 20+ messages in thread
From: Avi Kivity @ 2012-02-28 12:25 UTC (permalink / raw)
To: Anthony Liguori; +Cc: qemu-devel, Michael S. Tsirkin
[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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] [PULL] Memory core space reduction
2012-02-28 12:25 Avi Kivity
@ 2012-02-28 12:26 ` Avi Kivity
2012-02-28 17:59 ` Michael S. Tsirkin
1 sibling, 0 replies; 20+ messages in thread
From: Avi Kivity @ 2012-02-28 12:26 UTC (permalink / raw)
To: Anthony Liguori; +Cc: qemu-devel, Michael S. Tsirkin
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] [PULL] Memory core space reduction
2012-02-28 12:25 Avi Kivity
2012-02-28 12:26 ` Avi Kivity
@ 2012-02-28 17:59 ` Michael S. Tsirkin
2012-02-28 18:13 ` Anthony Liguori
1 sibling, 1 reply; 20+ messages in thread
From: Michael S. Tsirkin @ 2012-02-28 17:59 UTC (permalink / raw)
To: Avi Kivity; +Cc: qemu-devel, Anthony Liguori
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>
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
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] [PULL] Memory core space reduction
2012-02-28 17:59 ` Michael S. Tsirkin
@ 2012-02-28 18:13 ` Anthony Liguori
2012-02-28 18:15 ` Avi Kivity
0 siblings, 1 reply; 20+ messages in thread
From: Anthony Liguori @ 2012-02-28 18:13 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Avi Kivity, qemu-devel
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] [PULL] Memory core space reduction
2012-02-28 18:13 ` Anthony Liguori
@ 2012-02-28 18:15 ` Avi Kivity
2012-02-28 18:31 ` Anthony Liguori
` (2 more replies)
0 siblings, 3 replies; 20+ messages in thread
From: Avi Kivity @ 2012-02-28 18:15 UTC (permalink / raw)
To: Anthony Liguori; +Cc: qemu-devel, Michael S. Tsirkin
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] [PULL] Memory core space reduction
2012-02-28 18:15 ` Avi Kivity
@ 2012-02-28 18:31 ` Anthony Liguori
2012-02-28 18:56 ` Anthony Liguori
2012-02-28 19:14 ` Anthony Liguori
2 siblings, 0 replies; 20+ messages in thread
From: Anthony Liguori @ 2012-02-28 18:31 UTC (permalink / raw)
To: Avi Kivity; +Cc: qemu-devel, Michael S. Tsirkin
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
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] [PULL] Memory core space reduction
2012-02-28 18:15 ` Avi Kivity
2012-02-28 18:31 ` Anthony Liguori
@ 2012-02-28 18:56 ` Anthony Liguori
2012-02-28 19:14 ` Anthony Liguori
2 siblings, 0 replies; 20+ messages in thread
From: Anthony Liguori @ 2012-02-28 18:56 UTC (permalink / raw)
To: Avi Kivity; +Cc: qemu-devel, Michael S. Tsirkin
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] [PULL] Memory core space reduction
2012-02-28 18:15 ` Avi Kivity
2012-02-28 18:31 ` Anthony Liguori
2012-02-28 18:56 ` Anthony Liguori
@ 2012-02-28 19:14 ` Anthony Liguori
2012-02-28 19:17 ` Avi Kivity
2 siblings, 1 reply; 20+ messages in thread
From: Anthony Liguori @ 2012-02-28 19:14 UTC (permalink / raw)
To: Avi Kivity; +Cc: qemu-devel, Michael S. Tsirkin
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] [PULL] Memory core space reduction
2012-02-28 19:14 ` Anthony Liguori
@ 2012-02-28 19:17 ` Avi Kivity
2012-02-28 19:20 ` Anthony Liguori
0 siblings, 1 reply; 20+ messages in thread
From: Avi Kivity @ 2012-02-28 19:17 UTC (permalink / raw)
To: Anthony Liguori; +Cc: qemu-devel, Michael S. Tsirkin
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?
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] [PULL] Memory core space reduction
2012-02-28 19:17 ` Avi Kivity
@ 2012-02-28 19:20 ` Anthony Liguori
2012-02-28 22:58 ` Michael S. Tsirkin
0 siblings, 1 reply; 20+ messages in thread
From: Anthony Liguori @ 2012-02-28 19:20 UTC (permalink / raw)
To: Avi Kivity; +Cc: qemu-devel, Michael S. Tsirkin
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] [PULL] Memory core space reduction
2012-02-28 19:20 ` Anthony Liguori
@ 2012-02-28 22:58 ` Michael S. Tsirkin
2012-02-29 10:09 ` Avi Kivity
0 siblings, 1 reply; 20+ messages in thread
From: Michael S. Tsirkin @ 2012-02-28 22:58 UTC (permalink / raw)
To: Anthony Liguori; +Cc: Avi Kivity, qemu-devel
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.
--
MST
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] [PULL] Memory core space reduction
2012-02-28 22:58 ` Michael S. Tsirkin
@ 2012-02-29 10:09 ` Avi Kivity
2012-02-29 10:23 ` Michael S. Tsirkin
0 siblings, 1 reply; 20+ messages in thread
From: Avi Kivity @ 2012-02-29 10:09 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: qemu-devel, Anthony Liguori
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] [PULL] Memory core space reduction
2012-02-29 10:09 ` Avi Kivity
@ 2012-02-29 10:23 ` Michael S. Tsirkin
2012-02-29 10:53 ` Avi Kivity
0 siblings, 1 reply; 20+ messages in thread
From: Michael S. Tsirkin @ 2012-02-29 10:23 UTC (permalink / raw)
To: Avi Kivity; +Cc: qemu-devel, Anthony Liguori
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] [PULL] Memory core space reduction
2012-02-29 10:23 ` Michael S. Tsirkin
@ 2012-02-29 10:53 ` Avi Kivity
2012-02-29 11:25 ` Michael S. Tsirkin
2012-02-29 11:27 ` Avi Kivity
0 siblings, 2 replies; 20+ messages in thread
From: Avi Kivity @ 2012-02-29 10:53 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: qemu-devel, Anthony Liguori
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] [PULL] Memory core space reduction
2012-02-29 10:53 ` Avi Kivity
@ 2012-02-29 11:25 ` Michael S. Tsirkin
2012-02-29 11:31 ` Avi Kivity
2012-02-29 11:27 ` Avi Kivity
1 sibling, 1 reply; 20+ messages in thread
From: Michael S. Tsirkin @ 2012-02-29 11:25 UTC (permalink / raw)
To: Avi Kivity; +Cc: qemu-devel, Anthony Liguori
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] [PULL] Memory core space reduction
2012-02-29 10:53 ` Avi Kivity
2012-02-29 11:25 ` Michael S. Tsirkin
@ 2012-02-29 11:27 ` Avi Kivity
1 sibling, 0 replies; 20+ messages in thread
From: Avi Kivity @ 2012-02-29 11:27 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: qemu-devel, Anthony Liguori
[-- Attachment #1: Type: text/plain, Size: 210 bytes --]
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
[-- Attachment #2: 0001-kvm-fix-unaligned-slots.patch --]
[-- Type: text/x-patch, Size: 1887 bytes --]
>From 4fa865c7086e2f287c91f4372df6eb5ddf40a48c Mon Sep 17 00:00:00 2001
From: Avi Kivity <avi@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 <avi@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
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] [PULL] Memory core space reduction
2012-02-29 11:25 ` Michael S. Tsirkin
@ 2012-02-29 11:31 ` Avi Kivity
2012-02-29 11:45 ` Avi Kivity
0 siblings, 1 reply; 20+ messages in thread
From: Avi Kivity @ 2012-02-29 11:31 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: qemu-devel, Anthony Liguori
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] [PULL] Memory core space reduction
2012-02-29 11:31 ` Avi Kivity
@ 2012-02-29 11:45 ` Avi Kivity
2012-02-29 14:15 ` Michael S. Tsirkin
0 siblings, 1 reply; 20+ messages in thread
From: Avi Kivity @ 2012-02-29 11:45 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: qemu-devel, Anthony Liguori
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] [PULL] Memory core space reduction
2012-02-29 11:45 ` Avi Kivity
@ 2012-02-29 14:15 ` Michael S. Tsirkin
0 siblings, 0 replies; 20+ messages in thread
From: Michael S. Tsirkin @ 2012-02-29 14:15 UTC (permalink / raw)
To: Avi Kivity; +Cc: qemu-devel, Anthony Liguori
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
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2012-02-29 14:15 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-02-28 12:24 [Qemu-devel] [PULL] Memory core space reduction Avi Kivity
-- strict thread matches above, loose matches on Subject: below --
2012-02-28 12:25 Avi Kivity
2012-02-28 12:26 ` Avi Kivity
2012-02-28 17:59 ` Michael S. Tsirkin
2012-02-28 18:13 ` Anthony Liguori
2012-02-28 18:15 ` Avi Kivity
2012-02-28 18:31 ` Anthony Liguori
2012-02-28 18:56 ` Anthony Liguori
2012-02-28 19:14 ` Anthony Liguori
2012-02-28 19:17 ` Avi Kivity
2012-02-28 19:20 ` Anthony Liguori
2012-02-28 22:58 ` Michael S. Tsirkin
2012-02-29 10:09 ` Avi Kivity
2012-02-29 10:23 ` Michael S. Tsirkin
2012-02-29 10:53 ` Avi Kivity
2012-02-29 11:25 ` Michael S. Tsirkin
2012-02-29 11:31 ` Avi Kivity
2012-02-29 11:45 ` Avi Kivity
2012-02-29 14:15 ` Michael S. Tsirkin
2012-02-29 11:27 ` Avi Kivity
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).