linux-kernel - Re: [PATCH v3 11/23] iommufd/viommu: Add IOMMUFD_CMD_VQUEUE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <eb0d3629-8663-45e9-b929-0c6edff31291@amd.com>
Date: Wed, 7 May 2025 13:11:43 +0530
From: Vasant Hegde <vasant.hegde@....com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: Nicolin Chen <nicolinc@...dia.com>, kevin.tian@...el.com, corbet@....net,
 will@...nel.org, bagasdotme@...il.com, robin.murphy@....com,
 joro@...tes.org, thierry.reding@...il.com, vdumpa@...dia.com,
 jonathanh@...dia.com, shuah@...nel.org, jsnitsel@...hat.com,
 nathan@...nel.org, peterz@...radead.org, yi.l.liu@...el.com,
 mshavit@...gle.com, praan@...gle.com, zhangzekun11@...wei.com,
 iommu@...ts.linux.dev, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-tegra@...r.kernel.org, linux-kselftest@...r.kernel.org,
 patches@...ts.linux.dev, mochs@...dia.com, alok.a.tiwari@...cle.com,
 Suravee Suthikulpanit <suravee.suthikulpanit@....com>
Subject: Re: [PATCH v3 11/23] iommufd/viommu: Add IOMMUFD_CMD_VQUEUE_ALLOC
 ioctl

Hi Jason,


On 5/6/2025 5:31 PM, Jason Gunthorpe wrote:
> On Tue, May 06, 2025 at 02:45:00PM +0530, Vasant Hegde wrote:
>>> +/**
>>> + * struct iommu_vqueue_alloc - ioctl(IOMMU_VQUEUE_ALLOC)
>>> + * @size: sizeof(struct iommu_vqueue_alloc)
>>> + * @flags: Must be 0
>>> + * @viommu_id: Virtual IOMMU ID to associate the virtual queue with
>>> + * @type: One of enum iommu_vqueue_type
>>> + * @index: The logical index to the virtual queue per virtual IOMMU, for a multi
>>> + *         queue model
>>> + * @out_vqueue_id: The ID of the new virtual queue
>>> + * @addr: Base address of the queue memory in the guest physical address space
>>> + * @length: Length of the queue memory in the guest physical address space
>>> + *
>>> + * Allocate a virtual queue object for a vIOMMU-specific HW-acceleration feature
>>> + * that allows HW to access a guest queue memory described by @addr and @length.
>>> + * It's suggested for VMM to back the queue memory using a single huge page with
>>> + * a proper alignment for its contiguity in the host physical address space. The
>>> + * call will fail, if the queue memory is not contiguous in the physical address
>>> + * space. Upon success, its underlying physical pages will be pinned to prevent
>>> + * VMM from unmapping them in the IOAS, until the virtual queue gets destroyed.
>>> + *
>>> + * A vIOMMU can allocate multiple queues, but it must use a different @index to
>>> + * separate each allocation, e.g. VCMDQ0, VCMDQ1, ...
>>
>> This will handle multiple queues. But AMD vIOMMU needs to comunicate certain
>> control bit setting which is not related to buffers like "Completion wait
>> interrupt".
>>
>> How do we handle that? extend iommu_queue_alloc() or have different interface?
> 
> Do you need a modify queue operation?

We have two types of operations. One that impacts the queue, other set of bits
which doesn't operate on qeueue.

ex: Event log buffer
  - We configure "MMIO Offset 0010h Event Log Base Address Register" with Base
address and size

  -  MMIO Offset 0018h IOMMU Control Register
     EventLogEn: Event log enable
       * When guest sets this bit, qemu will trap and will send queue_alloc
       * When guest disables this bit, qemu will trap and send vqueue_destroy

     This part is fine.

     EventIntEn: Event log interrupt enable
       * When guest sets this bit, qemu will trap
       * this needs to be communicated to Host so that we can program VF Control
BAR and enable the interrupt

  - There is other bit "Completion wait interrupt enable"
    This doesn't related to any buffer. Instead if we configure this for
completion wait command it will generate interrupt.

I am asking how do we handle above two steps? Should it be part of queue IOCTL
or may be some other IOCTL which just passes these info to HW driver?

-Vasant