On Sun, Sep 11, 2016 at 08:23:34PM +0300, Marcel Apfelbaum wrote:
Otherwise SeaBIOS can't access virtio's modern BAR.
Signed-off-by: Marcel Apfelbaum marcel@redhat.com
Hi,
If there is no room to map all MMIO BARs into the 32-bit PCI window, SeaBIOS will re-allocate all 64-bit MMIO BARs into over-4G space.
Virtio 1.0 block devices (virtio-blk/virtio-scsi) use a 64-bit BAR unusable by SeaBIOS if mapped over 4G space, preventing the system to boot.
The simplest solution is to follow the xhci model and simply skip migrating the virtio 1.0 modern bar into over-4G space.
In order to reproduce the problem use: -device virtio-blk-pci, ...\ -object memory-backend-file,id=mem,size=4G,mem-path=/dev/hugepages,share=on \ -device ivshmem-plain,memdev=mem \
Thanks, Marcel
src/fw/pciinit.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c index 35d9902..3b76e66 100644 --- a/src/fw/pciinit.c +++ b/src/fw/pciinit.c @@ -655,6 +655,13 @@ static void pci_region_migrate_64bit_entries(struct pci_region *from, continue; if (entry->dev->class == PCI_CLASS_SERIAL_USB) continue;
if (entry->dev->vendor == PCI_VENDOR_ID_REDHAT_QUMRANET &&(entry->dev->device == PCI_DEVICE_ID_VIRTIO_BLK_09 ||entry->dev->device == PCI_DEVICE_ID_VIRTIO_BLK_10 ||entry->dev->device == PCI_DEVICE_ID_VIRTIO_SCSI_09 ||entry->dev->device == PCI_DEVICE_ID_VIRTIO_SCSI_10))continue;// Move from source list to destination list. hlist_del(&entry->node); hlist_add(&entry->node, last);-- 2.5.5
What if guest is booting from the network?
Rather than special-case virtio storage, it seems to me that the right thing to do is to only allocate resources for the boot devices, and rely on the OS to allocate resources for the rest. IIUC this is typically controlled by the plug and play OS flag in smbios.