On Wed, Jun 19, 2019 at 5:12 PM Will Deacon <will.deacon@xxxxxxx> wrote: > > On Wed, Jun 19, 2019 at 09:54:21AM +0100, Julien Grall wrote: > > On 6/19/19 9:07 AM, Guo Ren wrote: > > > You forgot CCing C-SKY folks :P > > > > I wasn't aware you could be interested :). > > > > > Move arm asid allocator code in a generic one is a agood idea, I've > > > made a patchset for C-SKY and test is on processing, See: > > > https://lore.kernel.org/linux-csky/1560930553-26502-1-git-send-email-guoren@xxxxxxxxxx/ > > > > > > If you plan to seperate it into generic one, I could co-work with you. > > > > Was the ASID allocator work out of box on C-Sky? If so, I can easily move > > the code in a generic place (maybe lib/asid.c). > > This is one place where I'd actually prefer not to go down the route of > making the code generic. Context-switching and low-level TLB management > is deeply architecture-specific and I worry that by trying to make this > code common, we run the real risk of introducing subtle bugs on some > architecture every time it is changed. "Add generic asid code" and "move arm's into generic" are two things. We could do first and let architecture's maintainer to choose. > Furthermore, the algorithm we use > on arm64 is designed to scale to large systems using DVM and may well be > too complex and/or sub-optimal for architectures with different system > topologies or TLB invalidation mechanisms. It's just a asid algorithm not very complex and there is a callback for architecture to define their own local hart tlb flush. Seems it has nothing with DVM or tlb broadcast mechanism. > > It's not a lot of code, so I don't see that it's a big deal to keep it > under arch/arm64. Yes, I think that's ok for arm64. Hi Arnd, What do you think about adding generic asid code for arch selection? Best Regards Guo Ren _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
