On Mon, 7 Dec 2020 03:19:20 -0600, Suravee Suthikulpanit wrote:
> According to the AMD IOMMU spec, the commit 73db2fc595f3
> ("iommu/amd: Increase interrupt remapping table limit to 512 entries")
> also requires the interrupt table length (IntTabLen) to be set to 9
> (power of 2) in the device
On Mon, 7 Dec 2020 17:35:53 +0800, Yong Wu wrote:
> Currently direct_mapping always use the smallest pgsize which is SZ_4K
> normally to mapping. This is unnecessary. we could gather the size, and
> call iommu_map then, iommu_map could decide how to map better with the
> just right pgsize.
>
>
Hi Will,
On 2020/12/7 18:59, Will Deacon wrote:
> On Sat, Dec 05, 2020 at 04:29:57PM +0800, Keqian Zhu wrote:
>> ... then we have more chance to detect wrong code logic.
>
> This could do with being a bit more explicit. Something like:
>
> Although handling a mapping request with no
On 2020-12-05 08:29, Keqian Zhu wrote:
... then we have more chance to detect wrong code logic.
I don't follow that justification - it's still the same check with the
same outcome, so how does moving it have any effect on the chance to
detect errors?
AFAICS the only difference it would
Currently direct_mapping always use the smallest pgsize which is SZ_4K
normally to mapping. This is unnecessary. we could gather the size, and
call iommu_map then, iommu_map could decide how to map better with the
just right pgsize.
>From the original comment, we should take care overlap,
Knowing from the code, the macro "iopte_type(pte, l)" doesn't use the
parameter "l" (level). So we'd better to remove it.
Fixes: e1d3c0fd701df(iommu: add ARM LPAE page table allocator)
Signed-off-by: Kunkun Jiang
---
drivers/iommu/io-pgtable-arm.c | 2 +-
1 file changed, 1 insertion(+), 1
According to the AMD IOMMU spec, the commit 73db2fc595f3
("iommu/amd: Increase interrupt remapping table limit to 512 entries")
also requires the interrupt table length (IntTabLen) to be set to 9
(power of 2) in the device table mapping entry (DTE).
Fixes: 73db2fc595f3 ("iommu/amd: Increase
Suravee Suthikulpanit @ 2020-12-07 02:19 MST:
> According to the AMD IOMMU spec, the commit 73db2fc595f3
> ("iommu/amd: Increase interrupt remapping table limit to 512 entries")
> also requires the interrupt table length (IntTabLen) to be set to 9
> (power of 2) in the device table mapping
On Mon, Dec 07, 2020 at 07:23:29PM +0800, Tian Tao wrote:
> Use devm_add_action_or_reset to avoid the situation where the release
> function is not called when devm_add_action returns an error.
>
> Signed-off-by: Tian Tao
>
> v2:
> check the return value about evm_add_action_or_reset()
> ---
>
On Mon, Dec 07, 2020 at 12:01:09PM +, Robin Murphy wrote:
> On 2020-12-05 08:29, Keqian Zhu wrote:
> > ... then we have more chance to detect wrong code logic.
>
> I don't follow that justification - it's still the same check with the same
> outcome, so how does moving it have any effect on
On Mon, Dec 07, 2020 at 04:14:04PM +0800, Kunkun Jiang wrote:
> Knowing from the code, the macro "iopte_type(pte, l)" doesn't use the
> parameter "l" (level). So we'd better to remove it.
>
> Fixes: e1d3c0fd701df(iommu: add ARM LPAE page table allocator)
> Signed-off-by: Kunkun Jiang
> ---
>
On Sat, Dec 05, 2020 at 04:29:57PM +0800, Keqian Zhu wrote:
> ... then we have more chance to detect wrong code logic.
This could do with being a bit more explicit. Something like:
Although handling a mapping request with no permissions is a
trivial no-op, defer the early return
Knowing from the code, the macro "iopte_type(pte, l)" doesn't use the
parameter "l" (level). So we'd better to remove it.
Fixes: e1d3c0fd701df(iommu: add ARM LPAE page table allocator)
Signed-off-by: Kunkun Jiang
---
drivers/iommu/io-pgtable-arm.c | 10 +-
1 file changed, 5
Hi,
On 2020/12/7 20:05, Will Deacon wrote:
> On Mon, Dec 07, 2020 at 12:01:09PM +, Robin Murphy wrote:
>> On 2020-12-05 08:29, Keqian Zhu wrote:
>>> ... then we have more chance to detect wrong code logic.
>>
>> I don't follow that justification - it's still the same check with the same
>>
On 2020-12-07 12:15, zhukeqian wrote:
Hi,
On 2020/12/7 20:05, Will Deacon wrote:
On Mon, Dec 07, 2020 at 12:01:09PM +, Robin Murphy wrote:
On 2020-12-05 08:29, Keqian Zhu wrote:
... then we have more chance to detect wrong code logic.
I don't follow that justification - it's still the
Hi Robin,
On 2020/12/7 20:46, Robin Murphy wrote:
> On 2020-12-07 12:15, zhukeqian wrote:
>> Hi,
>>
>> On 2020/12/7 20:05, Will Deacon wrote:
>>> On Mon, Dec 07, 2020 at 12:01:09PM +, Robin Murphy wrote:
On 2020-12-05 08:29, Keqian Zhu wrote:
> ... then we have more chance to detect
On Mon, Dec 07, 2020 at 10:06:24PM +, Ashish Kalra wrote:
> This is related to the earlier static adjustment of the SWIOTLB buffers
> as per guest memory size and Konrad's feedback on the same, as copied
> below :
>
> >>That is eating 128MB for 1GB, aka 12% of the guest memory allocated
>
> On Dec 7, 2020, at 4:14 PM, Borislav Petkov wrote:
>
> On Mon, Dec 07, 2020 at 10:06:24PM +, Ashish Kalra wrote:
>> This is related to the earlier static adjustment of the SWIOTLB buffers
>> as per guest memory size and Konrad's feedback on the same, as copied
>> below :
>>
That
From: Ashish Kalra
For SEV, all DMA to and from guest has to use shared (un-encrypted) pages.
SEV uses SWIOTLB to make this happen without requiring changes to device
drivers. However, depending on workload being run, the default 64MB of
SWIOTLB might not be enough and SWIOTLB may run out of
Hello Boris,
On Mon, Dec 07, 2020 at 01:10:07PM +0100, Borislav Petkov wrote:
> On Thu, Dec 03, 2020 at 03:25:59AM +, Ashish Kalra wrote:
> > diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> > index 1bcfbcd2bfd7..46549bd3d840 100644
> > --- a/arch/x86/mm/mem_encrypt.c
> >
Hi Christoph,
On Tue, Dec 1, 2020 at 11:49 PM Christoph Hellwig wrote:
>
> On Tue, Dec 01, 2020 at 12:36:58PM +0900, Sergey Senozhatsky wrote:
> > Not that I have any sound experience in this area, but the helper
> > probably won't hurt. Do you also plan to add vmap() to that helper
> > or
NVMe driver and other applications depend on the data offset
to operate correctly. Currently when unaligned data is mapped via
SWIOTLB, the data is mapped as slab aligned with the SWIOTLB. When
booting with --swiotlb=force option and using NVMe as interface,
running mkfs.xfs on Rhel fails because
On Mon, Dec 07, 2020 at 10:20:20PM +, Kalra, Ashish wrote:
> It is more of an approximation of the earlier static adjustment which
> was 128M for <1G guests, 256M for 1G-4G guests and 512M for >4G
> guests.
Makes sense and it is better than nothing. Please put that explanation
over the 6%
On (20/12/08 13:54), Tomasz Figa wrote:
>
> In any case, Sergey is going to share a preliminary patch on how the
> current API would be used in the V4L2 videobuf2 framework. That should
> give us more input on how such a helper could look.
HUGE apologies for the previous screw up! I replied in
24 matches
Mail list logo
