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