[SeaBIOS] Why drive_s is allocated from f-segment?

[Gleb Natapov]

On Thu, Apr 12, 2012 at 08:42:25AM -0400, Kevin O'Connor wrote:
> On Thu, Apr 12, 2012 at 08:11:13AM +0300, Gleb Natapov wrote:
> > On Wed, Apr 11, 2012 at 08:34:13PM -0400, Kevin O'Connor wrote:
> > > On Wed, Apr 11, 2012 at 04:27:57PM +0300, Gleb Natapov wrote:
> > > > Hi Kevin,
> > > > 
> > > > Is there a reason why drive_s structures are allocated from f-segment?
> > > 
> > > The data is accessed from 16bit mode, so it must be in the first meg.
> > > Only malloc_low() and malloc_fseg() provide data in this range.
> > > Putting it in the f-segment has the advantage of not taking space away
> > > from the OS (malloc_low uses the 9-segment) and the code generated
> > > from f-segment accesses is slightly better (it can use %cs).
> > > 
> > Each virtio disk allocates huge VQ from low memory. Allocating relatively
> > small drive_s should not take much additional memory. Besides OS has
> > enough memory as is. Some OSes do not use low memory at all since many
> > buggy bioses write there during SMM or resume.
> 
> Yes - but it's not nice for older OSs.  One of things I'd like to do
> is move malloc_low allocations from the 9-segment to the e-segment.
> Then the code can allocate what ever it wishes.
> 
> > > > The space for f-segment allocations are barely sufficient for bios
> > > > tables.
> > > 
> > > There's plenty of space in the f-segment.  All the 32bit init code
> > > that is relocated is given back to malloc_fseg - that's typically
> > > about 20k.
> > But f-seg allocation does not take advantage of that space.
> 
> It does use it - see addSpace() call in pmm.c:malloc_fixupreloc().
> 
> >It uses only
> > CONFIG_MAX_BIOSTABLE bytes which is 2048 currently. Is it OK to grow
> > this?
> 
> It could be increased, but I don't see why it would need to.
> 
For the problem I described below, but you are saying it is already
fixed in upstream.

> > >            Also, most of the bios tables are placed in high memory
> > > (malloc_high).
> > > 
> > The problem is with MPC table which has to be in low memory for older
> > Linux kernel and it has entry for each socket. When people use large smp
> > values boot starts to fail since bios can't init desks.
> 
> This should have been fixed in SeaBIOS commit 8b9137d29 (which was in
> v1.6.3).  There's plenty of space for the mptable now.
> 
Ah, I think I checked with rhel6 seabios which does not have this
commit. I'll recheck with upstream seabios.

> It may be worthwhile to put a cap on the size of the mptable in the
> f-segment - do something similar to what's currently done for smbios -
> if the mptable size is greater than some size then put it in high
> memory.  This should work on the premise that anyone using a setup
> sophisticated enough to require a very large mptable will likely have
> a recent Linux kernel.
> 
I wouldn't trust people on this :)

--
			Gleb.