On 29 November 2016 at 21:09, Christoffer Dall <christoffer.dall@xxxxxxxxxx> wrote: > Actually, I'm not sure what the semantics of the line level ioctl should > be for edge-triggered interrupts? My inclination is that it shouldn't > have any effect at this point, but that would mean that at this point we > should only set the pending variable and try to queue the interrupt if > the config is level. But that also means that when we set the config > later, we need to try to queue the interrupt, which we don't do > currently, because we rely on the guest not fiddling with the config of > an enabled interrupt. > > Could it be considered an error if user space tries to set the level for > an edge-triggered interrupt and therefore something we can just ignore > and assume that the corresponing interrupt will be configured as a > level-triggered one later? Userspace will always read the line-level values out and write them back for migration, and I'd rather not make it have to do cross-checks against whether the interrupt is edge or level triggered to see whether it should write the level values into the kernel. Telling the kernel the level for an edge-triggered interrupt should be a no-op because it doesn't have any effect on pending status. > In any case we probably need to clarify the ABI in terms of this > particular KVM_DEV_AR_VGIC_GRP_LEVEL_INFO group and how it relates to > the config of edge vs. level of interrupts and ordering on restore... IIRC the QEMU code restores the config first. (There's a similar ordering thing for GICv2 where we have to restore GICD_ICFGRn before GICD_ISPENDRn.) thanks -- PMM _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
