With recent fears about security, and given that these processors are aiming to go to the Enterprise space, AMD had to dedicate some time to explaining how secure the new platform is. AMD has had its Secure Processor in several CPUs at this point: a 32-bit ARM Cortex-A5 acting as a microcontroller that runs a secure OS/kernel with secure off-chip storage for firmware and data – this helps provide cryptographic functionality for secure key generation and key management. This starts with hardware validated boot (TPM), but includes Secure Memory Encryption and Secure Encrypted Virtualization.

Encryption starts at the DRAM level, with an AES-128 engine directly attached to the MMU. This is designed to protect against physical memory attacks, with each VM and Hypervisor able to generate a separate key for their environment. The OS or Hypervisor can choose which pages to encrypt via page tables, and the DMA engines can provide support for external devices such as network storage and graphics cards to access encrypted pages.

Because each VM or container can obtain its own encryption key, this isolates them from each other, protecting against cross-contamination. It also allows unencrypted VMs to run alongside encrypted ones, removing the all-or-nothing scenario. The keys are transparent to the VMs themselves, managed by the protected hypervisor. It all integrates with existing AMD-V technology.

Alongside this are direct RAS features in the core, with the L1 data cache using SEC-DED ECC and L2/L3 caches using DEC-TED ECC. The DRAM support involves x4 DRAM device failure correction with addr/cmd parity and write CRC with replay. Data poisoning is handled with reporting and a machine check recovery mode. The Infinity Fabric between dies and between sockets is also link-packet CRC backed with retry.

One element that was not discussed is live VM migration across encrypted environments. We fully suspect that an AMD-to-AMD live migration be feasible, although an AMD-to-Intel or Intel-to-AMD will have issues, given that each microarchitecture has unique implementations of certain commands.

NUMA NUMA: Infinity Fabric Bandwidths Power Management and Performance
Comments Locked

131 Comments

View All Comments

  • deltaFx2 - Wednesday, June 21, 2017 - link

    That's because intel cheats on SPEC in icc by doing transformations that are specifically targetted at making SPEC faster and nothing else. Libquantum is a particularly egregious example where you nearly double the performance by doing tricks that help nothing else. But this is generally true across the suite. It's not unlike VW's emission defeat devices: do something special when you're being tested.

    As for Tom's hardware, they're not authorities on anything server. What they know something about is gaming benchmarking, and that's pretty much it. I don't expect he'd know a thing about it, and whether 20% is correct vs 40%. It's a feeble attempt at sounding clever. The people buying this stuff know what they're doing, and aren't going to be influenced by some online reviewer.
  • Ryan Smith - Tuesday, June 20, 2017 - link

    I've posted galleries of the full slide decks. The slide you're interested in is: http://images.anandtech.com/galleries/5699/epyc_te...

    "Scores for these E5 processors extrapolated from test results published at www.spec.org, applying a conversion multiplier to each published score"
  • patrickjp93 - Wednesday, June 21, 2017 - link

    No, it vastly underestimates and undermines Intel's real-world performance.
  • lefty2 - Tuesday, June 20, 2017 - link

    I think you missed the point of the eight-core processor. That's for GPU compute servers, where you want the cheapest processor possible with the most PCIe lanes. It's probably going to be the one that sells the most, because Intel has nothing comparable.
  • Luckz - Tuesday, June 20, 2017 - link

    Is this useful for the mining craze?
  • LurkingSince97 - Tuesday, June 20, 2017 - link

    probably not. Miners want the most GPU (hashes) per Watt (combined with total price). If they can do that with 5 smaller, cheaper machines vs 1 larger one, they will. Mining does not need coordination across multiple GPUs.

    The enterprisey compute stuff -- machine learning being a huge one -- often _does_ need to coordinate across GPUs in one big data set and will run in datacenters where consolidation into performance/$ and performance/Watt will often like servers with few CPU and many GPU, with a ton of I/O and connectivity to other servers.

    Mining doesn't care about I/O, just total # of ports. People even use tools to split up a x16 bus of a normal consumer motherboard into may smaller PCIe ports each with a GPU on it. The GPU will compute hashes just as well with a x2 port as a x16 one.
  • KAlmquist - Wednesday, June 21, 2017 - link

    EPYC has 128 PCI-e lanes on both 1 socket and 2 socket systems, so if AMD had intended the EPYC 7251 to be used for GPU compute servers, they would have made it part of the single socket lineup. That doesn't mean that the chip won't be used in GPU compute servers; it just means that GPU compute servers are not the market that AMD intended to target with the chip.
  • Zizy - Thursday, June 22, 2017 - link

    All these 2P Epyc CPUs should be just fine in 1P as well. Obviously nobody will buy most of them to run in 1P, as 1P are cheaper. It is just 1P that is limited - it can be *only* used in 1P.
    And given 500-ish price of the chip, I can see why AMD didn't bother to give additional 400 chip for 1P - it wouldn't change anything. And limiting this chip to just 1P would be pointless, as the other segments such as "need tons of memory" would be hurting for no good reason.
  • armtec - Tuesday, June 20, 2017 - link

    NUMA NUMA IEI... I hadn't previously made this connection but now I will every time I need to think about server configs...
  • Barilla - Tuesday, June 20, 2017 - link

    I read that header and now that stupid song will be stuck in my head for days...

Log in

Don't have an account? Sign up now