[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAG8rG2wrt43HJeRjHPF_M6oXvmiDH6WRPm8dHXhT0QoP0YH+9g@mail.gmail.com>
Date: Fri, 26 Sep 2014 17:45:15 +0200
From: Antonios Motakis <a.motakis@...tualopensystems.com>
To: Alex Williamson <alex.williamson@...hat.com>
Cc: kvm-arm <kvmarm@...ts.cs.columbia.edu>,
Linux IOMMU <iommu@...ts.linux-foundation.org>,
VirtualOpenSystems Technical Team <tech@...tualopensystems.com>,
KVM devel mailing list <kvm@...r.kernel.org>,
Christoffer Dall <christoffer.dall@...aro.org>,
Will Deacon <will.deacon@....com>,
Kim Phillips <kim.phillips@...escale.com>,
Eric Auger <eric.auger@...aro.org>,
Marc Zyngier <marc.zyngier@....com>,
"open list:ABI/API" <linux-api@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCHv7 05/26] vfio: introduce the VFIO_DMA_MAP_FLAG_NOEXEC flag
On Wed, Sep 24, 2014 at 12:30 AM, Alex Williamson
<alex.williamson@...hat.com> wrote:
> 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@...tualopensystems.com>
>> > ---
>> > 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,
>
Sorry for the numbering, ack and ack :)
> 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) */
>>
>>
>
>
>
--
Antonios Motakis
Virtual Open Systems
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists