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.
