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 虚拟机)、dworsham@ (Zircon 虚拟机)、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 调用相同的句柄权限，因此安全暴露面或安全态势不会发生变化。

隐私注意事项

不存在隐私权问题。

测试

核心测试套件将更新为测试新调用。

文档

系统会更新系统调用文档，以描述新的调用。

缺点、替代方案和未知因素

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

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

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

根据此提案，针对每个访问的节点报告的深度字段相对于指定 VMAR（从零开始）。

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

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

在先技术和参考资料

另请参阅 ZX_INFO_PROCESS_MAPS 和 ZX_INFO_VMAR。