[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] piix: fix regression during unplug in Xen HVM domUs
From: |
Olaf Hering |
Subject: |
Re: [PATCH v2] piix: fix regression during unplug in Xen HVM domUs |
Date: |
Thu, 25 Mar 2021 12:12:19 +0100 |
Am Mon, 22 Mar 2021 18:09:17 -0400
schrieb John Snow <jsnow@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
pgp_5BegVOYL1.pgp
Description: Digitale Signatur von OpenPGP