Change Details

A series of four commits stemming from the interaction between how indicies are best handled in C, versus the API used by Xen. Xen numbers event channels starting from one. C arrays start from zero. Since xen_intr.c has to convert event channel numbers into a structure pointer, an array is used. Previously element 0 was never used since the conversion wasn't being done. Clean this up. This misfit caused at least one test line to be wrong. The result would be an overflow under some hard to produce conditions (not believed possible for attack), fix this. Some macros had been setup for interacting with the event channel, but they weren't being consistently used. Start using them in more places. This is actually 4 commits being submitted as one, since they're closely related and 3 were kind of small by themselves. There is room for separate resubmission, or potentially they could be squashed on commit.

A series of four commits stemming from the interaction between how indicies are best handled in C, versus the 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 come to the conclusion 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 under all conditions. 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 4 commits being submitted as one, since they're closely related and 3 were kind of small by themselves. There is room for separate resubmission, or potentially they could be squashed on commit.

A series of four commits stemming from the interaction between how indicies are best handled in C, versus the API used by Xen. Xen numbers event channels starting from oneOne test line was wrong. C arrays start from zero.The result would be an overflow under some Since xen_intr.c has to convert event channel numbers into a structurehard to produce conditions (not believed possible for attack), fix this. I've come to the conclusion is_valid_evtchn() was serving to obscure, pointer, an array is used. Previously element 0 was never used since the conversion wasn't being donerather than isolating anything useful. CleanAs such remove this upmacro. This misfit caused at least one test line to be wrongThere was some inconsistency when clearing xenisrc structures. The result wouldNow be an overflow under some hard to produceuse ~0 which is guaranteed invalid under all conditions (not believed. Also clean up possible for attack), fix thisone spot not using the proper variable when accessing xen_intr_port_to_isrc[]. Some macros had been setup for interacting with the event channel, butevtchn_cpu_mask_port()/evtchn_cpu_unmask_port() were misnamed as they weren't being consistently used. Start using them in more places're part of the interrupt code, not the event channel code. This is actually 4 commits being submitted as one, since they're closely related and 3 were kind of small by themselves. There is room for separate resubmission, or potentially they could be squashed on commit.