All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avnish Chouhan <avnish@linux.ibm.com>
To: Daniel Kiper <dkiper@net-space.pl>
Cc: grub-devel@gnu.org, brking@linux.ibm.com,
	meghanaprakash@in.ibm.com, mamatha4@linux.ibm.com
Subject: Re: [PATCH v2] powerpc: increase MIN RMA size for CAS negotiation
Date: Tue, 11 Mar 2025 14:59:35 +0530	[thread overview]
Message-ID: <9d4536d1fc9b16ade2c6c7735fce7dae@linux.ibm.com> (raw)
In-Reply-To: <20250310131233.wo4qd24bjgzfwzmv@tomti.i.net-space.pl>

Hi Daniel,
Thank you for your response!

--------------
Condition before the patch:

if (err == GRUB_ERR_NONE && rmo_top < (512 * 1024 * 1024))
   grub_ieee1275_ibm_cas ();

Condition after the patch:

if (!ibm_ca_support_reboot && err == GRUB_ERR_NONE && rmo_top < (512 * 
1024 * 1024))
   grub_ieee1275_ibm_cas ();

--------------

We have added just one extra check in the code "!ibm_ca_support_reboot" 
to check whether the reboot is a CAS reboot or not!

And these are below comments in the patch which are in question:

+      /*
+       * If we have an error or the reboot is detected as CAS reboot,
+       * don't call CAS, just hope for the best.
+       * Along with the above, if the rmo_top is 512 MB or above. We
+       * will skip the CAS call. Though if we call CAS, the rmo_top 
will
+       * be set to 768 MB via CAS Vector2. This condition is required 
to avoid the
+       * issue where the older Linux kernels are still using rmo_top as 
512 MB.
+       * If we call CAS where rmo_top is less then 768 MB, this will 
result in an issue
+       * due to IBM CAS reboot feature and we won't be able to boot the 
newer kernel.
+       * The machine will boot with the last booted kernel which has 
rmo_top as 512 MB.
+       */

I'm tried to explain in the comment on when the CAS will be called. And 
why we need to use this old condition "rmo_top < 512 MB" and not 
"rmo_top < 768 MB".

+      if (!ibm_ca_support_reboot && err == GRUB_ERR_NONE && rmo_top < 
(512 * 1024 * 1024))
+        grub_ieee1275_ibm_cas ();
      }


Condition 1: (!ibm_ca_support_reboot)

This condition checks whether the last reboot is caused by CAS. If the 
reboot is detected as a CAS reboot, the GRUB will skip the CAS call. As 
the CAS has already been called earlier and it's not required to call 
even if the other conditions are met!

Condition 2: (rmo_top < (512 * 1024 * 1024))

If the machine detects rmo_top as less than 512 MB, the CAS will be 
called.

Why we need this condition:

Logically as we are changing MIN_RMA as 768 MB in GRUB Options_vector2. 
We should check "rmo_top < (768 * 1024 * 1024)" and not "rmo_top < (512 
* 1024 * 1024)".

In the patch, whenever we are calling CAS. We set MIN_RMA as 768 MB. But 
we decide when to call CAS is based on old condition rmo_top < 512 MB. 
Logically it should be 768 MB. But we can't do this right now due to the 
below scenarios. We will change this condition to "rmo_top < (768 * 1024 
* 1024)" in the future.

*****
Scenario 1:
In kernel prom_init.c file. The Options_vector2 is using 512 MB as 
MIN_RMA. And GRUB is using "rmo_top < (768 * 1024 * 1024)" to call CAS.

1. Machine boots, GRUB detects rmo_top as less than 512 MB.
    GRUB calls CAS and sets MIN_RMA as 768MB.
    The machine reboots after the CAS call. (Every CAS call will result 
in a reboot)
2. Machine boots, GRUB detects rmo_top is not as less than 512 MB.
    GRUB skips CAS call.
3. After this kernel boots and detects MIN_RMA as other than its 512 MB 
required value.
    It calls CAS and makes the MIN_RMA again to 512 MB.
    As the CAS is called, the machine will go for a reboot again.

4. Now GRUB will again detects rmo_top as less than 512 MB (changed by 
kernel).
    And then we will again go back to step 1.

And machine will keep doing the CAS calls and change MIN_RMA from 512 to 
768 to 512 to 768 and so on. With this, the machine will stuck in this 
stage forever!
*****

In the above scenario 1, with (!ibm_ca_support_reboot) condition in 
place. We will avoid this CAS reboot loop. But if we use "rmo_top < (768 
* 1024 * 1024)". The machine will never get stuck in reboot loop, but as 
the CAS is called from GRUB (currently all the powerpc machines has 
rmo_top is 512 MB). The IBM CAS reboot feature will not allow us to boot 
with the newer kernel!

IBM CAS reboot feature:

Whenever a reboot is detected as the CAS reboot by GRUB. It will boot 
the machine with the last booted kernel by reading the variable 
"boot-last-label" that has the info related to the last boot. This is 
specific to IBM powerpc and no other architecture  has this.

*****
Scenario 2:
In kernel prom_init.c file. The Options_vector2 is using 768 MB as 
MIN_RMA. And GRUB is using "rmo_top < (768 * 1024 * 1024)" to call CAS.

