From: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
To: Sairaj Kodilkar <sarunkod@amd.com>, qemu-devel@nongnu.org
Cc: pbonzini@redhat.com, richard.henderson@linaro.org,
eduardo@habkost.net, peterx@redhat.com, david@redhat.com,
philmd@linaro.org, mst@redhat.com, marcel.apfelbaum@gmail.com,
alex.williamson@redhat.com, vasant.hegde@amd.com,
suravee.suthikulpanit@amd.com, santosh.shukla@amd.com,
Wei.Huang2@amd.com, clement.mathieu--drif@eviden.com,
ethan.milon@eviden.com, joao.m.martins@oracle.com,
boris.ostrovsky@oracle.com
Subject: Re: [PATCH v2 16/20] amd_iommu: Set all address spaces to default translation mode on reset
Date: Fri, 30 May 2025 17:30:11 -0400 [thread overview]
Message-ID: <18ca629c-0ac5-4a0f-a88f-92a3afa328ab@oracle.com> (raw)
In-Reply-To: <6cfb9c54-d7ac-4e4d-9370-b62175f861bc@amd.com>
Hey Sairaj,
On 5/29/25 2:16 AM, Sairaj Kodilkar wrote:
>
>
> On 5/2/2025 7:46 AM, Alejandro Jimenez wrote:
>> On reset, restore the default address translation mode for all the
>> address spaces managed by the vIOMMU.
>>
>> Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
>> ---
>> hw/i386/amd_iommu.c | 28 ++++++++++++++++++++++++++++
>> 1 file changed, 28 insertions(+)
>>
>> diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
>> index 71018d70dd10..90491367594b 100644
>> --- a/hw/i386/amd_iommu.c
>> +++ b/hw/i386/amd_iommu.c
>> @@ -962,6 +962,33 @@ static void
>> amdvi_switch_address_space(AMDVIAddressSpace *amdvi_as)
>> }
>> }
>> +/*
>> + * For all existing address spaces managed by the IOMMU, enable/
>> disable the
>> + * corresponding memory regions depending on the address translation
>> mode
>> + * as determined by the global and individual address space settings.
>> + */
>> +static void amdvi_switch_address_space_all(AMDVIState *s)
>> +{
>> + AMDVIAddressSpace **iommu_as;
>> +
>> + for (int bus_num = 0; bus_num < PCI_BUS_MAX; bus_num++) {
>> +
>> + /* Nothing to do if there are no devices on the current bus */
>> + if (!s->address_spaces[bus_num]) {
>> + continue;
>> + }
>> + iommu_as = s->address_spaces[bus_num];
>> +
>> + for (int devfn = 0; devfn < PCI_DEVFN_MAX; devfn++) {
>> +
>> + if (!iommu_as[devfn]) {
>> + continue;
>> + }
>> + amdvi_switch_address_space(iommu_as[devfn]);
>> + }
>> + }
>> +}
>> +
>> /* log error without aborting since linux seems to be using reserved
>> bits */
>> static void amdvi_inval_devtab_entry(AMDVIState *s, uint64_t *cmd)
>> {
>> @@ -2199,6 +2226,7 @@ static void amdvi_sysbus_reset(DeviceState *dev)
>> /* Discard all mappings on device reset */
>> amdvi_address_space_unmap_all(s);
>> + amdvi_switch_address_space_all(s);
>
> Hi Alejandro
>
> I think amdvi_sysbus_reset should set iommu_as->addr_translation flag to
> "false" before switching all the address spaces. Without this, the
> devices will keep using IOMMU address space.
>
My first impulse is to agree with you, from the standpoint of
considering the no_dma mode as the "default mode", and a reset should
bring us back to default. But I wonder that is necessarily the
architectural behavior...
After a reset, in order for any device transactions to be processed, a
guest driver must reinitialize the IOMMU data structures, including the
Device Table and specifically the table entry for the device. That must
trigger a INVAL_DEVTAB_ENTRY that will be intercepted and
as->addr_translation will be set correctly. If the guest driver doesn't
do these operations, then a device won't be able to use the IOMMU
because it doesn't have a valid DTE, right? The earlier mappings were
already dropped, so it doesn't affect the host.
Again, I see your point, and making this change is likely the right
thing to do, which is why I'll make the change for v3. Just wondering if
implementing such behavior is actually architecturally accurate or just
the "common sense" approach...
Thank you for your attention to detail and all the valuable feedback. I
will be out next week, and will send v3 once I am back online.
Alejandro
> Regards
> Sairaj Kodilkar
>> }
>> static void amdvi_sysbus_realize(DeviceState *dev, Error **errp)
>
next prev parent reply other threads:[~2025-05-30 21:31 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-02 2:15 [PATCH v2 00/20] AMD vIOMMU: DMA remapping support for VFIO devices Alejandro Jimenez
2025-05-02 2:15 ` [PATCH v2 01/20] memory: Adjust event ranges to fit within notifier boundaries Alejandro Jimenez
2025-05-11 18:31 ` Michael S. Tsirkin
2025-05-12 8:02 ` David Hildenbrand
2025-05-12 17:29 ` Peter Xu
2025-06-12 6:54 ` Vasant Hegde
2025-06-12 21:49 ` Alejandro Jimenez
2025-05-02 2:15 ` [PATCH v2 02/20] amd_iommu: Document '-device amd-iommu' common options Alejandro Jimenez
2025-05-02 2:15 ` [PATCH v2 03/20] amd_iommu: Reorder device and page table helpers Alejandro Jimenez
2025-05-02 2:15 ` [PATCH v2 04/20] amd_iommu: Helper to decode size of page invalidation command Alejandro Jimenez
2025-05-02 2:15 ` [PATCH v2 05/20] amd_iommu: Add helper function to extract the DTE Alejandro Jimenez
2025-05-12 6:45 ` Sairaj Kodilkar
2025-05-14 20:23 ` Alejandro Jimenez
2025-05-20 10:18 ` Ethan MILON
2025-05-21 14:49 ` Alejandro Jimenez
2025-06-12 8:31 ` Ethan MILON
2025-05-02 2:15 ` [PATCH v2 06/20] amd_iommu: Return an error when unable to read PTE from guest memory Alejandro Jimenez
2025-06-12 10:37 ` Vasant Hegde
2025-06-13 17:44 ` Alejandro Jimenez
2025-05-02 2:15 ` [PATCH v2 07/20] amd_iommu: Add helpers to walk AMD v1 Page Table format Alejandro Jimenez
2025-05-02 2:15 ` [PATCH v2 08/20] amd_iommu: Add a page walker to sync shadow page tables on invalidation Alejandro Jimenez
2025-05-02 2:15 ` [PATCH v2 09/20] amd_iommu: Add basic structure to support IOMMU notifier updates Alejandro Jimenez
2025-05-12 6:52 ` Sairaj Kodilkar
2025-06-23 10:53 ` Sairaj Kodilkar
2025-05-02 2:15 ` [PATCH v2 10/20] amd_iommu: Sync shadow page tables on page invalidation Alejandro Jimenez
2025-05-02 2:15 ` [PATCH v2 11/20] amd_iommu: Use iova_tree records to determine large page size on UNMAP Alejandro Jimenez
2025-06-11 8:29 ` Sairaj Kodilkar
2025-06-13 21:50 ` Alejandro Jimenez
2025-05-02 2:15 ` [PATCH v2 12/20] amd_iommu: Unmap all address spaces under the AMD IOMMU on reset Alejandro Jimenez
2025-05-02 2:15 ` [PATCH v2 13/20] amd_iommu: Add replay callback Alejandro Jimenez
2025-05-02 2:15 ` [PATCH v2 14/20] amd_iommu: Invalidate address translations on INVALIDATE_IOMMU_ALL Alejandro Jimenez
2025-05-02 2:16 ` [PATCH v2 15/20] amd_iommu: Toggle memory regions based on address translation mode Alejandro Jimenez
2025-05-12 6:52 ` Sairaj Kodilkar
2025-05-02 2:16 ` [PATCH v2 16/20] amd_iommu: Set all address spaces to default translation mode on reset Alejandro Jimenez
2025-05-29 6:16 ` Sairaj Kodilkar
2025-05-30 21:30 ` Alejandro Jimenez [this message]
2025-06-13 8:46 ` Sairaj Kodilkar
2025-06-23 22:08 ` Alejandro Jimenez
2025-05-02 2:16 ` [PATCH v2 17/20] amd_iommu: Add dma-remap property to AMD vIOMMU device Alejandro Jimenez
2025-05-02 2:16 ` [PATCH v2 18/20] amd_iommu: Toggle address translation mode on devtab entry invalidation Alejandro Jimenez
2025-06-12 8:27 ` Ethan MILON
2025-06-12 11:23 ` Sairaj Kodilkar
2025-05-02 2:16 ` [PATCH v2 19/20] amd_iommu: Do not assume passthrough translation when DTE[TV]=0 Alejandro Jimenez
2025-05-12 7:00 ` Sairaj Kodilkar
2025-05-14 21:49 ` Alejandro Jimenez
2025-05-16 8:14 ` Sairaj Kodilkar
2025-05-02 2:16 ` [PATCH v2 20/20] amd_iommu: Refactor amdvi_page_walk() to use common code for page walk Alejandro Jimenez
2025-05-11 18:34 ` [PATCH v2 00/20] AMD vIOMMU: DMA remapping support for VFIO devices Michael S. Tsirkin
2025-05-16 8:07 ` Sairaj Kodilkar
2025-05-21 2:35 ` Alejandro Jimenez
2025-05-21 6:21 ` Sairaj Kodilkar
2025-05-30 11:41 ` Michael S. Tsirkin
2025-05-30 14:39 ` Alejandro Jimenez
2025-06-02 4:49 ` Sairaj Kodilkar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=18ca629c-0ac5-4a0f-a88f-92a3afa328ab@oracle.com \
--to=alejandro.j.jimenez@oracle.com \
--cc=Wei.Huang2@amd.com \
--cc=alex.williamson@redhat.com \
--cc=boris.ostrovsky@oracle.com \
--cc=clement.mathieu--drif@eviden.com \
--cc=david@redhat.com \
--cc=eduardo@habkost.net \
--cc=ethan.milon@eviden.com \
--cc=joao.m.martins@oracle.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=santosh.shukla@amd.com \
--cc=sarunkod@amd.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=vasant.hegde@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).