On 12/18/2018 12:24 PM, Cornelia Huck wrote:
On Mon, 17 Dec 2018 16:53:34 -0500
Eric Farman <farman@xxxxxxxxxxxxx> 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)
