All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Michael Ellerman <mpe@ellerman.id.au>,
	Sathyanarayanan Kuppuswamy 
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	linux-efi@vger.kernel.org, Brijesh Singh <brijesh.singh@amd.com>,
	kvm@vger.kernel.org, dri-devel@lists.freedesktop.org,
	platform-driver-x86@vger.kernel.org,
	Paul Mackerras <paulus@samba.org>,
	linux-s390@vger.kernel.org, Andi Kleen <ak@linux.intel.com>,
	Joerg Roedel <joro@8bytes.org>,
	x86@kernel.org, amd-gfx@lists.freedesktop.org,
	Christoph Hellwig <hch@infradead.org>,
	linux-graphics-maintainer@vmware.com,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Tianyu Lan <Tianyu.Lan@microsoft.com>,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	iommu@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v3 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform_has()
Date: Wed, 15 Sep 2021 20:47:37 +0200	[thread overview]
Message-ID: <YUI/yaut2f9ZoJBd@zn.tnic> (raw)
In-Reply-To: <f8388f18-5e90-5d0f-d681-0b17f8307dd4@csgroup.eu>

On Wed, Sep 15, 2021 at 07:18:34PM +0200, Christophe Leroy wrote:
> Could you please provide more explicit explanation why inlining such an
> helper is considered as bad practice and messy ?

Tom already told you to look at the previous threads. Let's read them
together. This one, for example:

https://lore.kernel.org/lkml/YSScWvpXeVXw%2Fed5@infradead.org/

| > To take it out of line, I'm leaning towards the latter, creating a new
| > file that is built based on the ARCH_HAS_PROTECTED_GUEST setting.
| 
| Yes.  In general everytime architectures have to provide the prototype
| and not just the implementation of something we end up with a giant mess
| sooner or later.  In a few cases that is still warranted due to
| performance concerns, but i don't think that is the case here.

So I think what Christoph means here is that you want to have the
generic prototype defined in a header and arches get to implement it
exactly to the letter so that there's no mess.

As to what mess exactly, I'd let him explain that.

> Because as demonstrated in my previous response some days ago, taking that
> outline ends up with an unneccessary ugly generated code and we don't
> benefit front GCC's capability to fold in and opt out unreachable code.

And this is real fast path where a couple of instructions matter or what?

set_memory_encrypted/_decrypted doesn't look like one to me.

> I can't see your point here. Inlining the function wouldn't add any
> ifdeffery as far as I can see.

If the function is touching defines etc, they all need to be visible.
If that function needs to call other functions - which is the case on
x86, perhaps not so much on power - then you need to either ifdef around
them or provide stubs with ifdeffery in the headers. And you need to
make them global functions instead of keeping them static to the same
compilation unit, etc, etc.

With a separate compilation unit, you don't need any of that and it is
all kept in that single file.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@alien8.de>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: linux-efi@vger.kernel.org, Brijesh Singh <brijesh.singh@amd.com>,
	kvm@vger.kernel.org, dri-devel@lists.freedesktop.org,
	platform-driver-x86@vger.kernel.org,
	Paul Mackerras <paulus@samba.org>,
	linux-s390@vger.kernel.org, Andi Kleen <ak@linux.intel.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	x86@kernel.org, amd-gfx@lists.freedesktop.org,
	Christoph Hellwig <hch@infradead.org>,
	linux-graphics-maintainer@vmware.com,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Tianyu Lan <Tianyu.Lan@microsoft.com>,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	iommu@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v3 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform_has()
Date: Wed, 15 Sep 2021 20:47:37 +0200	[thread overview]
Message-ID: <YUI/yaut2f9ZoJBd@zn.tnic> (raw)
In-Reply-To: <f8388f18-5e90-5d0f-d681-0b17f8307dd4@csgroup.eu>

On Wed, Sep 15, 2021 at 07:18:34PM +0200, Christophe Leroy wrote:
> Could you please provide more explicit explanation why inlining such an
> helper is considered as bad practice and messy ?

Tom already told you to look at the previous threads. Let's read them
together. This one, for example:

