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 also need to make the MPIC code capabilities conditional here, so that large vectors are only supported when the machine requests them. Alex
