> > +In this mode each event in the events field will be encoded with mask, match, > > +and invert values in addition to an eventsel. These encoded events will be > > +matched against the event the guest is attempting to program to determine > > +whether the guest should have access to it. When matching an encoded event > > +with a guest event these steps are followed: > > + 1. Match the encoded eventsel to the guest eventsel. > > + 2. If that matches, match the mask and match values from the encoded event to > > + the guest's unit mask (ie: unit_mask & mask == match). > > + 3. If that matches, the guest is allow to program the event if its an allow > > + list or the guest is not allow to program the event if its a deny list. > > + 4. If the invert value is set in the encoded event, reverse the meaning of #3 > > + (ie: deny if its an allow list, allow if it's a deny list). > > The invert flag introduces some ambiguity. What if a particular event > matches two of the masked filter entries: one with an invert flag and > one without? > That's a good point! I think I can deal with that by validating the events when they are being set to ensure that for a particular event the invert flags are all set the same way and return EINVAL if they're not.
