mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Narayana Murty N <nnmlinux@linux.ibm.com>
To: Sourabh Jain <sourabhjain@linux.ibm.com>,
	mahesh@linux.ibm.com, maddy@linux.ibm.com, mpe@ellerman.id.au,
	christophe.leroy@csgroup.eu, oohall@gmail.com, npiggin@gmail.com,
	tpearson@raptorengineering.com, alex@shazbot.org
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	sbhat@linux.ibm.com, harshpb@linux.ibm.com
Subject: Re: [PATCH v4 4/5] powerpc/pseries/eeh: Implement RTAS-based EEH error injection
Date: Wed, 9 Sep 2026 11:37:19 +0530	[thread overview]
Message-ID: <385c38cc-fb9a-446c-9e19-2e4fa0631f19@linux.ibm.com> (raw)
In-Reply-To: <02c8c3a8-04f4-4664-a4fd-5223f5262508@linux.ibm.com>



On 02/09/26 10:46 AM, Sourabh Jain wrote:
> 
> 
> On 31/08/26 12:24, Narayana Murty N wrote:
>> Replace the legacy MMIO stub in pseries_eeh_err_inject() with a full
>> PAPR-compliant RTAS error injection path using the existing RTAS
>> work-area allocator.
>>
>> The mutex is not a buffer lock;
> Sorry but I didn't get this...
> 
>> it serializes the firmware session
>> open/inject/close sequence as required by PAPR.  No global buffer
>> is allocated or used.
> Nit:
> I think the above para is influenced form old suggestion to not use global
> dedicated buffer. Lets drop the global buffer thing from commit message
> explain just the current approach.
> 
Agreed. I will clean up the commit message and describe only the current
implementation. I will drop the "mutex is not a buffer lock" and "no 
global buffer is used" wording.
>>
>> VFIO EEH error injection exposes a generic userspace ABI.  pSeries maps
>> the generic EEH error types to RTAS ibm,errinjct encodings via
>> pseries_eeh_type_to_rtas().  EEH_ERR_TYPE_32 and EEH_ERR_TYPE_64 are
>> unchanged; their values are defined in arch/powerpc/include/uapi/asm/ 
>> eeh.h
>> and are not renumbered.
>>
>> Tested with corresponding QEMU patches:
>> https://lore.kernel.org/all/20251029150618.186803-1- 
>> nnmlinux@linux.ibm.com/
>>
>> Signed-off-by: Narayana Murty N <nnmlinux@linux.ibm.com>
>> ---
>>   arch/powerpc/platforms/pseries/eeh_pseries.c | 123 ++++++++++++++-----
>>   1 file changed, 95 insertions(+), 28 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/pseries/eeh_pseries.c b/arch/ 
>> powerpc/platforms/pseries/eeh_pseries.c
>> index fafe0004e738..fcb8c560d813 100644
>> --- a/arch/powerpc/platforms/pseries/eeh_pseries.c
>> +++ b/arch/powerpc/platforms/pseries/eeh_pseries.c
>> @@ -25,6 +25,7 @@
>>   #include <linux/rbtree.h>
>>   #include <linux/sched.h>
>>   #include <linux/seq_file.h>
>> +#include <linux/mutex.h>
>>   #include <linux/spinlock.h>
>>   #include <linux/crash_dump.h>
>> @@ -34,6 +35,7 @@
>>   #include <asm/machdep.h>
>>   #include <asm/ppc-pci.h>
>>   #include <asm/rtas.h>
>> +#include <asm/rtas-work-area.h>
>>   /* RTAS tokens */
>>   static int ibm_set_eeh_option;
>> @@ -958,8 +960,6 @@ static int prepare_errinjct_buffer(void *buf, 
>> struct eeh_pe *pe,
>>               return -EINVAL;
>>           if (upper_32_bits(addr) || upper_32_bits(mask)) {
>> -            pr_err("32-bit IOA injection cannot encode addr=%#lx 
>> mask=%#lx\n",
>> -                   addr, mask);
> 
> We are returning -EINVAL remove the error message, what is the need?
> 
Agreed. I will remove this unnecessary error message and just return
-EINVAL.

>>               return -EINVAL;
>>           }
>> @@ -992,50 +992,117 @@ static int prepare_errinjct_buffer(void *buf, 
>> struct eeh_pe *pe,
>>           break;
>>       default:
>> -        pr_err("unsupported RTAS error injection type 0x%x\n", 
>> rtas_type);
>> +        pr_err("unsupported RTAS error injection type 0x%x\n",
>> +               rtas_type);
> 
> Above change is not necessary..
> 
Agreed. I will drop this unrelated formatting-only change.
>>           return -EINVAL;
>>       }
>> -    pr_debug("errinjct buffer ready: rtas_type=0x%x func=%d 
>> addr=0x%lx mask=0x%lx\n",
>> -         rtas_type, func, addr, mask);
> 
> What is need to remove this debug message?
There is no strong reason to remove it. I will keep the existing debug 
message.
> 
>>       return 0;
>>   }
>> +/* pseries-local mutex serializes the open/inject/close RTAS session */
>> +static DEFINE_MUTEX(pseries_errinjct_mutex);
>> +
>>   /**
>>    * pseries_eeh_err_inject - Inject specified error to the indicated PE
>>    * @pe: the indicated PE
>> - * @type: error type
>> - * @func: specific error type
>> - * @addr: address
>> - * @mask: address mask
>> - * The routine is called to inject specified error, which is
>> - * determined by @type and @func, to the indicated PE
>> + * @type: generic EEH error type (EEH_ERR_TYPE_32 or EEH_ERR_TYPE_64)
>> + * @func: specific error function
>> + * @addr: address argument (type-dependent, may be zero)
>> + * @mask: address mask (type-dependent, may be zero)
>> + *
>> + * Implements PAPR-compliant error injection using:
>> + *   ibm,open-errinjct -> ibm,errinjct -> ibm,close-errinjct
>> + *
>> + * A short-lived RTAS work area is allocated per call; no global buffer
>> + * is used.
> Mentioning "no global buffer is used" is not adding any value, I think.
> 
Agreed.
>> pseries_errinjct_mutex serializes the open/inject/close
>> + * session sequence.
>> + *
>> + * Return: 0 on success, negative errno on failure.
>>    */
>>   static int pseries_eeh_err_inject(struct eeh_pe *pe, int type, int 
>> func,
>>                     unsigned long addr, unsigned long mask)
>>   {
>> -    struct    eeh_dev    *pdev;
>> +    struct rtas_work_area *area;
>> +    phys_addr_t area_phys;
>> +    u32 buf_phys;
>> +    void *buf;
>> +    int open_token, errinjct_token, close_token;
>> +    int session_token;
>> +    int rtas_type;
>> +    int close_rc;
>> +    int rc;
>> +
>> +    rc = validate_errinjct_args(pe, type, func, addr, mask);
>> +    if (rc)
>> +        return rc;
>> -    /* Check on PCI error type */
>> -    if (type != EEH_ERR_TYPE_32 && type != EEH_ERR_TYPE_64)
>> +    rtas_type = pseries_eeh_type_to_rtas(type);
>> +    if (rtas_type < 0)
>>           return -EINVAL;
>> -    switch (func) {
>> -    case EEH_ERR_FUNC_LD_MEM_ADDR:
>> -    case EEH_ERR_FUNC_LD_MEM_DATA:
>> -    case EEH_ERR_FUNC_ST_MEM_ADDR:
>> -    case EEH_ERR_FUNC_ST_MEM_DATA:
>> -        /* injects a MMIO error for all pdev's belonging to PE */
>> -        pci_lock_rescan_remove();
>> -        list_for_each_entry(pdev, &pe->edevs, entry)
>> -            eeh_pe_inject_mmio_error(pdev->pdev);
>> -        pci_unlock_rescan_remove();
>> -        break;
>> -    default:
>> -        return -ERANGE;
>> +    open_token    = rtas_function_token(RTAS_FN_IBM_OPEN_ERRINJCT);
>> +    errinjct_token = rtas_function_token(RTAS_FN_IBM_ERRINJCT);
>> +    close_token   = rtas_function_token(RTAS_FN_IBM_CLOSE_ERRINJCT);
>> +
>> +    if (open_token    == RTAS_UNKNOWN_SERVICE ||
>> +        errinjct_token == RTAS_UNKNOWN_SERVICE ||
>> +        close_token   == RTAS_UNKNOWN_SERVICE)
>> +        return -ENODEV;
>> +
>> +    area = rtas_work_area_alloc(RTAS_ERRINJCT_BUF_SIZE);
>> +    buf  = rtas_work_area_raw_buf(area);
>> +    area_phys = rtas_work_area_phys(area);
> 
> 
> I was wondering if there is any need to hold the work area buffer until
> we acquire pseries_errinjct_mutex.
> 
> Would it make sense to allocate the buffer only after acquiring the
> mutex? I suggested an order for the open, errinjct, and close calls
> below, which I think could also help address the above comment.
> 
Agreed. I will reorder the flow as suggested:

1. acquire the mutex
2. call ibm,open-errinjct
3. allocate the RTAS work area
4. populate the work buffer
5. call ibm,errinjct
6. free the RTAS work area
7. call ibm,close-errinjct
8. release the mutex

This avoids allocating the work area if ibm,open-errinjct fails and 
keeps the
work area held only while it is needed.
> Nit: this file is under pseries platform so pseries_errinjct_mutex can 
> renamed to errinct_mutex.
Agreed. I will rename it to errinjct_mutex.
>> +
>> +    if (WARN_ON_ONCE(upper_32_bits(area_phys))) {
>> +        rc = -ERANGE;
>> +        goto out_free_area;
>>       }
>> -    return 0;
>> +    buf_phys = lower_32_bits(area_phys);
> 
> I don't understand the above logic. First, we check area_phys and exit
> early if the address is above 4G, and then we take the lower 32 bits of
> the same address.
> 
> I think the RTAS work area allocation API should be responsible for
> allocating the work area buffer at the right location. The user
> shouldn't have to worry about where exactly the buffer is allocated
> unless they have a specific requirement.
> 
> Is the work area buffer allocated by the API not meeting your
> requirement? If so, could you please explain what the issue is? Let's
> see if we can fix it in the work area allocation API. Otherwise, I
> would suggest removing the checking and truncation done around
> area_phys.
> 
> Let me know your opinion.
> 
Agreed. Since this path uses the RTAS work area allocator, I will remove 
the explicit upper_32_bits(area_phys) check and the local address 
truncation logic. If the allocator does not provide an RTAS-suitable 
address, that should be handled in the allocator rather than in this EEH 
path.
> 
>> +
>> +    rc = prepare_errinjct_buffer(buf, pe, rtas_type, func, addr, mask);
>> +    if (rc)
>> +        goto out_free_area;
>> +
>> +    mutex_lock(&pseries_errinjct_mutex);
>> +
>> +    do {
>> +        rc = rtas_call(open_token, 0, 2, &session_token);
>> +    } while (rtas_busy_delay(rc));
>> +
>> +    if (rc) {
>> +        pr_err("ibm,open-errinjct failed: status=%d\n", rc);
>> +        rc = rtas_error_rc(rc);
>> +        goto out_unlock;
>> +    }
> 
> I think we should allocate the work area buffer only after the
> open-errinjct call succeeds. My preferred order is:
> 
> - Call RTAS open-errinjct
> - Allocate the work area buffer
> - Populate the work area buffer and make the errinjct RTAS call
> - Release the work area buffer
> - Call RTAS close-errinjct
> 
As stated above, will address in next version.
> This way, the work area buffer is held only for as long as it is needed,
> and we also avoid allocating it if open-errinjct fails.
Agreed.
> 
>> +
>> +    do {
>> +        rc = rtas_call(errinjct_token, 3, 1, NULL,
>> +                   rtas_type, session_token, buf_phys);
>> +    } while (rtas_busy_delay(rc));
>> +
>> +    if (rc) {
>> +        pr_err("ibm,errinjct failed: status=%d\n", rc);
>> +        rc = rtas_error_rc(rc);
>> +    }
>> +
>> +    do {
>> +        close_rc = rtas_call(close_token, 1, 1, NULL, session_token);
>> +    } while (rtas_busy_delay(close_rc));
>> +
>> +    if (close_rc) {
>> +        pr_warn("ibm,close-errinjct failed: status=%d\n", close_rc);
>> +        if (!rc)
>> +            rc = rtas_error_rc(close_rc);
>> +    }
>> +
>> +out_unlock:
>> +    mutex_unlock(&pseries_errinjct_mutex);
>> +
>> +out_free_area:
>> +    rtas_work_area_free(area);
>> +    return rc;
>>   }
>>   static struct eeh_ops pseries_eeh_ops = {
> 


  reply	other threads:[~2026-09-09  6:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-31  6:54 [PATCH v4 0/5] powerpc/eeh: Add RTAS-based error injection support on pSeries Narayana Murty N
2026-08-31  6:54 ` [PATCH v4 1/5] powerpc/rtas: Handle ibm,open-errinjct return format Narayana Murty N
2026-09-01  9:22   ` Sourabh Jain
2026-09-09  5:45     ` Narayana Murty N
2026-08-31  6:54 ` [PATCH v4 2/5] vfio/spapr_tce: Normalize EEH IOA error injection addresses Narayana Murty N
2026-08-31  6:54 ` [PATCH v4 3/5] powerpc/pseries/eeh: Add RTAS error validation helpers Narayana Murty N
2026-08-31  6:54 ` [PATCH v4 4/5] powerpc/pseries/eeh: Implement RTAS-based EEH error injection Narayana Murty N
2026-09-02  5:16   ` Sourabh Jain
2026-09-09  6:07     ` Narayana Murty N [this message]
2026-08-31  6:54 ` [PATCH v4 5/5] powerpc/powernv/eeh: Map VFIO EEH error injection to OPAL Narayana Murty N
2026-09-01 18:08 ` [PATCH v4 0/5] powerpc/eeh: Add RTAS-based error injection support on pSeries Narayana Murty N

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=385c38cc-fb9a-446c-9e19-2e4fa0631f19@linux.ibm.com \
    --to=nnmlinux@linux.ibm.com \
    --cc=alex@shazbot.org \
    --cc=christophe.leroy@csgroup.eu \
    --cc=harshpb@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=mahesh@linux.ibm.com \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=oohall@gmail.com \
    --cc=sbhat@linux.ibm.com \
    --cc=sourabhjain@linux.ibm.com \
    --cc=tpearson@raptorengineering.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®