From: "Yao, Jiewen" <jiewen.yao@intel.com>
To: "Kinney, Michael D" <michael.d.kinney@intel.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "Ni, Ruiyu" <ruiyu.ni@intel.com>, Leo Duran <leo.duran@amd.com>,
"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
Brijesh Singh <brijesh.singh@amd.com>
Subject: Re: [PATCH 1/3] MdeModulePkg/Include: Add IOMMU protocol definition.
Date: Tue, 28 Mar 2017 23:45:50 +0000 [thread overview]
Message-ID: <74D8A39837DF1E4DA445A8C0B3885C503A916565@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <E92EE9817A31E24EB0585FDF735412F57D163D00@ORSMSX113.amr.corp.intel.com>
Agree. That is a good idea.
I will add that in V2 patch.
Thank you
Yao Jiewen
From: Kinney, Michael D
Sent: Wednesday, March 29, 2017 7:03 AM
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Yao, Jiewen <jiewen.yao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Ni, Ruiyu <ruiyu.ni@intel.com>; Leo Duran <leo.duran@amd.com>; edk2-devel@lists.01.org; Brijesh Singh <brijesh.singh@amd.com>
Subject: RE: [edk2] [PATCH 1/3] MdeModulePkg/Include: Add IOMMU protocol definition.
Ard,
I agree. And I think the IOMMU protocol should also support flexible
double buffer operations so the extra copies by the host CPU can be
avoided if the logical DMA address can directly map to the original
buffer.
Mike
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ard
> Biesheuvel
> Sent: Tuesday, March 28, 2017 3:39 PM
> To: Yao, Jiewen <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>
> Cc: Ni, Ruiyu <ruiyu.ni@intel.com<mailto:ruiyu.ni@intel.com>>; Leo Duran <leo.duran@amd.com<mailto:leo.duran@amd.com>>; edk2-
> devel@lists.01.org<mailto:devel@lists.01.org>; Brijesh Singh <brijesh.singh@amd.com<mailto:brijesh.singh@amd.com>>
> Subject: Re: [edk2] [PATCH 1/3] MdeModulePkg/Include: Add IOMMU protocol
> definition.
>
> On 25 March 2017 at 09:28, Jiewen Yao <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>> wrote:
> > This protocol is to abstract IOMMU access.
> >
> > Cc: Ruiyu Ni <ruiyu.ni@intel.com<mailto:ruiyu.ni@intel.com>>
> > Cc: Leo Duran <leo.duran@amd.com<mailto:leo.duran@amd.com>>
> > Cc: Brijesh Singh <brijesh.singh@amd.com<mailto:brijesh.singh@amd.com>>
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Jiewen Yao <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>
>
> Hello all,
>
> It would be very useful for a IOMMU protocol such as this one to
> support non-identity mappings between the host and the PCI bus.
>
> On 64-bit ARM systems, no RAM may exist below 4 GB, and if a IOMMU is
> available, it could be used to remap RAM for DMA in a way that makes
> it 32-bit addressable for PCI masters that are not 64-bit capable.
>
> The PCI protocols in UEFI already allow such non-identity mappings. If
> a IOMMU protocol is introduced, it makes sense to allow it to be
> involved in establishing the device address when performing a map
> operation.
>
> --
> Ard.
>
>
> > ---
> > MdeModulePkg/Include/Protocol/IoMmu.h | 132 ++++++++++++++++++++
> > MdeModulePkg/MdeModulePkg.dec | 3 +
> > 2 files changed, 135 insertions(+)
> >
> > diff --git a/MdeModulePkg/Include/Protocol/IoMmu.h
> b/MdeModulePkg/Include/Protocol/IoMmu.h
> > new file mode 100644
> > index 0000000..55b9c78
> > --- /dev/null
> > +++ b/MdeModulePkg/Include/Protocol/IoMmu.h
> > @@ -0,0 +1,132 @@
> > +/** @file
> > + EFI IOMMU Protocol.
> > +
> > +Copyright (c) 2017, Intel Corporation. All rights reserved.<BR>
> > +This program and the accompanying materials are licensed and made available
> under
> > +the terms and conditions of the BSD License that accompanies this distribution.
> > +The full text of the license may be found at
> > +http://opensource.org/licenses/bsd-license.php.
> > +
> > +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> > +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> > +
> > +**/
> > +
> > +
> > +#ifndef __IOMMU_H__
> > +#define __IOMMU_H__
> > +
> > +//
> > +// IOMMU Protocol GUID value
> > +//
> > +#define EDKII_IOMMU_PROTOCOL_GUID \
> > + { \
> > + 0x4e939de9, 0xd948, 0x4b0f, { 0x88, 0xed, 0xe6, 0xe1, 0xce, 0x51, 0x7c,
> 0x1e } \
> > + }
> > +
> > +//
> > +// Forward reference for pure ANSI compatability
> > +//
> > +typedef struct _EDKII_IOMMU_PROTOCOL EDKII_IOMMU_PROTOCOL;
> > +
> > +//
> > +// Revision The revision to which the IOMMU interface adheres.
> > +// All future revisions must be backwards compatible.
> > +// If a future version is not back wards compatible it is not the same
> GUID.
> > +//
> > +#define EDKII_IOMMU_PROTOCOL_REVISION 0x00010000
> > +
> > +//
> > +// IOMMU attribute.
> > +// These types can be "ORed" together as needed.
> > +// Any undefined bits are reserved and must be zero.
> > +//
> > +#define EDKII_IOMMU_ATTRIBUTE_READ 0x1
> > +#define EDKII_IOMMU_ATTRIBUTE_WRITE 0x2
> > +
> > +/**
> > + Set IOMMU attribute for a system memory.
> > +
> > + If the IOMMU protocol exists, the system memory cannot be used
> > + for DMA by default.
> > +
> > + When a device requests a DMA access for a system memory,
> > + the device driver need use SetAttribute() to update the IOMMU
> > + attribute to request DMA access (read and/or write).
> > +
> > + The DeviceHandle is used to identify which device it is.
> > + The IOMMU implementation need translate the device path to an IOMMU device ID,
> > + and set IOMMU hardware register accordingly.
> > + 1) DeviceHandle can be a standard PCI device.
> > + The memory for BusMasterRead need set EDKII_IOMMU_ATTRIBUTE_READ.
> > + The memory for BusMasterWrite need set EDKII_IOMMU_ATTRIBUTE_WRITE.
> > + The memory for BusMasterCommonBuffer need set
> EDKII_IOMMU_ATTRIBUTE_READ|EDKII_IOMMU_ATTRIBUTE_WRITE.
> > + After the memory is used, the memory need set 0 to keep it being protected.
> > + 2) DeviceHandle can be an ACPI device (ISA, I2C, SPI, etc).
> > + The memory for DMA access need set EDKII_IOMMU_ATTRIBUTE_READ and/or
> EDKII_IOMMU_ATTRIBUTE_WRITE.
> > +
> > + @param This The protocol instance pointer.
> > + @param DeviceHandle The device who initiates the DMA access request.
> > + @param BaseAddress The base of system memory address to be used as the
> DMA memory.
> > + @param Length The length of system memory address to be used as
> the DMA memory.
> > + @param IoMmuAttribute The IOMMU attribute.
> > +
> > + @retval EFI_SUCCESS The IoMmuAttribute is set for the memory range
> specified by BaseAddress and Length.
> > + @retval EFI_INVALID_PARAMETER DeviceHandle is an invalid handle.
> > + @retval EFI_INVALID_PARAMETER BaseAddress is not IoMmu Page size aligned.
> > + @retval EFI_INVALID_PARAMETER Length is not IoMmu Page size aligned.
> > + @retval EFI_INVALID_PARAMETER Length is 0.
> > + @retval EFI_INVALID_PARAMETER IoMmuAttribute specified an illegal combination
> of attributes.
> > + @retval EFI_UNSUPPORTED DeviceHandle is unknown by the IOMMU.
> > + @retval EFI_UNSUPPORTED The bit mask of IoMmuAttribute is not supported
> by the IOMMU.
> > + @retval EFI_UNSUPPORTED The IOMMU does not support the memory range
> specified by BaseAddress and Length.
> > + @retval EFI_OUT_OF_RESOURCES There are not enough resources available to
> modify the IOMMU attribute.
> > + @retval EFI_DEVICE_ERROR The IOMMU device reported an error while
> attempting the operation.
> > +
> > +**/
> > +typedef
> > +EFI_STATUS
> > +(EFIAPI *EDKII_IOMMU_SET_ATTRIBUTE)(
> > + IN EDKII_IOMMU_PROTOCOL *This,
> > + IN EFI_HANDLE DeviceHandle,
> > + IN UINT64 BaseAddress,
> > + IN UINT64 Length,
> > + IN UINT64 IoMmuAttribute
> > + );
> > +
> > +/**
> > + Get IOMMU page size.
> > +
> > + This is the minimal supported page size for a IOMMU.
> > + For example, if an IOMMU supports 4KiB, 2MiB and 1GiB,
> > + 4KiB should be returned.
> > +
> > + @param This Protocol instance pointer.
> > + @param PageSize The minimal supported page size for a IOMMU.
> > +
> > + @retval EFI_SUCCESS The page size is returned.
> > + @retval EFI_INVALID_PARAMETER PageSize is NULL.
> > +
> > +**/
> > +typedef
> > +EFI_STATUS
> > +(EFIAPI *EDKII_IOMMU_GET_PAGE_SIZE)(
> > + IN EDKII_IOMMU_PROTOCOL *This,
> > + OUT UINTN *PageSize
> > + );
> > +
> > +///
> > +/// IOMMU Protocol structure.
> > +///
> > +struct _EDKII_IOMMU_PROTOCOL {
> > + UINT64 Revision;
> > + EDKII_IOMMU_GET_PAGE_SIZE GetPageSize;
> > + EDKII_IOMMU_SET_ATTRIBUTE SetAttribute;
> > +};
> > +
> > +///
> > +/// IOMMU Protocol GUID variable.
> > +///
> > +extern EFI_GUID gEdkiiIoMmuProtocolGuid;
> > +
> > +#endif
> > diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
> > index 356b3e1..db596b6 100644
> > --- a/MdeModulePkg/MdeModulePkg.dec
> > +++ b/MdeModulePkg/MdeModulePkg.dec
> > @@ -540,6 +540,9 @@
> > ## Include/Protocol/NonDiscoverableDevice.h
> > gEdkiiNonDiscoverableDeviceProtocolGuid = { 0x0d51905b, 0xb77e, 0x452a, {0xa2,
> 0xc0, 0xec, 0xa0, 0xcc, 0x8d, 0x51, 0x4a } }
> >
> > + ## Include/Protocol/IoMmu.h
> > + gEdkiiIoMmuProtocolGuid = { 0x4e939de9, 0xd948, 0x4b0f, { 0x88, 0xed, 0xe6,
> 0xe1, 0xce, 0x51, 0x7c, 0x1e } }
> > +
> > #
> > # [Error.gEfiMdeModulePkgTokenSpaceGuid]
> > # 0x80000001 | Invalid value provided.
> > --
> > 2.7.4.windows.1
> >
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel
next prev parent reply other threads:[~2017-03-28 23:45 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-25 9:28 [RFC] [PATCH 0/3] Add IOMMU support Jiewen Yao
2017-03-25 9:28 ` [PATCH 1/3] MdeModulePkg/Include: Add IOMMU protocol definition Jiewen Yao
2017-03-28 22:38 ` Ard Biesheuvel
2017-03-28 23:02 ` Kinney, Michael D
2017-03-28 23:45 ` Yao, Jiewen [this message]
2017-03-29 14:22 ` Ard Biesheuvel
2017-03-30 12:37 ` Yao, Jiewen
2017-03-30 13:54 ` Ard Biesheuvel
2017-03-25 9:28 ` [RFC] [PATCH 2/3] MdeModulePkg/PciHostBridge: Add IOMMU support Jiewen Yao
2017-03-27 5:31 ` Ni, Ruiyu
2017-03-27 6:01 ` Yao, Jiewen
2017-03-27 6:18 ` Ni, Ruiyu
2017-03-27 6:23 ` Yao, Jiewen
2017-03-27 6:25 ` Ni, Ruiyu
2017-03-25 9:28 ` [RFC] [PATCH 3/3] MdeModulePkg/PciBus: " Jiewen Yao
2017-03-27 5:39 ` Ni, Ruiyu
2017-03-27 6:15 ` Yao, Jiewen
2017-03-27 6:23 ` Ni, Ruiyu
2017-03-27 19:50 ` [RFC] [PATCH 0/3] " Duran, Leo
2017-03-28 1:40 ` Yao, Jiewen
2017-03-28 1:54 ` Yao, Jiewen
2017-03-28 2:24 ` Ni, Ruiyu
2017-03-28 2:32 ` Yao, Jiewen
-- strict thread matches above, loose matches on Subject: below --
2017-04-29 13:48 [RFC] [PATCH V4 " Jiewen Yao
2017-04-29 13:48 ` [PATCH 1/3] MdeModulePkg/Include: Add IOMMU protocol definition Jiewen Yao
2017-05-02 9:56 ` Ard Biesheuvel
2017-05-02 12:54 ` Yao, Jiewen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=74D8A39837DF1E4DA445A8C0B3885C503A916565@shsmsx102.ccr.corp.intel.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox