SMMU는 누구의 주소를 변환합니까?

식별자는 표를 고르고, 표는 주소를 바꿉니다

장치가 메모리를 읽거나 쓸 때는 접근할 주소뿐 아니라 어느 장치의 요청인지도 구별해야 합니다. 한 장치가 여러 프로세스의 작업을 받는다면 어느 주소 공간을 사용할지도 정해야 합니다. SMMU를 읽다가 StreamID와 PASID, 가상 주소가 모두 숫자로 나오더라도 같은 종류의 값으로 취급하지 않습니다.

PCIe Requester ID와 SID도 무조건 같은 숫자는 아닙니다. 예를 들어 ACPI의 IORT를 사용하는 v6.18.37 코드는 PCI DMA alias를 IORT의 ID mapping에 넣고 나온 streamid를 등록합니다. firmware가 기술한 연결과 alias를 확인해야 합니다. IORT는 장치와 IOMMU 사이의 연결·식별자 대응을 알리는 ACPI 표입니다. iort_pci_iommu_init·iort_id_map

Linux의 arm_smmu_make_s1_cd는 CD에 ASID와 표의 시작 주소, 메모리 속성을 채웁니다. arm_smmu_map_pages는 별도로 iova와 paddr의 대응을 페이지 표에 만듭니다. 문맥을 선택하는 값과 변환할 주소가 코드에서도 별개의 인자로 다뤄집니다. CD 구성·페이지 매핑

같은 주소에 PASID만 다르면 어떻게 됩니까?

두 문맥이 같은 가상 주소를 서로 다른 메모리에 연결했다고 가정하겠습니다. 두 단계 모두 4 KiB 페이지를 쓰며, 표와 권한·메모리 속성이 유효한 예입니다. 아래 숫자는 원리를 설명하기 위해 정했으며 실제 장치에서 읽은 값이 아닙니다.

0x234는 페이지 안의 위치입니다. 이 예에서는 각 단계가 페이지 번호를 바꾸고 같은 offset을 유지합니다. SID가 같아도 CD가 다르면 Stage-1 표가 달라질 수 있습니다. 반대로 서로 다른 식별자가 같은 메모리를 공유하도록 매핑할 수도 있으므로, 식별자가 다르다는 사실만으로 두 buffer가 반드시 분리되었다고 판단하지 않습니다.

IOMMUFD 문서는 커널이 관리하는 HWPT_PAGING과 그 위에 연결되는 HWPT_NESTED를 구분합니다. 중첩 구성에서는 장치의 Stage-1 표를 guest·사용자 공간이 관리하고, 부모의 Stage-2가 최종 접근 범위를 제한하는 관계를 표현합니다. CPU KVM memslot을 등록한 사실만으로 장치의 매핑까지 끝났다고 볼 수 없습니다. IOMMUFD 객체와 nested translation

SubstreamID가 없는 요청과 값이 0인 요청도 다릅니다

구형 설명의 “Stage-1이 꺼져 있는데 SubstreamID를 붙이면 요청이 종료된다”는 부분은 무조건 틀린 설명이 아닙니다. Arm IHI 0070C.a의 해당 규칙과 맞습니다. 다만 SMMU가 활성화되어 STE 설정을 적용하는 경우라는 전제를 붙여야 합니다. SMMU 전체를 비활성화한 global bypass와 STE의 Stage-1 bypass는 같은 상태가 아닙니다.

따라서 “없으면 0”으로 치환해서 해석하면 조건을 놓칩니다. 위 표는 2019년의 IHI 0070C.a 규칙을 확인한 것이며, 모든 후속 확장과 구현을 망라한 표는 아닙니다. Arm IHI 0070C.a · 3.3.2·3.9·STE S1DSS

SVA는 같은 주소 공간을 쓰게 하는 기능입니다

SVA, Shared Virtual Addressing은 장치가 프로세스의 가상 주소 공간을 이용하도록 연결하는 기능입니다. “주소가 같다”와 “CPU가 접근할 수 있으면 장치도 아무 준비 없이 접근한다”는 다릅니다. 지원되는 장치·IOMMU·커널 설정과 연결 절차, 권한 검사가 필요합니다.

mm_struct는 프로세스의 주소 공간을 관리하는 커널 객체입니다. 여러 thread가 이를 공유할 수 있으므로 task 하나와 주소 공간 하나를 항상 일대일로 보면 안 됩니다. SVA bind의 호출자는 유효한 mm 참조를 유지해야 하며, 실패는 ERR_PTR로 돌아옵니다. 성공한 handle에서 iommu_sva_get_pasid로 얻은 값은 장치가 사용할 문맥 식별자이지 process PID가 아닙니다. SVA bind·PASID 취득·unbind

이 버전의 arm_smmu_make_sva_cd는 mm가 있으면 mm->pgd의 물리 주소를 CD의 표 시작 주소에 반영합니다. pgd는 CPU 주소 공간의 최상위 페이지 표를 가리키는 포인터입니다. 이 코드가 사용자 buffer의 내용을 CD에 복사하는 것은 아닙니다. 또한 arm_smmu_sva_supported는 coherency, 주소 폭, page granule 등의 조건을 확인하므로 SMMUv3라는 이름만으로 SVA 사용 가능 여부를 정할 수 없습니다. SVA CD 구성과 지원 조건

SVA·ATS·PRI·stall을 같은 기능으로 읽지 않습니다

