qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/1] s390x: create a compat s390 phb for <=2.10


From: Christian Borntraeger
Subject: Re: [Qemu-devel] [PATCH 1/1] s390x: create a compat s390 phb for <=2.10
Date: Wed, 27 Sep 2017 14:26:50 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0


On 09/27/2017 02:21 PM, David Hildenbrand wrote:
> On 27.09.2017 12:59, Christian Borntraeger wrote:
>>
>>
>> On 09/27/2017 12:56 PM, Cornelia Huck wrote:
>>> On Wed, 27 Sep 2017 18:25:00 +0800
>>> Yi Min Zhao <address@hidden> wrote:
>>>
>>>> 在 2017/9/27 下午5:47, Cornelia Huck 写道:
>>>>> On Tue, 26 Sep 2017 20:40:25 +0200
>>>>> David Hildenbrand <address@hidden> 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.
>>
> 
> Interesting, so how is migration then handled for e.g. x86 or other
> architectures that can work without CONFIG_PCI? I assume their migration
> should also break?

If you migrate from a QEMU with CONFIG_PCI to a QEMU without CONFIG_PCI 
I assume it will break. But maybe there is really some clever way to
do the right thing. 

PS: Is really anybody disabling CONFIG_PCI and why?




reply via email to

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