Announcement

Collapse
No announcement yet.

Intel Readies "PFRUT" For Linux 5.17 To Allow Updating System Firmware Without Rebooting

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Intel Readies "PFRUT" For Linux 5.17 To Allow Updating System Firmware Without Rebooting

    Phoronix: Intel Readies "PFRUT" For Linux 5.17 To Allow Updating System Firmware Without Rebooting

    Intel open-source engineers have prepared "PFRUT" support for Platform Firmware Runtime Updates for allowing (U)EFI capsule updates to be performed on capable systems without rebooting the system in order to eliminate downtime...

    https://www.phoronix.com/scan.php?pa...RUT-Linux-5.17

  • #2
    Here is a list of consumer retail motherboards capable of this on Linux:

    Comment


    • #3
      Also, "telemetry"? Telemetry as in something very useful like sensor data (temperatures, fan speeds, voltages, case intrusion detection, etc.), or something shady like being able to read out the system's memory/sending network packets without OS visibility?

      Comment


      • #4
        Originally posted by tildearrow View Post
        Here is a list of consumer retail motherboards capable of this on Linux:
        Well, then, obviously, "consumer retail" is not the focus of this project...

        Comment


        • #5
          Intel and Microsoft gave a presentation about this a while back at the 2019 OCP Summit: https://146a55aca6f00848c565-a763552...475346580c.pdf

          tl;dr: The idea here is to enable UEFI to write a staged copy somewhere that will be activated next time the system is booted, rather than the typical UEFI "capsule" update mechanism which updates the firmware as part of the boot process itself. There absolutely is a reboot and downtime involved here, and the datasheets specify it in more detail. The wording "without rebooting" and "eliminate downtime" used in the article is simply wrong.

          That said, the wording of the Kconfig option in the patch is technically correct in that *some* components can be updated at runtime. Microcode is a good example. Perhaps they plan to eliminate the ability for Linux to update microcode on its own the way it does today and require a trip through closed-source UEFI code instead.
          davidhendricks
          Junior Member
          Last edited by davidhendricks; 28 December 2021, 11:49 PM.

          Comment


          • #6
            Originally posted by davidhendricks View Post
            That said, the wording of the Kconfig option in the patch is technically correct in that *some* components can be updated at runtime.
            In the networking world, where uptime is often paramount at the core of the core, updating firmware (for some components) in real time, at run time, has been possible for quite some time. Some updates required a momentary quiescence of a linecard/port to swap over to the updated firmware, and some required failover to an alternative pathing during the update. One can easily imagine a similar situation for CPUs (for "real time" updates, quiescent instruction processing, flush caches, swap to the new firmware, restart processing), although it may take some time to get to that stage. And for larger (or more complex) updates, migrating a physical CPU offline/online (logically no different than OIR) is certainly a possibility.

            And yes, this is likely server class only, as one doesn't have the necessary redundancy in consumer priced equipment, and while there are likely a handful of consumers willing to pay for enterprise servers as their desktop, the vast majority of the consumer class are not going to be willing to pay for the capability to avoid a reboot a few times a year.

            Comment


            • #7
              Originally posted by davidhendricks View Post
              Perhaps they plan to eliminate the ability for Linux to update microcode on its own the way it does today and require a trip through closed-source UEFI code instead.
              This took a turn. You sound like a war veteran who's seen some shit.

              Comment


              • #8
                Originally posted by CommunityMember View Post

                In the networking world, where uptime is often paramount at the core of the core, updating firmware (for some components) in real time, at run time, has been possible for quite some time. Some updates required a momentary quiescence of a linecard/port to swap over to the updated firmware, and some required failover to an alternative pathing during the update. One can easily imagine a similar situation for CPUs (for "real time" updates, quiescent instruction processing, flush caches, swap to the new firmware, restart processing), although it may take some time to get to that stage. And for larger (or more complex) updates, migrating a physical CPU offline/online (logically no different than OIR) is certainly a possibility.

                And yes, this is likely server class only, as one doesn't have the necessary redundancy in consumer priced equipment, and while there are likely a handful of consumers willing to pay for enterprise servers as their desktop, the vast majority of the consumer class are not going to be willing to pay for the capability to avoid a reboot a few times a year.
                True, but this isn't online CPU replacement, nor is it updating firmware on a peripheral. What you describe is great, it just isn't what the article is talking about.

                Comment


                • #9
                  Interesting to compare Intel and AMD in regards to focus on technologies surrounding their CPUs, e.g. drivers, chipset, utils, Linux support etc. AMD still haven't understood the importance of features and stability of the WHOLE system not just the CPU, that's why Intel can still charge a premium price for their CPUs and still sell many times more, even for CPU's that a slower. That's why businesses choose Intel and not AMD, the risk of "trouble" is just not worse it. I know AMD is taking market shares, but Intel is still way ahead and will keep being so until AMD start to understand it's not all about the CPU isolated. There are always exceptions, e.g. AMD was first with PCIe4, has less CPU vulnerabilities, but overall, people still trust the Intel brand more than AMD for their vital infrastructure, it's another story in the consumer market.
                  MrCal
                  Junior Member
                  Last edited by MrCal; 03 January 2022, 11:57 AM.

                  Comment


                  • #10
                    Originally posted by MrCal View Post
                    Interesting to compare Intel and AMD in regards to focus on technologies surrounding their CPUs, e.g. drivers, chipset, utils, Linux support etc. AMD still haven't understood the importance of features and stability of the WHOLE system not just the CPU, that's why Intel can still charge a premium price for their CPUs and still sell many times more, even for CPU's that a slower. That's why businesses choose Intel and not AMD, the risk of "trouble" is just not worse it. I know AMD is taking market shares, but Intel is still way ahead and will keep being so until AMD start to understand it's not all about the CPU isolated. There are always exceptions, e.g. AMD was first with PCIe4, has less CPU vulnerabilities, but overall, people still trust the Intel brand more than AMD for their vital infrastructure, it's another store in the consumer market.
                    You are right but in AMD's defence just a few years ago their companies strategy was to "just survive" with their limited resources. The things we are talking here are relevant but not if you are about to go "all in" for your next chip design - IPC performances and corecounts are the attention drivers across the whole industry.
                    Luckily they have turned everything to the positive side. And yes to prosper now your point has to be taken into consideration.

                    Comment

                    Working...
                    X