qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] register reset handler to write image into m


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH v2] register reset handler to write image into memory
Date: Sun, 26 Aug 2012 23:16:34 -0700


On 26.08.2012, at 20:50, Yin Olivia-R63875 <address@hidden> wrote:

> Thanks to Dunrong and Andreas.
> 
> $ scripts/get_maintainer.pl -f hw/loader.c
> Alexander Graf <address@hidden> (commit_signer:3/6=50%)
> Anthony Liguori <address@hidden> (commit_signer:2/6=33%)
> Stefan Weil <address@hidden> (commit_signer:1/6=17%)
> Benjamin Herrenschmidt <address@hidden> (commit_signer:1/6=17%)
> Avi Kivity <address@hidden> (commit_signer:1/6=17%)
> 
> Dear maintainers,
> Could you please help review this patch?
> 
> So far I got feedback from Andreas and try to answer the question.
> 
>> This patch does not answer the question why you try to avoid the ROM blobs
>> and what ROM blobs are still being used for after your patch. I don't 
>> think it makes much sense to work around them for your use cases and to 
>> leave them behind - if there's something fundamentally wrong with them 
>> they should be ripped out completely or fixed. But maybe I'm 
>> misunderstanding 
>> in the absence of explanations?
> 
> It's a general problem. 
> 
> For example, in my case, there're 3 different files loaded from host rootfs.
> $ qemu-system-ppc -enable-kvm -m 256 -nographic -M mpc8544ds -kernel 
> uImage.8572.agraf -initrd /media/ram/guest-8572.rootfs.ext2.gz -append 
> "root=/dev/ram rw loglevel=7 console=ttyS0,115200" -serial tcp::4445,server 
> -net nic
> 
> (qemu) info roms
> addr=0000000000000000 size=0x782840 mem=ram name="uImage.8572.agraf"
> addr=0000000000c00000 size=0x010000 mem=ram name="mpc8544ds.dtb"
> addr=0000000002000000 size=0x3f922f mem=ram 
> name="/media/ram/guest-8572.rootfs.ext2.gz"
> 
> The problem is that rom_add_*() mallocs memory for the image, and then 
> rom_reset()
> copies those images into the guest's memory, but the QEMU memory does not get 
> freed.
> On a VM reset, the images get recopied from QEMU to guest.
> 
> Comparing the memory map of qemu process before and after starting up guest,
> we can find that QEMU consumes much memory for those images.
> 
> $ diff -urN pmap.pre.log pmap.post.log
> --- pmap.pre.log
> +++ pmap.post.log
> @@ -33,7 +33,14 @@
> 0ffee000      8K rwx--  /lib/ld-2.13.so
> 10000000   3472K r-x--  qemu-system-ppc
> 10374000    112K rwx--  qemu-system-ppc
> -10390000   6524K rwx--    [ anon ]
> +10390000   7100K rwx--    [ anon ]
> 48002000     16K rw---    [ anon ]
> +48006000      4K -----    [ anon ]
> +48007000   8188K rw---    [ anon ]
> +48806000      8K rw-s-    [ anon ]
> +48808000      4K rw---    [ anon ]
> +48809000 262144K rw---    [ anon ]
> +58809000   5280K rw---    [ anon ]
> +5cb98000   7692K rw---    [ anon ]
> bf93e000    132K rw---    [ stack ]
> - total    14456K
> + total   298352K
> 
> Exactly we can re-load them from disk on a reset instead of holding onto the 
> images in QEMU's memory.
> 
> With this patch, the two big images (uImage and especially initrd) will not 
> be loaded into QEMU's memory
> (qemu) info roms
> addr=0000000000c00000 size=0x010000 mem=ram name="mpc8544ds.dtb"
> 
> It will save much memory space according to memory map of QEMU process.
> # diff -urN pmap.pre.log pmap.post.log
> --- pmap.pre.log
> +++ pmap.post.log
> @@ -33,7 +33,14 @@
> 0ffee000      8K rwx--  /lib/ld-2.13.so
> 10000000   3472K r-x--  qemu-system-ppc
> 10374000    112K rwx--  qemu-system-ppc
> -10390000   6524K rwx--    [ anon ]
> +10390000   7036K rwx--    [ anon ]
> 48002000     16K rw---    [ anon ]
> +48006000      4K -----    [ anon ]
> +48007000   8188K rw---    [ anon ]
> +48806000      8K rw-s-    [ anon ]
> +48808000      4K rw---    [ anon ]
> +48809000 262144K rw---    [ anon ]
> +58809000      4K rw---    [ anon ]
> +58c04000   1204K rw---    [ anon ]
> bfb2a000    132K rw---    [ stack ]
> - total    14456K
> + total   286524K
> 
> This patch changes all the image load process called by load_uimage() and 
> load_image_targphys() in platform initialization.

This doesn't explain why you leave the old in-RAM code alive though. The only 
reason I can imagine would be to allow for reset to not reload new roms after 
an update.

Anthony, any opinion here? Do we need the keep-in-RAM rom code? Or could we 
just always load rom blobs on demand for everything?


Alex

> 
> Best Regards,
> Olivia
> 
>> -----Original Message-----
>> From: Dunrong Huang [mailto:address@hidden
>> Sent: Thursday, August 23, 2012 6:44 PM
>> To: Yin Olivia-R63875
>> Cc: address@hidden; address@hidden
>> Subject: Re: [Qemu-devel] [PATCH v2] register reset handler to write
>> image into memory
>> 
>> 2012/8/23 Yin Olivia-R63875 <address@hidden>:
>>> Dear All,
>>> 
>>> I can't find MAINTAINER of hw/loader.c.
>>> Who can help review and apply this patch?
>>> 
>> Please use the script scripts/get_maintainer.pl, like:
>> $ scripts/get_maintainer.pl your_patch_file.patch or
>> $ scripts/get_maintainer.pl -f hw/loader.c
>>> Best Regards,
>>> Olivia Yin
>>> 
>> 
>> 
>> --
>> Best Regards,
>> 
>> Dunrong Huang
> 
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]