Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GIPC: Introduce G-stage page table In Process Context (GIPC) capability #413

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

guoren83
Copy link

The current G-stage page table resides within the device context, bound specifically to a PCI-e function. Consequently, this setup limits the function's capability to serve only a single virtual machine.

PCI-e introduces SR-IOV to address this issue, yet it comes with constraints: SR-IOV consumes PCI configuration address space and must be configured during the PCI device enumeration process. Its finite capacity and inflexibility make it ill-suited for fulfilling the needs of higher-density I/O environments.

The number of use cases for virtualizing DMA devices that do not have built-in SR_IOV capability is increasing. The Linux VFIO driver framework provides device-agnostic and unified APIs for direct device access. This framework is called as Virtual Function I/O (VFIO) Mediated devices.

The GIPC of riscv IOMMU could bind any mediated devices to any virtual machine without SR-IOV.

Here is the abstract of this approach:

  • Use PC.iohgatp instead of DC.iohgatp.
  • Use PC.msi* instead of DC.msi*.
  • Use SPA instead of GPA for DC.fsc.pdtp and PDT. (PDT is maintained by the host instead of the guest. For example, the guest uses virtio-IOMMU API to configure a portion, not the entire, of the PDT. Every PDT entry could be a software-defined device for any VM.)

TODO:

  • iommu_ref_model

@guoren83 guoren83 marked this pull request as draft August 29, 2024 03:58
@guoren83 guoren83 marked this pull request as ready for review August 29, 2024 03:58
The current G-stage page table resides within the device context and is
only bound to one PCI-e function. Consequently, this setup limits the
function's capability to serve only a single virtual machine.

PCI-e introduces SR-IOV to address this issue, yet it comes with
constraints: SR-IOV consumes PCI configuration address space and must be
configured during the PCI device enumeration process. Its finite
capacity and inflexibility make it ill-suited for fulfilling the needs of
higher-density I/O environments.

The number of use cases for virtualizing DMA devices that do not have
built-in SR-IOV capability is increasing. The Linux VFIO driver framework
provides device-agnostic and unified APIs for direct device access. This
framework is called as Virtual Function I/O (VFIO) Mediated devices.

The GIPC of riscv IOMMU could bind any mediated devices to any virtual
machine without SR-IOV.

Here is the abstract of this approach:
 - Use PC.iohgatp instead of DC.iohgatp.
 - Use PC.msi* instead of DC.msi*.
 - Use SPA instead of GPA for DC.fsc.pdtp and PDT. (PDT is maintained by
   the host instead of guest. e.g. The guest use virtio-IOMMU API to
   configure a portion, not the entire, of the PDT. Every PDT entry
   could be a software-defined device for any VM.)
 - Use SPA instead of GPA for DC.fsc.pdtp and PDT. (The host maintains
   the PDT instead of the guest. For example, the guest uses the
   virtio-IOMMU API to configure a portion, not the entire PDT. Every PDT
   entry could be a software-defined device for any VM.)

TODO:
 - iommu_ref_model

Signed-off-by: Guo Ren <[email protected]>
Signed-off-by: Hao Ziyi <[email protected]>
Signed-off-by: Dust Li <[email protected]>
Signed-off-by: Shuai Xue <[email protected]>
Signed-off-by: Feng Guanghui <[email protected]>
@leBsky
Copy link

leBsky commented Sep 30, 2024

  1. when GIPC==1 && dc.tc.PDTV ==1,it seems that iohgatp and msi* are all in process context. However, when dc.tc.pdtp.mode == bare, the first stage transaltion is treated as bare, and no process directory table walk is needed, as a result, iohgatp and msi* information cannot be found in this case. Please help clarify this.

  2. when GIPC==1 && dc.tc.PDTV ==1, should the dc.tc.iohgatp and dc.msi* be reserved? That is, if detect the dc.tc.iohgatp or dc.msi* are not 0, is it required to report "DDT entry misconfigured" ?

@guoren83
Copy link
Author

guoren83 commented Oct 7, 2024

  1. when GIPC==1 && dc.tc.PDTV ==1,it seems that iohgatp and msi* are all in process context. However, when dc.tc.pdtp.mode == bare, the first stage transaltion is treated as bare, and no process directory table walk is needed, as a result, iohgatp and msi* information cannot be found in this case. Please help clarify this.

Yes, you are right. Thanks for pointing it out; I missed dc.tc.pdtp.mode = bare. The words should be "dc.tc.GIPC==1 && dc.tc.pdtp.mode != bare".

  1. when GIPC==1 && dc.tc.PDTV ==1, should the dc.tc.iohgatp and dc.msi* be reserved? That is, if detect the dc.tc.iohgatp or dc.msi* are not 0, is it required to report "DDT entry misconfigured" ?

Yes, when "dc.tc.GIPC==1 && dc.tc.pdtp.mode != bare", dc.tc.iohgatp and dc.msi are ignored. I will add explicit words for clarification in the next version.

Thx for the review. I will add your name to the co-develop list.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants