I forgot to mark this series as v2 when generating the patches.
Sorry for the confusion.
--
Thiago Jung Bauermann
IBM Linux Technology Center
Secure Memory Encryption is an x86-specific feature, so it shouldn't appear
in generic kernel code.
In DMA mapping code, Christoph Hellwig mentioned that "There is no reason
why we should have a special debug printk just for one specific reason why
there is a requirement for a large DMA mask.", so
powerpc is also going to use this feature, so put it in a generic location.
Signed-off-by: Thiago Jung Bauermann
Reviewed-by: Thomas Gleixner
---
arch/Kconfig | 3 +++
arch/s390/Kconfig | 3 ---
arch/x86/Kconfig | 4 +---
3 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch
Hello,
This version mostly changes patch 2/3, removing dma_check_mask() from
kernel/dma/mapping.c as suggested by Christoph Hellwig, and also adapting
s390's . There's also a small change in patch 1/3 as
mentioned in the changelog below.
Patch 3/3 may or may not need to change s390 code depending
Secure Encrypted Virtualization is an x86-specific feature, so it shouldn't
appear in generic kernel code because it forces non-x86 architectures to
define the sev_active() function, which doesn't make a lot of sense.
To solve this problem, add an x86 elfcorehdr_read() function to override
the gen
[ Cc'ing Tom Lendacky which I forgot to do earlier. Sorry about that. ]
Hello Christoph,
Christoph Hellwig writes:
> Honestly I think this code should go away without any replacement.
> There is no reason why we should have a special debug printk just
> for one specific reason why there is a
Hello Thomas,
Thanks for quickly reviewing the patches.
Thomas Gleixner writes:
> On Fri, 12 Jul 2019, Thiago Jung Bauermann wrote:
>
>> powerpc and s390 are going to use this feature as well, so put it in a
>> generic location.
>>
>> Signed-off-by: Thiago Jung Bauermann
>
> Reviewed-by: Th
The pull request you sent on Thu, 11 Jul 2019 15:56:54 +0200:
> git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9e3a25dc992dd9f3170fb643bdd95da5ca9c5576
Thank you!
--
Deet-doot-dot, I am a bot.
ht
[ Cc'ing Tom Lendacky which I forgot to do earlier. Sorry about that. ]
Hello Halil,
Thanks for the quick review.
Halil Pasic writes:
> On Fri, 12 Jul 2019 02:36:31 -0300
> Thiago Jung Bauermann wrote:
>
>> Secure Encrypted Virtualization is an x86-specific feature, so it shouldn't
>> appea
Hello,
When we allocate cma memory using dma_alloc_attr using
DMA_ATTR_NO_KERNEL_MAPPING attribute. It will return physical address
without virtual mapping and thats the use case of this attribute. but lets
say some vpu/gpu drivers required virtual mapping of some part of the
allocation. then we d
On Fri, 12 Jul 2019, Thiago Jung Bauermann wrote:
> diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.h
> index b310a9c18113..f2e399fb626b 100644
> --- a/include/linux/mem_encrypt.h
> +++ b/include/linux/mem_encrypt.h
> @@ -21,23 +21,11 @@
>
> #else/* !CONFIG_ARCH_HAS_
On Fri, 12 Jul 2019, Thiago Jung Bauermann wrote:
> powerpc and s390 are going to use this feature as well, so put it in a
> generic location.
>
> Signed-off-by: Thiago Jung Bauermann
Reviewed-by: Thomas Gleixner
On Fri, 12 Jul 2019 17:11:29 +0200
Christoph Hellwig wrote:
> On Fri, Jul 12, 2019 at 04:51:53PM +0200, Halil Pasic wrote:
> > Thank you very much! I will have another look, but it seems to me,
> > without further measures taken, this would break protected virtualization
> > support on s390. The
On Fri, 12 Jul 2019 16:08:12 +0200
Christoph Hellwig wrote:
> On Fri, Jul 12, 2019 at 03:09:12PM +0200, Halil Pasic wrote:
> > This is the implementation for the guys that don't
> > have ARCH_HAS_MEM_ENCRYPT.
> >
> > Means sev_active() may not be used in such code after this
> > patch. What abou
On Fri, Jul 12, 2019 at 04:51:53PM +0200, Halil Pasic wrote:
> Thank you very much! I will have another look, but it seems to me,
> without further measures taken, this would break protected virtualization
> support on s390. The effect of the che for s390 is that
> force_dma_unencrypted() will alwa
On Fri, Jul 12, 2019 at 03:09:12PM +0200, Halil Pasic wrote:
> This is the implementation for the guys that don't
> have ARCH_HAS_MEM_ENCRYPT.
>
> Means sev_active() may not be used in such code after this
> patch. What about
>
> static inline bool force_dma_unencrypted(void)
> {
> retur
On Fri, 12 Jul 2019 02:36:31 -0300
Thiago Jung Bauermann wrote:
> Secure Encrypted Virtualization is an x86-specific feature, so it shouldn't
> appear in generic kernel code because it forces non-x86 architectures to
> define the sev_active() function, which doesn't make a lot of sense.
sev_acti
On 2019/7/11 下午9:56, Eric Auger wrote:
This series brings the VFIO part of HW nested paging support
in the SMMUv3.
The series depends on:
[PATCH v9 00/14] SMMUv3 Nested Stage Setup (IOMMU part)
(https://www.spinics.net/lists/kernel/msg3187714.html)
3 new IOCTLs are introduced that allow the u
Honestly I think this code should go away without any replacement.
There is no reason why we should have a special debug printk just
for one specific reason why there is a requirement for a large DMA
mask.
___
iommu mailing list
iommu@lists.linux-foundati
19 matches
Mail list logo