https://lore.kernel.org/lkml/YSScWvpXeVXw%2Fed5@infradead.org/

| > To take it out of line, I'm leaning towards the latter, creating a new
| > file that is built based on the ARCH_HAS_PROTECTED_GUEST setting.
| 
| Yes.  In general everytime architectures have to provide the prototype
| and not just the implementation of something we end up with a giant mess
| sooner or later.  In a few cases that is still warranted due to
| performance concerns, but i don't think that is the case here.

So I think what Christoph means here is that you want to have the
generic prototype defined in a header and arches get to implement it
exactly to the letter so that there's no mess.

As to what mess exactly, I'd let him explain that.

> Because as demonstrated in my previous response some days ago, taking that
> outline ends up with an unneccessary ugly generated code and we don't
> benefit front GCC's capability to fold in and opt out unreachable code.

And this is real fast path where a couple of instructions matter or what?

set_memory_encrypted/_decrypted doesn't look like one to me.

> I can't see your point here. Inlining the function wouldn't add any
> ifdeffery as far as I can see.

If the function is touching defines etc, they all need to be visible.
If that function needs to call other functions - which is the case on
x86, perhaps not so much on power - then you need to either ifdef around
them or provide stubs with ifdeffery in the headers. And you need to
make them global functions instead of keeping them static to the same
compilation unit, etc, etc.

With a separate compilation unit, you don't need any of that and it is
all kept in that single file.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@alien8.de>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Sathyanarayanan Kuppuswamy
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	linux-efi@vger.kernel.org, Brijesh Singh <brijesh.singh@amd.com>,
	kvm@vger.kernel.org, dri-devel@lists.freedesktop.org,
	platform-driver-x86@vger.kernel.org,
	Paul Mackerras <paulus@samba.org>,
	linux-s390@vger.kernel.org, Andi Kleen <ak@linux.intel.com>,
	Joerg Roedel <joro@8bytes.org>,
	x86@kernel.org, amd-gfx@lists.freedesktop.org,
	Christoph Hellwig <hch@infradead.org>,
	linux-graphics-maintainer@vmware.com,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Tianyu Lan <Tianyu.Lan@microsoft.com>,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	iommu@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v3 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform_has()
Date: Wed, 15 Sep 2021 20:47:37 +0200	[thread overview]
Message-ID: <YUI/yaut2f9ZoJBd@zn.tnic> (raw)
In-Reply-To: <f8388f18-5e90-5d0f-d681-0b17f8307dd4@csgroup.eu>

On Wed, Sep 15, 2021 at 07:18:34PM +0200, Christophe Leroy wrote:
> Could you please provide more explicit explanation why inlining such an
> helper is considered as bad practice and messy ?

Tom already told you to look at the previous threads. Let's read them
together. This one, for example:

https://lore.kernel.org/lkml/YSScWvpXeVXw%2Fed5@infradead.org/

| > To take it out of line, I'm leaning towards the latter, creating a new
| > file that is built based on the ARCH_HAS_PROTECTED_GUEST setting.
| 
| Yes.  In general everytime architectures have to provide the prototype
| and not just the implementation of something we end up with a giant mess
| sooner or later.  In a few cases that is still warranted due to
| performance concerns, but i don't think that is the case here.

So I think what Christoph means here is that you want to have the
generic prototype defined in a header and arches get to implement it
exactly to the letter so that there's no mess.

As to what mess exactly, I'd let him explain that.

> Because as demonstrated in my previous response some days ago, taking that
> outline ends up with an unneccessary ugly generated code and we don't
> benefit front GCC's capability to fold in and opt out unreachable code.

And this is real fast path where a couple of instructions matter or what?

set_memory_encrypted/_decrypted doesn't look like one to me.

> I can't see your point here. Inlining the function wouldn't add any
> ifdeffery as far as I can see.

If the function is touching defines etc, they all need to be visible.
If that function needs to call other functions - which is the case on
x86, perhaps not so much on power - then you need to either ifdef around
them or provide stubs with ifdeffery in the headers. And you need to
make them global functions instead of keeping them static to the same
compilation unit, etc, etc.

