[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] docs: fusa: Add requirements for Device Passthrough


  • To: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Ayan Kumar Halder <ayankuma@xxxxxxx>
  • Date: Wed, 9 Oct 2024 12:24:52 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=riu8HWjqa4InVj9zFGeHqoBn4+hudaVwmcJhwBovG7w=; b=OsBcISy1A8GTB+yb5/KZWmaMQrq17+ZRkwIbfn9BEmLb7EpQwOLR3q8NCY/JW7bW9IusRRn0/Z1NkpuO2DL/UFgjbQ37Ua4AK0JiHfcsJFcY74FRgwSRAUU3cy4InNRNEnFCG1h/ETWrvEwNCxOqMleoZ/oFxmlkpZkFrgp2FvGi7OGG5kT5gqU5/8rf/p/WRvlZrzWbFDsmhNj7h+pTDj0dMxKDPo45tbAfbTtOFLsm+lIo6up0HQmDldS7pcLtbNW1T6F274tcnx93wKnmhTBm7RQletoVxIU9Mz+4eZABy3LlAK22vpDkkWH8YPTHAQT7QYw5kbkwOtNx9e12MA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kB45s9DAWYBGKitDIwWPHErFqAH8tz4Pea2JCZlLs0jcuOi/k8eCzM+dpLIvQAPk/hoVjgGpB8iFRrV9qz0b0zUFrQR59sckyCXQmyA8NITycJZnaBdGVR6nekmuhxa9NS/i+e5twWcfLJ66XE+wtYqLxn+rZR9SQTcDOD+RDpJztdtDZwg3G9+0pzz7j0gnd6/BHsK05psNTx7cDiHX3qDqsiC+3t1E0pLNhXTBECeLZg3aQ/czm6JnQOfa3OaZWWIMk6kann/tCXEnhvw7O0gTIvP0q6BRB0b4ekmuKt2PM97NgjBWOl6aNcD6H7mZyqn5owfq6wYL2Il+EDFQCg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
  • Cc: Oleksandr Tyshchenko <olekstysh@xxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>, Artem Mygaiev <artem_mygaiev@xxxxxxxx>, Hisao Munakata <hisao.munakata.vt@xxxxxxxxxxx>
  • Delivery-date: Wed, 09 Oct 2024 11:25:15 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Hi Bertrand/Stefano/all,

Let me know if the explanation makes sense.

On 09/10/2024 07:30, Bertrand Marquis wrote:
Hi Stefano,

On 9 Oct 2024, at 00:46, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:

On Tue, 8 Oct 2024, Oleksandr Tyshchenko wrote:
On 7 Oct 2024, at 20:55, Oleksandr Tyshchenko <olekstysh@xxxxxxxxx> wrote:

From: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>

Add common requirements for a physical device assignment to Arm64
and AMD64 PVH domains.

Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>
---
Based on:
[PATCH] docs: fusa: Replace VM with domain
https://patchew.org/Xen/20241007182603.826807-1-ayan.kumar.halder@xxxxxxx/
---
---
.../reqs/design-reqs/common/passthrough.rst   | 365 ++++++++++++++++++
docs/fusa/reqs/index.rst                      |   1 +
docs/fusa/reqs/market-reqs/reqs.rst           |  33 ++
docs/fusa/reqs/product-reqs/common/reqs.rst   |  29 ++
4 files changed, 428 insertions(+)
create mode 100644 docs/fusa/reqs/design-reqs/common/passthrough.rst
create mode 100644 docs/fusa/reqs/product-reqs/common/reqs.rst

diff --git a/docs/fusa/reqs/design-reqs/common/passthrough.rst
b/docs/fusa/reqs/design-reqs/common/passthrough.rst
new file mode 100644
index 0000000000..a1d6676f65
--- /dev/null
+++ b/docs/fusa/reqs/design-reqs/common/passthrough.rst
@@ -0,0 +1,365 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Device Passthrough
+==================
+
+The following are the requirements related to a physical device
assignment
+[1], [2] to Arm64 and AMD64 PVH domains.
+
+Requirements for both Arm64 and AMD64 PVH
+=========================================
+
+Hide IOMMU from a domain
+------------------------
+
+`XenSwdgn~passthrough_hide_iommu_from_domain~1`
+
+Description:
+Xen shall not expose the IOMMU device to the domain even if I/O
virtualization
+is disabled. The IOMMU shall be under hypervisor control only.
+
+Rationale:
I think there should be a rationale here to explain why we do not want the
IOMMU
in particular to be assigned to a domain.

