RFC-0253：zx_object_get_info ZX_INFO_VMAR_MAPS

问题陈述

当调用方只关心一个 VMAR 时，ZX_INFO_PROCESS_MAPS 会效率低下。

ZX_INFO_PROCESS_MAPS 会迭代进程的地址空间，为调用方提供描述进程可用的每个地址区域和映射的 zx_info_maps_t 结构体。即使调用方只需要其中的一部分信息（例如仅需要一个特定 VMAR 的内容），也必须支付全额费用。更糟糕的是，调用方必须过滤结果。

摘要

我们建议添加一个新的 object_info 主题 ZX_INFO_VMAR_MAPS，其行为与 ZX_INFO_PROCESS_MAPS 类似，但适用于 VMAR。

利益相关方

哪些人对此 RFC 的接受与否有利益相关？（此部分为可选部分，但建议填写。）

教员：

审核者：adamperry@（Starnix）、adanis@（Zircon VM）、dworsham@（Zircon VM）、mcgrathr@（Zircon）

共享：在起草此 RFC 之前，我们曾与 adamperry@ 和 adanis@ 简要讨论过该提案。

要求

此提案旨在允许 Starnix 查询特定 VMAR（Linux 进程地址空间，也称为受限区域），而不是整个进程的地址空间，从而提高 Starnix 性能。

效率 - 新系统调用应执行与指定 VMAR 的大小/复杂性成正比的工作。

对称性和人体工学 - 新调用产生的结果在结构上应与现有 ZX_INFO_PROCESS_MAPS 产生的结果类似，以尽可能减少希望使用新调用的现有调用方的工作量。

设计

我们将添加一个名为 ZX_INFO_VMAR_MAPS 的新 object_info 主题。这个新主题的行为将与现有的 ZX_INFO_PROCESS_MAPS 类似，但它将返回指定 VMAR 的结果，而不是返回指定进程的结果。

与 ZX_INFO_PROCESS_MAPS 一样，结果将是深度优先的先序遍历。

第一个结果记录将描述指定的 VMAR。

与 ZX_INFO_PROCESS_MAPS 不同，结果的深度字段将相对于指定的 VMAR，而不是相对于指定的进程。第一个结果记录的深度为 0。

举例来说，更新后的 object_get_info 文档将如下所示：

If *topic* is `ZX_INFO_VMAR_MAPS`, *handle* must be of type `ZX_OBJ_TYPE_VMAR`
and have `ZX_RIGHT_INSPECT`.

和

### ZX_INFO_VMAR_MAPS

*handle* type: `VM Address Region`, with `ZX_RIGHT_INSPECT`

*buffer* type: `zx_info_maps_t[n]`

The `zx_info_maps_t` array is a depth-first pre-order walk of the target
VMAR tree. As per the pre-order traversal base addresses will be in ascending
order.

See `ZX_INFO_PROCESS_MAPS` for a description of `zx_info_maps_t`.

The first `zx_info_maps_t` will describe the queried VMAR. The *depth*
field of each entry describes its relationship to the nodes that come
before it. The queried VMAR will have depth 0. All other entries have
depth 1 or greater.

Additional errors:

*   `ZX_ERR_ACCESS_DENIED`: If the appropriate rights are missing.
*   `ZX_ERR_BAD_STATE`: If the target process containing the VMAR has
    terminated, or if the address space containing the VMAR has been
    destroyed.

实现

我们将通过一系列向后兼容的小更改来实现新功能，其中包括对测试和文档的更新。我们将重构一些现有代码，以便在 ZX_INFO_PROCESS_MAPS 和 ZX_INFO_VMAR_MAPS 中重复使用。

性能

对现有代码/系统没有影响。完成后，从 ZX_INFO_PROCESS_MAPS 迁移到 ZX_INFO_VMAR_MAPS 的调用方应该会看到性能提升，因为系统会减少系统调用执行的工作量，并消除任何调用后过滤步骤。

工效学设计

为方便使用，结果类型和语义将与现有调用 object_get_info 与 ZX_INFO_PROCESS_MAPS 的结果类型和语义非常接近。

向后兼容性

建议的更改是向后兼容的。现有通话不会受到影响。新通话的行为与现有通话类似。

安全注意事项

由于返回的信息是 ZX_INFO_PROCESS_MAPS 返回信息的一部分，并且由于新的 object_get_info 调用将需要与现有 ZX_INFO_PROCESS_MAPS 调用所需的相同句柄权限，因此安全边界或状态不会发生变化。

隐私注意事项

没有隐私问题。

测试

core-tests 套件将更新为测试新调用。

文档

系统会更新系统调用文档，以介绍新调用。

缺点、替代方案和未知情况

实现此方案只需要少量工程工作。未来对新系统调用的维护应尽可能少。此外，新调用不会显著降低（内核实现）灵活性或（API）自由度。

实现新主题的主要替代方案是继续使用效率较低的 ZX_INFO_PROCESS_MAPS 并继续过滤结果。

相对于目标的深度与地址空间

在此提案中，为每个访问过的节点报告的深度字段相对于目标（指定的 VMAR）而言，从零开始。

另一种方法是报告相对于进程地址空间的深度。即报告绝对深度。这两种方案都符合要求，并且在实现指定目标方面表现相似。

我们选择了相对于目标的深度，因为它向调用方公开的信息更少，并且在内部锁定策略方面实现更灵活。

在先技术和参考文档

另请参阅 ZX_INFO_PROCESS_MAPS 和 ZX_INFO_VMAR。