On Tue, 2014-09-23 at 16:21 -0600, Alex Williamson wrote:
> On Tue, 2014-09-23 at 16:46 +0200, Antonios Motakis wrote:
> > We introduce the VFIO_DMA_MAP_FLAG_NOEXEC flag to the VFIO dma map call,
> > and expose its availability via the capability VFIO_IOMMU_PROT_NOEXEC.
> > This way the user can control whether the XN flag will be set on the
> > requested mappings. The IOMMU_NOEXEC flag needs to be available for all
> > the IOMMUs of the container used.
> >
> > Signed-off-by: Antonios Motakis <a.motakis@xxxxxxxxxxxxxxxxxxxxxx>
> > ---
> > include/uapi/linux/vfio.h | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > index 6612974..30f630c 100644
> > --- a/include/uapi/linux/vfio.h
> > +++ b/include/uapi/linux/vfio.h
> > @@ -29,6 +29,7 @@
> > * capability is subject to change as groups are added or removed.
> > */
> > #define VFIO_DMA_CC_IOMMU 4
> > +#define VFIO_IOMMU_PROT_NOEXEC 5
>
> Can't we advertise this as a flag bit in vfio_iommu_type1_info instead?
Ok, I see in the next patch that it's pretty similar to
VFIO_DMA_CC_IOMMU, so the check extension is probably correct for
determining the current state. Maybe we could name it more similarly,
VFIO_DMA_NOEXEC_IOMMU. I guess the intended usage is that once a user
attaches a group to the container they can query whether the
VFIO_DMA_MAP_FLAG_NOEXEC is valid. Ok. Thanks,
Alex
> Also, EEH already took 5 as seen immediately below.
>
> >
> > /* Check if EEH is supported */
> > #define VFIO_EEH 5
> > @@ -401,6 +402,7 @@ struct vfio_iommu_type1_dma_map {
> > __u32 flags;
> > #define VFIO_DMA_MAP_FLAG_READ (1 << 0) /* readable from device */
> > #define VFIO_DMA_MAP_FLAG_WRITE (1 << 1) /* writable from device */
> > +#define VFIO_DMA_MAP_FLAG_NOEXEC (1 << 2) /* not executable from device */
> > __u64 vaddr; /* Process virtual address */
> > __u64 iova; /* IO virtual address */
> > __u64 size; /* Size of mapping (bytes) */
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
