Re: [Qemu-devel] [PATCH] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

[Cédric Le Goater]

On 06/28/2018 10:00 AM, Andrea Bolognani wrote:
> On Thu, 2018-06-28 at 13:59 +1000, David Gibson wrote:
>> On Wed, Jun 27, 2018 at 12:22:31PM +0200, Andrea Bolognani wrote:
>>> On Tue, 2018-06-26 at 19:02 +0200, Cédric Le Goater wrote:
>>>> I didn't follow that discussion but this is "another" kind of PHB.
>>>> This one models the baremetal controller as found on OpenPOWER and
>>>> IBM Power machines. pSeries has a virtual PHB.
>>>
>>> I understand that, and of course libvirt will need to learn about
>>> this new type of PHB and make sure both pSeries and PowerNV guests
>>> get the correct one assigned to them.
>>
>> Hmm.. does it?  I would have thought pnv could act more like x86, in
>> that libvirt doesn't attempt to create PHBs at all and just use the
>> ones that are built in.
> 
> AFAIK x86 guests have a single PHB and additional ones cannot be
> created in any way, which means we don't have to do any additional
> second-guessing when assigning IDs to additional PCI controllers.
> 
>> Though, come to that, I wouldn't think pnv support for libvirt would
>> be much of a priority anyway.  The machine type is still very much in
>> flux, and it's designed primarily for testing and development, not
>> "real world" usage.
> 
> Can you *guarantee* that someone won't ask for PowerNV support in
> libvirt at some point? Because if you can't (and I don't think you
> can ;) then this is still a valuable conversation to have.
> 
>>> What I meant is that pSeries guests get a single PHB by default,
>>> with additional ones being instantiable through -device; this is
>>> also consistent with how PCI controllers are added to other guest
>>> types including pc, q35 and aarch64/virt, so it would be really
>>> nice if PowerNV behaved the same way.
>>
>> Well.. sure.. but it doesn't.  pSeries is a virtual platform, so we
>> have a reasonable amount of flexibility to define it as we want.
>> PowerNV is an emulation of existing hardware which has a specific
>> behaviour which we need to match.
> 
> Sure, that's something to keep in mind.
> 
> But the thing is, you still need to have *some* flexibility in
> the number of PHBs, since there is variation among real Power8
> and Power9 chips; in the current incarnation, that flexibility
> is provided by the num_phbs parameter, which is an entirely new
> interface that's exclusive to PowerNV.
> 
> What I'm suggesting is that the same amount of flexibility is
> offered through a standard interface, namely -device, instead.

Yes. I don't know to be honest. Adding support for -device is not 
complex.

v2 proposes to initialize a fixed set of PHBs 2, 3, 4 depending on 
the CPU. I think this is the best modeling option to fit the HW.

Thanks,

C.