On Wed, Mar 3, 2010 at 3:38 PM, Khaled Ibrahim <[email protected]> wrote: > > > > ---------------------------------------- >> Date: Wed, 3 Mar 2010 15:09:17 -0700 >> Subject: Re: IVSHMEM and limits on shared memory >> From: [email protected] >> To: [email protected] >> CC: [email protected] >> >> On Wed, Mar 3, 2010 at 12:06 AM, Khaled Ibrahim wrote: >>> >>> Hi Cam, >>> >>> I used your patches successfully to support shared memory on KVM and >>> used the test cases successfully, but qemu-kvm crashes when I increased the >>> size of the shared memory. I >>> applied the ivshmem patch to qemu-kvm-0.12.3 (some manual patching was >>> needed). It worked flawlessly for >>> up to 128MB of shared memory on my system. I am running on a machine with >>> 64GB >>> memory running opensuse (kernel 2.6.27) on AMD opteron. >>> >>> Qemu crashes with >>> smp=4 and the shared memory requested in 256MB, (512MB with smp=1), even >>> though >>> the shared memory file is created. I debugged the problem and it seems that >>> some memory corruptions happens. >> >> Can you please provide the full command-line for the smp=1 instance? > > qemu-system-x86_64 ./qemudisk0.raw \ -net > nic,model=rtl8139,macaddr=52:54:00:12:34:50\ -net > tap,ifname=tap0,script=no,downscript=no \ -m 4096 \ -ivshmem > 512,kvmshmem\ -smp 1 \ -usb \ -usbdevice tablet > \ -localtime > > >> >>> >>> It crashes in the subpage_register for rtl8139 pci driver!, >>> tracked back to rtl8139_mmio_map. The problem starts with corrupted value in >>> the config field in the struct for the rtl8139 driver. At offset 20 of this >>> field the address should indicate that the address is uninitialized at that >>> time of crash, but surprisingly the value changes over the course of >>> execution >>> and gets the SIZE of the shared memory allocated (related to ivshmem). I >>> failed >>> to identify what changes/corrupts that field. I tried some padding for >>> allocation but the field always gets updated with the size of the shared >>> memory >>> in a very consistent way.
Good debugging. I've been able to reproduce your error when applying my patch to qemu-kvm-0.12.3 and can trace the error to the subpage_register. Curiously, this bug does not occur with the latest version from the git repo. I've tested up to 1 GB without problem. So I'm not sure if it's an error in my patch or elsewhere in the memory management that has since been fixed. As a test, I removed anywhere my patch stored the size of the shared memory region and hard coded the size of 512 MB into qemu_ram_alloc and pci_register_bar, so that my patch never writes the size of the memory region anywhere. And I discovered that the value of 512MB still shows up at the offset you mention, so it seems something else is storing that value in the wrong location and corrupting memory. Can you try using the version from the git repo and see if the error recurs? Cam >>> >> >> As far as you know does anything in the guest trigger the corruption? >> Does the corruption happen immediately or after running some of the >> test programs? > > The boot process does not complete, and it fails before it reach grub. > _________________________________________________________________ > Hotmail: Trusted email with Microsoft’s powerful SPAM protection. > http://clk.atdmt.com/GBL/go/201469226/direct/01/ > > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
