On 27/09/2017 16:35, Kevin O'Connor wrote: > On Wed, Sep 27, 2017 at 04:15:49PM +0200, Paolo Bonzini wrote: >> On 27/09/2017 15:58, Kevin O'Connor wrote: >>> On Wed, Sep 27, 2017 at 09:36:01AM +0200, Paolo Bonzini wrote: >>>> On 21/06/2017 00:44, Kevin O'Connor wrote: >>>>>> 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. >>>> >>>> I don't think this is the issue. virtqueues actually have been >>>> allocated with memalign_high since 2015 (commit 6cfebb4e). >>>> >>>> virtio-blk is allocating 68 fseg bytes for the controller-specific data, >>>> virtio-scsi only 16. struct drive_s is about 40 bytes long. >>> >>> What is the test case for reproducing the problem? > [...] >> respects it. The reason is that with "manydisks" you get many FSEG >> allocation failures in virtio_scsi_init_lun. > > I can confirm it fails on SeaBIOS master, but works on the > "work-drive-lowmem-20170711" branch. > > I didn't want to commit that branch without confirming it fixed the > underlying problem. Is this sufficient confirmation?
Yes, I tried with more disks and it works with about 900. I guess that's fine. Paolo _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org https://mail.coreboot.org/mailman/listinfo/seabios