Re: [PATCH 1/3] vfio-ccw: add capabilities chain

Eric Farman
2018-12-18T17:56:08Z

On 12/18/2018 12:24 PM, Cornelia Huck wrote:
> On Mon, 17 Dec 2018 16:53:34 -0500
> Eric Farman <farman@linux.ibm.com> wrote:
>
>> On 11/22/2018 11:54 AM, Cornelia Huck wrote:
>>
>> ...snip...
>>
>>> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
>>> index 813102810f53..565669f95534 100644
>>> --- a/include/uapi/linux/vfio.h
>>> +++ b/include/uapi/linux/vfio.h
>>> @@ -297,6 +297,7 @@ struct vfio_region_info_cap_type {
>>>
>>> #define VFIO_REGION_TYPE_PCI_VENDOR_TYPE (1 << 31)
>>> #define VFIO_REGION_TYPE_PCI_VENDOR_MASK (0xffff)
>>> +#define VFIO_REGION_TYPE_CCW (1 << 30)
>>
>> Oof. So the existing VFIO_REGION_TYPE_PCI_VENDOR_TYPE gets OR'd with
>> another value (e.g., 8086). But in 4.20, there was a
>> VFIO_REGION_TYPE_GFX is added as simply "1" ... Which direction are
>> these definitions being added from? I guess asked another way, is
>> _TYPE_CCW going to be OR'd with anything else that necessitates its
>> presence as an identifier with some Other Thing, or should this follow
>> the TYPE_GFX enumeration? Perhaps the type field needs to be tidied up
>> to help this sit more cleanly now? (Sorry!)
>
> The semantics of that type stuff are really a bit unclear to me :(

+1

I was confused when I first looked at this. When I applied it to 4.20,
I got another level of confusion. ;)

>
> I don't think we'll ever do any fancy mask handling for ccw. It is
> probably enough to have any kind of uniqueness within the different
> types, so maybe counting up would be indeed enough...

Considering the subtype space, I think it would be fine too. But wanted
to ask in case I've been out of the loop on something.

>
>>
>> - Eric
>>
>>>
>>> /* 8086 Vendor sub-types */
>>> #define VFIO_REGION_SUBTYPE_INTEL_IGD_OPREGION (1)
>>>
>>
>