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

"guest" in IOMMU and vIOMMU #15

Open
pinggit opened this issue Jul 16, 2020 · 4 comments
Open

"guest" in IOMMU and vIOMMU #15

pinggit opened this issue Jul 16, 2020 · 4 comments

Comments

@pinggit
Copy link
Owner

pinggit commented Jul 16, 2020

reading vIOMMU in ch3, again the term "guest" bring a little confusions:

image

IOMMU provides a short path for the guest to get access to the physical device memory. IOMMU helps to prevent DMA attacks that could be originated by malicious devices. IOMMU provides DMA and interrupt remapping facilities to ensure I/O devices behave within the boundaries they've been allotted

what is the "guest" here? I believe it is an user application trying to access NIC? (so with IOMMU instead of access low-level NIC physical address, user just need to access a host memory address which was mapped from the NIC physical address)

@pinggit
Copy link
Owner Author

pinggit commented Jul 16, 2020

and same in vIOMMU, "guest" means a VM here I believe?

Virtual IOMMU
Virtual IOMMU (vIOMMU) is allowing to emulate IOMMU for guest VMs.

vIOMMU has the following characteristics:
• translates guest I/O Virtual Addresses (IOVA) to Guest Physical Addresses (GPA)
• Guest Physical Addresses (GPA) are translated to Host Virtual Addresses (HVA) through the hypervisor memory management system.
• performs device isolation.
• implements a I/O TLB (Translation Lookaside Buffer) API which exposes memory mappings

In order to get a virtual device working with a virtual IOMMU we have to:
• create the needed IOVA mappings into the vIOMMU
• configure the device’s DMA with the IOVA

Following mechanisms can be used to create vIOMMU memory mappings:
• Linux Kernel’s DMA API for kernel drivers
• VFIO for userspace drivers

@ldurandadomia
Copy link
Collaborator

Guest is the VM. Host is the Hypervisor compute node (real physical node).

IOMMU help to protect DMA transfer (IOMMU = intel vt-d).
A guest VM does not access directly to the host memory, but is used an indirection table that provide access to the real memory.
Hence you can scope (limit, give boundaries) the host memory area which is accessed by a guest.

IOMMU is used for device assignment to a VM (Guest instance). When a host physical NIC card is assigned to a VM (= moved to be used exclusively by this VM), IOMMU is used to define a host memory area in which the device and the VM will operate (memory area used for DMA transfer between VM and physical NIC).

@ldurandadomia
Copy link
Collaborator

vIOMMU is a step further .... used in nested virtualization.
If you have a guest instance running a VM, you could be interested to assign a host physical NIC to these nested VM.

To do so, you need both IOMMU and vIOMMU:

  • IOMMU = protect host memory (book host memory to be used by the virtual guest = L1)
  • vIOMMU = protect guest memory (book guest memory to be used by the nested guest = L2).

@pinggit
Copy link
Owner Author

pinggit commented Jul 16, 2020

thanks @ldurandadomia . it's much clearer now. basically if I got it correct 2 things achieved:

  1. address mapping between pNIC and host memory. to access pNIC, a VM does not need to know its address structure, but instead was given a mapping table in host mem, so VM only need to know how to access that part of host address.
  2. because of 1, if we go further, we can "limit" the access of the pNIC (by access the specific part of the mapped host mem), to only one VM. that is effectively "assign" the pNIC to the VM.

and, sounds like vIOMMU is nothing but the exactly same thing done for nested VM(l2 VM), inside of VM (l1 vm).

correct me if I'm wrong.

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

No branches or pull requests

2 participants