Category: amd

Phoronix is wondering if there’s about to be a big announcement from AMD:

AMD dropped a juicy tid-bit of information to be announced next month with “openSIL” [an open-source AMD x86 silicon initialization library], complete with AMD Coreboot support….

While about a decade ago AMD was big into Coreboot and at the time committed to it for future hardware platforms (2011: AMD To Support Coreboot On All Future CPUs) [and] open-source AGESA at the time did a lot of enabling around it, that work had died off. In more recent years, AMD’s Coreboot contributions have largely been limited to select consumer APU/SoC platforms for Google Chromebook use. But issues around closing up the AGESA as well as concerns with the AMD Platform Security Processor (PSP) have diminished open-source firmware hopes in recent years….

For the Open Compute Project Regional Summit in Prague, there is a new entry added with a title of OSF on AMD — Enabled by openSIL (yes, folks, OSF as in “Open-Source Firmware”)…. [H]opefully this will prove to be a monumental shift for open-source firmware in the HPC server space.
From the talk’s description:

openSIL (AMD open-source x86 Silicon Initialization Library) offers the versatility, scalability, and light weight interface to allow for ease of integration with open-source and/or proprietary host boot solutions such as coreboot, UEFI and others and adds major flexibility to the overall platform design.

In other words, this library-based solution simply allows a platform integrator to scale from feature rich solutions such as UEFI to slim, lightweight, and secure solutions such as coreboot.
The description promises the talk will include demonstrations “highlighting system bring-up using openSIL integrated with coreboot and UEFI Host Firmware stacks on AMD’s Genoa based platforms.”

It’s now possible to cram more than 192 x64 cores into your typical 2U dual socket system, something that just five years ago would have required at least three nodes. However, as Uptime noted, many legacy datacenters were not designed to accommodate systems this power dense. A single dual-socket system from either vendor can easily exceed a kilowatt, and depending on the kinds of accelerators being deployed in these systems, boxen can consume well in excess of that figure. The rapid trend towards hotter, more power dense systems upends decades-old assumptions about datacenter capacity planning, according to Uptime, which added: “This trend will soon reach a point when it starts to destabilize existing facility design assumptions.”

A typical rack remains under 10kW of design capacity, the analysts note. But with modern systems trending toward higher compute density and by extension power density, that’s no longer adequate. While Uptime notes that for new builds, datacenter operators can optimize for higher rack power densities, they still need to account for 10 to 15 years of headroom. As a result, datacenter operators must speculate as the long-term power and cooling demands which invites the risk of under or over building. With that said, Uptime estimates that within a few years a quarter rack will reach 10kW of consumption. That works out to approximately 1kW per rack unit for a standard 42U rack.

With the new IP-based discovery “block by block” approach to how the open-source AMD Radeon Linux graphics driver is managing the hardware initialization with RDNA3 and moving forward, the AMDGPU driver will try to probe all Radeon GPUs even if it might not end up being fully supported. In turn that ends up destroying the system firmware frame-buffer. But right now in the case of booting an RDNA3 GPU with a slightly out of date kernel (pre-6.0) or lacking the necessary RDNA3 firmware for hardware initialization, it can mean the screen freezing or system appearing unresponsive.

With this workaround still being applied to even modern AMD systems, K Prateek Nayak discovered: “Sampling certain workloads with IBS on AMD Zen3 system shows that a significant amount of time is spent in the dummy op, which incorrectly gets accounted as C-State residency. A large C-State residency value can prime the cpuidle governor to recommend a deeper C-State during the subsequent idle instances, starting a vicious cycle, leading to performance degradation on workloads that rapidly switch between busy and idle phases. One such workload is tbench where a massive performance degradation can be observed during certain runs.”

At least for Tbench, this long-time, unconditional workaround in the Linux kernel has been hurting AMD Ryzen / Threadripper / EPYC performance in select workloads. This workaround hasn’t affected modern Intel systems since those newer Intel platforms use the alternative MWAIT-based intel_idle driver code path instead. The AMD patch evolved into this patch by Intel Linux engineer Dave Hansen. That patch to limit the “dummy wait” workaround to old systems is already queued into TIP’s x86/urgent branch. With it going the route of “x86/urgent” and for fixing a overzealous workaround that isn’t needed on modern hardware, it’s likely this patch will be submitted this week still for the Linux 6.0 kernel rather than needing to wait until the next (v6.1) merge window.

The Ryzen 7000 processors come to market on September 27, and they’ll be joined by new DDR5 memory products that support new EXPO overclocking profiles. AMD’s partners will also offer a robust lineup of motherboards – the chips will snap into new Socket AM5 motherboards that AMD says it will support until 2025+. These motherboards support DDR5 memory and the PCIe 5.0 interface, bringing the Ryzen family up to the latest connectivity standards. The X670 Extreme and standard X670 chipsets arrive first in September, while the more value-oriented B650 options will come to market in October. That includes the newly announced B650E chipset that brings full PCIe 5.0 connectivity to budget motherboards, while the B650 chipset slots in as a lower-tier option. The Ryzen 7000 lineup also brings integrated RDNA 2 graphics to all of the processors in the stack, a first for the Ryzen family.

In response to the research, both Intel and AMD advised customers to adopt new mitigations that the researchers said will add as much as 28 percent more overhead to operations. […] Both Intel and AMD have responded with advisories. Intel has confirmed that the vulnerability exists on Skylake-generation processors that don’t have a protection known as enhanced Indirect Branch Restricted Speculation (eIBRS) in place. “Intel has worked with the Linux community and VMM vendors to provide customers with software mitigation guidance which should be available on or around today’s public disclosure date,” Intel wrote in a blog post. “Note that Windows systems are not affected given that these systems use Indirect Branch Restricted Speculation (IBRS) by default which is also the mitigation being made available to Linux users. Intel is not aware of this issue being exploited outside of a controlled lab environment.” AMD, meanwhile, has also published guidance. “As part of its ongoing work to identify and respond to new potential security vulnerabilities, AMD is recommending software suppliers consider taking additional steps to help guard against Spectre-like attacks,” a spokesman wrote in an email. The company has also published a whitepaper.

[Research Kaveh Razavi added:] “Retbleed is more than just a retpoline bypass on Intel, specially on AMD machines. AMD is in fact going to release a white paper introducing Branch Type Confusion based on Retbleed. Essentially, Retbleed is making AMD CPUs confuse return instructions with indirect branches. This makes exploitation of returns very trivial on AMD CPUs.” The mitigations will come at a cost that the researchers measured to be between 12 percent and 28 percent more computational overhead. Organizations that rely on affected CPUs should carefully read the publications from the researchers, Intel, and AMD and be sure to follow the mitigation guidance.

On their own, the chips aren’t that exciting. They seemingly offer similar performance to the already-released Ryzen 5000 U-series chips. The Ryzen 5000 C-series also uses years-old Vega integrated graphics rather than the upgraded RDNA 2 found in Ryzen 6000 mobile chips, which, upon release, AMD said are “up to 2.1 times faster.” But for someone who’s constantly pushing their Chromebook to do more than just open a Chrome tab or two, the chips bring potentially elevated performance than what’s currently available.