On Fri, Jul 07, 2017 at 04:14:01PM +0200, Paolo Bonzini wrote: > > > On 21/06/2017 00:44, Kevin O'Connor wrote: > > On Tue, Jun 20, 2017 at 04:05:32PM -0400, Paolo Bonzini wrote: > >>> If virtio-scsi didn't need to allocate any space in the f-segment, > >>> does this problem go away in practice? > >> > >> Yes, I think so. I'm not sure why virtqueues are allocated > >> in low memory. Either cargo culting, or a remain of when > >> virtio was a 16-bit driver, if it ever was. > > > > The 'struct drive_s' storage currently must be allocated in the > > f-segment so that the disk.c code can access some critical details of > > mapped drives when in 16bit mode. However, we could change the code > > to allocate that data separately from the controller specific data and > > then move the controller specific data to a larger memory pool. This > > would have two gains - there's a cap of 16 hard drives that can be > > mapped so we'd be less likely to exceed the f-segment, and even if the > > f-segment did run out of space it would almost certainly be on a > > non-bootable drive.
I was hoping to be able to prototype the above, but haven't gotten a chance to yet. I think I should be able to get to it next week. > Or maybe, after the first 16 hard drives, we can stop allocating from > the fseg. The user could select any drive to boot from, so it would be hard to know which drives could be allocated in f-seg and which couldn't (at least until after the user has made the boot selection). -Kevin _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org https://mail.coreboot.org/mailman/listinfo/seabios
