On Tue, 8 May 2018 11:35:00 +0100
Jean-Philippe Brucker wrote:
> Hi Jacob,
>
> Looks mostly good to me, I just have a couple more comments
>
> On 04/05/18 19:07, Jacob Pan wrote:
> > Now the passdown invalidation granularities look like:
> > (sorted by
On Tue, 8 May 2018 11:35:00 +0100
Jean-Philippe Brucker wrote:
> Hi Jacob,
>
> Looks mostly good to me, I just have a couple more comments
>
> On 04/05/18 19:07, Jacob Pan wrote:
> > Now the passdown invalidation granularities look like:
> > (sorted by coarseness), will send out in v5 patchset
Hi Jacob,
Looks mostly good to me, I just have a couple more comments
On 04/05/18 19:07, Jacob Pan wrote:
> Now the passdown invalidation granularities look like:
> (sorted by coarseness), will send out in v5 patchset soon if no issues.
>
> /**
> * enum iommu_inv_granularity - Generic
Hi Jacob,
Looks mostly good to me, I just have a couple more comments
On 04/05/18 19:07, Jacob Pan wrote:
> Now the passdown invalidation granularities look like:
> (sorted by coarseness), will send out in v5 patchset soon if no issues.
>
> /**
> * enum iommu_inv_granularity - Generic
On Sat, 5 May 2018 15:19:43 -0700
Jerry Snitselaar wrote:
> >
> >+static inline int iommu_sva_invalidate(struct iommu_domain *domain,
> >+struct device *dev, struct tlb_invalidate_info
> >*inv_info) +{
> >+return -EINVAL;
> >+}
> >+
>
> Would -ENODEV make
On Sat, 5 May 2018 15:19:43 -0700
Jerry Snitselaar wrote:
> >
> >+static inline int iommu_sva_invalidate(struct iommu_domain *domain,
> >+struct device *dev, struct tlb_invalidate_info
> >*inv_info) +{
> >+return -EINVAL;
> >+}
> >+
>
> Would -ENODEV make more sense here?
>
On Mon Apr 16 18, Jacob Pan wrote:
From: "Liu, Yi L"
When an SVM capable device is assigned to a guest, the first level page
tables are owned by the guest and the guest PASID table pointer is
linked to the device context entry of the physical IOMMU.
Host IOMMU driver
On Mon Apr 16 18, Jacob Pan wrote:
From: "Liu, Yi L"
When an SVM capable device is assigned to a guest, the first level page
tables are owned by the guest and the guest PASID table pointer is
linked to the device context entry of the physical IOMMU.
Host IOMMU driver has no knowledge of
On Thu, 3 May 2018 21:46:16 -0700
Jacob Pan wrote:
> On Wed, 2 May 2018 10:31:50 +0100
> Jean-Philippe Brucker wrote:
>
> > On 01/05/18 23:58, Jacob Pan wrote:
> > Maybe this should be called "NG_PAGE_PASID",
> > >>>
On Thu, 3 May 2018 21:46:16 -0700
Jacob Pan wrote:
> On Wed, 2 May 2018 10:31:50 +0100
> Jean-Philippe Brucker wrote:
>
> > On 01/05/18 23:58, Jacob Pan wrote:
> > Maybe this should be called "NG_PAGE_PASID",
> > >>> Sure. I was thinking page range already implies non-global
> >
On Wed, 2 May 2018 10:31:50 +0100
Jean-Philippe Brucker wrote:
> On 01/05/18 23:58, Jacob Pan wrote:
> Maybe this should be called "NG_PAGE_PASID",
> >>> Sure. I was thinking page range already implies non-global
> >>> pages.
> and "DOMAIN_PAGE"
On Wed, 2 May 2018 10:31:50 +0100
Jean-Philippe Brucker wrote:
> On 01/05/18 23:58, Jacob Pan wrote:
> Maybe this should be called "NG_PAGE_PASID",
> >>> Sure. I was thinking page range already implies non-global
> >>> pages.
> and "DOMAIN_PAGE" should
> instead be
On 01/05/18 23:58, Jacob Pan wrote:
Maybe this should be called "NG_PAGE_PASID",
>>> Sure. I was thinking page range already implies non-global pages.
and "DOMAIN_PAGE" should
instead be "PAGE_PASID". If I understood their meaning correctly,
it would be more consistent with
On 01/05/18 23:58, Jacob Pan wrote:
Maybe this should be called "NG_PAGE_PASID",
>>> Sure. I was thinking page range already implies non-global pages.
and "DOMAIN_PAGE" should
instead be "PAGE_PASID". If I understood their meaning correctly,
it would be more consistent with
On Fri, 27 Apr 2018 19:07:43 +0100
Jean-Philippe Brucker wrote:
> On 23/04/18 21:43, Jacob Pan wrote:
> [...]
> >> The last name is a bit unfortunate. Since the Arm architecture uses
> >> the name "context" for what a PASID points to, "Device cache" would
> >> suit
On Fri, 27 Apr 2018 19:07:43 +0100
Jean-Philippe Brucker wrote:
> On 23/04/18 21:43, Jacob Pan wrote:
> [...]
> >> The last name is a bit unfortunate. Since the Arm architecture uses
> >> the name "context" for what a PASID points to, "Device cache" would
> >> suit us better but it's not
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Saturday, April 28, 2018 2:08 AM
>
> [...]
> >> If this corresponds to QI_GRAN_ALL_ALL in patch 9, the comment should
> >> be "Cache of all PASIDs"? Or maybe "all entries for all PASIDs"? Is it
> >> different from
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Saturday, April 28, 2018 2:08 AM
>
> [...]
> >> If this corresponds to QI_GRAN_ALL_ALL in patch 9, the comment should
> >> be "Cache of all PASIDs"? Or maybe "all entries for all PASIDs"? Is it
> >> different from
On 23/04/18 21:43, Jacob Pan wrote:
[...]
>> The last name is a bit unfortunate. Since the Arm architecture uses
>> the name "context" for what a PASID points to, "Device cache" would
>> suit us better but it's not important.
>>
> or call it device context cache. actually so far context cache is
On 23/04/18 21:43, Jacob Pan wrote:
[...]
>> The last name is a bit unfortunate. Since the Arm architecture uses
>> the name "context" for what a PASID points to, "Device cache" would
>> suit us better but it's not important.
>>
> or call it device context cache. actually so far context cache is
On Fri, 20 Apr 2018 19:19:54 +0100
Jean-Philippe Brucker wrote:
> Hi Jacob,
>
> On Mon, Apr 16, 2018 at 10:48:54PM +0100, Jacob Pan wrote:
> [...]
> > +/**
> > + * enum iommu_inv_granularity - Generic invalidation granularity
> > + *
> > + * When an invalidation
On Fri, 20 Apr 2018 19:19:54 +0100
Jean-Philippe Brucker wrote:
> Hi Jacob,
>
> On Mon, Apr 16, 2018 at 10:48:54PM +0100, Jacob Pan wrote:
> [...]
> > +/**
> > + * enum iommu_inv_granularity - Generic invalidation granularity
> > + *
> > + * When an invalidation request is sent to IOMMU to
Hi Jacob,
On Mon, Apr 16, 2018 at 10:48:54PM +0100, Jacob Pan wrote:
[...]
> +/**
> + * enum iommu_inv_granularity - Generic invalidation granularity
> + *
> + * When an invalidation request is sent to IOMMU to flush translation caches,
> + * it may carry different granularity. These granularity
Hi Jacob,
On Mon, Apr 16, 2018 at 10:48:54PM +0100, Jacob Pan wrote:
[...]
> +/**
> + * enum iommu_inv_granularity - Generic invalidation granularity
> + *
> + * When an invalidation request is sent to IOMMU to flush translation caches,
> + * it may carry different granularity. These granularity
From: "Liu, Yi L"
When an SVM capable device is assigned to a guest, the first level page
tables are owned by the guest and the guest PASID table pointer is
linked to the device context entry of the physical IOMMU.
Host IOMMU driver has no knowledge of caching
From: "Liu, Yi L"
When an SVM capable device is assigned to a guest, the first level page
tables are owned by the guest and the guest PASID table pointer is
linked to the device context entry of the physical IOMMU.
Host IOMMU driver has no knowledge of caching structure updates unless
the guest
From: "Liu, Yi L"
When an SVM capable device is assigned to a guest, the first level page
tables are owned by the guest and the guest PASID table pointer is
linked to the device context entry of the physical IOMMU.
Host IOMMU driver has no knowledge of caching
From: "Liu, Yi L"
When an SVM capable device is assigned to a guest, the first level page
tables are owned by the guest and the guest PASID table pointer is
linked to the device context entry of the physical IOMMU.
Host IOMMU driver has no knowledge of caching structure updates unless
the guest
28 matches
Mail list logo