Hi Nicolin, On 4/29/2025 10:44 PM, Nicolin Chen wrote: > On Tue, Apr 29, 2025 at 03:52:48PM +0530, Vasant Hegde wrote: >> On 4/29/2025 12:15 PM, Nicolin Chen wrote: >>> On Tue, Apr 29, 2025 at 11:04:06AM +0530, Vasant Hegde wrote: >>>> On 4/29/2025 1:32 AM, Nicolin Chen wrote: >>>>> On Mon, Apr 28, 2025 at 05:42:27PM +0530, Vasant Hegde wrote: >>>>> Yes. For AMD "vIOMMU", it needs a new type for iommufd vIOMMU: >>>>> IOMMU_VIOMMU_TYPE_AMD_VIOMMU, >>>>> >>>>> For AMD "vIOMMU" command buffer, it needs a new type too: >>>>> IOMMU_VCMDQ_TYPE_AMD_VIOMMU, /* Kdoc it to be Command Buffer */ >>>> >>>> You are suggesting we define one type for AMD and use it for all buffers like >>>> command buffer, event log, PPR buffet etc? and use iommu_vcmdq_alloc->index to >>>> identity different buffer type? >>> >>> We have vEVENTQ for event logging and FAULT_QUEUE for PRI, but both >>> are not for hardware accelerated use cases. >>> >>> I didn't check the details of AMD's event log and PPR buffers. But >>> they seem to be the same ring buffers and can be consumed by guest >>> kernel directly? >> >> Right. Event log is accelerated and consumed by guest directly. Also we have >> Event Log B ! >> >>> >>> Will the hardware replace the physical device ID in the event with >>> the virtual device ID when injecting the event to a guest event/PPR >>> queue? >>> If so, yea, I think you can define them separately using the> vCMDQ >> infrastructures: >>> - IOMMU_VCMDQ_TYPE_AMD_VIOMMU_CMDBUF >>> - IOMMU_VCMDQ_TYPE_AMD_VIOMMU_EVENTLOG >>> - IOMMU_VCMDQ_TYPE_AMD_VIOMMU_PPRLOG >>> (@Kevin @Jason Hmm, in this case we might want to revert the naming >>> "vCMDQ" back to "vQEUEUE", once Vasant confirms.) > > I think I should rename IOMMUFD_OBJ_VCMDQ back to IOMMUFD_OBJ_VQUEUE > since the same object fits three types of queue now in the AMD case. Makes sense. AMD architecture supports 5 buffers. In practice we have not implemented event log B / PPR Log B in Linux. Command buffer Event Log A / B PPR Log A / B -Vasant
