Hi Marc,
I am from Cavium and we have tried your GICv3 driver on our internal
emulation platform. We have booted systems with >8 cores and tested
basic SGIs, PPIs and SPIs.
However we haven't exercised LPIs and ITS yet. We plan to do this soon.
If you have a new version of the patches coming out soon, we can
exercise that as well on our platform.
regards,
Radha Mohan
On Thu, Feb 27, 2014 at 5:37 PM, Will Deacon <will.deacon@xxxxxxx> wrote:
> On Wed, Feb 26, 2014 at 12:53:34PM +0000, Marc Zyngier wrote:
>> On 25/02/14 18:06, Will Deacon wrote:
>> > Not sure if you care, but readq is a show-stopper if you want to build this
>> > with arch/arm/.
>>
>> I realized that recently. Any reason why we don't have writeq/readq on
>> LPAE-capable stuff (other than the obvious runtime detection madness)?
>
> I'm not sure that you'd be guaranteed single-copy atomicity for such an
> access, which is probably assumed by readq/writeq.
>
>> >> + if ((typer >> 32) == aff) {
>> >> + gic_data_rdist_rd_base() = ptr;
>> >> + pr_info("CPU%d: found redistributor %llx @%p\n",
>> >> + smp_processor_id(),
>> >> + (unsigned long long) mpidr, ptr);
>> >> + return 0;
>> >> + }
>> >> +
>> >> + if (gic_data.redist_stride) {
>> >> + ptr += gic_data.redist_stride;
>> >> + } else {
>> >> + ptr += SZ_64K * 2; /* Skip RD_base + SGI_base */
>> >> + if (typer & GICR_TYPER_VLPIS)
>> >> + ptr += SZ_64K * 2; /* Skip VLPI_base + reserved page */
>> >> + }
>> >
>> > VLPIS is RES0 in GICv3.
>>
>> Indeed. But we still want this driver to run on GICv4 HW, even if we
>> don't use VLPIs just yet.
>
> Ok, just mention that in the commit then.
>
>> >> +static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
>> >> + bool force)
>> >> +{
>> >> + unsigned int cpu = cpumask_any_and(mask_val, cpu_online_mask);
>> >> + void __iomem *reg;
>> >> + u64 val;
>> >> +
>> >> + if (gic_irq(d) < 32)
>> >> + return -EINVAL;
>> >> +
>> >> + reg = gic_dist_base(d) + GICD_IROUTER + (gic_irq(d) * 8);
>> >> + val = gic_mpidr_to_affinity(cpu_logical_map(cpu));
>> >> +
>> >> + writeq_relaxed(val, reg);
>> >
>> > How do you ensure that the interrupt has actually moved?
>>
>> There is no way to ensure it actually did (other than reading back from
>> the same register, if that's what you're aiming for?).
>
> I guess it depends how angry Linux will get if the interrupt fires on the
> wrong CPU. If the interrupt is pending when the moving takes place, will it
> be asserted on the new target?
>
> Will
> _______________________________________________
> kvmarm mailing list
> kvmarm@xxxxxxxxxxxxxxxxxxxxx
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
