[PATCH v9 3/6] drm/xe/uapi: Define drm_xe_vm_get_property
Cavitt, Jonathan
jonathan.cavitt at intel.com
Wed Mar 19 21:13:56 UTC 2025
-----Original Message-----
From: Zhang, Jianxun <jianxun.zhang at intel.com>
Sent: Wednesday, March 19, 2025 2:02 PM
To: Cavitt, Jonathan <jonathan.cavitt at intel.com>; intel-xe at lists.freedesktop.org
Cc: Gupta, saurabhg <saurabhg.gupta at intel.com>; Zuo, Alex <alex.zuo at intel.com>; joonas.lahtinen at linux.intel.com; Brost, Matthew <matthew.brost at intel.com>; Lin, Shuicheng <shuicheng.lin at intel.com>; dri-devel at lists.freedesktop.org; Wajdeczko, Michal <Michal.Wajdeczko at intel.com>; Mrozek, Michal <michal.mrozek at intel.com>
Subject: Re: [PATCH v9 3/6] drm/xe/uapi: Define drm_xe_vm_get_property
>
> ________________________________________
> From: Cavitt, Jonathan <jonathan.cavitt at intel.com>
> Sent: Wednesday, March 19, 2025 1:13 PM
> To: Zhang, Jianxun; intel-xe at lists.freedesktop.org
> Cc: Gupta, saurabhg; Zuo, Alex; joonas.lahtinen at linux.intel.com; Brost, Matthew; Lin, Shuicheng; dri-devel at lists.freedesktop.org; Wajdeczko, Michal; Mrozek, Michal; Cavitt, Jonathan
> Subject: RE: [PATCH v9 3/6] drm/xe/uapi: Define drm_xe_vm_get_property
>
> -----Original Message-----
> From: Zhang, Jianxun <jianxun.zhang at intel.com>
> Sent: Wednesday, March 19, 2025 12:59 PM
> To: Cavitt, Jonathan <jonathan.cavitt at intel.com>; intel-xe at lists.freedesktop.org
> Cc: Gupta, saurabhg <saurabhg.gupta at intel.com>; Zuo, Alex <alex.zuo at intel.com>; joonas.lahtinen at linux.intel.com; Brost, Matthew <matthew.brost at intel.com>; Lin, Shuicheng <shuicheng.lin at intel.com>; dri-devel at lists.freedesktop.org; Wajdeczko, Michal <Michal.Wajdeczko at intel.com>; Mrozek, Michal <michal.mrozek at intel.com>
> Subject: Re: [PATCH v9 3/6] drm/xe/uapi: Define drm_xe_vm_get_property
> >
> > On 3/18/25 10:11, Jonathan Cavitt wrote:
> > > Add initial declarations for the drm_xe_vm_get_property ioctl.
> > >
> > > v2:
> > > - Expand kernel docs for drm_xe_vm_get_property (Jianxun)
> > >
> > > Signed-off-by: Jonathan Cavitt <jonathan.cavitt at intel.com>
> > > Cc: Zhang Jianxun <jianxun.zhang at intel.com>
> > > ---
> > > include/uapi/drm/xe_drm.h | 80 +++++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 80 insertions(+)
> > >
> > > diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
> > > index 616916985e3f..ef335471653e 100644
> > > --- a/include/uapi/drm/xe_drm.h
> > > +++ b/include/uapi/drm/xe_drm.h
> > > @@ -81,6 +81,7 @@ extern "C" {
> > > * - &DRM_IOCTL_XE_EXEC
> > > * - &DRM_IOCTL_XE_WAIT_USER_FENCE
> > > * - &DRM_IOCTL_XE_OBSERVATION
> > > + * - &DRM_IOCTL_XE_VM_GET_PROPERTY
> > > */
> > >
> > > /*
> > > @@ -102,6 +103,7 @@ extern "C" {
> > > #define DRM_XE_EXEC 0x09
> > > #define DRM_XE_WAIT_USER_FENCE 0x0a
> > > #define DRM_XE_OBSERVATION 0x0b
> > > +#define DRM_XE_VM_GET_PROPERTY 0x0c
> > >
> > > /* Must be kept compact -- no holes */
> > >
> > > @@ -117,6 +119,7 @@ extern "C" {
> > > #define DRM_IOCTL_XE_EXEC DRM_IOW(DRM_COMMAND_BASE + DRM_XE_EXEC, struct drm_xe_exec)
> > > #define DRM_IOCTL_XE_WAIT_USER_FENCE DRM_IOWR(DRM_COMMAND_BASE + DRM_XE_WAIT_USER_FENCE, struct drm_xe_wait_user_fence)
> > > #define DRM_IOCTL_XE_OBSERVATION DRM_IOW(DRM_COMMAND_BASE + DRM_XE_OBSERVATION, struct drm_xe_observation_param)
> > > +#define DRM_IOCTL_XE_VM_GET_PROPERTY DRM_IOWR(DRM_COMMAND_BASE + DRM_XE_VM_GET_PROPERTY, struct drm_xe_vm_get_property)
> > >
> > > /**
> > > * DOC: Xe IOCTL Extensions
> > > @@ -1189,6 +1192,83 @@ struct drm_xe_vm_bind {
> > > __u64 reserved[2];
> > > };
> > >
> > > +/** struct xe_vm_fault - Describes faults for %DRM_XE_VM_GET_PROPERTY_FAULTS */
> > > +struct xe_vm_fault {
> > > + /** @address: Address of the fault */
> > > + __u64 address;
> > > +#define DRM_XE_FAULT_ADDRESS_TYPE_NONE_EXT 0
>
> > Just a question, VK_DEVICE_FAULT_ADDRESS_TYPE_NONE_EXT in Vulkan spec
> > specifies the address of the fault does not describe a page fault, or an
> > instruction address. Does this NONE type in KMD mean the same thing?
>
> I think it means that the page that was attempted to be accessed did not exist.
> Read, by comparison, means that the page existed, but that permission was
> not granted to read the contents. Write means the same thing for write
> permissions.
>
> At least, that was my understanding.
>
> -Jonathan Cavitt
>
> But no matter if the page existing or not, the type of access, read, write or exec is always present. Make sense?
Yeah, that makes sense. Though I don't think that's what the address type field is being used for?
Here's the itemized list of places where these address types are used:
DRM_XE_FAULT_ADDRESS_TYPE_NONE_EXT:
Used during pagefault handling, if no associated VM was found. It's also technically the default address type
(as the pagefault structure is initialized to all zeroes).
DRM_XE_FAULT_ADDRESS_TYPE_READ_INVALID_EXT:
Currently unused
DRM_XE_FAULT_ADDRESS_TYPE_WRITE_INVALID_EXT:
Reported if we attempt to perform a non-read operation on a read-only VMA.
Should we expand this list before creating the next revision? Or perhaps rename address_type to
something else?
-Jonathan Cavitt
>
> > > +#define DRM_XE_FAULT_ADDRESS_TYPE_READ_INVALID_EXT 1
> > > +#define DRM_XE_FAULT_ADDRESS_TYPE_WRITE_INVALID_EXT 2
> > > + /** @address_type: Type of address access that resulted in fault */
> > > + __u32 address_type;
> > > + /** @address_precision: Precision of faulted address */
> > > + __u32 address_precision;
> > > + /** @fault_level: fault level of the fault */
> > > + __u8 fault_level;
> > > + /** @engine_class: class of engine fault was reported on */
> > > + __u8 engine_class;
> > > + /** @engine_instance: instance of engine fault was reported on */
> > > + __u8 engine_instance;
> > > + /** @pad: MBZ */
> > > + __u8 pad[5];
> > > + /** @reserved: MBZ */
> > > + __u64 reserved[3];
> > > +};
> > > +
> > > +/**
> > > + * struct drm_xe_vm_get_property - Input of &DRM_IOCTL_XE_VM_GET_PROPERTY
> > > + *
> > > + * The user provides a VM and a property to query among DRM_XE_VM_GET_PROPERTY_*,
> > > + * and sets the values in the vm_id and property members, respectively. This
> > > + * determines both the VM to get the property of, as well as the property to
> > > + * report.
> > > + *
> > > + * If size is set to 0, the driver fills it with the required size for the
> > > + * requested property. The user is expected here to allocate memory for the
> > > + * property structure and to provide a pointer to the allocated memory using the
> > > + * data member. For some properties, this may be zero, in which case, the
> > > + * value of the property will be saved to the value member and size will remain
> > > + * zero on return.
> > > + *
> > > + * If size is not zero, then the IOCTL will attempt to copy the requested
> > > + * property into the data member.
> > > + *
> > > + * The IOCTL will return -ENOENT if the VM could not be identified from the
> > > + * provided VM ID, or -EINVAL if the IOCTL fails for any other reason, such as
> > > + * providing an invalid size for the given property or if the property data
> > > + * could not be copied to the memory allocated to the data member.
> > > + *
> > > + * The property member can be:
> > > + * - %DRM_XE_VM_GET_PROPERTY_FAULTS
> > > + */
> > > +struct drm_xe_vm_get_property {
> > > + /** @extensions: Pointer to the first extension struct, if any */
> > > + __u64 extensions;
> > > +
> > > + /** @vm_id: The ID of the VM to query the properties of */
> > > + __u32 vm_id;
> > > +
> > > +#define DRM_XE_VM_GET_PROPERTY_FAULTS 0
> > > + /** @property: property to get */
> > > + __u32 property;
> > > +
> > > + /** @size: Size to allocate for @data */
> > > + __u32 size;
> > > +
> > > + /** @pad: MBZ */
> > > + __u32 pad;
> > > +
> > > + union {
> > > + /** @data: Pointer to user-defined array of flexible size and type */
> > > + __u64 data;
> > > + /** @value: Return value for scalar queries */
> > > + __u64 value;
> > > + };
> > > +
> > > + /** @reserved: MBZ */
> > > + __u64 reserved[3];
> > > +};
> > > +
> > > /**
> > > * struct drm_xe_exec_queue_create - Input of &DRM_IOCTL_XE_EXEC_QUEUE_CREATE
> > > *
> >
> >
>
More information about the Intel-xe
mailing list