On 09/27/2017 12:56 PM, Cornelia Huck wrote: > On Wed, 27 Sep 2017 18:25:00 +0800 > Yi Min Zhao <zyi...@linux.vnet.ibm.com> wrote: > >> 在 2017/9/27 下午5:47, Cornelia Huck 写道: >>> On Tue, 26 Sep 2017 20:40:25 +0200 >>> David Hildenbrand <da...@redhat.com> wrote: > >>>> I'd really really really (did I mention really?) favor something like a >>>> dummy device, because we could easily handle the !CONFIG_PCI case then. >>>> >>>> All these compat options and conditions will kill us someday... we're >>>> already patching around that whole stuff way too much. >>>> >>>> If we ever unconditionally created a device, we should keep doing so. >>> Yes, that whole thing is horrible, especially interaction with compat >>> machines. >>> >>> Do you have an idea on how to create such a dummy device (without >>> having to effectively copy a lot of configured-out code)? >>> >>> >> How about in s390_pcihost_hot_plug() we check s390_has_feat(zpci)? >> If no zpci feature, we avoid plugging any pci device. >> Then we could always create phb. >> I think pcibus's vmstate is only data to migrate. > > That's still problematic if CONFIG_PCI is off. I currently don't have a > better idea than either disallowing compat machines on builds without > pci, or using a dummy device...
For this particular case your initial patch might be less problematic than a dummy device, because the code that does the migration is NOT contained in s390 specific code but in common PCI code instead. We would need to keep the dummy device always in a way that it will work with the common PCI code.
