On Thu, 28 Sep 2017 14:07:05 +0200 Joerg Roedel <[email protected]> wrote:
> On Wed, Sep 27, 2017 at 10:51:55AM -0700, Jacob Pan wrote: > > On Wed, 27 Sep 2017 15:40:41 +0200 > > Joerg Roedel <[email protected]> wrote: > > > enum pasid_table_model { > > > PASID_TABLE_INTEL, > > > PASID_TABLE_ARM, > > > PASID_TABLE_AMD, > > > /* ... */ > > > }; > > > > > I guess one vendor could have multiple pasid table format. so > > perhaps the name could reflect the format as well? > > Yes, that makes sense. > > > > struct pasid_table_config { > > > __u64 base_ptr; > > > __u8 pasid_bits; > > > union { > > > struct { > > > /* Intel specific fields */ > > > } intel; > > > > > > struct { > > > /* ARM specific fields */ > > > } arm; > > > > > > > > > struct { > > > /* AMD specific fields */ > > > } amd; > > > > > > /* ... */ > > > }; > > > }; > > > > > > How does that look? > > > > > It should work for us for now but I am not sure how stable the > > vendor specific fields will be, this is UAPI. BTW, do you also > > intend to include the pasid_table_model # in pasid_table_config? > > If its going to be UAPI then we probably also need a version and a > length/size field. But since individual formats do not change, their > sub-struct should be stable. > just to confirm, we have two separate APIs for bind_pasid_table_ptr and bind_page_table. For the former, we need to passdown the following info from qemu/vfio. For now struct pasid_table_config { __u32 version; #define PASID_TABLE_CONFIG_VERSION_1 (1) __u32 bytes; __u64 base_ptr; __u8 pasid_bits; enum pasid_table_model model; union { struct { /* Intel specific fields */ } intel; struct { /* ARM specific fields */ } arm; struct { /* AMD specific fields */ } amd; /* ... */ }; }; > Regards, > > Joerg > [Jacob Pan] _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
