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. Or any better naming suggestion? Thanks Nicolin
