Papi normally uses the OS_NONE mode. But I changed the call to pfm_get_os_event_encoding to use the OS_PERF_EVENT_EXT mode for the test I mentioned below.
If we could get to the encode call it might work. But before papi calls the encode function, it calls pfm_find_event passing the event string (which includes an extended mask). The code in libpfm4 is hard coded to force OS_NONE to get used by pfmlib_build_event_pattrs (which gets called under pfm_find_event).
So the problem is that event strings which contain an extended mask cannot be passed to pfm_find_event. If you do it always returns an error.
I ran both of the libpfm4 examples you show below and they both worked correctly. But when I turned on libpfm4 debug, it showed that neither of them ever called pfm_find_event (I have inserted an extra debug message in my version so I can see if it gets called).
I do not know why papi uses pfm_find_event but do not think I am up to restructuring the way papi uses the libpfm4 API.
So it looks like I cannot use your extended masks unless pfm_find_event can accept event strings that contain them.
As a test, I put a change in the pfm_find_event to force the osid index to PFM_OS_PERF_EVENT_EXT after the new event table is cleared. With this change, when PAPI uses the cpu mask it seems to work (at least I do not get any errors and the cpu number comes back from the encode function in the arg structure). I have not done the papi changes yet to use it but that should be possible.
So with it sort of working, I tried to list the native events with papi_native_avail. The list did not show the cpu mask on any of the events (probably somewhere in the papi or libpfm4 list code I will need to force it to use the extended OS mode).
After getting it working part way, I am not convinced it is cleaner than what I had added to libpfm4. Making this work with extended event masks will also require changes in both papi and libpfm4. The change I made above to force pfm_find_event to always use extended masks may not be the right approach. In addition papi will not be able to use this approach to add additional masks in its effort to change the effective scope of other papi attributes (without additional support in libpfm4 to also know about new masks for those attributes). The patch I gave you allows papi to extend the event masks without you having to know anything about what they are doing.
But you are in charge so do you want to go with the patch I had provided or do you want me to make it work using extended event masks ?
I am sorry this has been a pain but thanks a bunch for your help and understanding.