With a separate compilation unit, you don't need any of that and it is
all kept in that single file.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@alien8.de>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Michael Ellerman <mpe@ellerman.id.au>,
	Sathyanarayanan Kuppuswamy
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	linux-efi@vger.kernel.org, Brijesh Singh <brijesh.singh@amd.com>,
	kvm@vger.kernel.org, dri-devel@lists.freedesktop.org,
	platform-driver-x86@vger.kernel.org,
	Paul Mackerras <paulus@samba.org>,
	linux-s390@vger.kernel.org, Andi Kleen <ak@linux.intel.com>,
	Joerg Roedel <joro@8bytes.org>,
	x86@kernel.org, amd-gfx@lists.freedesktop.org,
	Christoph Hellwig <hch@infradead.org>,
	linux-graphics-maintainer@vmware.com,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Tianyu Lan <Tianyu.Lan@microsoft.com>,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	iommu@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v3 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform_has()
Date: Wed, 15 Sep 2021 20:47:37 +0200	[thread overview]
Message-ID: <YUI/yaut2f9ZoJBd@zn.tnic> (raw)
In-Reply-To: <f8388f18-5e90-5d0f-d681-0b17f8307dd4@csgroup.eu>

On Wed, Sep 15, 2021 at 07:18:34PM +0200, Christophe Leroy wrote:
> Could you please provide more explicit explanation why inlining such an
> helper is considered as bad practice and messy ?

Tom already told you to look at the previous threads. Let's read them
together. This one, for example:

https://lore.kernel.org/lkml/YSScWvpXeVXw%2Fed5@infradead.org/

| > To take it out of line, I'm leaning towards the latter, creating a new
| > file that is built based on the ARCH_HAS_PROTECTED_GUEST setting.
| 
| Yes.  In general everytime architectures have to provide the prototype
| and not just the implementation of something we end up with a giant mess
| sooner or later.  In a few cases that is still warranted due to
| performance concerns, but i don't think that is the case here.

So I think what Christoph means here is that you want to have the
generic prototype defined in a header and arches get to implement it
exactly to the letter so that there's no mess.

As to what mess exactly, I'd let him explain that.

> Because as demonstrated in my previous response some days ago, taking that
> outline ends up with an unneccessary ugly generated code and we don't
> benefit front GCC's capability to fold in and opt out unreachable code.

And this is real fast path where a couple of instructions matter or what?

set_memory_encrypted/_decrypted doesn't look like one to me.

> I can't see your point here. Inlining the function wouldn't add any
> ifdeffery as far as I can see.

If the function is touching defines etc, they all need to be visible.
If that function needs to call other functions - which is the case on
x86, perhaps not so much on power - then you need to either ifdef around
them or provide stubs with ifdeffery in the headers. And you need to
make them global functions instead of keeping them static to the same
compilation unit, etc, etc.

With a separate compilation unit, you don't need any of that and it is
all kept in that single file.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2021-09-15 18:47 UTC|newest]

