On Apr 25, 2013, at 11:20 AM, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: > On 25 April 2013 19:04, Christoffer Dall <cdall@xxxxxxxxxxxxxxx> wrote: >> I prefer not hard-coding this stuff in the kernel, but let user space >> decide this. If we have good technical arguments not to do that (such >> as knowing that this is always defined per-core and not for an SoC >> (ARM guys?) then at least the patch should lookup the target processor >> and set the irq number accordingly. > > Well, this is all implementation-defined. The ARM ARM mandates > that the generic timers deliver a PPI, and that it must be the > same PPI for all processors in an MP implementation, but not which > PPI. The A15 and A7 happen to both be hardwired to ID27. You could > in theory design a core which let the SoC configure the virtual > timer ID (or let the guest arbitrarily program it, for that > matter, I suppose), though I'm not sure why you'd want to. > > I think I'd take the simple approach of saying "the timer PPI > is a fixed property of the guest CPU" unless somebody actually > builds something where it isn't fixed... (for that CPU we > could then define it as a feature argument to KVM_ARM_VCPU_INIT). > Ok, let's not bother with user space injection then, but instead of hard defaulting to two specific cores, please make a switch statement on the target CPU and log an error on init if it's an unknown core. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
