qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resiz


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize
Date: Wed, 19 Nov 2014 15:53:25 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

* Michael S. Tsirkin (address@hidden) wrote:
> On Wed, Nov 19, 2014 at 02:59:12PM +0000, Dr. David Alan Gilbert wrote:
> > * Paolo Bonzini (address@hidden) wrote:
> > > 
> > > 
> > > On 19/11/2014 15:26, Dr. David Alan Gilbert wrote:
> > > > * Paolo Bonzini (address@hidden) wrote:
> > > >>
> > > >>
> > > >> On 19/11/2014 15:13, Dr. David Alan Gilbert wrote:
> > > >>> Since we've wondered off the actual ACPI table stuff into general
> > > >>> ROM sizing, I'd like to propose some concrete fixes:
> > > >>>
> > > >>>   1) We explicitly name the bios file in a .romfile attribute for
> > > >>>      all ROMs.
> > > >>>   2) The code that uses .romfile has an expansion for $MACHINETYPE
> > > >>>   3) We actually symlink all of those together, anyone who wants/has
> > > >>>      to deal with different versions can downstream.
> > > >>>   4) The machine types contain size attributes for the ROMs that
> > > >>>      are generoously larger than the ROMs anyone currently uses.
> > > >>>
> > > >>> I think 1..3 should deal with those of us who have to deal with 
> > > >>> different
> > > >>> ROM versions on different machine types.
> > > >>
> > > >> It should, but it's a solution in search of a problem.
> > > > 
> > > > Well we already do something close to 1 & 2 downstream but more ad-hoc;
> > > > it's just a generalisation (and 4 from padding the size of our images).
> > > > So we already had that problem.
> > > 
> > > Upstream too.  See pxe-* vs. efi-* NIC option ROMs.  The latter includes
> > > both PXE firmware for BIOS and EFI drivers.  We keep two copies because
> > > they have different sizes.  Having explicit expansions for $MACHINETYPE
> > > would be hugely overkill, in my opinion.
> > 
> > Yes it is, but it's simple and feels easy to understand.
> > 
> > Dave
> 
> I feel it's an implementation detail that really shouldn't
> be pushed out to users.

Define 'users' - I don't see that it's being pushed anywhere except giving
the ROM packagers control to make sure they supply the right thing.
The end user of qemu doesn't have to worry about it.

Dave

> 
> 
> > > 
> > > Paolo
> > > 
> > > >>
> > > >>> 4 might be good enough for the ACPI tables if you can bound it.
> > > >>
> > > >> Already doing that (rounding to 128k, warning if >64k), but it is not a
> > > >> definitive solution.
> > > >>
> > > >> We also do (4) for ROMs, since VGA BIOSes use only 36k out of 64k and
> > > >> iPXE ROMs use only ~200k out of 256k.
> > > >>
> > > >> Paolo
> > > > --
> > > > Dr. David Alan Gilbert / address@hidden / Manchester, UK
> > > > 
> > --
> > Dr. David Alan Gilbert / address@hidden / Manchester, UK
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

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