qemu-block
[Top][All Lists]
Advanced

[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

Attachment: pgp_5BegVOYL1.pgp
Description: Digitale Signatur von OpenPGP


reply via email to

[Prev in Thread] Current Thread [Next in Thread]