> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, May 05, 2016 11:05 PM
>
> On Thu, 5 May 2016 12:15:46 +
> "Tian, Kevin" wrote:
>
> > > From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com]
> > > Sent: Thursday, May 05, 2016 7:43 PM
> > >
> > > Hi David and Kevin,
On Mon, May 9, 2016 at 3:40 PM, Robin Murphy wrote:
> On 08/05/16 10:33, Jayachandran C via iommu wrote:
>>
>> Add a new flag PCI_DEV_FLAGS_DMA_ALIAS_ROOT to limit the DMA alias
>> search to go no further than the bridge where the IOMMU is attached.
>>
>> This has been added to support Broadcom's
On Thu, 2016-05-05 at 13:10 +0200, Arnd Bergmann wrote:
> On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote:
> > > -Original Message-
> > > From: Arnd Bergmann [mailto:a...@arndb.de]
> > > Sent: Thursday, May 05, 2016 4:32 PM
> > > To: linuxppc-...@lists.ozlabs.org
> > > Cc: Yangbo Lu; linux
Hi Eric,
On 10/05/16 17:10, Eric Auger wrote:
Hi Alex,
On 05/10/2016 12:49 AM, Alex Williamson wrote:
On Wed, 4 May 2016 11:54:16 +
Eric Auger wrote:
On x86 IRQ remapping is abstracted by the IOMMU. On ARM this is abstracted
by the msi controller. vfio_safe_irq_domain allows to check wh
On 05/10/2016 01:03 AM, Alex Williamson wrote:
> On Wed, 4 May 2016 14:06:19 +0200
> Eric Auger wrote:
>
>> Hi Alex,
>> On 05/04/2016 01:54 PM, Eric Auger wrote:
>>> This patch allows the user-space to retrieve the MSI geometry. The
>>> implementation is based on capability chains, now also added
Hi Alex,
On 05/10/2016 12:49 AM, Alex Williamson wrote:
> On Wed, 4 May 2016 11:54:18 +
> Eric Auger wrote:
>
>> This patch allows the user-space to retrieve the MSI geometry. The
>> implementation is based on capability chains, now also added to
>> VFIO_IOMMU_GET_INFO.
>>
>> The returned in
Hi Alex,
On 05/10/2016 12:49 AM, Alex Williamson wrote:
> On Wed, 4 May 2016 11:54:16 +
> Eric Auger wrote:
>
>> On x86 IRQ remapping is abstracted by the IOMMU. On ARM this is abstracted
>> by the msi controller. vfio_safe_irq_domain allows to check whether
>> interrupts are "safe" for a gi
rk_iommu_command() takes a struct rk_iommu and iterates over the slave
MMUs, so this is doubly wrong in that we're passing in the wrong pointer
and talking to MMUs that we shouldn't be.
Fixes: cd6438c5f844 ("iommu/rockchip: Reconstruct to support multi slaves")
Signed-off-by: John Keeping
---
dr
Hi Alex,
On 05/10/2016 05:29 PM, Alex Williamson wrote:
> On Wed, 4 May 2016 11:54:15 +
> Eric Auger wrote:
>
>> The user is allowed to register a reserved MSI IOVA range by using the
>> DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA.
>> This region is stored in th
On Wed, 4 May 2016 11:54:15 +
Eric Auger wrote:
> The user is allowed to register a reserved MSI IOVA range by using the
> DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA.
> This region is stored in the vfio_dma rb tree. At that point the iova
> range is not mapped
Hi Alex,
On 05/10/2016 12:49 AM, Alex Williamson wrote:
> On Wed, 4 May 2016 11:54:13 +
> Eric Auger wrote:
>
>> In our RB-tree we now have slots of different types (USER and RESERVED).
>> It becomes useful to be able to search for dma slots of a specific type or
>> any type. This patch prop
Hi Alex,
On 05/09/2016 10:57 PM, Alex Williamson wrote:
> On Wed, 4 May 2016 11:40:03 +
> Eric Auger wrote:
>
>> iommu_get/put_msi_cookie allocates/frees the resource used to store
>> and ref count the MSI doorbell mappings. iommu_msi_set_aperture
>> initializes the iova domain used for MSI
On 5/10/16, 12:34 AM, "Eric Auger" wrote:
>Hi Chalamarla,
>> On 5/9/16, 12:48 AM, "Eric Auger" wrote:
>>
>>> Hi Chalarmala,
>>> On 05/05/2016 07:44 PM, Chalamarla, Tirumalesh wrote:
Hi Eric,
Does this series supports gicv3-its emulation?
Do we have a tree with all the d
On Tue, 26 Apr, at 05:57:40PM, Tom Lendacky wrote:
> The EFI tables are not encrypted and need to be accessed as such. Be sure
> to memmap them without the encryption attribute set. For EFI support that
> lives outside of the arch/x86 tree, create a routine that uses the __weak
> attribute so that
On Tue, May 10, 2016 at 02:43:58PM +0100, Matt Fleming wrote:
> Is it not possible to maintain some kind of kernel virtual address
> mapping so memremap*() and friends can figure out when to twiddle the
> mapping attributes and map with/without encryption?
I guess we can move the sme_* specific st
On Tue, May 10, 2016 at 01:23:35PM +0200, Paolo Bonzini wrote:
> It can send plaintext packets that will be stored encrypted in memory.
> (Of course the hypervisor can do that too if it has access to the guest
> network).
And then what?
You need to find out where exactly (which pages) got the pac
On 09/05/2016 23:08, Tom Lendacky wrote:
> On 05/09/2016 10:13 AM, Paolo Bonzini wrote:
>>
>>
>> On 02/05/2016 20:31, Andy Lutomirski wrote:
>>> And did the SEV implementation remember to encrypt the guest register
>>> state? Because, if not, everything of importance will leak out
>>> through th
On 09/05/16 09:00, honghui.zh...@mediatek.com wrote:
[...]
+static void *mtk_iommu_alloc_pgt(struct device *dev, size_t size, gfp_t gfp)
+{
+ dma_addr_t dma;
+ void *pages = alloc_pages_exact(size, gfp | __GFP_ZERO);
+
+ if (!pages)
+ return NULL;
+
+ dma = d
On Mon, May 09, 2016 at 05:20:09PM +0100, Robin Murphy wrote:
> Changes from v1: Rebased onto iommu/core to accommodate SMMUv2 changes.
>
> drivers/iommu/arm-smmu-v3.c | 19 ++-
> drivers/iommu/arm-smmu.c| 27 +++
> 2 files changed, 25 insertions(+), 21
From: Wan Zongshun
This patch is to do the following:
1. Add error check for caller of iommu_device_create.
2. Add error check for caller of iommu_device_link and
move 'iommu = amd_iommu_rlookup_table[dev_data->devid]' out of
iommuv2 capability condition that make iommu_device_link also
use the
Hi Chalamarla,
> On 5/9/16, 12:48 AM, "Eric Auger" wrote:
>
>> Hi Chalarmala,
>> On 05/05/2016 07:44 PM, Chalamarla, Tirumalesh wrote:
>>> Hi Eric,
>>>
>>> Does this series supports gicv3-its emulation?
>>> Do we have a tree with all the dependent patches
>> GICv3 ITS emulation support comes with
21 matches
Mail list logo
