qemu-ppc
[Top][All Lists]
Advanced

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

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


From: Cédric Le Goater
Subject: Re: [Qemu-ppc] [PATCH] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge
Date: Thu, 28 Jun 2018 15:05:03 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

On 06/28/2018 01:40 PM, Andrea Bolognani wrote:
> On Thu, 2018-06-28 at 12:04 +0200, Cédric Le Goater wrote:
>> On 06/28/2018 10:00 AM, Andrea Bolognani wrote:
>>> On Thu, 2018-06-28 at 13:59 +1000, David Gibson wrote:
>>>> 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.
> 
> That approach would require even more hacks in libvirt if we ever
> wanted to support PowerNV - basing the PCI address allocation on
> the CPU model is not something that's really ever happened before.

It's even more complex than that but let's keep it "simple" and
consider that some CPU flavors can have more or less PHBs.

May be, we could agree on a common number of PHBs per chip which 
would be statically initialized. *two* PHBs should cover all CPU 
flavors. Extra PHBs created by the user with -device would be 
allowed but capped by a per CPU flavor limit. How's that ? 

C.   

> 
> To make it somewhat reasonable, information about the number of
> PHBs created for each CPU model would have to be exposed through
> QMP. And I wonder what a multi-chip guest would look like...
> 
> Plus, as soon as you try something like
> 
>   $ qemu-system-ppc64 \
>     -nodefaults -display none \
>     -machine powernv -cpu POWER8E \
>     -device pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1 \
>     -device megasas,id=scsi0,bus=pci.1,addr=0x1
> 
> very interesting things will start happening :)
> 




reply via email to

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