ok, will add. I propose the following text:

Xen having the whole picture of the host resources and device assignment
unlike the individual domain makes use of the IOMMU to:
- perform DMA Remapping on Arm64 and AMD64 platforms, which is also known as
stage-2 (or 2nd stage) address translations for DMA devices passed through to
domains and Interrupt Remapping on AMD64 platforms.
- provide access protection functionalities to prevent malicious or buggy DMA
devices from accessing arbitrary memory ranges (e.g. memory allocated to other
domains) or from generating interrupts that could affect other domains.


Added to that, I am not completely sure that there is a clear way to test
this one
as for example one could assign registers not known by Xen.
I am afraid you are right, valid point. For example, on Arm64, if there is no
corresponding driver in use, we will end up exposing IOMMU dt node to Dom0.


Shouldn't this requirement in fact be an assumption of use ?
Assumption of use on Xen? From my PoV sounds reasonable, will do.
In my view, this does not qualify as an Assumption of Use, as it does
not align with the definition we have used so far. If we were to
categorize this as an Assumption of Use, we would need to change the
definition.

We have defined an Assumption of Use as something Xen expects from the
rest of the system for it to function correctly, such as being loaded at
EL2. On the other hand, 'Requirements' refer to behaviors we expect Xen
to exhibit.

Our goal is for Xen to configure the IOMMU at boot using the stage 2
translation, and to ensure that Xen prevents domains from altering the
IOMMU configuration. These are specific expectations of Xen's behavior,
so I believe they fall under Requirements and should be validated in
some way.

However, we could adjust the wording. For example, we might replace the
negative phrasing with a positive requirement, such as: 'Xen shall
configure the IOMMU at boot according to the stage 2 translation
tables.' There is no need to explicitly state that the IOMMU is not
exposed to guests, as nothing is exposed unless explicitly allowed or
mentioned. We could, however, include a brief note about it for clarity.
I agree that this is the right way to turn the requirement into something
that Xen shall do.

Now i think we will need to have a discussion to clear up what to do with:
- assumption of use

Assumption of use is something that other software/hardware components need to do to ensure the correct behavior of Xen.

For eg 1) AoU on hardware :- The hardware needs to support NS-EL2. The hardware needs to have GICv3, SMMUv3 as these are in the scope of safety certification. The hardware needs to have Cortex-A53  r0p4 as these have some errata fixes which affect Xen.

2) AoU on bootloader/firmware - 1) Bootloader/Firmware needs to load Xen in NS-EL2 mode. 2) Bootloader/Firmware needs to initialize DDR

3) AoU on compiler - 1) The GCC version used should be 5.1 or later.

4) AoU on domain - 1) Domains should not use HVC DCC registers as Xen does not emulate them.

The AoUs can either be tested or need to be stated explicitly in the safety manual.

- "integrator" (word always problematic in Fusa as usually use to bail out
and give responsibility to someone else) shall and shall not do (for example
giving access to IOMMU registers to a domain)

The responsibility with the integrator lies for things which cannot be tested. For eg Xen has to be built with a particular configuration (eg SMMUv3) or a specific CPU errata. Integrator should provide at the most X amount of memory for each domain. SMMU (or any specific device) should not be assigned to a domain (which should be under Xen's control).

For some of the AoUs which cannot be tested (eg Bootloader/Firmare needs to initialize the DDR, CNTFRQ_EL0 needs to contain the correct system counter frequency), the responsibility will lie with the integrator.

- interface and what we expect a domain will do with it

This should be covered as part of AoU on domain. We can have more examples of this in near future.

Kind regards,

Ayan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.