On 2016年05月10日 01:29, Peter Maydell wrote: > This series implements emulation of the GICv3 interrupt controller. > It is based to some extent on previous patches from Shlomo and > Pavel, but the bulk of it has turned out to be new code. (The > combination of changing the underlying data structures, adding > support for TrustZone and implementing proper GICv3 behaviour rather > than borrowing fragments of GICv2 emulation code meant there wasn't > much left to reuse.) I've tried to reflect this in the various > authorship credits on the patches, but please let me know if you > feel I got anything miscredited one way or the other. > > Key points about the GICv3 emulated here: > * "non-legacy" only, ie system registers and affinity routing > * TrustZone is implemented > * no virtualization support > * only the "core" GICv3, so no LPI support (via ITS or otherwise) > > I have included the "support KVM save/restore" patches from Pavel, > reworked to use the new data structures, but they are only RFC > status because the kernel API is not yet final (there are a couple > of loose threads there to be followed up). Those patches are at the > end of the series; I think everything else is in a commitable state > (give or take code review). > > Testing: I have confirmed that we can boot a Linux guest kernel, > but not tried any other GIC-using guest code. I've done some light > stress-testing using 'stress', and checked an SMP (2-cpu) boot. > > Design: all the code here is in hw/intc/, split into several > files to avoid them being huge. The interface between the CPU > proper and the CPU interface is a bit ad-hoc (you can see the > awkward seams that result from the choice to think of the cpu > i/f as part of the GIC device rather than part of the CPU itself), > but I think that if you put the cpu i/f in the CPU you'd end up > with an ad-hoc interface and awkward seams in the other direction. > The GICv3 device currently assumes it is always connected to all > CPUs; we can change that later to allow some kind of QOM link > property to specify the CPUs explicitly, but I think this is OK > for now (and it's already a pretty huge set of code changes to > have to review). > > I include a workaround for a Linux kernel bug which otherwise > prevents booting on the virt board. I've reported the bug to > Marc Zyngier and he should post a kernel patch to fix it shortly, > but I think we'll need to retain the workaround for the benefit > of older kernels (an ugly but pragmatic choice). > > > Code review, testing, attempts to run guests other than Linux > welcome (UEFI, anybody?) > > thanks > -- PMM > > Pavel Fedin (5): > target-arm: Add mp-affinity property for ARM CPU class > hw/intc/arm_gicv3: Add state information > hw/intc/arm_gicv3: Add vmstate descriptors > NOT-FOR-UPSTREAM: kernel: Add definitions for GICv3 attributes > RFC: hw/intc/arm_gicv3_kvm: Implement get/put functions > > Peter Maydell (15): > migration: Define VMSTATE_UINT64_2DARRAY > bitops.h: Implement half-shuffle and half-unshuffle ops > target-arm: Define new arm_is_el3_or_mon() function > target-arm: Provide hook to tell GICv3 about changes of security state > hw/intc/arm_gicv3: Move irq lines into GICv3CPUState structure > hw/intc/arm_gicv3: Implement functions to identify next pending irq > hw/intc/arm_gicv3: Wire up distributor and redistributor MMIO regions > hw/intc/arm_gicv3: Implement gicv3_set_irq() > hw/intc/arm_gicv3: Implement GICv3 CPU interface registers > hw/intc/arm_gicv3: Implement gicv3_cpuif_update() > hw/intc/arm_gicv3: Implement CPU i/f SGI generation registers > hw/intc/arm_gicv3: Add IRQ handling CPU interface registers > target-arm/machine.c: Allow user to request GICv3 emulation > target-arm/monitor.c: Advertise emulated GICv3 in capabilities > hw/intc/arm_gicv3: Work around Linux assuming interrupts are group 1 > > Shlomo Pongratz (3): > hw/intc/arm_gicv3: ARM GICv3 device framework > hw/intc/arm_gicv3: Implement GICv3 distributor registers > hw/intc/arm_gicv3: Implement GICv3 redistributor registers > Hi Peter, I have gone through these patches. I think I don't have further comments. Sorry that I just reviewed the patches while studying the SPEC, so there are only few problems I found(on the hand your patches are good:) ). I hope I'll give effective comments on the next version.
Thanks, -- Shannon