Thread overview: 233+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-08 22:58 [PATCH v3 0/8] Implement generic cc_platform_has() helper function Tom Lendacky
2021-09-08 22:58 ` Tom Lendacky
2021-09-08 22:58 ` Tom Lendacky
2021-09-08 22:58 ` Tom Lendacky
2021-09-08 22:58 ` Tom Lendacky via iommu
2021-09-08 22:58 ` [PATCH v3 1/8] x86/ioremap: Selectively build arch override encryption functions Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky via iommu
2021-09-08 22:58 ` [PATCH v3 2/8] mm: Introduce a function to check for confidential computing features Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky via iommu
2021-09-09  7:35   ` Christophe Leroy
2021-09-09  7:35     ` Christophe Leroy
2021-09-09  7:35     ` Christophe Leroy
2021-09-09  7:35     ` Christophe Leroy
2021-09-10 15:02   ` Borislav Petkov
2021-09-10 15:02     ` Borislav Petkov
2021-09-10 15:02     ` Borislav Petkov
2021-09-10 15:02     ` Borislav Petkov
2021-09-10 15:02     ` Borislav Petkov
2021-09-08 22:58 ` [PATCH v3 3/8] x86/sev: Add an x86 version of cc_platform_has() Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky via iommu
2021-09-11 10:10   ` Borislav Petkov
2021-09-11 10:10     ` Borislav Petkov
2021-09-11 10:10     ` Borislav Petkov
2021-09-11 10:10     ` Borislav Petkov
2021-09-11 10:10     ` Borislav Petkov
2021-09-08 22:58 ` [PATCH v3 4/8] powerpc/pseries/svm: Add a powerpc " Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky via iommu
2021-09-09  7:40   ` Christophe Leroy
2021-09-09  7:40     ` Christophe Leroy
2021-09-09  7:40     ` Christophe Leroy
2021-09-09  7:40     ` Christophe Leroy
2021-09-14 11:58   ` Borislav Petkov
2021-09-14 11:58     ` Borislav Petkov
2021-09-14 11:58     ` Borislav Petkov
2021-09-14 11:58     ` Borislav Petkov
2021-09-14 11:58     ` Borislav Petkov
2021-09-14 14:47     ` Christophe Leroy
2021-09-14 14:47       ` Christophe Leroy
2021-09-14 14:47       ` Christophe Leroy
2021-09-14 14:47       ` Christophe Leroy
2021-09-14 14:47       ` Christophe Leroy
2021-09-14 14:56       ` Borislav Petkov
2021-09-14 14:56         ` Borislav Petkov
2021-09-14 14:56         ` Borislav Petkov
2021-09-14 14:56         ` Borislav Petkov
2021-09-14 14:56         ` Borislav Petkov
2021-09-15  0:28     ` Michael Ellerman
2021-09-15  0:28       ` Michael Ellerman
2021-09-15  0:28       ` Michael Ellerman
2021-09-15  0:28       ` Michael Ellerman
2021-09-15  0:28       ` Michael Ellerman
2021-09-15 10:08       ` Borislav Petkov
2021-09-15 10:08         ` Borislav Petkov
2021-09-15 10:08         ` Borislav Petkov
2021-09-15 10:08         ` Borislav Petkov
2021-09-15 10:08         ` Borislav Petkov
2021-09-15 17:18         ` Christophe Leroy
2021-09-15 17:18           ` Christophe Leroy
2021-09-15 17:18           ` Christophe Leroy
2021-09-15 17:18           ` Christophe Leroy
2021-09-15 17:18           ` Christophe Leroy
2021-09-15 18:47           ` Borislav Petkov [this message]
2021-09-15 18:47             ` Borislav Petkov
2021-09-15 18:47             ` Borislav Petkov
2021-09-15 18:47             ` Borislav Petkov
2021-09-15 18:47             ` Borislav Petkov
2021-09-16  7:35           ` Christoph Hellwig
2021-09-16  7:35             ` Christoph Hellwig
2021-09-16  7:35             ` Christoph Hellwig
2021-09-16  7:35             ` Christoph Hellwig
2021-09-16  7:35             ` Christoph Hellwig
2021-09-16 11:51             ` Michael Ellerman
2021-09-16 11:51               ` Michael Ellerman
2021-09-16 11:51               ` Michael Ellerman
2021-09-16 11:51               ` Michael Ellerman
2021-09-16 11:51               ` Michael Ellerman
2021-09-08 22:58 ` [PATCH v3 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has() Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky via iommu
2021-09-14 18:24   ` Borislav Petkov
2021-09-14 18:24     ` Borislav Petkov
2021-09-14 18:24     ` Borislav Petkov
2021-09-14 18:24     ` Borislav Petkov
2021-09-14 18:24     ` Borislav Petkov
2021-09-20 19:23   ` Kirill A. Shutemov
2021-09-20 19:23     ` Kirill A. Shutemov
2021-09-20 19:23     ` Kirill A. Shutemov
2021-09-20 19:23     ` Kirill A. Shutemov
2021-09-20 19:23     ` Kirill A. Shutemov
2021-09-21 17:04     ` Tom Lendacky
2021-09-21 17:04       ` Tom Lendacky
2021-09-21 17:04       ` Tom Lendacky
2021-09-21 17:04       ` Tom Lendacky
2021-09-21 17:04       ` Tom Lendacky via iommu
2021-09-21 17:47       ` Borislav Petkov
2021-09-21 17:47         ` Borislav Petkov
2021-09-21 17:47         ` Borislav Petkov
2021-09-21 17:47         ` Borislav Petkov
2021-09-21 17:47         ` Borislav Petkov
2021-09-21 21:20         ` Kirill A. Shutemov
2021-09-21 21:20           ` Kirill A. Shutemov
2021-09-21 21:20           ` Kirill A. Shutemov
2021-09-21 21:20           ` Kirill A. Shutemov
2021-09-21 21:20           ` Kirill A. Shutemov
2021-09-21 21:27           ` Borislav Petkov
2021-09-21 21:27             ` Borislav Petkov
2021-09-21 21:27             ` Borislav Petkov
2021-09-21 21:27             ` Borislav Petkov
2021-09-21 21:27             ` Borislav Petkov
2021-09-21 21:34             ` Kirill A. Shutemov
2021-09-21 21:34               ` Kirill A. Shutemov
2021-09-21 21:34               ` Kirill A. Shutemov
2021-09-21 21:34               ` Kirill A. Shutemov
2021-09-21 21:34               ` Kirill A. Shutemov
2021-09-21 21:43               ` Tom Lendacky
2021-09-21 21:43                 ` Tom Lendacky
2021-09-21 21:43                 ` Tom Lendacky
2021-09-21 21:43                 ` Tom Lendacky
2021-09-21 21:43                 ` Tom Lendacky via iommu
2021-09-21 21:58                 ` Kirill A. Shutemov
2021-09-21 21:58                   ` Kirill A. Shutemov
2021-09-21 21:58                   ` Kirill A. Shutemov
2021-09-21 21:58                   ` Kirill A. Shutemov
2021-09-21 21:58                   ` Kirill A. Shutemov
2021-09-22 13:40                   ` Tom Lendacky
2021-09-22 13:40                     ` Tom Lendacky
2021-09-22 13:40                     ` Tom Lendacky
2021-09-22 13:40                     ` Tom Lendacky
2021-09-22 13:40                     ` Tom Lendacky via iommu
2021-09-22 14:30                     ` Kirill A. Shutemov
2021-09-22 14:30                       ` Kirill A. Shutemov
2021-09-22 14:30                       ` Kirill A. Shutemov
2021-09-22 14:30                       ` Kirill A. Shutemov
2021-09-22 14:30                       ` Kirill A. Shutemov
2021-09-22 19:52                       ` Borislav Petkov
2021-09-22 19:52                         ` Borislav Petkov
2021-09-22 19:52                         ` Borislav Petkov
2021-09-22 19:52                         ` Borislav Petkov
2021-09-22 19:52                         ` Borislav Petkov
2021-09-22 21:05                         ` Kirill A. Shutemov
2021-09-22 21:05                           ` Kirill A. Shutemov
2021-09-22 21:05                           ` Kirill A. Shutemov
2021-09-22 21:05                           ` Kirill A. Shutemov
2021-09-22 21:05                           ` Kirill A. Shutemov
2021-09-23 18:21                           ` Borislav Petkov
2021-09-23 18:21                             ` Borislav Petkov
2021-09-23 18:21                             ` Borislav Petkov
2021-09-23 18:21                             ` Borislav Petkov
2021-09-23 18:21                             ` Borislav Petkov
2021-09-24  9:41                             ` Kirill A. Shutemov
2021-09-24  9:41                               ` Kirill A. Shutemov
2021-09-24  9:41                               ` Kirill A. Shutemov
2021-09-24  9:41                               ` Kirill A. Shutemov
2021-09-24  9:41                               ` Kirill A. Shutemov
2021-09-24  9:51                               ` Borislav Petkov
2021-09-24  9:51                                 ` Borislav Petkov
2021-09-24  9:51                                 ` Borislav Petkov
2021-09-24  9:51                                 ` Borislav Petkov
2021-09-24  9:51                                 ` Borislav Petkov
2021-09-24 13:31                                 ` Tom Lendacky
2021-09-24 13:31                                   ` Tom Lendacky
2021-09-24 13:31                                   ` Tom Lendacky
2021-09-24 13:31                                   ` Tom Lendacky
2021-09-24 13:31                                   ` Tom Lendacky via iommu
2021-09-08 22:58 ` [PATCH v3 6/8] x86/sev: Replace occurrences of sev_active() " Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky via iommu
2021-09-08 22:58 ` [PATCH v3 7/8] x86/sev: Replace occurrences of sev_es_active() " Tom Lendacky via iommu
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58 ` [PATCH v3 8/8] treewide: Replace the use of mem_encrypt_active() " Tom Lendacky via iommu
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky
2021-09-08 22:58   ` Tom Lendacky
2021-09-09  7:25   ` Christophe Leroy
2021-09-09  7:25     ` Christophe Leroy
2021-09-09  7:25     ` Christophe Leroy
2021-09-09  7:25     ` Christophe Leroy
2021-09-09  7:25     ` Christophe Leroy
2021-09-09 13:10     ` Tom Lendacky via iommu
2021-09-09 13:10       ` Tom Lendacky
2021-09-09 13:10       ` Tom Lendacky
2021-09-09 13:10       ` Tom Lendacky
2021-09-09 13:10       ` Tom Lendacky
2021-09-09  7:32 ` [PATCH v3 0/8] Implement generic cc_platform_has() helper function Christian Borntraeger
2021-09-09  7:32   ` Christian Borntraeger
2021-09-09  7:32   ` Christian Borntraeger
2021-09-09  7:32   ` Christian Borntraeger
2021-09-09  7:32   ` Christian Borntraeger
2021-09-09 13:01   ` Tom Lendacky
2021-09-09 13:01     ` Tom Lendacky
2021-09-09 13:01     ` Tom Lendacky
2021-09-09 13:01     ` Tom Lendacky
2021-09-09 13:01     ` Tom Lendacky via iommu
2021-09-15 16:46 ` Borislav Petkov
2021-09-15 16:46   ` Borislav Petkov
2021-09-15 16:46   ` Borislav Petkov
2021-09-15 16:46   ` Borislav Petkov
2021-09-15 16:46   ` Borislav Petkov
2021-09-15 17:26   ` Kuppuswamy, Sathyanarayanan
2021-09-15 17:26     ` Kuppuswamy, Sathyanarayanan
2021-09-15 17:26     ` Kuppuswamy, Sathyanarayanan
2021-09-15 17:26     ` Kuppuswamy, Sathyanarayanan
2021-09-15 17:26     ` Kuppuswamy, Sathyanarayanan
2021-09-16 15:02     ` Borislav Petkov
2021-09-16 15:02       ` Borislav Petkov
2021-09-16 15:02       ` Borislav Petkov
2021-09-16 15:02       ` Borislav Petkov
2021-09-16 15:02       ` Borislav Petkov
2021-09-16 18:38       ` Kuppuswamy, Sathyanarayanan
2021-09-16 18:38         ` Kuppuswamy, Sathyanarayanan
2021-09-16 18:38         ` Kuppuswamy, Sathyanarayanan
2021-09-16 18:38         ` Kuppuswamy, Sathyanarayanan
2021-09-16 18:38         ` Kuppuswamy, Sathyanarayanan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YUI/yaut2f9ZoJBd@zn.tnic \
    --to=bp@alien8.de \
    --cc=Tianyu.Lan@microsoft.com \
    --cc=ak@linux.intel.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=brijesh.singh@amd.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hch@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=kexec@lists.infradead.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-graphics-maintainer@vmware.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=thomas.lendacky@amd.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.