ATS와 PRI의 일반적인 관계는 Linux의 x86 SVA 문서에서도 설명합니다. 다만 그 문서의 ENQCMD·IA32_PASID 같은 x86 명령·register를 ARM 구현에 그대로 옮기지 않습니다. PCIe ATS·PRI와 x86 전용 절차의 구분

Linux v6.18.37의 Arm SMMUv3에서 특히 확인할 부분은 arm_smmu_handle_ppr입니다. 이 함수는 PRI 요청을 예상 밖의 요청으로 기록하고, 해당 request group의 마지막 요청이면 PRI_RESP_DENY 응답을 만듭니다. 이 코드를 “PRI로 요청을 받으면 페이지를 준비해서 DMA를 계속시킨다”라고 설명할 수는 없습니다. 이 판정은 이 태그의 이 드라이버 경로에 대한 것이며 모든 IOMMU나 다른 커널 버전의 지원 여부를 대신하지 않습니다. arm_smmu_handle_ppr·arm_smmu_priq_thread

arm_smmu_enable_iopf는 CONFIG_ARM_SMMU_V3_SVA를 확인합니다. CONFIG 이름은 커널 빌드에서 기능 포함 여부를 정한 값입니다. 기능이 빌드되었다는 사실만으로 실행 중 모든 장치에서 stall이 활성화되지는 않습니다. 이 버전은 stall을 사용하는 IOPF 등록 경로에서 stream이 하나인 장치를 요구하는 조건도 둡니다. IOPF 활성화 조건·event 변환·page response iommu_sva_handle_mm의 VMA·권한 검사

예전 VFIO ioctl 이름은 현재 헤더와 대조합니다

예전 자료에 등장하는 VFIO_DEVICE_BIND_TASK는 v6.18.37의 공개 include/uapi/linux/vfio.h에서 제공하는 ioctl 이름이 아닙니다. 그 이름을 현재 실행 가능한 예제처럼 옮기면 안 됩니다. 아래는 이 태그의 VFIO device cdev와 IOMMUFD 경로입니다. 기존 VFIO group/container 경로가 모두 사라졌다는 뜻은 아니며, 커널 드라이버의 SVA API와도 구분합니다.

PASID를 사용하는 HWPT에는 IOMMU_HWPT_ALLOC_PASID 같은 할당 조건이 있으며, 하드웨어·드라이버가 요청을 지원하지 않으면 실패할 수 있습니다. 헤더에 구조체가 있다는 것만으로 모든 장치가 그 동작을 지원한다고 판단하지 않습니다. 중첩 SMMUv3 설정도 허용된 STE 필드만 받을 수 있고 부모 변환을 통해 접근 가능한 표여야 합니다. IOAS·HWPT·SMMUv3 설정 정의 VFIO cdev bind·attach 정의

/* 이미 bind한 device cdev와 호환되는 HWPT를 준비한 뒤의 요청 예입니다. */
struct vfio_device_attach_iommufd_pt req = {
    .argsz = sizeof(req),
    .flags = VFIO_DEVICE_ATTACH_PASID,
    .pt_id = hwpt_id,
    .pasid = pasid,
};
int rc = ioctl(device_fd, VFIO_DEVICE_ATTACH_IOMMUFD_PT, &req);

위 코드는 필드의 의미를 보기 위한 일부입니다. fd 생성, 권한, 기능 확인, 객체 할당, 오류 처리와 해제를 포함한 완전한 실행 프로그램은 아닙니다. attach의 pt_id는 입력뿐 아니라 출력 의미도 있으므로 반환 뒤에는 API가 돌려준 값을 기준으로 관리합니다. 이전 글의 구형 ioctl 하나를 다른 ioctl 하나로 이름만 바꿔 이식할 수는 없습니다. IOMMUFD 객체의 연결 관계

프로세스가 끝났다고 장치도 멈춘 것은 아닙니다

CPU가 buffer를 더 사용하지 않아도 장치는 이미 받은 명령으로 DMA를 수행할 수 있습니다. SVA에서는 프로세스 주소 공간이 해제될 때 장치 쪽 변환도 함께 정리해야 합니다. 이때 CPU TLB, SMMU의 변환 cache, ATS 장치의 ATC, 실제 장치 작업의 완료를 나누어 봐야 합니다.

arm_smmu_mm_release의 주석도 DMA가 아직 실행 중일 수 있음을 전제로 합니다. 따라서 “주소 공간을 해제했다”, “변환 cache를 비웠다”, “장치가 buffer 쓰기를 끝냈다”는 세 문장을 구분해서 써야 합니다. 오류나 강제 종료에서는 정상 완료 대신 abort·reset을 선택할 수 있으며, 메모리를 재사용해도 안전한 시점은 장치와 커널의 종료 절차가 보장해야 합니다. mm release·TLB·ATC 무효화 unbind의 호출 조건

기존 코드 분석과 함께 확인할 위치

기존 SMMUv3 분석에는 STE·CD 구성, domain attach와 IOTLB 동기화 helper의 설명이 있습니다. 이 글은 그 코드를 다시 나열하기보다 식별자와 주소의 실제 의미, fault 처리의 지원 범위, 사용자 API와 buffer 수명에서 생기기 쉬운 오해를 보충합니다. 코드와 API는 v6.18.37을 기준으로 대조했으며, 설명용 주소 예제를 실제 하드웨어 실행 결과로 제시하지 않았습니다.

이어서 읽기

• DMA buffer의 주소·소유권·완료
• 게스트 SVC와 Stage-2·KVM 반환
• CPU·장치의 접근 순서와 cache
• blog/kernel/armv9-smmuv3-iommu.html
• ARM SMMUv3·IOMMU·DMA 소스 분석