Am Mon, 22 Mar 2021 18:09:17 -0400 schrieb John Snow <js...@redhat.com>:
> My understanding is that XEN has some extra disks that it unplugs when > it later figures out it doesn't need them. How exactly this works is > something I've not looked into too closely. It has no extra disks, why would it? I assume each virtualization variant has some sort of unplug if it has to support guests that lack PV/virtio/enlightened/whatever drivers. In case of HVM, the configured block or network devices can be either accessed via emulated PCI or via the PV drivers. Since the BIOS, the bootloader and potentially the operating system kernel typically lack PV drivers, they will find the devices only via the PCI bus. In case they happen to have PV drivers in addition to PCI drivers, both drivers will find and offer the same resource via different paths. In case of a block device, ata_piix.ko will show it via "/dev/sda" and xen-blkfront.ko will show it via "/dev/xvda". This is obviously bad, at least in the read-write case. The pvops kernel triggers the unplug of the emulated PCI hardware early, prior any other PCI initialization. As a result the PCI drivers will not find their hardware anymore. In case of ata_piix, only the non-CDROM storage will be removed in qmeu, because there is no PV-CDROM driver. The PV support in old xenlinux based kernels is only available as modules. As a result the unplug will happen after PCI was initialized, but it must happen before any PCI device drivers are loaded. > So if these IDE devices have been "unplugged" already, we avoid > resetting them here. What about this reset causes the bug you describe > in the commit message? > > Does this reset now happen earlier/later as compared to what it did > prior to ee358e91 ? Prior this commit, piix_ide_reset was only called when the entire emulated machine was reset. Like: never. With this commit, piix_ide_reset will be called from pci_piix3_xen_ide_unplug. For some reason it confuses the emulated USB hardware. Why it does confused it, no idea. I wonder what the purpose of the qdev_reset_all() call really is. It is 10 years old. It might be stale. Olaf
pgpiJF0BreQPC.pgp
Description: Digitale Signatur von OpenPGP
