We use to warn on wrong rid2pasid entry. But this error could be
triggered by the guest and could happens during initialization. So
let's don't warn in this case.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
hw/i386/intel_iommu.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index 874d01c162..90964b201c 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -1554,8 +1554,10 @@ static bool vtd_dev_pt_enabled(IntelIOMMUState *s, VTDContextEntry *ce)
if (s->root_scalable) {
ret = vtd_ce_get_rid2pasid_entry(s, ce, &pe);
if (ret) {
- error_report_once("%s: vtd_ce_get_rid2pasid_entry error: %"PRId32,
- __func__, ret);
+ /*
+ * This error is guest triggerable. We should assumt PT
+ * not enabled for safety.
+ */
return false;
}
return (VTD_PE_GET_TYPE(&pe) == VTD_SM_PASID_ENTRY_PT);
--
2.25.1> From: Jason Wang
> Sent: Monday, March 21, 2022 1:54 PM
>
> We use to warn on wrong rid2pasid entry. But this error could be
> triggered by the guest and could happens during initialization. So
> let's don't warn in this case.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> hw/i386/intel_iommu.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> index 874d01c162..90964b201c 100644
> --- a/hw/i386/intel_iommu.c
> +++ b/hw/i386/intel_iommu.c
> @@ -1554,8 +1554,10 @@ static bool vtd_dev_pt_enabled(IntelIOMMUState
> *s, VTDContextEntry *ce)
> if (s->root_scalable) {
> ret = vtd_ce_get_rid2pasid_entry(s, ce, &pe);
> if (ret) {
> - error_report_once("%s: vtd_ce_get_rid2pasid_entry error: %"PRId32,
> - __func__, ret);
> + /*
> + * This error is guest triggerable. We should assumt PT
> + * not enabled for safety.
> + */
suppose a VT-d fault should be queued in this case besides returning false:
SPD.1: A hardware attempt to access the scalable-mode PASID-directory
entry referenced through the PASIDDIRPTR field in scalable-mode
context-entry resulted in an error
SPT.1: A hardware attempt to access a scalable-mode PASID-table entry
referenced through the SMPTBLPTR field in a scalable-mode PASID-directory
entry resulted in an error.
Currently the implementation of vtd_ce_get_rid2pasid_entry() is also
problematic. According to VT-d spec, RID2PASID field is effective only
when ecap.rps is true otherwise PASID#0 is used for RID2PASID. I didn't
see ecap.rps is set, neither is it checked in that function. It works possibly
just because Linux currently programs 0 to RID2PASID...
> return false;
> }
> return (VTD_PE_GET_TYPE(&pe) == VTD_SM_PASID_ENTRY_PT);
> --
> 2.25.1
>
On Thu, Mar 24, 2022 at 4:21 PM Tian, Kevin <kevin.tian@intel.com> wrote:
>
> > From: Jason Wang
> > Sent: Monday, March 21, 2022 1:54 PM
> >
> > We use to warn on wrong rid2pasid entry. But this error could be
> > triggered by the guest and could happens during initialization. So
> > let's don't warn in this case.
> >
> > Signed-off-by: Jason Wang <jasowang@redhat.com>
> > ---
> > hw/i386/intel_iommu.c | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> > index 874d01c162..90964b201c 100644
> > --- a/hw/i386/intel_iommu.c
> > +++ b/hw/i386/intel_iommu.c
> > @@ -1554,8 +1554,10 @@ static bool vtd_dev_pt_enabled(IntelIOMMUState
> > *s, VTDContextEntry *ce)
> > if (s->root_scalable) {
> > ret = vtd_ce_get_rid2pasid_entry(s, ce, &pe);
> > if (ret) {
> > - error_report_once("%s: vtd_ce_get_rid2pasid_entry error: %"PRId32,
> > - __func__, ret);
> > + /*
> > + * This error is guest triggerable. We should assumt PT
> > + * not enabled for safety.
> > + */
>
> suppose a VT-d fault should be queued in this case besides returning false:
>
> SPD.1: A hardware attempt to access the scalable-mode PASID-directory
> entry referenced through the PASIDDIRPTR field in scalable-mode
> context-entry resulted in an error
>
> SPT.1: A hardware attempt to access a scalable-mode PASID-table entry
> referenced through the SMPTBLPTR field in a scalable-mode PASID-directory
> entry resulted in an error.
Probably, but this issue is not introduced in this patch. We can fix
it on top if necessary.
>
> Currently the implementation of vtd_ce_get_rid2pasid_entry() is also
> problematic. According to VT-d spec, RID2PASID field is effective only
> when ecap.rps is true otherwise PASID#0 is used for RID2PASID. I didn't
> see ecap.rps is set, neither is it checked in that function. It works possibly
> just because Linux currently programs 0 to RID2PASID...
This seems to be another issue since the introduction of scalable mode.
Thanks
>
> > return false;
> > }
> > return (VTD_PE_GET_TYPE(&pe) == VTD_SM_PASID_ENTRY_PT);
> > --
> > 2.25.1
> >
>
On 2022/3/28 10:27, Jason Wang wrote:
> On Thu, Mar 24, 2022 at 4:21 PM Tian, Kevin <kevin.tian@intel.com> wrote:
>>
>>> From: Jason Wang
>>> Sent: Monday, March 21, 2022 1:54 PM
>>>
>>> We use to warn on wrong rid2pasid entry. But this error could be
>>> triggered by the guest and could happens during initialization. So
>>> let's don't warn in this case.
>>>
>>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>>> ---
>>> hw/i386/intel_iommu.c | 6 ++++--
>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
>>> index 874d01c162..90964b201c 100644
>>> --- a/hw/i386/intel_iommu.c
>>> +++ b/hw/i386/intel_iommu.c
>>> @@ -1554,8 +1554,10 @@ static bool vtd_dev_pt_enabled(IntelIOMMUState
>>> *s, VTDContextEntry *ce)
>>> if (s->root_scalable) {
>>> ret = vtd_ce_get_rid2pasid_entry(s, ce, &pe);
>>> if (ret) {
>>> - error_report_once("%s: vtd_ce_get_rid2pasid_entry error: %"PRId32,
>>> - __func__, ret);
>>> + /*
>>> + * This error is guest triggerable. We should assumt PT
>>> + * not enabled for safety.
>>> + */
>>
>> suppose a VT-d fault should be queued in this case besides returning false:
>>
>> SPD.1: A hardware attempt to access the scalable-mode PASID-directory
>> entry referenced through the PASIDDIRPTR field in scalable-mode
>> context-entry resulted in an error
>>
>> SPT.1: A hardware attempt to access a scalable-mode PASID-table entry
>> referenced through the SMPTBLPTR field in a scalable-mode PASID-directory
>> entry resulted in an error.
>
> Probably, but this issue is not introduced in this patch. We can fix
> it on top if necessary.
agreed.
>>
>> Currently the implementation of vtd_ce_get_rid2pasid_entry() is also
>> problematic. According to VT-d spec, RID2PASID field is effective only
>> when ecap.rps is true otherwise PASID#0 is used for RID2PASID. I didn't
>> see ecap.rps is set, neither is it checked in that function. It works possibly
>> just because Linux currently programs 0 to RID2PASID...
>
> This seems to be another issue since the introduction of scalable mode.
yes. this is not introduced in this series. The current scalable mode
vIOMMU support was following 3.0 spec, while RPS is added in 3.1. Needs
to be fixed.
> Thanks
>
>>
>>> return false;
>>> }
>>> return (VTD_PE_GET_TYPE(&pe) == VTD_SM_PASID_ENTRY_PT);
>>> --
>>> 2.25.1
>>>
>>
>
--
Regards,
Yi Liu
在 2022/3/28 下午4:53, Yi Liu 写道:
>
>
> On 2022/3/28 10:27, Jason Wang wrote:
>> On Thu, Mar 24, 2022 at 4:21 PM Tian, Kevin <kevin.tian@intel.com>
>> wrote:
>>>
>>>> From: Jason Wang
>>>> Sent: Monday, March 21, 2022 1:54 PM
>>>>
>>>> We use to warn on wrong rid2pasid entry. But this error could be
>>>> triggered by the guest and could happens during initialization. So
>>>> let's don't warn in this case.
>>>>
>>>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>>>> ---
>>>> hw/i386/intel_iommu.c | 6 ++++--
>>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
>>>> index 874d01c162..90964b201c 100644
>>>> --- a/hw/i386/intel_iommu.c
>>>> +++ b/hw/i386/intel_iommu.c
>>>> @@ -1554,8 +1554,10 @@ static bool vtd_dev_pt_enabled(IntelIOMMUState
>>>> *s, VTDContextEntry *ce)
>>>> if (s->root_scalable) {
>>>> ret = vtd_ce_get_rid2pasid_entry(s, ce, &pe);
>>>> if (ret) {
>>>> - error_report_once("%s: vtd_ce_get_rid2pasid_entry
>>>> error: %"PRId32,
>>>> - __func__, ret);
>>>> + /*
>>>> + * This error is guest triggerable. We should assumt PT
>>>> + * not enabled for safety.
>>>> + */
>>>
>>> suppose a VT-d fault should be queued in this case besides returning
>>> false:
>>>
>>> SPD.1: A hardware attempt to access the scalable-mode PASID-directory
>>> entry referenced through the PASIDDIRPTR field in scalable-mode
>>> context-entry resulted in an error
>>>
>>> SPT.1: A hardware attempt to access a scalable-mode PASID-table entry
>>> referenced through the SMPTBLPTR field in a scalable-mode
>>> PASID-directory
>>> entry resulted in an error.
>>
>> Probably, but this issue is not introduced in this patch. We can fix
>> it on top if necessary.
>
> agreed.
>
>>>
>>> Currently the implementation of vtd_ce_get_rid2pasid_entry() is also
>>> problematic. According to VT-d spec, RID2PASID field is effective only
>>> when ecap.rps is true otherwise PASID#0 is used for RID2PASID. I didn't
>>> see ecap.rps is set, neither is it checked in that function. It
>>> works possibly
>>> just because Linux currently programs 0 to RID2PASID...
>>
>> This seems to be another issue since the introduction of scalable mode.
>
> yes. this is not introduced in this series. The current scalable mode
> vIOMMU support was following 3.0 spec, while RPS is added in 3.1. Needs
> to be fixed.
Interesting, so this is more complicated when dealing with migration
compatibility. So what I suggest is probably something like:
-device intel-iommu,version=$version
Then we can maintain migration compatibility correctly. For 3.0 we can
go without RPS and 3.1 and above we need to implement RPS.
Since most of the advanced features has not been implemented, we may
probably start just from 3.4 (assuming it's the latest version). And all
of the following effort should be done for 3.4 in order to productize it.
Thanks
>
>> Thanks
>>
>>>
>>>> return false;
>>>> }
>>>> return (VTD_PE_GET_TYPE(&pe) == VTD_SM_PASID_ENTRY_PT);
>>>> --
>>>> 2.25.1
>>>>
>>>
>>
>
On Tue, Mar 29, 2022 at 12:52:08PM +0800, Jason Wang wrote:
>
> 在 2022/3/28 下午4:53, Yi Liu 写道:
> >
> >
> > On 2022/3/28 10:27, Jason Wang wrote:
> > > On Thu, Mar 24, 2022 at 4:21 PM Tian, Kevin <kevin.tian@intel.com>
> > > wrote:
> > > >
> > > > > From: Jason Wang
> > > > > Sent: Monday, March 21, 2022 1:54 PM
> > > > >
> > > > > We use to warn on wrong rid2pasid entry. But this error could be
> > > > > triggered by the guest and could happens during initialization. So
> > > > > let's don't warn in this case.
> > > > >
> > > > > Signed-off-by: Jason Wang <jasowang@redhat.com>
> > > > > ---
> > > > > hw/i386/intel_iommu.c | 6 ++++--
> > > > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> > > > > index 874d01c162..90964b201c 100644
> > > > > --- a/hw/i386/intel_iommu.c
> > > > > +++ b/hw/i386/intel_iommu.c
> > > > > @@ -1554,8 +1554,10 @@ static bool vtd_dev_pt_enabled(IntelIOMMUState
> > > > > *s, VTDContextEntry *ce)
> > > > > if (s->root_scalable) {
> > > > > ret = vtd_ce_get_rid2pasid_entry(s, ce, &pe);
> > > > > if (ret) {
> > > > > - error_report_once("%s:
> > > > > vtd_ce_get_rid2pasid_entry error: %"PRId32,
> > > > > - __func__, ret);
> > > > > + /*
> > > > > + * This error is guest triggerable. We should assumt PT
> > > > > + * not enabled for safety.
> > > > > + */
> > > >
> > > > suppose a VT-d fault should be queued in this case besides
> > > > returning false:
> > > >
> > > > SPD.1: A hardware attempt to access the scalable-mode PASID-directory
> > > > entry referenced through the PASIDDIRPTR field in scalable-mode
> > > > context-entry resulted in an error
> > > >
> > > > SPT.1: A hardware attempt to access a scalable-mode PASID-table entry
> > > > referenced through the SMPTBLPTR field in a scalable-mode
> > > > PASID-directory
> > > > entry resulted in an error.
> > >
> > > Probably, but this issue is not introduced in this patch. We can fix
> > > it on top if necessary.
> >
> > agreed.
> >
> > > >
> > > > Currently the implementation of vtd_ce_get_rid2pasid_entry() is also
> > > > problematic. According to VT-d spec, RID2PASID field is effective only
> > > > when ecap.rps is true otherwise PASID#0 is used for RID2PASID. I didn't
> > > > see ecap.rps is set, neither is it checked in that function. It
> > > > works possibly
> > > > just because Linux currently programs 0 to RID2PASID...
> > >
> > > This seems to be another issue since the introduction of scalable mode.
> >
> > yes. this is not introduced in this series. The current scalable mode
> > vIOMMU support was following 3.0 spec, while RPS is added in 3.1. Needs
> > to be fixed.
>
>
> Interesting, so this is more complicated when dealing with migration
> compatibility. So what I suggest is probably something like:
>
> -device intel-iommu,version=$version
>
> Then we can maintain migration compatibility correctly. For 3.0 we can go
> without RPS and 3.1 and above we need to implement RPS.
>
> Since most of the advanced features has not been implemented, we may
> probably start just from 3.4 (assuming it's the latest version). And all of
> the following effort should be done for 3.4 in order to productize it.
>
> Thanks
I would advise calling it x-version. And declare it unstable for now. I
think that we don't at this point want to support users tweaking version
to arbitrary values.
>
> >
> > > Thanks
> > >
> > > >
> > > > > return false;
> > > > > }
> > > > > return (VTD_PE_GET_TYPE(&pe) == VTD_SM_PASID_ENTRY_PT);
> > > > > --
> > > > > 2.25.1
> > > > >
> > > >
> > >
> >
> From: Jason Wang <jasowang@redhat.com> > Sent: Tuesday, March 29, 2022 12:52 PM > > > >>> > >>> Currently the implementation of vtd_ce_get_rid2pasid_entry() is also > >>> problematic. According to VT-d spec, RID2PASID field is effective only > >>> when ecap.rps is true otherwise PASID#0 is used for RID2PASID. I didn't > >>> see ecap.rps is set, neither is it checked in that function. It > >>> works possibly > >>> just because Linux currently programs 0 to RID2PASID... > >> > >> This seems to be another issue since the introduction of scalable mode. > > > > yes. this is not introduced in this series. The current scalable mode > > vIOMMU support was following 3.0 spec, while RPS is added in 3.1. Needs > > to be fixed. > > > Interesting, so this is more complicated when dealing with migration > compatibility. So what I suggest is probably something like: > > -device intel-iommu,version=$version > > Then we can maintain migration compatibility correctly. For 3.0 we can > go without RPS and 3.1 and above we need to implement RPS. This is sensible. Probably a new version number is created only when it breaks compatibility with an old version, i.e. not necessarily to follow every release from VT-d spec. In this case we definitely need one from 3.0 to 3.1+ given RID2PASID working on a 3.0 implementation will trigger a reserved fault due to RPS not set on a 3.1 implementation. > > Since most of the advanced features has not been implemented, we may > probably start just from 3.4 (assuming it's the latest version). And all > of the following effort should be done for 3.4 in order to productize it. > Agree. btw in your understanding is intel-iommu in a production quality now? If not, do we want to apply this version scheme only when it reaches the production quality or also in the experimental phase? Thanks Kevin
On Wed, Mar 30, 2022 at 4:16 PM Tian, Kevin <kevin.tian@intel.com> wrote: > > > From: Jason Wang <jasowang@redhat.com> > > Sent: Tuesday, March 29, 2022 12:52 PM > > > > > >>> > > >>> Currently the implementation of vtd_ce_get_rid2pasid_entry() is also > > >>> problematic. According to VT-d spec, RID2PASID field is effective only > > >>> when ecap.rps is true otherwise PASID#0 is used for RID2PASID. I didn't > > >>> see ecap.rps is set, neither is it checked in that function. It > > >>> works possibly > > >>> just because Linux currently programs 0 to RID2PASID... > > >> > > >> This seems to be another issue since the introduction of scalable mode. > > > > > > yes. this is not introduced in this series. The current scalable mode > > > vIOMMU support was following 3.0 spec, while RPS is added in 3.1. Needs > > > to be fixed. > > > > > > Interesting, so this is more complicated when dealing with migration > > compatibility. So what I suggest is probably something like: > > > > -device intel-iommu,version=$version > > > > Then we can maintain migration compatibility correctly. For 3.0 we can > > go without RPS and 3.1 and above we need to implement RPS. > > This is sensible. Probably a new version number is created only when > it breaks compatibility with an old version, i.e. not necessarily to follow > every release from VT-d spec. In this case we definitely need one from > 3.0 to 3.1+ given RID2PASID working on a 3.0 implementation will > trigger a reserved fault due to RPS not set on a 3.1 implementation. 3.0 should be fine, but I need to check whether there's another difference for PASID mode. It would be helpful if there's a chapter in the spec to describe the difference of behaviours. > > > > > Since most of the advanced features has not been implemented, we may > > probably start just from 3.4 (assuming it's the latest version). And all > > of the following effort should be done for 3.4 in order to productize it. > > > > Agree. btw in your understanding is intel-iommu in a production quality > now? Red Hat supports vIOMMU for the guest DPDK path now. For scalable-mode we need to see some use cases then we can evaluate. virtio SVA could be a possible use case, but it requires more work e.g PRS queue. > If not, do we want to apply this version scheme only when it > reaches the production quality or also in the experimental phase? Yes. E.g if we think scalable mode is mature, we can enable 3.0. Thanks > > Thanks > Kevin
> From: Jason Wang <jasowang@redhat.com> > Sent: Wednesday, March 30, 2022 4:37 PM > On Wed, Mar 30, 2022 at 4:16 PM Tian, Kevin <kevin.tian@intel.com> wrote: > > > > > From: Jason Wang <jasowang@redhat.com> > > > Sent: Tuesday, March 29, 2022 12:52 PM > > > > > > > >>> > > > >>> Currently the implementation of vtd_ce_get_rid2pasid_entry() is also > > > >>> problematic. According to VT-d spec, RID2PASID field is effective only > > > >>> when ecap.rps is true otherwise PASID#0 is used for RID2PASID. I > didn't > > > >>> see ecap.rps is set, neither is it checked in that function. It > > > >>> works possibly > > > >>> just because Linux currently programs 0 to RID2PASID... > > > >> > > > >> This seems to be another issue since the introduction of scalable mode. > > > > > > > > yes. this is not introduced in this series. The current scalable mode > > > > vIOMMU support was following 3.0 spec, while RPS is added in 3.1. > Needs > > > > to be fixed. > > > > > > > > > Interesting, so this is more complicated when dealing with migration > > > compatibility. So what I suggest is probably something like: > > > > > > -device intel-iommu,version=$version > > > > > > Then we can maintain migration compatibility correctly. For 3.0 we can > > > go without RPS and 3.1 and above we need to implement RPS. > > > > This is sensible. Probably a new version number is created only when > > it breaks compatibility with an old version, i.e. not necessarily to follow > > every release from VT-d spec. In this case we definitely need one from > > 3.0 to 3.1+ given RID2PASID working on a 3.0 implementation will > > trigger a reserved fault due to RPS not set on a 3.1 implementation. > > 3.0 should be fine, but I need to check whether there's another > difference for PASID mode. > > It would be helpful if there's a chapter in the spec to describe the > difference of behaviours. There is a section called 'Revision History' in the start of the VT-d spec. It talks about changes in each revision, e.g.: -- June 2019, 3.1: Added support for RID-PASID capability (RPS field in ECAP_REG). -- > > > > > > > > > Since most of the advanced features has not been implemented, we may > > > probably start just from 3.4 (assuming it's the latest version). And all > > > of the following effort should be done for 3.4 in order to productize it. > > > > > > > Agree. btw in your understanding is intel-iommu in a production quality > > now? > > Red Hat supports vIOMMU for the guest DPDK path now. > > For scalable-mode we need to see some use cases then we can evaluate. > virtio SVA could be a possible use case, but it requires more work e.g > PRS queue. Yes it's not ready for full evaluation yet. The current state before your change is exactly feature-on-par with the legacy mode, except using scalable format in certain structures. That alone is not worthy of a formal evaluation. > > > If not, do we want to apply this version scheme only when it > > reaches the production quality or also in the experimental phase? > > Yes. E.g if we think scalable mode is mature, we can enable 3.0. > Nice to know. Thanks Kevin
On Sat, Apr 2, 2022 at 3:34 PM Tian, Kevin <kevin.tian@intel.com> wrote: > > > From: Jason Wang <jasowang@redhat.com> > > Sent: Wednesday, March 30, 2022 4:37 PM > > On Wed, Mar 30, 2022 at 4:16 PM Tian, Kevin <kevin.tian@intel.com> wrote: > > > > > > > From: Jason Wang <jasowang@redhat.com> > > > > Sent: Tuesday, March 29, 2022 12:52 PM > > > > > > > > > >>> > > > > >>> Currently the implementation of vtd_ce_get_rid2pasid_entry() is also > > > > >>> problematic. According to VT-d spec, RID2PASID field is effective only > > > > >>> when ecap.rps is true otherwise PASID#0 is used for RID2PASID. I > > didn't > > > > >>> see ecap.rps is set, neither is it checked in that function. It > > > > >>> works possibly > > > > >>> just because Linux currently programs 0 to RID2PASID... > > > > >> > > > > >> This seems to be another issue since the introduction of scalable mode. > > > > > > > > > > yes. this is not introduced in this series. The current scalable mode > > > > > vIOMMU support was following 3.0 spec, while RPS is added in 3.1. > > Needs > > > > > to be fixed. > > > > > > > > > > > > Interesting, so this is more complicated when dealing with migration > > > > compatibility. So what I suggest is probably something like: > > > > > > > > -device intel-iommu,version=$version > > > > > > > > Then we can maintain migration compatibility correctly. For 3.0 we can > > > > go without RPS and 3.1 and above we need to implement RPS. > > > > > > This is sensible. Probably a new version number is created only when > > > it breaks compatibility with an old version, i.e. not necessarily to follow > > > every release from VT-d spec. In this case we definitely need one from > > > 3.0 to 3.1+ given RID2PASID working on a 3.0 implementation will > > > trigger a reserved fault due to RPS not set on a 3.1 implementation. > > > > 3.0 should be fine, but I need to check whether there's another > > difference for PASID mode. > > > > It would be helpful if there's a chapter in the spec to describe the > > difference of behaviours. > > There is a section called 'Revision History' in the start of the VT-d spec. > It talks about changes in each revision, e.g.: > -- > June 2019, 3.1: > > Added support for RID-PASID capability (RPS field in ECAP_REG). Good to know that, does it mean, except for this revision history, all the other semantics keep backward compatibility across the version? > -- > > > > > > > > > > > > > > Since most of the advanced features has not been implemented, we may > > > > probably start just from 3.4 (assuming it's the latest version). And all > > > > of the following effort should be done for 3.4 in order to productize it. > > > > > > > > > > Agree. btw in your understanding is intel-iommu in a production quality > > > now? > > > > Red Hat supports vIOMMU for the guest DPDK path now. > > > > For scalable-mode we need to see some use cases then we can evaluate. > > virtio SVA could be a possible use case, but it requires more work e.g > > PRS queue. > > Yes it's not ready for full evaluation yet. > > The current state before your change is exactly feature-on-par with the > legacy mode, except using scalable format in certain structures. That alone > is not worthy of a formal evaluation. Right. Thanks > > > > > > If not, do we want to apply this version scheme only when it > > > reaches the production quality or also in the experimental phase? > > > > Yes. E.g if we think scalable mode is mature, we can enable 3.0. > > > > Nice to know. > > Thanks > Kevin
> From: Jason Wang <jasowang@redhat.com> > Sent: Wednesday, April 6, 2022 11:33 AM > To: Tian, Kevin <kevin.tian@intel.com> > Cc: Liu, Yi L <yi.l.liu@intel.com>; mst@redhat.com; peterx@redhat.com; > yi.y.sun@linux.intel.com; qemu-devel@nongnu.org > Subject: Re: [PATCH V2 1/4] intel-iommu: don't warn guest errors when > getting rid2pasid entry > > On Sat, Apr 2, 2022 at 3:34 PM Tian, Kevin <kevin.tian@intel.com> wrote: > > > > > From: Jason Wang <jasowang@redhat.com> > > > Sent: Wednesday, March 30, 2022 4:37 PM > > > On Wed, Mar 30, 2022 at 4:16 PM Tian, Kevin <kevin.tian@intel.com> > wrote: > > > > > > > > > From: Jason Wang <jasowang@redhat.com> > > > > > Sent: Tuesday, March 29, 2022 12:52 PM > > > > > > > > > > > >>> > > > > > >>> Currently the implementation of vtd_ce_get_rid2pasid_entry() is > also > > > > > >>> problematic. According to VT-d spec, RID2PASID field is effective > only > > > > > >>> when ecap.rps is true otherwise PASID#0 is used for RID2PASID. I > > > didn't > > > > > >>> see ecap.rps is set, neither is it checked in that function. It > > > > > >>> works possibly > > > > > >>> just because Linux currently programs 0 to RID2PASID... > > > > > >> > > > > > >> This seems to be another issue since the introduction of scalable > mode. > > > > > > > > > > > > yes. this is not introduced in this series. The current scalable mode > > > > > > vIOMMU support was following 3.0 spec, while RPS is added in 3.1. > > > Needs > > > > > > to be fixed. > > > > > > > > > > > > > > > Interesting, so this is more complicated when dealing with migration > > > > > compatibility. So what I suggest is probably something like: > > > > > > > > > > -device intel-iommu,version=$version > > > > > > > > > > Then we can maintain migration compatibility correctly. For 3.0 we > can > > > > > go without RPS and 3.1 and above we need to implement RPS. > > > > > > > > This is sensible. Probably a new version number is created only when > > > > it breaks compatibility with an old version, i.e. not necessarily to follow > > > > every release from VT-d spec. In this case we definitely need one from > > > > 3.0 to 3.1+ given RID2PASID working on a 3.0 implementation will > > > > trigger a reserved fault due to RPS not set on a 3.1 implementation. > > > > > > 3.0 should be fine, but I need to check whether there's another > > > difference for PASID mode. > > > > > > It would be helpful if there's a chapter in the spec to describe the > > > difference of behaviours. > > > > There is a section called 'Revision History' in the start of the VT-d spec. > > It talks about changes in each revision, e.g.: > > -- > > June 2019, 3.1: > > > > Added support for RID-PASID capability (RPS field in ECAP_REG). > > Good to know that, does it mean, except for this revision history, all > the other semantics keep backward compatibility across the version? Yes and if you find anything not clarified properly I can help forward to the spec owner. Thanks Kevin
© 2016 - 2026 Red Hat, Inc.