Cloudflare 将推出容器平台 Containers，深度集成 Workers Cloudflare 宣布，其容器平台 Cloudflare Containers 将于 2025 年 6 月下旬正式开启公测。这项服务将...

Cloudflare 将推出容器平台 Containers，深度集成 Workers

Cloudflare 宣布，其容器平台 Cloudflare Containers 将于 2025 年 6 月下旬正式开启公测。这项服务将标准 OCI (Docker) 容器无缝部署到 Cloudflare 遍布全球 300 多个节点的边缘网络上，实现按需启动和运行。

CF Containers 提供比传统虚拟机方案更快的启动速度和更高的资源效率，深度集成 Workers 和 Durable Objects（无服务器分布式存储和状态管理服务），提供内置的 API 网关功能、服务网格支持以及自定义编排能力。开发者通过少量代码即可便捷地实现服务间的路由、鉴权、监控和调度逻辑，简化复杂应用的部署与管理。

CF Containers 费用从向容器发送请求或手动启动容器时开始计算。容器进入休眠状态后计费停止，休眠可在配置的超时后自动执行。在计费模式上采用与 Google Cloud Run 类似的精细化计算定价方式，成本与之相当。它按照容器 CPU 、内存和磁盘 I/O 实际占用时长计费，精确到 10 毫秒。网络出站流量提供每月 1TB 的免费额度，超出部分将根据不同区域进行分区定价。

CF 表示将制定具体细节，推出涵盖所有维度的清晰透明的定价方案。

[消息等级 Level C2 · 简要]

Read More

Linux 6.16 Could See AMD SEV-SNP SVSM vTPM Driver Merged For EPYC CPUs

The Linux 6.16 kernel this summer will likely see the new SNP SVSM vTPM driver introduced for further enhancing the AMD EPYC confidential computing capabilities atop the mainline Linux kernel.

Queued this week via the tip/tip.git x86/sev Git branch is this SNP SVSM vTPM driver for recent EPYC CPUs boasting Secure Encrypted Virtualization Secure Nested Paging (SEV-SNP) capabilities. With the driver making it now to a tip/tip.git branch, it will likely be submitted for the next merge window (Linux 6.16 in June) barring any new problems from arising with the code or other objections being raised.

AMD driver queued


Stefano Garzarella of Red Hat spearheaded the effort on this new Linux driver for helping the AMD virtualization confidential computing effort. Stefano explains of this new driver in the patch series now queued in the TIP branch:
"AMD SEV-SNP defined a new mechanism for adding privileged levels (VMPLs) in the context of a Confidential VM. These levels can be used to run the guest OS at a lower privilege level than a Secure VM Service Module (SVSM). In this way SVSM can be used to emulate those devices (such as TPM) that cannot be delegated to an untrusted host.

The guest OS can talk to SVSM using a specific calling convention and instructions (a kind of system call/hyper call) and request services such as TPM emulation.

The main goal of this series is to add a driver for the vTPM defined by the AMD SVSM spec. The specification defines a protocol that a
SEV-SNP guest OS (running on VMPL >= 1) can use to discover and talk to a vTPM emulated by the SVSM in the guest context, but at a more
privileged level (VMPL0).

This series is based on the RFC sent by James last year. In the meantime, the patches have been maintained and tested in the Coconut Linux fork along with the work to support the vTPM emulation in Coconut SVSM."

This new driver is gated by the TCG_SVSM Kconfig switch.

TCG_SVSM

Nice to see more of the AMD SEV-SNP / Trusted Computing / Confidential Computing work nearing the mainline kernel. Like with Intel and their Trust Domain Extensions (TDX) enablement, some elements of the upstreaming have dragged on for quite some time and multiple rounds of code review.

Read More

A Fresh Take On Virtual Swap Space Being Pursued For The Linux Kernel

A request for comments (RFC) patch series sent out this week for the Linux kernel is working on the notion of Virtual Swap Space support. The notion of Virtual Swap Space has been talked about for years and even going back to 2011 there's been efforts to redesign the kernel's swap cache along similar lines.

This latest work on Virtual Swap Space for Linux was posted by open-source developer Nhat Pham and is currently deemed a prototype implementation. With this new code the focus is on decoupling Zswap from the backing swap file as well as simplifying/optimizing Swapoff behavior. Additionally, this code could help out for scenarios around multi-tier swapping, swapfile compaction, and other functionality.

Nhat Pham explains of this work on Virtual Swap Space for Linux:
"This RFC implements the virtual swap space idea, based on Yosry's proposals at LSFMMBPF 2023, as well as valuable
inputs from Johannes Weiner. The same idea (with different implementation details) has been floated by Rik van Riel since at least
2011.

The code attached to this RFC is purely a prototype. It is not 100% merge-ready. I do, however, want to show people this prototype/RFC, including all the bells and whistles and a couple of actual use cases, so that folks can see what the end results will look like, and give me early feedback :)

I. Motivation

Currently, when an anon page is swapped out, a slot in a backing swap device is allocated and stored in the page table entries that refer to the original page. This slot is also used as the "key" to find the swapped out content, as well as the index to swap data structures, such as the swap cache, or the swap cgroup mapping. Tying a swap entry to its backing slot in this way is performant and efficient when swap is purely just disk space, and swapoff is rare.

However, the advent of many swap optimizations has exposed major drawbacks of this design. The first problem is that we occupy a physical slot in the swap space, even for pages that are NEVER expected to hit the disk: pages compressed and stored in the zswap pool, zero-filled pages, or pages rejected by both of these optimizations when zswap writeback is disabled. This is the arguably central shortcoming of zswap:

* In deployments when no disk space can be afforded for swap (such as mobile and embedded devices), users cannot adopt zswap, and are forced to use zram. This is confusing for users, and creates extra burdens for developers, having to develop and maintain similar features for two separate swap backends (writeback, cgroup charging, THP support, etc.).

* Resource-wise, it is hugely wasteful in terms of disk usage, and limits the memory saving potentials of these optimizations by the static size of the swapfile, especially in high memory systems that can have up to terabytes worth of memory. It also creates significant challenges for users who rely on swap utilization as an early OOM signal.

Another motivation for a swap redesign is to simplify swapoff, which is complicated and expensive in the current design. Tight coupling between a swap entry and its backing storage means that it requires a whole page table walk to update all the page table entries that refer to this swap entry, as well as updating all the associated swap data structures (swap cache, etc.).
...
This design allows us to:
* Decouple zswap (and zeromapped swap entry) from backing swapfile: simply associate the virtual swap slot with one of the supported backends: a zswap entry, a zero-filled swap page, a slot on the swapfile, or an in-memory page.

* Simplify and optimize swapoff: we only have to fault the page in and have the virtual swap slot points to the page instead of the on-disk physical swap slot. No need to perform any page table walking.
...
Other than decoupling swap backends and optimizing swapoff, this new design allows us to implement the following more easily and efficiently:

* Multi-tier swapping, with transparent transferring (promotion/demotion) of pages across tiers. Similar to swapoff, with the old design we would need to perform the expensive page table walk.

* Swapfile compaction to alleviate fragmentation (as proposed by Ying Huang).

* Mixed backing THP swapin: Once you have pinned down the backing store of THPs, then you can dispatch each range of subpages to appropriate swapin handle.

* Swapping a folio out with discontiguous physical swap slots"

Those wanting to learn more about this prototype work on Virtual Swap Space for Linux can see this RFC patch series for all the details.

Read More