On Wed, Jul 6, 2022 at 9:11 AM Aaron Lewis <aaronlewis@xxxxxxxxxx> wrote: > > > > +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. Once conflicts are disallowed, how is the behavior changed by an 'invert' entry? Isn't the behavior the same as not including the entry at all?
