[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Why is "spapr-pci-host-bridge" no-user?
From: |
Alexey Kardashevskiy |
Subject: |
Re: [Qemu-devel] Why is "spapr-pci-host-bridge" no-user? |
Date: |
Fri, 3 Jun 2016 21:52:59 +1000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 |
On 03/06/16 21:36, Markus Armbruster wrote:
> Alexey Kardashevskiy <address@hidden> writes:
>
>> On 03/06/16 16:40, Markus Armbruster wrote:
>>> Commit 09aa9a5 "spapr-pci: enable adding PHB via -device" set
>>> cannot_instantiate_with_device_add_yet without also adding a comment
>>> explaining why. It is currently the only one lacking such a comment.
>>> Let's fix that.
>>>
>>> Unfortunately, the commit message doesn't tell me (or I'm too dense to
>>> understand it):
>>>
>>> spapr-pci: enable adding PHB via -device
>>>
>>> Recent changes introduced cannot_instantiate_with_device_add_yet
>>> and removed capability of adding yet another PCI host bridge via
>>> command line for SPAPR platform (POWERPC64 server).
>>>
>>> This brings the capability back and puts SPAPR PHB into "bridge"
>>> category.
>>>
>>> This is not much use for emulated PHB but it is absolutely required
>>> for VFIO as we put an IOMMU group onto a separate PHB on SPAPR.
>>>
>>> Signed-off-by: Alexey Kardashevskiy <address@hidden>
>>> Signed-off-by: Alexander Graf <address@hidden>
>>>
>>> Alexey, can you explain why the device cannot be used with -device /
>>> device_add?
>>
>> It can be used with "-device" with as it is today, i.e. with
>> "cannot_instantiate_with_device_add_yet=false".
>
> I misread the code. But the assignment needs an explanation anyway :)
imho at that moment it was pretty valid :) Now we do not even have to have
multiple PHBs on spapr, although we still support this ;)
>
>> With "cannot_instantiate_with_device_add_yet=true", I get this:
>>
>> qemu-system-ppc64: -device spapr-pci-host-bridge,id=phb10,index=10:
>> Parameter 'driver' expects pluggable device type
>>
>>
>> At that moment (sha1 09aa9a526a86fd2e380e86^) it failed because of
>> inherited "cannot_instantiate_with_device_add_yet=true" from
>> sysbus_device_class_init() (which is gone now):
>>
>> qemu-system-ppc64: -device spapr-pci-host-bridge,id=phb10,index=10:
>> Parameter 'driver' expects pluggable device type
>>
>> So there was my patch.
>>
>>
>> "device_add" is different, it does not work because:
>> (qemu) device_add spapr-pci-host-bridge
>> Bus 'main-system-bus' does not support hotplugging
>>
>> Which I am not sure if it is true for all platforms or just spapr/ppc64 but
>> I do not care much now as there is some work to do anyway to support PHB
>> hotplug as per LoPAPR specification anyway.
>>
>> Does this help? :)
>
> Now you made me read the code more carefully, I have different
> questions.
>
> Can we delete the assignment? -device
> spapr-pci-host-bridge,id=phb10,index=10 still works for me then.
_Now_ we can indeed as the default has changed, this works for me too, I
just forgot to mention this, sorry.
>
> If not, why?
>
--
Alexey