On 04/14/22 17:43, Richard W.M. Jones wrote:
On Thu, Apr 14, 2022 at 04:40:25PM +0100, Richard W.M. Jones wrote:
>> + (* For IDE disks, IDE CD-ROMs, SCSI disks, SCSI CD-ROMs, and floppies, we
>> + * need host-bus adapters (HBAs) between these devices and the PCI(e) root
>> + * bus. Some machine types create these HBAs automatically (despite
>> + * "-no-user-config -nodefaults"), some don't...
>> + *)
>> + let parent_ctrl_needed target_bus dev_filter =
>> + try ignore (List.find dev_filter (Array.to_list target_bus)); true
>> + with Not_found -> false
>
> You can Array.exists here, but it might also be worth converting
^ use
> everything to a list earlier on in the file, eg:
>
> let target_virtio_blk_bus = Array.to_list target_buses.target_virtio_blk_bus
> and target_ide_bus = Array.to_list target_buses.target_ide_bus
> [etc]
and then using List.exists here and List.iter{,i} below.
[warning telling people to file a bug]
>
> So it's good that it's a warning (dropping a floppy or CD-ROM when
> converting is not a reason to fail), however it could be a bit more
> actionable. I would include a reference to the manual, "BUGS" section
> in virt-v2v(1).
Actually I'm having second thoughts about encouraging people to file a
bug at all. If lots of people see this message and file bugs, is that
something we actually would need to fix? If yes then OK, otherwise
we'll just get more bugs on the backlog.
If those branches ever fire, then we do have a bug: it means that the
target bus assignment in "convert/target_bus_assignment.ml" created such
a machine config that is impossible to map to QEMU.
The first branch in particular could refer to an IDE *disk* (not just
CD-ROM) on the Virt machine type, which would absolutely be a bug
*somewhere*. It would mean that we found some fixed disk on the source,
and that the guest OS (aarch64 Linux, most likely) does not have a
virtio-blk-driver -- and so we'd map the disk to IDE. That mapping is
wrong for us to do; but it's even worse for the guest not to have a
virtio-blk driver!
I figured an assertion failure would be too strong for this. And yes, if
this ever pops up in practice, I think we should discuss such cases on
the list, probably telling users "your guest kernel config is broken".
Thanks,
Laszlo