qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [Qemu-devel] [PATCH v2] register reset handler to write i


From: Alexander Graf
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH v2] register reset handler to write image into memory
Date: Thu, 20 Sep 2012 14:09:52 +0200

On 23.08.2012, at 13:38, Andreas Färber wrote:

> Hi,
> 
> Am 23.08.2012 11:45, schrieb Yin Olivia-R63875:
>> Dear All,
>> 
>> I can't find MAINTAINER of hw/loader.c.
>> Who can help review and apply this patch?
> 
> This patch is not a small bugfix so it won't be applied during the v1.2
> Hard Freeze. You based it onto ppc-next so the obvious answer is, Alex
> needs to review it, whom you forgot to cc.
> 
> 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?

The fundamental problem is the memory footprint. We only need ROM blobs on 
reset, where they get copied into guest RAM. That means during the lifetime of 
the VM, we waste host memory for no good reason. Imagine a guest that runs with 
-kernel and -initrd, each 10MB in size. Then that VM wastes 20MB of precious 
host memory.

Eventually, I don't think we will need the full-blown rom interface with 
in-memory rom blobs anymore. Everything should be constructed on demand during 
reset.

However, if you look at code like the s390 initialization, some users of the 
rom interface expect changes done once to be persistent. These will have to be 
rewritten to redo their changes on reset.

So Olivia, please do the following:

  - Make sure that _no_ persistent rom code is left over eventually. This also 
means that you need to convert ELF.
  - Go through every user of rom_ptr and write the code differently. For now, 
probably by just registering a reset handler that overwrites the respective 
memory location on every reset, rather than modify the rom blob.


Alex




reply via email to

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