Change Details

A series of three commits stemming from the interaction between how indicies are best handled in C, versus the event channel API used by Xen. One test line was wrong. The result would be an overflow under some hard to produce conditions (not believed possible for attack), fix this. I've concluded is_valid_evtchn() was serving to obscure, rather than isolating anything useful. As such remove this macro. There was some inconsistency when clearing xenisrc structures. Now use ~0 which is guaranteed invalid, instead of 0 which is reserved //not// invalid. Also clean up one spot not using the proper variable when accessing xen_intr_port_to_isrc[]. evtchn_cpu_mask_port()/evtchn_cpu_unmask_port() were misnamed as they're part of the interrupt code, not the event channel code. This is actually 3 commits being submitted as one, since they're closely related and were kind of small by themselves. There is room for separate resubmission, or potentially they could be squashed on commit.

A series of three commits stemming from the interaction between how indicies are best handled in C, versus the event channel API used by Xen. One test line was wrong. The result would be an overflow under some hard to produce conditions (not believed possible for attack), fix this. The removal from xen_intr_port_to_isrc[] inside xen_intr_release_isrc() was wrong. If ->xi_port was invalid an entry would be incorrectly cleared. Previously this was mitigated by 0 being used as the invalid value for ->xi_port, but this will now manifest due to ~0 being used instead. I've concluded is_valid_evtchn() was serving to obscure, rather than usefully isolating anything. As such remove this macro. There was some inconsistency when clearing xenisrc structures. Now use ~0 which is guaranteed invalid, instead of 0 which is reserved //not// invalid. Use isrc->xi_port whenever possible. This aids identifying duplicate sections, aiding potential merges. This is actually 3 commits being submitted as one, since they're closely related and were kind of small by themselves. Potentially they could be squashed on commit.

A series of three commits stemming from the interaction between how indicies are best handled in C, versus the event channel API used by Xen. One test line was wrong. The result would be an overflow under some hard to produce conditions (not believed possible for attack), fix this. The removal from xen_intr_port_to_isrc[] inside xen_intr_release_isrc() was wrong. If ->xi_port was invalid an entry would be incorrectly cleared. Previously this was mitigated by 0 being used as the invalid value for ->xi_port, but this will now manifest due to ~0 being used instead. I've concluded is_valid_evtchn() was serving to obscure, rather than usefully isolating anything useful. As such remove this macro. There was some inconsistency when clearing xenisrc structures. Now use ~0 which is guaranteed invalid, instead of 0 which is reserved //not// invalid. Also clean up one spot not using the proper variable when accessing xen_intr_port_to_isrc[]. evtchn_cpu_maskUse isrc->xi_port()/evtchn_cpu_unmask_port() were misnamed as they're part of the interrupt code whenever possible. This aids identifying duplicate sections, not the event channel codeaiding potential merges. This is actually 3 commits being submitted as one, since they're closely related and were kind of small by themselves. There is room for separate resubmission, or pPotentially they could be squashed on commit.