On 6/13/24 7:40 PM, Duan, Zhenzhong wrote:
>
>> -Original Message-
>> From: Kuppuswamy, Sathyanarayanan
>> Subject: Re: [PATCH v4 3/3] PCI/AER: Clear UNCOR_STATUS bits that might
>> be ANFE
>>
>>
>> On 5/9/24 1:48 AM, Zhenzhong Duan wro
On 6/13/24 7:39 PM, Duan, Zhenzhong wrote:
> Hi
>
>> -Original Message-----
>> From: Kuppuswamy Sathyanarayanan
>>
>> Subject: Re: [PATCH v4 1/3] PCI/AER: Store UNCOR_STATUS bits that might
>> be ANFE in aer_err_info
>>
>> Hi,
>>
>>
On 5/9/24 1:48 AM, Zhenzhong Duan wrote:
> When processing an ANFE, ideally both correctable error(CE) status and
> uncorrectable error(UE) status should be cleared. However, there is no
> way to fully identify the UE associated with ANFE. Even worse, Non-Fatal
> Error(NFE) may set the same UE st
t;Wang, Qingshun"
> Signed-off-by: "Wang, Qingshun"
> Signed-off-by: Zhenzhong Duan
> ---
LGTM
Reviewed-by: Kuppuswamy Sathyanarayanan
> drivers/pci/pcie/aer.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/pci/pcie/aer.c b/dri
Hi,
On 5/9/24 1:48 AM, Zhenzhong Duan wrote:
> In some cases the detector of a Non-Fatal Error(NFE) is not the most
> appropriate agent to determine the type of the error. For example,
> when software performs a configuration read from a non-existent
> device or Function, completer will send an ER
hould not affect the
> basic functionality.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=209149
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216295
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=218090
> Signed-off-by: Kai-Heng Feng
> ---
Looks good to me.
R
On 4/15/24 9:32 PM, Kai-Heng Feng wrote:
> In addition to nearest upstream bridge, driver may want to know if the
> entire hierarchy can be powered off to perform different action.
>
> So walk higher up the hierarchy to find out if any device has valid
> _PR3.
>
> The user will be introduced in n
On 1/24/24 10:27 PM, Wang, Qingshun wrote:
> When Advisory Non-Fatal errors are raised, both correctable and
Maybe you can start with same info about what Advisory Non-FataL
errors are and the specification reference. I know that you included
it in cover letter. But it is good to include it in c
Corrected error received: :00:1c.5
> + pcieport :00:1c.5: AER: Correctable error received: :00:1c.5
>
> Signed-off-by: Bjorn Helgaas
> ---
Looks good to me.
Reviewed-by: Kuppuswamy Sathyanarayanan
> drivers/pci/pcie/aer.c | 6 +++---
> 1 file changed, 3 insertions(+),
gt; Signed-off-by: Bjorn Helgaas
Except for the suggestion given below, it looks good to me.
Reviewed-by: Kuppuswamy Sathyanarayanan
> ---
> drivers/pci/pcie/aer.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pcie/aer.c b/driver
[Eric: proposed reproducing steps]
Fixes: 4696b828ca37 ("PCI/AER: Hoist aerdrv.c, aer_inject.c up to
drivers/pci/pcie/")
Reported-by: Eric Badger
Reviewed-by: Ashok Raj
Signed-off-by: Kuppuswamy Sathyanarayanan
---
Changes since v2:
* Added more details to the commit log.
* Rebase
: Root Error Status 0002
Currently, the above issue has been only reproduced in the ICL server
platform.
[Eric: proposed reproducing steps]
Fixes: 4696b828ca37 ("PCI/AER: Hoist aerdrv.c, aer_inject.c up to
drivers/pci/pcie/")
Reported-by: Eric Badger
Reviewed-by: Ashok Raj
Signed-of
Reviewed-by: Ashok Raj
Signed-off-by: Kuppuswamy Sathyanarayanan
---
drivers/pci/pcie/aer.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index 9fa1f97e5b27..7952e5efd6cf 100644
--- a/drivers/pci/pcie/aer.c
+++ b/dr
On 9/28/21 1:58 PM, Borislav Petkov wrote:
On Tue, Sep 28, 2021 at 01:48:46PM -0700, Kuppuswamy, Sathyanarayanan wrote:
Just read it. If you want to use cpuid_has_tdx_guest() directly in
cc_platform_has(), then you want to rename intel_cc_platform_has() to
tdx_cc_platform_has()?
Why?
You
On 9/28/21 1:31 PM, Borislav Petkov wrote:
On Tue, Sep 28, 2021 at 12:19:49PM -0700, Kuppuswamy, Sathyanarayanan wrote:
Intel CC support patch is not included in this series. You want me
to address the issue raised by Joerg before merging it?
Did you not see my email to you today:
https
On 9/28/21 12:10 PM, Borislav Petkov wrote:
From: Borislav Petkov
Hi all,
here's v4 of the cc_platform_has() patchset with feedback incorporated.
I'm going to route this through tip if there are no objections.
Intel CC support patch is not included in this series. You want me
to address
On 9/16/21 8:02 AM, Borislav Petkov wrote:
On Wed, Sep 15, 2021 at 10:26:06AM -0700, Kuppuswamy, Sathyanarayanan wrote:
I have a Intel variant patch (please check following patch). But it includes
TDX changes as well. Shall I move TDX changes to different patch and just
create a separate
patch (please check following patch). But it includes
TDX changes as well. Shall I move TDX changes to different patch and just
create a separate patch for adding intel_cc_platform_has()?
commit fc5f98a0ed94629d903827c5b44ee9295f835831
Author: Kuppuswamy Sathyanarayanan
Date: Wed May 12 11:35:13
On 8/19/21 11:33 AM, Tom Lendacky wrote:
There was some talk about this on the mailing list where TDX and SEV may
need to be differentiated, so we wanted to reserve a range of values per
technology. I guess I can remove them until they are actually needed.
In TDX also we have similar require
technology-specific checks
to the code (e.g. if (sev_active() || tdx_active())).
Reviewed-by: Joerg Roedel
Co-developed-by: Andi Kleen
Signed-off-by: Andi Kleen
Co-developed-by: Kuppuswamy
Sathyanarayanan
Signed-off-by: Kuppuswamy
Sathyanarayanan
Signed-off-by: Tom Lendacky
---
arch/Kconfig
On 7/27/21 3:26 PM, Tom Lendacky wrote:
diff --git a/include/linux/protected_guest.h b/include/linux/protected_guest.h
new file mode 100644
index ..f8ed7b72967b
--- /dev/null
+++ b/include/linux/protected_guest.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ *
On 8/10/21 12:48 PM, Tom Lendacky wrote:
On 8/10/21 1:45 PM, Kuppuswamy, Sathyanarayanan wrote:
On 7/27/21 3:26 PM, Tom Lendacky wrote:
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index de01903c3735..cafed6456d45 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86
On 7/27/21 3:26 PM, Tom Lendacky wrote:
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index de01903c3735..cafed6456d45 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -19,7 +19,7 @@
#include
#include
#include
-#include
+#include
#include
On 8/9/21 2:59 PM, Tom Lendacky wrote:
Not sure how TDX will handle AP booting, are you sure it needs this
special setup as well? Otherwise a check for SEV-ES would be better
instead of the generic PATTR_GUEST_PROT_STATE.
Yes, I'm not sure either. I figure that change can be made, if needed,
Hi Tom,
On 7/27/21 3:26 PM, Tom Lendacky wrote:
This patch series provides a generic helper function, prot_guest_has(),
to replace the sme_active(), sev_active(), sev_es_active() and
mem_encrypt_active() functions.
It is expected that as new protected virtualization technologies are
added to th
Hi Bjorn, Derrick,
On 5/22/20 12:46 PM, Bjorn Helgaas wrote:
On Fri, May 22, 2020 at 05:23:31PM +, Derrick, Jonathan wrote:
On Fri, 2020-05-01 at 11:35 -0600, Jonathan Derrick wrote:
On Fri, 2020-05-01 at 12:16 -0500, Bjorn Helgaas wrote:
On Thu, Apr 30, 2020 at 12:46:07PM -0600, Jon Derr
On 4/27/20 8:15 AM, Derrick, Jonathan wrote:
Hi Sathyanarayanan,
On Sat, 2020-04-25 at 13:46 -0700, Kuppuswamy, Sathyanarayanan wrote:
On 4/23/20 8:11 AM, Derrick, Jonathan wrote:
Hi Sathyanarayanan,
On Wed, 2020-04-22 at 15:50 -0700, Kuppuswamy, Sathyanarayanan wrote:
On 4/20/20 2:37
On 4/23/20 8:11 AM, Derrick, Jonathan wrote:
Hi Sathyanarayanan,
On Wed, 2020-04-22 at 15:50 -0700, Kuppuswamy, Sathyanarayanan wrote:
On 4/20/20 2:37 PM, Jon Derrick wrote:
The existing portdrv model prevents DPC services without either OS
control (_OSC) granted to AER services, a Host
On 4/20/20 2:37 PM, Jon Derrick wrote:
The existing portdrv model prevents DPC services without either OS
control (_OSC) granted to AER services, a Host Bridge requesting Native
AER, or using one of the 'pcie_ports=' parameters of 'native' or
'dpc-native'.
The DPC port service driver itself w
On 4/20/20 2:37 PM, Jon Derrick wrote:
Some platforms have a mix of ports whose capabilities can be negotiated
by _OSC, and some ports which are not described by ACPI and instead
managed by Native drivers. The existing Firmware-First HEST model can
incorrectly tag these Native, Non-ACPI ports
Hi,
On 4/16/20 12:59 PM, Jon Derrick wrote:
Some platforms have a mix of ports whose capabilities can be negotiated
by _OSC, and some ports which are not described by ACPI and instead
managed by Native drivers. The existing Firmware-First HEST model can
incorrectly tag these Native, Non-ACPI por
_isr'
aer.c:1209: warning: Function parameter or member 'context' not described in
'aer_isr'
aer.c:1209: warning: Excess function parameter 'work' description in 'aer_isr'
Fix the above accordingly.
Signed-off-by: Andy Shevchenko
Reviewed-by: Kuppusw
On 8/27/19 8:18 AM, Andy Shevchenko wrote:
This simplifies and standardizes slot manipulation code
by using for_each_set_bit() library function.
Signed-off-by: Andy Shevchenko
Reviewed-by: Kuppuswamy Sathyanarayanan
---
drivers/pci/pcie/aer.c | 19 ---
1 file changed, 8
33 matches
Mail list logo
