On Tue, Nov 23, 2021 at 03:25:24PM +0100, Andrew Jones wrote:
> On Mon, Nov 08, 2021 at 06:38:49PM -0800, Ricardo Koller wrote:
> > This series adds a new test, aarch64/vgic-irq, that validates the injection of
> > different types of IRQs from userspace using various methods and configurations
> > (when applicable):
> >
> > Intid Method | | Configuration
> > | |
> > IRQ_LINE | |
> > SGI LEVEL_INFO | |
> > PPI x IRQFD | x | level-sensitive x EOIR + DIR
> > SPI ISPENDR | | edge-triggered EOIR only
> > bogus ISACTIVER | |
> > | |
> >
> > vgic-irq is implemented by having a single vcpu started in any of the 4 (2x2)
> > configurations above. The guest then "asks" userspace to inject all intids of
> > a given IRQ type using each applicable method via a GUEST_SYNC call. The
> > applicable methods and intids for a given configuration are specified in tables
> > like this one:
> >
> > /* edge-triggered */
> > static struct kvm_inject_desc inject_edge_fns[] = {
> > /* sgi ppi spi */
> > { KVM_IRQ_LINE, false, false, true },
> > { IRQFD, false, false, true },
> > { ISPENDR, true, false, true },
> > };
> >
> > Based on the (example) table above, a guest running in an edge-triggered
> > configuration will try injecting SGIs and SPIs. The specific methods are also
> > given in the table, e.g.: SGIs are injected from userspace by writing into the
> > ISPENDR register.
> >
> > This test also adds some extra edge tests like: IRQ preemption, restoring
> > active IRQs, trying to inject bogus intid's (e.g., above the configured KVM
> > nr_irqs).
> >
> > Note that vgic-irq is currently limited to a single vcpu, GICv3, and does not
> > test the vITS (no MSIs).
> >
> > - Commits 1-3 add some GICv3 library functions on the guest side, e.g.: set the
> > priority of an IRQ.
> > - Commits 4-5 add some vGICv3 library functions on the userspace side, e.g.: a
> > wrapper for KVM_IRQ_LINE.
> > - Commit 6 adds the basic version of this test: inject an SPI using
> > KVM_IRQ_LINE.
> > - Commits 7-17 add other IRQs types, methods and configurations.
> >
>
> Hi Ricardo,
>
> I didn't review this in detail, but it looks good and quite thorough.
Thanks Andrew!
> Out
> of curiosity did thoroughness come from attempting to get coverage on KVM
> code?
Yes, that was the main reason. Although, keep in mind that there are a
lot of features not covered, like routing and the ITS.
> I.e were you running some sort of code coverage tool on KVM with
> these tests?
No, not really. It would be nice to know how much coverage (and
distribution) we are getting from all tests (selftests and KUT) at the
moment and maybe use that to decide on future tests.
>
> Unfortunately I probably won't have a chance to look much closer than the
> scan I just did, so FWIW
>
> For the series
>
> Acked-by: Andrew Jones <drjones@xxxxxxxxxx>
>
> Thanks,
> drew
>
Thanks,
Ricardo
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
