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?
Do
for i in $(seq 1 500); do echo -drive if=none,file=null-co://,id=null$i echo -device scsi-hd,lun=$i,drive=null$i; done > manydisks for i in $(seq 1 10); do echo -drive if=none,file=null-co://,id=null$i echo -device scsi-hd,lun=$i,drive=null$i; done > fewdisks
then
qemu-kvm -device virtio-scsi-pci \ -drive if=none,file=someos.qcow2,id=os \ -device scsi-hd,lun=0,bootindex=0,drive=os $(cat manydisks)
does not respect bootindex=0 while
qemu-kvm -device virtio-scsi-pci \ -drive if=none,file=someos.qcow2,id=os \ -device scsi-hd,lun=0,bootindex=0,drive=os $(cat fewdisks)
respects it. The reason is that with "manydisks" you get many FSEG allocation failures in virtio_scsi_init_lun.
Paolo
I can test with the patchset I posted earlier:
https://mail.coreboot.org/pipermail/seabios/2017-July/011452.html
which is also now at:
https://github.com/KevinOConnor/seabios/tree/work-drive-lowmem-20170711
-Kevin