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-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
---
include/uapi/linux/vfio.h | 2 ++
1 file changed, 2 insertions(+)
From: Alex Williamson <hidden> Date: 2014-09-23 22:21:31
On Tue, 2014-09-23 at 16:46 +0200, Antonios Motakis wrote:
quoted hunk
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-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
---
include/uapi/linux/vfio.h | 2 ++
1 file changed, 2 insertions(+)
From: Alex Williamson <hidden> Date: 2014-09-23 22:30:40
On Tue, 2014-09-23 at 16:21 -0600, Alex Williamson wrote:
On Tue, 2014-09-23 at 16:46 +0200, Antonios Motakis wrote:
quoted
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-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
---
include/uapi/linux/vfio.h | 2 ++
1 file changed, 2 insertions(+)
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.
quoted
/* Check if EEH is supported */
#define VFIO_EEH 5
On Wed, Sep 24, 2014 at 12:30 AM, Alex Williamson
[off-list ref] wrote:
On Tue, 2014-09-23 at 16:21 -0600, Alex Williamson wrote:
quoted
On Tue, 2014-09-23 at 16:46 +0200, Antonios Motakis wrote:
quoted
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-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
---
include/uapi/linux/vfio.h | 2 ++
1 file changed, 2 insertions(+)
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,
Sorry for the numbering, ack and ack :)
Alex
quoted
Also, EEH already took 5 as seen immediately below.
quoted
/* Check if EEH is supported */
#define VFIO_EEH 5