| Message ID | 1484917736-32056-17-git-send-email-peterx@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 2017年01月20日 21:08, Peter Xu wrote: > Before this one we only invalidate context cache when we receive context > entry invalidations. However it's possible that the invalidation also > contains a domain switch (only if cache-mode is enabled for vIOMMU). In > that case we need to notify all the registered components about the new > mapping. > > Signed-off-by: Peter Xu <peterx@redhat.com> > --- > hw/i386/intel_iommu.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c > index f9c5142..4b08b4d 100644 > --- a/hw/i386/intel_iommu.c > +++ b/hw/i386/intel_iommu.c > @@ -1146,6 +1146,16 @@ static void vtd_context_device_invalidate(IntelIOMMUState *s, > trace_vtd_inv_desc_cc_device(bus_n, VTD_PCI_SLOT(devfn_it), > VTD_PCI_FUNC(devfn_it)); > vtd_as->context_cache_entry.context_cache_gen = 0; > + /* > + * So a device is moving out of (or moving into) a > + * domain, a replay() suites here to notify all the > + * IOMMU_NOTIFIER_MAP registers about this change. > + * This won't bring bad even if we have no such > + * notifier registered - the IOMMU notification > + * framework will skip MAP notifications if that > + * happened. > + */ > + memory_region_iommu_replay_all(&vtd_as->iommu); DSI and GLOBAL questions come back again or no need to care about them :) ? Thanks > } > } > }
On Mon, Jan 23, 2017 at 06:36:17PM +0800, Jason Wang wrote: > > > On 2017年01月20日 21:08, Peter Xu wrote: > >Before this one we only invalidate context cache when we receive context > >entry invalidations. However it's possible that the invalidation also > >contains a domain switch (only if cache-mode is enabled for vIOMMU). In > >that case we need to notify all the registered components about the new > >mapping. > > > >Signed-off-by: Peter Xu <peterx@redhat.com> > >--- > > hw/i386/intel_iommu.c | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > >diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c > >index f9c5142..4b08b4d 100644 > >--- a/hw/i386/intel_iommu.c > >+++ b/hw/i386/intel_iommu.c > >@@ -1146,6 +1146,16 @@ static void vtd_context_device_invalidate(IntelIOMMUState *s, > > trace_vtd_inv_desc_cc_device(bus_n, VTD_PCI_SLOT(devfn_it), > > VTD_PCI_FUNC(devfn_it)); > > vtd_as->context_cache_entry.context_cache_gen = 0; > >+ /* > >+ * So a device is moving out of (or moving into) a > >+ * domain, a replay() suites here to notify all the > >+ * IOMMU_NOTIFIER_MAP registers about this change. > >+ * This won't bring bad even if we have no such > >+ * notifier registered - the IOMMU notification > >+ * framework will skip MAP notifications if that > >+ * happened. > >+ */ > >+ memory_region_iommu_replay_all(&vtd_as->iommu); > > DSI and GLOBAL questions come back again or no need to care about them :) ? DSI/GLOBAL hanldings are in patch 20 (though it'll be squashed into 18 in my next post). Is that what you mean above? Thanks! -- peterx
On 2017年01月24日 12:52, Peter Xu wrote: > On Mon, Jan 23, 2017 at 06:36:17PM +0800, Jason Wang wrote: >> >> On 2017年01月20日 21:08, Peter Xu wrote: >>> Before this one we only invalidate context cache when we receive context >>> entry invalidations. However it's possible that the invalidation also >>> contains a domain switch (only if cache-mode is enabled for vIOMMU). In >>> that case we need to notify all the registered components about the new >>> mapping. >>> >>> Signed-off-by: Peter Xu <peterx@redhat.com> >>> --- >>> hw/i386/intel_iommu.c | 10 ++++++++++ >>> 1 file changed, 10 insertions(+) >>> >>> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c >>> index f9c5142..4b08b4d 100644 >>> --- a/hw/i386/intel_iommu.c >>> +++ b/hw/i386/intel_iommu.c >>> @@ -1146,6 +1146,16 @@ static void vtd_context_device_invalidate(IntelIOMMUState *s, >>> trace_vtd_inv_desc_cc_device(bus_n, VTD_PCI_SLOT(devfn_it), >>> VTD_PCI_FUNC(devfn_it)); >>> vtd_as->context_cache_entry.context_cache_gen = 0; >>> + /* >>> + * So a device is moving out of (or moving into) a >>> + * domain, a replay() suites here to notify all the >>> + * IOMMU_NOTIFIER_MAP registers about this change. >>> + * This won't bring bad even if we have no such >>> + * notifier registered - the IOMMU notification >>> + * framework will skip MAP notifications if that >>> + * happened. >>> + */ >>> + memory_region_iommu_replay_all(&vtd_as->iommu); >> DSI and GLOBAL questions come back again or no need to care about them :) ? > DSI/GLOBAL hanldings are in patch 20 (though it'll be squashed into 18 > in my next post). Is that what you mean above? Seems not, I mean DSI/GLOBAL for context cache invalidation instead of IOTLB :) Thanks > > Thanks! > > -- peterx >
On Wed, Jan 25, 2017 at 11:09:39AM +0800, Jason Wang wrote: > > > On 2017年01月24日 12:52, Peter Xu wrote: > >On Mon, Jan 23, 2017 at 06:36:17PM +0800, Jason Wang wrote: > >> > >>On 2017年01月20日 21:08, Peter Xu wrote: > >>>Before this one we only invalidate context cache when we receive context > >>>entry invalidations. However it's possible that the invalidation also > >>>contains a domain switch (only if cache-mode is enabled for vIOMMU). In > >>>that case we need to notify all the registered components about the new > >>>mapping. > >>> > >>>Signed-off-by: Peter Xu <peterx@redhat.com> > >>>--- > >>> hw/i386/intel_iommu.c | 10 ++++++++++ > >>> 1 file changed, 10 insertions(+) > >>> > >>>diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c > >>>index f9c5142..4b08b4d 100644 > >>>--- a/hw/i386/intel_iommu.c > >>>+++ b/hw/i386/intel_iommu.c > >>>@@ -1146,6 +1146,16 @@ static void vtd_context_device_invalidate(IntelIOMMUState *s, > >>> trace_vtd_inv_desc_cc_device(bus_n, VTD_PCI_SLOT(devfn_it), > >>> VTD_PCI_FUNC(devfn_it)); > >>> vtd_as->context_cache_entry.context_cache_gen = 0; > >>>+ /* > >>>+ * So a device is moving out of (or moving into) a > >>>+ * domain, a replay() suites here to notify all the > >>>+ * IOMMU_NOTIFIER_MAP registers about this change. > >>>+ * This won't bring bad even if we have no such > >>>+ * notifier registered - the IOMMU notification > >>>+ * framework will skip MAP notifications if that > >>>+ * happened. > >>>+ */ > >>>+ memory_region_iommu_replay_all(&vtd_as->iommu); > >>DSI and GLOBAL questions come back again or no need to care about them :) ? > >DSI/GLOBAL hanldings are in patch 20 (though it'll be squashed into 18 > >in my next post). Is that what you mean above? > > Seems not, I mean DSI/GLOBAL for context cache invalidation instead of IOTLB > :) Yes, I should possibly do the same thing for context cache global invalidations. IIUC context global invalidation should be a superset of iotlb invalidation, so maybe I'll add one more patch to call iotlb invalidation in context invalidation as well. Kevin/others, please correct me if I misunderstood the spec. Thanks, -- peterx
> From: Peter Xu [mailto:peterx@redhat.com] > Sent: Wednesday, January 25, 2017 11:46 AM > > On Wed, Jan 25, 2017 at 11:09:39AM +0800, Jason Wang wrote: > > > > > > On 2017年01月24日 12:52, Peter Xu wrote: > > >On Mon, Jan 23, 2017 at 06:36:17PM +0800, Jason Wang wrote: > > >> > > >>On 2017年01月20日 21:08, Peter Xu wrote: > > >>>Before this one we only invalidate context cache when we receive context > > >>>entry invalidations. However it's possible that the invalidation also > > >>>contains a domain switch (only if cache-mode is enabled for vIOMMU). In > > >>>that case we need to notify all the registered components about the new > > >>>mapping. > > >>> > > >>>Signed-off-by: Peter Xu <peterx@redhat.com> > > >>>--- > > >>> hw/i386/intel_iommu.c | 10 ++++++++++ > > >>> 1 file changed, 10 insertions(+) > > >>> > > >>>diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c > > >>>index f9c5142..4b08b4d 100644 > > >>>--- a/hw/i386/intel_iommu.c > > >>>+++ b/hw/i386/intel_iommu.c > > >>>@@ -1146,6 +1146,16 @@ static void > vtd_context_device_invalidate(IntelIOMMUState *s, > > >>> trace_vtd_inv_desc_cc_device(bus_n, VTD_PCI_SLOT(devfn_it), > > >>> VTD_PCI_FUNC(devfn_it)); > > >>> vtd_as->context_cache_entry.context_cache_gen = 0; > > >>>+ /* > > >>>+ * So a device is moving out of (or moving into) a > > >>>+ * domain, a replay() suites here to notify all the > > >>>+ * IOMMU_NOTIFIER_MAP registers about this change. > > >>>+ * This won't bring bad even if we have no such > > >>>+ * notifier registered - the IOMMU notification > > >>>+ * framework will skip MAP notifications if that > > >>>+ * happened. > > >>>+ */ > > >>>+ memory_region_iommu_replay_all(&vtd_as->iommu); > > >>DSI and GLOBAL questions come back again or no need to care about them :) ? > > >DSI/GLOBAL hanldings are in patch 20 (though it'll be squashed into 18 > > >in my next post). Is that what you mean above? > > > > Seems not, I mean DSI/GLOBAL for context cache invalidation instead of IOTLB > > :) > > Yes, I should possibly do the same thing for context cache global > invalidations. IIUC context global invalidation should be a superset > of iotlb invalidation, so maybe I'll add one more patch to call iotlb > invalidation in context invalidation as well. Kevin/others, please > correct me if I misunderstood the spec. Thanks, > context invalidation is not superset of iotlb invalidation. The spec just requires software to always follow a context-cache invalidation with a PASID-cache invalidation, followed by an IOTLB invalidation. Thanks Kevin
On Wed, Jan 25, 2017 at 06:37:23AM +0000, Tian, Kevin wrote: > > From: Peter Xu [mailto:peterx@redhat.com] > > Sent: Wednesday, January 25, 2017 11:46 AM > > > > On Wed, Jan 25, 2017 at 11:09:39AM +0800, Jason Wang wrote: > > > > > > > > > On 2017年01月24日 12:52, Peter Xu wrote: > > > >On Mon, Jan 23, 2017 at 06:36:17PM +0800, Jason Wang wrote: > > > >> > > > >>On 2017年01月20日 21:08, Peter Xu wrote: > > > >>>Before this one we only invalidate context cache when we receive context > > > >>>entry invalidations. However it's possible that the invalidation also > > > >>>contains a domain switch (only if cache-mode is enabled for vIOMMU). In > > > >>>that case we need to notify all the registered components about the new > > > >>>mapping. > > > >>> > > > >>>Signed-off-by: Peter Xu <peterx@redhat.com> > > > >>>--- > > > >>> hw/i386/intel_iommu.c | 10 ++++++++++ > > > >>> 1 file changed, 10 insertions(+) > > > >>> > > > >>>diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c > > > >>>index f9c5142..4b08b4d 100644 > > > >>>--- a/hw/i386/intel_iommu.c > > > >>>+++ b/hw/i386/intel_iommu.c > > > >>>@@ -1146,6 +1146,16 @@ static void > > vtd_context_device_invalidate(IntelIOMMUState *s, > > > >>> trace_vtd_inv_desc_cc_device(bus_n, VTD_PCI_SLOT(devfn_it), > > > >>> VTD_PCI_FUNC(devfn_it)); > > > >>> vtd_as->context_cache_entry.context_cache_gen = 0; > > > >>>+ /* > > > >>>+ * So a device is moving out of (or moving into) a > > > >>>+ * domain, a replay() suites here to notify all the > > > >>>+ * IOMMU_NOTIFIER_MAP registers about this change. > > > >>>+ * This won't bring bad even if we have no such > > > >>>+ * notifier registered - the IOMMU notification > > > >>>+ * framework will skip MAP notifications if that > > > >>>+ * happened. > > > >>>+ */ > > > >>>+ memory_region_iommu_replay_all(&vtd_as->iommu); > > > >>DSI and GLOBAL questions come back again or no need to care about them :) ? > > > >DSI/GLOBAL hanldings are in patch 20 (though it'll be squashed into 18 > > > >in my next post). Is that what you mean above? > > > > > > Seems not, I mean DSI/GLOBAL for context cache invalidation instead of IOTLB > > > :) > > > > Yes, I should possibly do the same thing for context cache global > > invalidations. IIUC context global invalidation should be a superset > > of iotlb invalidation, so maybe I'll add one more patch to call iotlb > > invalidation in context invalidation as well. Kevin/others, please > > correct me if I misunderstood the spec. Thanks, > > > > context invalidation is not superset of iotlb invalidation. The spec just > requires software to always follow a context-cache invalidation with > a PASID-cache invalidation, followed by an IOTLB invalidation. Thanks for pointing out. If so, looks like current version suffice for this, right? (so no further change needed for this one) -- peterx
On 2017年01月25日 14:44, Peter Xu wrote: > On Wed, Jan 25, 2017 at 06:37:23AM +0000, Tian, Kevin wrote: >>> From: Peter Xu [mailto:peterx@redhat.com] >>> Sent: Wednesday, January 25, 2017 11:46 AM >>> >>> On Wed, Jan 25, 2017 at 11:09:39AM +0800, Jason Wang wrote: >>>> >>>> On 2017年01月24日 12:52, Peter Xu wrote: >>>>> On Mon, Jan 23, 2017 at 06:36:17PM +0800, Jason Wang wrote: >>>>>> On 2017年01月20日 21:08, Peter Xu wrote: >>>>>>> Before this one we only invalidate context cache when we receive context >>>>>>> entry invalidations. However it's possible that the invalidation also >>>>>>> contains a domain switch (only if cache-mode is enabled for vIOMMU). In >>>>>>> that case we need to notify all the registered components about the new >>>>>>> mapping. >>>>>>> >>>>>>> Signed-off-by: Peter Xu <peterx@redhat.com> >>>>>>> --- >>>>>>> hw/i386/intel_iommu.c | 10 ++++++++++ >>>>>>> 1 file changed, 10 insertions(+) >>>>>>> >>>>>>> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c >>>>>>> index f9c5142..4b08b4d 100644 >>>>>>> --- a/hw/i386/intel_iommu.c >>>>>>> +++ b/hw/i386/intel_iommu.c >>>>>>> @@ -1146,6 +1146,16 @@ static void >>> vtd_context_device_invalidate(IntelIOMMUState *s, >>>>>>> trace_vtd_inv_desc_cc_device(bus_n, VTD_PCI_SLOT(devfn_it), >>>>>>> VTD_PCI_FUNC(devfn_it)); >>>>>>> vtd_as->context_cache_entry.context_cache_gen = 0; >>>>>>> + /* >>>>>>> + * So a device is moving out of (or moving into) a >>>>>>> + * domain, a replay() suites here to notify all the >>>>>>> + * IOMMU_NOTIFIER_MAP registers about this change. >>>>>>> + * This won't bring bad even if we have no such >>>>>>> + * notifier registered - the IOMMU notification >>>>>>> + * framework will skip MAP notifications if that >>>>>>> + * happened. >>>>>>> + */ >>>>>>> + memory_region_iommu_replay_all(&vtd_as->iommu); >>>>>> DSI and GLOBAL questions come back again or no need to care about them :) ? >>>>> DSI/GLOBAL hanldings are in patch 20 (though it'll be squashed into 18 >>>>> in my next post). Is that what you mean above? >>>> Seems not, I mean DSI/GLOBAL for context cache invalidation instead of IOTLB >>>> :) >>> Yes, I should possibly do the same thing for context cache global >>> invalidations. IIUC context global invalidation should be a superset >>> of iotlb invalidation, so maybe I'll add one more patch to call iotlb >>> invalidation in context invalidation as well. Kevin/others, please >>> correct me if I misunderstood the spec. Thanks, >>> >> context invalidation is not superset of iotlb invalidation. The spec just >> requires software to always follow a context-cache invalidation with >> a PASID-cache invalidation, followed by an IOTLB invalidation. > Thanks for pointing out. If so, looks like current version suffice for > this, right? (so no further change needed for this one) > > -- peterx > We could not depends on guest or driver behavior. I still prefer to add unamp for DSI/GLOBAL to prevent us from leaking mappings. Thanks
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c index f9c5142..4b08b4d 100644 --- a/hw/i386/intel_iommu.c +++ b/hw/i386/intel_iommu.c @@ -1146,6 +1146,16 @@ static void vtd_context_device_invalidate(IntelIOMMUState *s, trace_vtd_inv_desc_cc_device(bus_n, VTD_PCI_SLOT(devfn_it), VTD_PCI_FUNC(devfn_it)); vtd_as->context_cache_entry.context_cache_gen = 0; + /* + * So a device is moving out of (or moving into) a + * domain, a replay() suites here to notify all the + * IOMMU_NOTIFIER_MAP registers about this change. + * This won't bring bad even if we have no such + * notifier registered - the IOMMU notification + * framework will skip MAP notifications if that + * happened. + */ + memory_region_iommu_replay_all(&vtd_as->iommu); } } }
Before this one we only invalidate context cache when we receive context entry invalidations. However it's possible that the invalidation also contains a domain switch (only if cache-mode is enabled for vIOMMU). In that case we need to notify all the registered components about the new mapping. Signed-off-by: Peter Xu <peterx@redhat.com> --- hw/i386/intel_iommu.c | 10 ++++++++++ 1 file changed, 10 insertions(+)