Re: [RFC PATCH v4 25/28] x86: Access the setup data through sysfs decrypted

On 3/8/2017 1:09 AM, Dave Young wrote: On 02/16/17 at 09:47am, Tom Lendacky wrote: Use memremap() to map the setup data. This will make the appropriate decision as to whether a RAM remapping can be done or if a fallback to ioremap_cache() is needed (similar to the setup data debugfs support).

Re: [RFC PATCH v4 24/28] x86: Access the setup data through debugfs decrypted

On 3/8/2017 1:04 AM, Dave Young wrote: On 02/16/17 at 09:47am, Tom Lendacky wrote: Use memremap() to map the setup data. This simplifies the code and will make the appropriate decision as to whether a RAM remapping can be done or if a fallback to ioremap_cache() is needed (which includes

Re: [RFC PATCH v4 14/28] Add support to access boot related data in the clear

On 3/8/2017 12:55 AM, Dave Young wrote: On 02/16/17 at 09:45am, Tom Lendacky wrote: [snip] + * This function determines if an address should be mapped encrypted. + * Boot setup data, EFI data and E820 areas are checked in making this + * determination. + */ +static bool

Re: amd-iommu: can't boot with amdgpu, AMD-Vi: Completion-Wait loop timed out

On Fri, Mar 17, 2017 at 8:15 AM, Daniel Drake wrote: > Hi, > > On Mon, Mar 13, 2017 at 2:01 PM, Deucher, Alexander > wrote: >> > We are unable to boot Acer Aspire E5-553G (AMD FX-9800P RADEON R7) nor >> > Acer Aspire E5-523 with standard

Re: amd-iommu: can't boot with amdgpu, AMD-Vi: Completion-Wait loop timed out

Hi, On Mon, Mar 13, 2017 at 2:01 PM, Deucher, Alexander wrote: > > We are unable to boot Acer Aspire E5-553G (AMD FX-9800P RADEON R7) nor > > Acer Aspire E5-523 with standard configurations because during boot > > the screen is flooded with the following error message

RE: [RFC PATCH] iommu/dma: account pci host bridge dma_mask for IOVA allocation

Hi Robin, Currently this patch involves multiple framework. I have coalesced the patch into one to present it as a whole as one RFC. it involves 1) pcie of framework changes 2) iommu ops 3) pci dma-ranges discussion. 4) also it talks about the bug in device tree framework (dma-ranges) (just in

Re: [PATCH v11 09/10] perf/amd/iommu: Introduce amd_iommu-specific struct in struct hw_perf_event

On Fri, Feb 24, 2017 at 02:48:21AM -0600, Suravee Suthikulpanit wrote: > From: Suravee Suthikulpanit > > Current AMD IOMMU Perf PMU inappropriately uses hardware struct > inside the union inside the struct hw_perf_event, mainly the use of > extra_reg. > > Instead,

RE: [RFC PATCH] iommu/dma: account pci host bridge dma_mask for IOVA allocation

Hi, There are certain areas which requires contemplation. And this problem requires more attention from Pci of framework and iommu, and integration of both. Regards, Oza. -Original Message- From: Oza Pawandeep [mailto:oza@broadcom.com] Sent: Friday, March 17, 2017 11:41 AM To: Joerg

[RFC PATCH] iommu/dma: account pci host bridge dma_mask for IOVA allocation

It is possible that PCI device supports 64-bit DMA addressing, and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host bridge may have limitations on the inbound transaction addressing. As an example, consider NVME SSD device connected to iproc-PCIe controller.