1. Machine boots, GRUB detects rmo_top as less than 512 MB.
    GRUB calls CAS and sets MIN_RMA as 768MB.
    The machine reboots after the CAS call. (Every CAS call will result 
in a reboot)
2. Machine boots, GRUB detects rmo_top is not as less than 512 MB.
    GRUB skips CAS call.
3. But as the last boot was a CAS reboot, the machine will boot with the 
last booted kernel having MIN_RMA as 512 MB. We will not see an option 
to choose which kernel a user like to boot to.
*****

_________________

Please let me know if you feel I need to change or add any content in my 
"comment" in the patch. I have tried my best to explain and cover these 
above scenarios in simple and short message.
And let me know if you have any queries on this!

Thank you,
Avnish Chouhan


On 2025-03-10 18:42, Daniel Kiper wrote:
> On Fri, Mar 07, 2025 at 02:31:18PM +0530, Avnish Chouhan wrote:
>> Hi Daniel,
>> Thank you so much for your patch reviews.
>> 
>> I'll replace the words as suggested by you.
> 
> Thank you!
> 
>> ****
>> > > +       * If we have an error or the reboot is detected as CAS reboot,
>> > > +       * don't call CAS, just hope for the best.
>> > > +       * Along with the above, if the rmo_top is 512 MB or above. We
>> > > +       * will skip the CAS call. Though if we call CAS, the rmo_top
>> > > will
>> > > +       * be set to 768 MB via CAS Vector2. This condition is
>> > > required to avoid the
>> > > +       * issue where the older Linux kernels are still using
>> > > rmo_top as 512 MB.
>> > > +       * If we call CAS where rmo_top is less then 768 MB, this
>> > > will result in an issue
>> > > +       * due to IBM CAS reboot feature and we won't be able to boot
>> > > the newer kernel.
>> >
>> > Could you be more specific? What is "an issue due to IBM CAS reboot
>> > feature"?
>> >
>> > And I think it would be nice if you put here a reference to
>> > documentation,
>> > including chapters names, etc., which discuss RMA and issues fixed here.
>> >
>> > > +       * The machine will boot with the last booted kernel which
>> > > has rmo_top as 512 MB.
>> > > +       */
>> ****
>> 
>> On this. This patch only change the size of RMA from 512 MB to 768 MB. 
>> The
>> change is done via CAS call. Condition for calling a CAS has no change 
>> other
>> than adding a check on "whether the reboot is a CAS reboot". This is
>> required to avoid unwanted and repetitive CAS calls.
> 
> OK...
> 
>> With this CAS reboot check condition, in any scenario, where we are 
>> using
>> older kernel and CAS is still using 512 MB RMA but with the updated 
>> Grub.
> 
> I am not sure I understand this sentence...
> 
>> The repeated CAS calls will be avoided.
>> 
>> In IBM CAS reboot feature, whenever CAS call occurred. We skip 
>> providing the
> 
> Ditto...
> 
>> kernel options to boot to and we directly boot to the lasted booted 
>> kernel.
> 
> s/lasted/last/?
> 
>> With this feature in place. If we upgrade the machine's kernel and 
>> grub, and
> 
> The project name is GRUB not grub nor Grub... Please be consistent...
> 
>> as the machine is lasted booted with old kernel. Any CAS call from 
>> Grub will
> 
> s/lasted/last/?
> 
>> restrict user to keep booting to last booted kernel!
> 
> Again, I am not sure I understand this paragraph. Please rephrase it.
> 
>> So these conditions are made to avoid any of these possible issues.
>> 
>> on adding the documentation, we can add the PAPR document link which 
>> has
>> been shared with you earlier by IBM folks.
> 
> That would be perfect!
> 
> Daniel

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

  reply	other threads:[~2025-03-11  9:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-03 16:49 [PATCH v2] powerpc: increase MIN RMA size for CAS negotiation Avnish Chouhan
2025-03-04 15:09 ` Daniel Kiper
2025-03-07  9:01   ` Avnish Chouhan
2025-03-10 13:12     ` Daniel Kiper
2025-03-11  9:29       ` Avnish Chouhan [this message]
2025-03-11 13:44         ` Daniel Kiper
2025-03-12  9:46           ` Avnish Chouhan
  -- strict thread matches above, loose matches on Subject: below --
2024-12-06  6:55 Avnish Chouhan
2024-12-07  1:58 ` Michael Ellerman
2024-12-11 12:05   ` Avnish Chouhan
2025-01-09  9:32   ` Sourabh Jain
2025-01-22 12:43 ` Madhavan Srinivasan
2025-01-23  3:06   ` Sourabh Jain
2025-01-24  3:58   ` Sourabh Jain

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=9d4536d1fc9b16ade2c6c7735fce7dae@linux.ibm.com \
    --to=avnish@linux.ibm.com \
    --cc=brking@linux.ibm.com \
    --cc=dkiper@net-space.pl \
    --cc=grub-devel@gnu.org \
    --cc=mamatha4@linux.ibm.com \
    --cc=meghanaprakash@in.ibm.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 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.