On 09.08.2012, at 23:11, Scott Wood wrote: > On 08/09/2012 04:01 PM, Alexander Graf wrote: >> >> On 09.08.2012, at 22:58, Scott Wood wrote: >> >>> On 08/09/2012 03:52 PM, Alexander Graf wrote: >>>> >>>> On 09.08.2012, at 22:50, Scott Wood wrote: >>>> >>>>> On 08/09/2012 03:48 PM, Alexander Graf wrote: >>>>>> >>>>>> On 09.08.2012, at 00:40, Scott Wood wrote: >>>>>> >>>>>>> On 08/08/2012 04:16 PM, Alexander Graf wrote: >>>>>>>> >>>>>>>> On 24.06.2012, at 01:07, Alexander Graf wrote: >>>>>>>> >>>>>>>>> Due to popular demand, we're updating the way we generate the MPIC >>>>>>>>> node and interrupt lines based on what the current state of art is. >>>>>>>>> >>>>>>>>> Requested-by: Scott Wood <scottw...@freescale.com> >>>>>>>>> Signed-off-by: Alexander Graf <ag...@suse.de> >>>>>>>> >>>>>>>> Hey Scott, >>>>>>>> >>>>>>>> This patch breaks SMP for me. The reason for the breakage is that >>>>>>>> Linux does some things differently when it finds an fsl,mpic instead >>>>>>>> of a generic openpic. I have assembled logs between a working version >>>>>>>> (compatible openpic) and a broken version (compatible fsl,mpic) with >>>>>>>> guest and host debug turned on. >>>>>>>> >>>>>>>> Maybe you have an idea what's going wrong. >>>>>>> >>>>>>> IIRC QEMU is missing support for large vectors, which is probably >>>>>>> breaking IPIs. A recent change to Linux has it assuming it can use >>>>>>> large vectors when it sees fsl,mpic, as we're running out of vectors (on >>>>>>> p4080 MSIs collided with the arbitrarily chosen timer vector, and on >>>>>>> t4240 the normal internal interrupts alone go beyond 256). >>>>>>> >>>>>>> We need to get the enhancements from our internal KVM MPIC back into >>>>>>> QEMU. >>>>>> >>>>>> Ok, so the quick fix for 1.2 would be to revert to the old compatible >>>>>> name. Can we leave the 4-field interrupt numbers or do we need to >>>>>> revert the whole patch? >>>>> >>>>> In theory you shouldn't have 4-cell interrupt numbers without fsl,mpic, >>>>> but I don't think it will actually break in Linux -- the extra cells >>>>> should just be ignored. >>>> >>>> So I suppose the best would be to revert the whole patch and simply >>>> go back to the old format then, to make sure we don't introduce more >>>> oddness for non-Linux guests (not that I'm aware we're capable of >>>> running any, especially any that would use the dtb). >>>> >>>> Once we have working large vectors in our MPIC emulation, we can >>>> easily put the patch into place again and generate dt's that show an >>>> fsl mpic. >>> >>> Additionally, we should consider adding extra compatibles with the major >>> QEMU version in them, so that QEMU-aware target code can work around >>> QEMU limitations even if it's been fixed in a more recent QEMU. >>> >>> I think this is what you were getting at in the e500 platform >>> discussion, when you pointed at the PC versioning, but it's not about >>> documenting semantics so much as identifying the actual implementation. >> >> Yes, -M e500-1.2 should expose chrp,open-pic while -M e500 should expose >> fsl,mpic. > > We could do that too if the chrp,open-pic version actually makes it into > a release before we fix fsl,mpic (I don't know what the release schedule
We are past soft freeze, hard feature freeze is coming up next week. > is), but what I meant was that the device tree should have something like > compatible = "qemu,1.2-chrp-openpic", "chrp,open-pic" > or > compatible = "qemu,1.3-fsl-mpic", "fsl,mpic" > > ...so that we can run new kernels on old QEMUs, not just the other way > around. Why would we bother? > >> We also need to make the MPIC code capabilities conditional here, so >> that large vectors are only supported when the machine requests >> them. > > Maybe, but the risk is minimal (target software would have to be setting > those bits to non-zero and expecting them to be ignored) and the > potential for making (more of) a mess of the code is high if we > conditionalize everything. > > Are there any currently supported machines where real hardware doesn't > have large vectors? I'm not sure what bamboo would support in real hw. Same for the frankenstein-U3 we expose. I agree that risk looks low for now, but let's evaluate it when I see the patch that actually changes things. Alex
