On Fri, May 12, 2023 at 5:14 PM Stefano Stabellini <sstabell...@kernel.org> wrote: > > On Wed, 10 May 2023, Olaf Hering wrote: > > Wed, 10 May 2023 00:58:27 +0200 Olaf Hering <o...@aepfle.de>: > > > > > In my debugging (with v8.0.0) it turned out the three pci_set_word > > > causes the domU to hang. In fact, it is just the last one: > > > > > > pci_set_byte(pci_conf + 0x20, 0x01); /* BMIBA: 20-23h */ > > > > > > It changes the value from 0xc121 to 0x1. > > > > If I disable just "pci_set_word(pci_conf + PCI_COMMAND, 0x0000);" it works > > as well. > > It changes the value from 0x5 to 0. > > > > In general I feel it is wrong to fiddle with PCI from the host side. > > This is most likely not the intention of the Xen unplug protocol. > > I'm sure the guest does not expect such changes under the hood. > > It happens to work by luck with pvops kernels because their PCI discovery > > is done after the unplug. > > > > So, what do we do here to get this off the table? > > I don't have a concrete suggestion because I don't understand the root > cause of the issue. Looking back at Paolo's reply from 2021 > > https://marc.info/?l=xen-devel&m=161669099305992&w=2 > > I think he was right. We can either fix the root cause of the issue or > avoid calling qdev_reset_all on unplug. I am OK with either one.
I haven't touched IDE or block code in quite a long while now -- I don't think I can help land this fix, but I won't get in anyone's way, either. Maybe just re-submit the patches with an improved commit message / cover letter that helps collect the info from the previous thread, the core issue, etc. --js
