On Thu, Jan 03, 2019 at 06:44:30PM +0100, Cédric Le Goater wrote: > On 1/3/19 4:57 AM, David Gibson wrote: > > On Wed, Jan 02, 2019 at 06:57:35AM +0100, Cédric Le Goater wrote: > >> which will be used by the machine only when the XIVE interrupt mode is > >> in use. > > > > I don't love the idea of putting a hook this specific into the > > PowerPCCPU structure, though it might be the easiest path in the short > > term. > > > > A couple of approaches: 1) revisit my changes to allow for a pointer > > to machine-defined per-cpu data. > > ok but we still need two different presenters objects, one for each > mode. > > > or 2) do we actually need a cpu to tctx pointer. > > > > Expanding on (2) - here you use the pointer to find the right TIMA > > state to access, > > yes. > > > but that could also be handled by having different TIMA IO instances > > and mapping those individually to cpu_as. > > It might work for QEMU but I am not sure how to implement the KVM > backend with such a design. We only have a single ram ptr mapping > for the machine in the KVM case. > > There are a couple of places where we need to loop on the XiveTCTX > (presenter, KVM) and we use the QEMU CPU list and the cpu->tctx for > that. One of the reasons we introduced the cpu->intc pointer some > time ago was to get rid of the ICP array. > > I don't think we want to introduce a XiveTCTX array again. > > > On the interrupt delivery side I think a tctx to cpu link will suffice. > > yes. that we already have. It is mostly used by KVM in fact. > > > For sPAPR there might be complications with translating cpu numbers in > > hcalls to the right tctx. > > The XiveTCTX is not used by the hcalls. We are fine on that side. > > > The double pointer solution is what I prefer today, but if you are > uncomfortable with it, we can come back to the previous where I was > allocating a XiveTCTX child under the CPU and switching the presenter > objects at reset. The only issue remaining was the child unparenting > in the unrealize() method.
Hm, yes, I see your point. For now I'm applying patches 1-3, and hope to clean it up later with a revised version of my machine specific per-cpu patch when I get the chance. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature