On 30 August 2015 at 17:50, Christoffer Dall <christoffer.dall@xxxxxxxxxx> wrote: > I had imagined we would encode the GICv3 register accesses through the > device API and not through the system register API, since I'm not crazy > about polluting the general system register handling logic with GIC > registers solely for the purposes of migration. There's an interesting design question lurking under this about the extent to which you expose the h/w design split between the CPU interface and the GIC proper as part of the KVM APIs. I'm inclined to agree that it's better to for our purposes treat both bits as just part of an irqchip device, but I haven't given it a great deal of thought. (Similarly in the QEMU emulated-GICv3 case you could also split the CPU i/f more formally, or not. The kernel's choice would have implications for which way QEMU ends up going, I think.) thanks -- PMM _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
