qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v5 02/10] linker-loader: Add new 'write pointer'


From: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH v5 02/10] linker-loader: Add new 'write pointer' command
Date: Tue, 7 Feb 2017 13:11:43 +0100

On Mon, 6 Feb 2017 19:31:24 +0200
"Michael S. Tsirkin" <address@hidden> wrote:

> On Mon, Feb 06, 2017 at 09:16:25AM -0800, Ben Warren wrote:
> > >> @@ -257,8 +263,11 @@ void bios_linker_loader_add_pointer(BIOSLinker 
> > >> *linker,
> > >>     const BiosLinkerFileEntry *source_file =
> > >>         bios_linker_find_file(linker, src_file);
> > >> 
> > >> -    assert(dst_patched_offset < dst_file->blob->len);
> > >> -    assert(dst_patched_offset + dst_patched_size <= 
> > >> dst_file->blob->len);
> > >> +    /* dst_file need not exist if writing back */  
> > > 
> > > Why not?  
> > Because WRITE_POINTER can be called without having first called
> > ALLOCATE.  In the Vm Generation ID example, there’s no reason for BIOS
> > to allocate memory for the address fw_cfg, since it’s a construct that
> > only matters to QEMU.  This is something that was requested by Laszlo.  
> 
> Well all other commands require you to first allocate.
> How does bios know e.g. which zone to put it in then?
There is no need to know which zone to put it in as file
is writeback only, i.e. there is no need to allocate
RAM for file (shadow it) which won't be read by guest side ever
if I got idea right.
Issue in the patch is combining new command with existing API
bios_linker_loader_add_pointer(),
as you suggested new API function + good description what it does
would be better than reusing.


> 
> I don't like the asymmetry ... Laszlo? 




reply via email to

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