Pasid table memory allocation could return failure due to memory
shortage. Limit the pasid table size to 1MiB because current 8MiB
contiguous physical memory allocation can be hard to come by. W/o
a PASID table, the device could continue to work with only shared
virtual memory impacted. So, let's
On Fri, 7 Sep 2018 20:02:54 +0200
Christian König wrote:
> Am 07.09.2018 um 17:45 schrieb Jean-Philippe Brucker:
> > On 07/09/2018 09:55, Christian König wrote:
> >> I will take this as an opportunity to summarize some of the
> >> requirements we have for PASID management from the amdgpu
On Fri, Sep 07, 2018 at 06:55:45PM +0100, Jean-Philippe Brucker wrote:
> On 07/09/2018 17:53, Jerome Glisse wrote:
> > So there is no reasons to do that under VFIO. Especialy as in your example
> > it is not a real user space device driver, the userspace portion only knows
> > about writting
Am 07.09.2018 um 17:45 schrieb Jean-Philippe Brucker:
On 07/09/2018 09:55, Christian König wrote:
I will take this as an opportunity to summarize some of the requirements
we have for PASID management from the amdgpu driver point of view:
That's incredibly useful, thanks :)
1. We need to be
On 07/09/2018 17:53, Jerome Glisse wrote:
> So there is no reasons to do that under VFIO. Especialy as in your example
> it is not a real user space device driver, the userspace portion only knows
> about writting command into command buffer AFAICT.
>
> VFIO is for real userspace driver where
On Fri, Sep 07, 2018 at 10:47:11AM +0800, Lu Baolu wrote:
>
> >>+
> >>+ intel_pasid_clear_entry(dev, pasid);
> >>+
> >>+ if (!ecap_coherent(iommu->ecap)) {
> >>+ pte = intel_pasid_get_entry(dev, pasid);
> >>+ clflush_cache_range(pte, sizeof(*pte));
> >>+ }
> >>+
> >>+
On Fri, Sep 07, 2018 at 12:01:38PM +0800, Kenneth Lee wrote:
> On Thu, Sep 06, 2018 at 09:31:33AM -0400, Jerome Glisse wrote:
> > Date: Thu, 6 Sep 2018 09:31:33 -0400
> > From: Jerome Glisse
> > To: Kenneth Lee
> > CC: Alex Williamson , Kenneth Lee
> > , Jonathan Corbet , Herbert Xu
> > ,
On 07/09/2018 09:55, Christian König wrote:
> I will take this as an opportunity to summarize some of the requirements
> we have for PASID management from the amdgpu driver point of view:
That's incredibly useful, thanks :)
> 1. We need to be able to allocate PASID between 1 and some maximum.
Hi Rob,
2018-09-05 21:37 GMT+02:00 Rob Herring :
> This series adds an iterator for cpu nodes and converts users over to use
> it or of_get_cpu_node in some cases. This allows us to remove the
> dependency on device_type property for cpu nodes though removing that
> from DTS files will have to
On Fri, Sep 7, 2018 at 7:54 AM Michal Simek wrote:
>
> Hi Rob,
>
> 2018-09-05 21:37 GMT+02:00 Rob Herring :
>>
>> This series adds an iterator for cpu nodes and converts users over to use
>> it or of_get_cpu_node in some cases. This allows us to remove the
>> dependency on device_type property
On 07/09/2018 08:11, Auger Eric wrote:
>>> On 09/06/2018 02:42 PM, Jean-Philippe Brucker wrote:
On 06/09/2018 10:25, Auger Eric wrote:
>> +mutex_lock(>lock);
>> +list_add_tail(_pending->list, >faults);
> same doubt as Yi Liu. You cannot rely on the
On Fri, Sep 7, 2018 at 3:22 PM Tomasz Figa wrote:
>
> On Fri, Sep 7, 2018 at 6:38 PM Vivek Gautam
> wrote:
> >
> > Hi Tomasz,
> >
> >
> > On 9/7/2018 2:46 PM, Tomasz Figa wrote:
> > > Hi Vivek,
> > >
> > > On Thu, Aug 30, 2018 at 11:46 PM Vivek Gautam
> > > wrote:
> > >> From: Sricharan R
> >
On Fri, Sep 7, 2018 at 6:38 PM Vivek Gautam wrote:
>
> Hi Tomasz,
>
>
> On 9/7/2018 2:46 PM, Tomasz Figa wrote:
> > Hi Vivek,
> >
> > On Thu, Aug 30, 2018 at 11:46 PM Vivek Gautam
> > wrote:
> >> From: Sricharan R
> >>
> >> The smmu device probe/remove and add/remove master device callbacks
>
Hi Tomasz,
On 9/7/2018 2:46 PM, Tomasz Figa wrote:
Hi Vivek,
On Thu, Aug 30, 2018 at 11:46 PM Vivek Gautam
wrote:
From: Sricharan R
The smmu device probe/remove and add/remove master device callbacks
gets called when the smmu is not linked to its master, that is without
the context of the
Hi Vivek,
On Thu, Aug 30, 2018 at 11:46 PM Vivek Gautam
wrote:
>
> From: Sricharan R
>
> The smmu device probe/remove and add/remove master device callbacks
> gets called when the smmu is not linked to its master, that is without
> the context of the master device. So calling runtime apis in
Am 06.09.2018 um 14:45 schrieb Jean-Philippe Brucker:
On 06/09/2018 12:12, Christian König wrote:
Am 06.09.2018 um 13:09 schrieb Jean-Philippe Brucker:
Hi Eric,
Thanks for reviewing
On 05/09/2018 12:29, Auger Eric wrote:
+int iommu_sva_device_init(struct device *dev, unsigned long features,
In kdump kernel, it will copy the device table of IOMMU from the old device
table, which is encrypted when SME is enabled in the first kernel. So we
have to remap the old device table with the memory encryption mask.
Signed-off-by: Lianbo Jiang
---
drivers/iommu/amd_iommu_init.c | 14
In kdump kernel, we need to dump the old memory into vmcore file,if SME
is enabled in the first kernel, we have to remap the old memory with the
memory encryption mask, which will be automatically decrypted when we
read from DRAM.
For SME kdump, there are two cases that doesn't support:
When SME is enabled on AMD machine, the memory is encrypted in the first
kernel. In this case, SME also needs to be enabled in kdump kernel, and
we have to remap the old memory with the memory encryption mask.
Signed-off-by: Lianbo Jiang
---
arch/x86/include/asm/io.h | 3 +++
When SME is enabled in the first kernel, we will allocate unencrypted pages
for kdump in order to be able to boot the kdump kernel like kexec.
Signed-off-by: Lianbo Jiang
---
kernel/kexec_core.c | 12
1 file changed, 12 insertions(+)
diff --git a/kernel/kexec_core.c
When SME is enabled on AMD machine, we also need to support kdump. Because
the memory is encrypted in the first kernel, we will remap the old memory
to the kdump kernel for dumping data, and SME is also enabled in the kdump
kernel, otherwise the old memory can not be decrypted.
For the kdump, it
On Thu, Sep 6, 2018 at 4:39 PM Hans Verkuil wrote:
>
> On 09/06/2018 09:25 AM, Tomasz Figa wrote:
> > On Thu, Sep 6, 2018 at 4:01 PM Hans Verkuil wrote:
> >>
> >> On 09/05/2018 06:29 PM, Paul Kocialkowski wrote:
> >>> Hi and thanks for the review!
> >>>
> >>> Le lundi 03 septembre 2018 à 11:11
Hi Jean-Philippe,
On 09/06/2018 07:06 PM, Jean-Philippe Brucker wrote:
> On 06/09/2018 14:14, Auger Eric wrote:
>> Hi Jean-Philippe,
>>
>> On 09/06/2018 02:42 PM, Jean-Philippe Brucker wrote:
>>> On 06/09/2018 10:25, Auger Eric wrote:
> + mutex_lock(>lock);
> +
23 matches
Mail list logo
