t;; Greg Kroah-Hartman
> >> <gre...@linuxfoundation.org>; Wysocki, Rafael J
> >> <rafael.j.wyso...@intel.com>; LKML <linux-kernel@vger.kernel.org>;
> >> io...@lists.linux-foundation.org; David Woodhouse
> >> <dw...@infradead.org>
>
Rafael J
> ; LKML ;
> io...@lists.linux-foundation.org; David Woodhouse
> Subject: Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function
>
> On 2017/10/12 17:50, Liu, Yi L wrote:
> >
> >
> >> -Original Message-
> >> From: Bob Liu [mai
socki, Rafael J
>>> <rafael.j.wyso...@intel.com>; LKML <linux-kernel@vger.kernel.org>;
>>> io...@lists.linux-foundation.org; David Woodhouse <dw...@infradead.org>
>>> Subject: Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function
>>
el
>>> ; Liu, Yi L
>>> Cc: Lan, Tianyu ; Liu, Yi L
>>> ; Greg
>>> Kroah-Hartman ; Wysocki, Rafael J
>>> ; LKML ;
>>> io...@lists.linux-foundation.org; David Woodhouse
>>> Subject: Re: [PATCH v2 03/16] iommu: introduce iommu invalidate
;linux-kernel@vger.kernel.org>;
>> io...@lists.linux-foundation.org; David Woodhouse <dw...@infradead.org>
>> Subject: Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function
>>
>> On 2017/10/11 20:48, Jean-Philippe Brucker wrote:
>>> On 11/10/17 13:
Yi L
>> ; Greg
>> Kroah-Hartman ; Wysocki, Rafael J
>> ; LKML ;
>> io...@lists.linux-foundation.org; David Woodhouse
>> Subject: Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function
>>
>> On 2017/10/11 20:48, Jean-Philippe Brucker wrote:
>>&
yu <tianyu@intel.com>; Liu, Yi L <yi.l@linux.intel.com>;
> Greg
> Kroah-Hartman <gre...@linuxfoundation.org>; Wysocki, Rafael J
> <rafael.j.wyso...@intel.com>; LKML <linux-kernel@vger.kernel.org>;
> io...@lists.linux-foundation.org; David Woodhous
...@lists.linux-foundation.org; David Woodhouse
> Subject: Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function
>
> On 2017/10/11 20:48, Jean-Philippe Brucker wrote:
> > On 11/10/17 13:15, Joerg Roedel wrote:
> >> On Wed, Oct 11, 2017 at 11:54:52AM +, Liu,
On 2017/10/11 20:48, Jean-Philippe Brucker wrote:
> On 11/10/17 13:15, Joerg Roedel wrote:
>> On Wed, Oct 11, 2017 at 11:54:52AM +, Liu, Yi L wrote:
>>> I didn't quite get 'iovm' mean. Can you explain a bit about the idea?
>>
>> It's short for IO Virtual Memory, basically a replacement term
On 2017/10/11 20:48, Jean-Philippe Brucker wrote:
> On 11/10/17 13:15, Joerg Roedel wrote:
>> On Wed, Oct 11, 2017 at 11:54:52AM +, Liu, Yi L wrote:
>>> I didn't quite get 'iovm' mean. Can you explain a bit about the idea?
>>
>> It's short for IO Virtual Memory, basically a replacement term
On Wed, Oct 11, 2017 at 01:48:00PM +0100, Jean-Philippe Brucker wrote:
> I wonder if SVM originated in OpenCL first, rather than intel? That's why
> I'm using it, but it is ambiguous. I'm not sure IOVM is precise enough
> though, since the name could as well be used without shared tables, for
>
On Wed, Oct 11, 2017 at 01:48:00PM +0100, Jean-Philippe Brucker wrote:
> I wonder if SVM originated in OpenCL first, rather than intel? That's why
> I'm using it, but it is ambiguous. I'm not sure IOVM is precise enough
> though, since the name could as well be used without shared tables, for
>
On 11/10/17 13:15, Joerg Roedel wrote:
> On Wed, Oct 11, 2017 at 11:54:52AM +, Liu, Yi L wrote:
>> I didn't quite get 'iovm' mean. Can you explain a bit about the idea?
>
> It's short for IO Virtual Memory, basically a replacement term for 'svm'
> that is not ambiguous (afaik) and not
On 11/10/17 13:15, Joerg Roedel wrote:
> On Wed, Oct 11, 2017 at 11:54:52AM +, Liu, Yi L wrote:
>> I didn't quite get 'iovm' mean. Can you explain a bit about the idea?
>
> It's short for IO Virtual Memory, basically a replacement term for 'svm'
> that is not ambiguous (afaik) and not
On Wed, Oct 11, 2017 at 11:54:52AM +, Liu, Yi L wrote:
> I didn't quite get 'iovm' mean. Can you explain a bit about the idea?
It's short for IO Virtual Memory, basically a replacement term for 'svm'
that is not ambiguous (afaik) and not specific to Intel.
Joerg
On Wed, Oct 11, 2017 at 11:54:52AM +, Liu, Yi L wrote:
> I didn't quite get 'iovm' mean. Can you explain a bit about the idea?
It's short for IO Virtual Memory, basically a replacement term for 'svm'
that is not ambiguous (afaik) and not specific to Intel.
Joerg
> On Wed, Oct 11, 2017 at 07:54:32AM +, Liu, Yi L wrote:
> > I agree that iommu_invalidate() is too generic. Additionally, also
> > better to avoid making it svm specific.
>
> I also don't like to name the functions after the Intel feature, but I failed
> to come up
> with a better
> On Wed, Oct 11, 2017 at 07:54:32AM +, Liu, Yi L wrote:
> > I agree that iommu_invalidate() is too generic. Additionally, also
> > better to avoid making it svm specific.
>
> I also don't like to name the functions after the Intel feature, but I failed
> to come up
> with a better
On Wed, Oct 11, 2017 at 07:54:32AM +, Liu, Yi L wrote:
> I agree that iommu_invalidate() is too generic. Additionally, also
> better to avoid making it svm specific.
I also don't like to name the functions after the Intel feature, but I
failed to come up with a better alternative so far. The
On Wed, Oct 11, 2017 at 07:54:32AM +, Liu, Yi L wrote:
> I agree that iommu_invalidate() is too generic. Additionally, also
> better to avoid making it svm specific.
I also don't like to name the functions after the Intel feature, but I
failed to come up with a better alternative so far. The
> On Tue, 10 Oct 2017 15:35:42 +0200
> Joerg Roedel wrote:
>
> > On Thu, Oct 05, 2017 at 04:03:31PM -0700, Jacob Pan wrote:
> > > +int iommu_invalidate(struct iommu_domain *domain,
> > > + struct device *dev, struct tlb_invalidate_info
> > > *inv_info)
> >
> > This name
> On Tue, 10 Oct 2017 15:35:42 +0200
> Joerg Roedel wrote:
>
> > On Thu, Oct 05, 2017 at 04:03:31PM -0700, Jacob Pan wrote:
> > > +int iommu_invalidate(struct iommu_domain *domain,
> > > + struct device *dev, struct tlb_invalidate_info
> > > *inv_info)
> >
> > This name is way too
On Tue, 10 Oct 2017 15:35:42 +0200
Joerg Roedel wrote:
> On Thu, Oct 05, 2017 at 04:03:31PM -0700, Jacob Pan wrote:
> > +int iommu_invalidate(struct iommu_domain *domain,
> > + struct device *dev, struct tlb_invalidate_info
> > *inv_info)
>
> This name is way too
On Tue, 10 Oct 2017 15:35:42 +0200
Joerg Roedel wrote:
> On Thu, Oct 05, 2017 at 04:03:31PM -0700, Jacob Pan wrote:
> > +int iommu_invalidate(struct iommu_domain *domain,
> > + struct device *dev, struct tlb_invalidate_info
> > *inv_info)
>
> This name is way too generic, it should
On Thu, Oct 05, 2017 at 04:03:31PM -0700, Jacob Pan wrote:
> +int iommu_invalidate(struct iommu_domain *domain,
> + struct device *dev, struct tlb_invalidate_info *inv_info)
This name is way too generic, it should at least be called
iommu_svm_invalidate() or something like that. With
On Thu, Oct 05, 2017 at 04:03:31PM -0700, Jacob Pan wrote:
> +int iommu_invalidate(struct iommu_domain *domain,
> + struct device *dev, struct tlb_invalidate_info *inv_info)
This name is way too generic, it should at least be called
iommu_svm_invalidate() or something like that. With
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