On Fri, 9 Jun 2017 12:24:52 +1000 David Gibson <da...@gibson.dropbear.id.au> wrote:
> On Thu, Jun 08, 2017 at 10:45:30AM +0200, Greg Kurz wrote: > > On Thu, 8 Jun 2017 12:01:12 +1000 > > David Gibson <da...@gibson.dropbear.id.au> wrote: > > > > > On Wed, Jun 07, 2017 at 07:17:09PM +0200, Greg Kurz wrote: > > > > Until recently, spapr used to allocate ICPState objects for the lifetime > > > > of the machine. They would only be associated to vCPUs in > > > > xics_cpu_setup() > > > > when plugging a CPU core. > > > > > > > > Now that ICPState objects have the same lifecycle as vCPUs, it is > > > > possible to associate them during realization. > > > > > > > > This patch hence open-codes xics_cpu_setup() in icp_realize(). The vCPU > > > > is passed as a property. Note that vCPU now needs to be realized first > > > > for the IRQs to be allocated. It also needs to resetted before ICPState > > > > realization in order to synchronize with KVM. > > > > > > Ok, what enforces those ordering constraints? > > > > > > > I'm not sure about what you're asking... I had to re-order because > > xics_cpu_setup() used to be called after the vCPU is realized and > > put in PAPR mode. > > Duh, sorry, I wasn't thinking to ask about realize order, since that's > manual and you've re-ordered it to be correct. > > You also mention that reset order matters, and I'm less clear on what > guarantees that the reset handlers for the components get called in > the right order. > Oops... my bad, this is a mistake in the changelog. The KVM error I was seing isn't related to CPU reset as I was thinking first but to cpu_ppc_set_papr()... :-\ The last sentence should rather be something like: "We also need to call spapr_cpu_init() before ICPState realization in order to enable PAPR mode in KVM." Can you fix this in your tree or should I send an updated version ? Cheers, -- Greg
pgpwxjBpk7U1n.pgp
Description: OpenPGP digital signature
