From: CLEMENT MATHIEU--DRIF <clement.mathieu--drif@eviden.com>
To: "Duan, Zhenzhong" <zhenzhong.duan@intel.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: "jasowang@redhat.com" <jasowang@redhat.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
"Liu, Yi L" <yi.l.liu@intel.com>,
"joao.m.martins@oracle.com" <joao.m.martins@oracle.com>,
"peterx@redhat.com" <peterx@redhat.com>
Subject: Re: [PATCH ats_vtd v2 20/25] intel_iommu: fill the PASID field when creating an instance of IOMMUTLBEntry
Date: Tue, 21 May 2024 05:09:40 +0000 [thread overview]
Message-ID: <b29561fa-70e8-48c6-ae8f-9cc43bc19a4d@eviden.com> (raw)
In-Reply-To: <SJ0PR11MB674405DBEDD710A2B38E0E1192EA2@SJ0PR11MB6744.namprd11.prod.outlook.com>
On 21/05/2024 05:11, Duan, Zhenzhong wrote:
> Caution: External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe.
>
>
>> -----Original Message-----
>> From: CLEMENT MATHIEU--DRIF <clement.mathieu--drif@eviden.com>
>> Subject: Re: [PATCH ats_vtd v2 20/25] intel_iommu: fill the PASID field when
>> creating an instance of IOMMUTLBEntry
>>
>>
>> On 17/05/2024 12:40, Duan, Zhenzhong wrote:
>>> Caution: External email. Do not open attachments or click links, unless this
>> email comes from a known sender and you know the content is safe.
>>>
>>>> -----Original Message-----
>>>> From: CLEMENT MATHIEU--DRIF <clement.mathieu--drif@eviden.com>
>>>> Subject: [PATCH ats_vtd v2 20/25] intel_iommu: fill the PASID field when
>>>> creating an instance of IOMMUTLBEntry
>>>>
>>>> Signed-off-by: Clément Mathieu--Drif <clement.mathieu--
>> drif@eviden.com>
>>>> ---
>>>> hw/i386/intel_iommu.c | 7 +++++++
>>>> 1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
>>>> index 53f17d66c0..c4ebd4569e 100644
>>>> --- a/hw/i386/intel_iommu.c
>>>> +++ b/hw/i386/intel_iommu.c
>>>> @@ -2299,6 +2299,7 @@ out:
>>>> entry->translated_addr = vtd_get_slpte_addr(pte, s->aw_bits) &
>>>> page_mask;
>>>> entry->addr_mask = ~page_mask;
>>>> entry->perm = access_flags;
>>>> + entry->pasid = pasid;
>>> For PCI_NO_PASID, do we want to assign PCI_NO_PASID or rid2pasid?
>> we have the following statement a few lines above :
>> if (rid2pasid) {
>> pasid = VTD_CE_GET_RID2PASID(&ce);
>> }
>>
>> so we store rid2pasid if the feature is enabled.
>>
>> But maybe we should store PCI_NO_PASID because the rest of the world is
>> not supposed to be aware of what we are doing with rid2pasid.
>>
>> Does it look good to you?
> Yes, that make sense.
ok, will do
>
>>> Thanks
>>> Zhenzhong
>>>
>>>> return true;
>>>>
>>>> error:
>>>> @@ -2307,6 +2308,7 @@ error:
>>>> entry->translated_addr = 0;
>>>> entry->addr_mask = 0;
>>>> entry->perm = IOMMU_NONE;
>>>> + entry->pasid = PCI_NO_PASID;
>>>> return false;
>>>> }
>>>>
>>>> @@ -3497,6 +3499,7 @@ static void
>>>> vtd_piotlb_pasid_invalidate_notify(IntelIOMMUState *s,
>>>> event.entry.target_as = &address_space_memory;
>>>> event.entry.iova = notifier->start;
>>>> event.entry.perm = IOMMU_NONE;
>>>> + event.entry.pasid = pasid;
>>>> event.entry.addr_mask = notifier->end - notifier->start;
>>>> event.entry.translated_addr = 0;
>>>>
>>>> @@ -3678,6 +3681,7 @@ static void
>>>> vtd_piotlb_page_invalidate(IntelIOMMUState *s, uint16_t domain_id,
>>>> event.entry.target_as = &address_space_memory;
>>>> event.entry.iova = addr;
>>>> event.entry.perm = IOMMU_NONE;
>>>> + event.entry.pasid = pasid;
>>>> event.entry.addr_mask = size - 1;
>>>> event.entry.translated_addr = 0;
>>>>
>>>> @@ -4335,6 +4339,7 @@ static void
>>>> do_invalidate_device_tlb(VTDAddressSpace *vtd_dev_as,
>>>> event.entry.iova = addr;
>>>> event.entry.perm = IOMMU_NONE;
>>>> event.entry.translated_addr = 0;
>>>> + event.entry.pasid = vtd_dev_as->pasid;
>>>> memory_region_notify_iommu(&vtd_dev_as->iommu, 0, event);
>>>> }
>>>>
>>>> @@ -4911,6 +4916,7 @@ static IOMMUTLBEntry
>>>> vtd_iommu_translate(IOMMUMemoryRegion *iommu, hwaddr addr,
>>>> IOMMUTLBEntry iotlb = {
>>>> /* We'll fill in the rest later. */
>>>> .target_as = &address_space_memory,
>>>> + .pasid = vtd_as->pasid,
>>>> };
>>>> bool success;
>>>>
>>>> @@ -4923,6 +4929,7 @@ static IOMMUTLBEntry
>>>> vtd_iommu_translate(IOMMUMemoryRegion *iommu, hwaddr addr,
>>>> iotlb.translated_addr = addr & VTD_PAGE_MASK_4K;
>>>> iotlb.addr_mask = ~VTD_PAGE_MASK_4K;
>>>> iotlb.perm = IOMMU_RW;
>>>> + iotlb.pasid = PCI_NO_PASID;
>>>> success = true;
>>>> }
>>>>
>>>> --
>>>> 2.44.0
next prev parent reply other threads:[~2024-05-21 5:10 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-15 7:14 [PATCH ats_vtd v2 00/25] ATS support for VT-d CLEMENT MATHIEU--DRIF
2024-05-15 7:14 ` [PATCH ats_vtd v2 01/25] intel_iommu: fix FRCD construction macro CLEMENT MATHIEU--DRIF
2024-05-15 7:14 ` [PATCH ats_vtd v2 03/25] intel_iommu: check if the input address is canonical CLEMENT MATHIEU--DRIF
2024-05-15 7:14 ` [PATCH ats_vtd v2 02/25] intel_iommu: make types match CLEMENT MATHIEU--DRIF
2024-05-15 7:14 ` [PATCH ats_vtd v2 06/25] intel_iommu: extract device IOTLB invalidation logic CLEMENT MATHIEU--DRIF
2024-05-15 7:14 ` [PATCH ats_vtd v2 04/25] intel_iommu: set accessed and dirty bits during first stage translation CLEMENT MATHIEU--DRIF
2024-05-15 7:14 ` [PATCH ats_vtd v2 05/25] intel_iommu: return page walk level even when the translation fails CLEMENT MATHIEU--DRIF
2024-05-15 7:14 ` [PATCH ats_vtd v2 07/25] intel_iommu: do not consider wait_desc as an invalid descriptor CLEMENT MATHIEU--DRIF
2024-05-15 7:14 ` [PATCH ats_vtd v2 12/25] intel_iommu: add an internal API to find an address space with PASID CLEMENT MATHIEU--DRIF
2024-05-15 7:14 ` [PATCH ats_vtd v2 11/25] intel_iommu: declare supported PASID size CLEMENT MATHIEU--DRIF
2024-05-15 7:14 ` [PATCH ats_vtd v2 08/25] memory: add permissions in IOMMUAccessFlags CLEMENT MATHIEU--DRIF
2024-05-15 7:14 ` [PATCH ats_vtd v2 10/25] pcie: helper functions to check if PASID and ATS are enabled CLEMENT MATHIEU--DRIF
2024-05-15 7:14 ` [PATCH ats_vtd v2 09/25] pcie: add helper to declare PASID capability for a pcie device CLEMENT MATHIEU--DRIF
2024-05-15 7:14 ` [PATCH ats_vtd v2 14/25] pci: cache the bus mastering status in the device CLEMENT MATHIEU--DRIF
2024-05-15 7:14 ` [PATCH ats_vtd v2 13/25] intel_iommu: add support for PASID-based device IOTLB invalidation CLEMENT MATHIEU--DRIF
2024-05-15 7:14 ` [PATCH ats_vtd v2 16/25] pci: add a pci-level initialization function for iommu notifiers CLEMENT MATHIEU--DRIF
2024-05-15 7:14 ` [PATCH ats_vtd v2 15/25] pci: add IOMMU operations to get address spaces and memory regions with PASID CLEMENT MATHIEU--DRIF
2024-05-15 7:14 ` [PATCH ats_vtd v2 19/25] memory: Allow to store the PASID in IOMMUTLBEntry CLEMENT MATHIEU--DRIF
2024-05-15 7:14 ` [PATCH ats_vtd v2 20/25] intel_iommu: fill the PASID field when creating an instance of IOMMUTLBEntry CLEMENT MATHIEU--DRIF
2024-05-17 10:40 ` Duan, Zhenzhong
2024-05-17 11:11 ` CLEMENT MATHIEU--DRIF
2024-05-21 3:11 ` Duan, Zhenzhong
2024-05-21 5:09 ` CLEMENT MATHIEU--DRIF [this message]
2024-05-15 7:14 ` [PATCH ats_vtd v2 18/25] intel_iommu: implement the get_memory_region_pasid iommu operation CLEMENT MATHIEU--DRIF
2024-05-15 7:14 ` [PATCH ats_vtd v2 17/25] intel_iommu: implement the get_address_space_pasid " CLEMENT MATHIEU--DRIF
2024-05-15 7:14 ` [PATCH ats_vtd v2 21/25] atc: generic ATC that can be used by PCIe devices that support SVM CLEMENT MATHIEU--DRIF
2024-05-17 10:44 ` Duan, Zhenzhong
2024-05-17 11:12 ` CLEMENT MATHIEU--DRIF
2024-05-15 7:14 ` [PATCH ats_vtd v2 22/25] memory: add an API for ATS support CLEMENT MATHIEU--DRIF
2024-05-15 7:14 ` [PATCH ats_vtd v2 23/25] pci: add a pci-level API for ATS CLEMENT MATHIEU--DRIF
2024-05-15 7:14 ` [PATCH ats_vtd v2 24/25] intel_iommu: set the address mask even when a translation fails CLEMENT MATHIEU--DRIF
2024-05-15 7:14 ` [PATCH ats_vtd v2 25/25] intel_iommu: add support for ATS CLEMENT MATHIEU--DRIF
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=b29561fa-70e8-48c6-ae8f-9cc43bc19a4d@eviden.com \
--to=clement.mathieu--drif@eviden.com \
--cc=jasowang@redhat.com \
--cc=joao.m.martins@oracle.com \
--cc=kevin.tian@intel.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=yi.l.liu@intel.com \
--cc=zhenzhong.duan@intel.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).