Re: [PATCH kernel v5 10/10] KVM: PPC: VFIO: Add in-kernel acceleration for VFIO

[David Gibson]

On Mon, Feb 27, 2017 at 02:20:13PM +1100, Alexey Kardashevskiy wrote:
> On 27/02/17 12:53, David Gibson wrote:
> > On Fri, Feb 24, 2017 at 02:43:05PM +1100, Alexey Kardashevskiy wrote:
> >> On 24/02/17 14:36, David Gibson wrote:
> >>> On Fri, Feb 24, 2017 at 02:29:14PM +1100, Alexey Kardashevskiy wrote:
>  On 24/02/17 13:14, David Gibson wrote:
> > On Wed, Feb 22, 2017 at 07:21:33PM +1100, Alexey Kardashevskiy
> >> wrote:
> > [snip]
> >> +static long kvmppc_rm_tce_iommu_unmap(struct kvm *kvm,
> >> +  struct iommu_table *tbl, unsigned long entry)
> >> +{
> >> +  enum dma_data_direction dir = DMA_NONE;
> >> +  unsigned long hpa = 0;
> >> +  long ret;
> >> +
> >> +  if (iommu_tce_xchg_rm(tbl, entry, , ))
> >> +  return H_HARDWARE;
> >
> > To avoid a double WARN() (and to make the warnings easier to
> > understand) I'd suggest putting a WARN_ON() here, rather than in the
> > callers when they receieve an H_HARDWARE.  IIUC this really shouldn't
> > ever happen, and it certainly can't be the guest's fault?
> 
> 
>  Makes sense.
> >>>
> >>> I guess it might want WARN_ON_ONCE() to avoid spamming the user with
> >>> errors for every TCE, though.
> >>
> >>
> >> We do not expect this to happen at all :) I can convert all of them to
> >> _ONCE really as the purpose of WARN_ON is mostly to document what we do not
> >> expect.
> > 
> > Sure, seems reasonable.
> > 
> > [snip]
> >> @@ -220,9 +338,10 @@ long kvmppc_rm_h_put_tce_indirect(struct kvm_vcpu 
> >> *vcpu,
> >>  {
> >>struct kvmppc_spapr_tce_table *stt;
> >>long i, ret = H_SUCCESS;
> >> -  unsigned long tces, entry, ua = 0;
> >> +  unsigned long tces, entry, ua = 0, tce, gpa;
> >>unsigned long *rmap = NULL;
> >>bool prereg = false;
> >> +  struct kvmppc_spapr_tce_iommu_table *stit;
> >>  
> >>stt = kvmppc_find_table(vcpu->kvm, liobn);
> >>if (!stt)
> >> @@ -287,12 +406,24 @@ long kvmppc_rm_h_put_tce_indirect(struct 
> >> kvm_vcpu *vcpu,
> >>}
> >>  
> >>for (i = 0; i < npages; ++i) {
> >> -  unsigned long tce = be64_to_cpu(((u64 *)tces)[i]);
> >> +  tce = be64_to_cpu(((u64 *)tces)[i]);
> >>  
> >>ret = kvmppc_tce_validate(stt, tce);
> >>if (ret != H_SUCCESS)
> >>goto unlock_exit;
> >>  
> >> +  gpa = tce & ~(TCE_PCI_READ | TCE_PCI_WRITE);
> >> +
> >> +  list_for_each_entry_lockless(stit, >iommu_tables, 
> >> next) {
> >> +  ret = kvmppc_rm_tce_iommu_map(vcpu->kvm,
> >> +  stit->tbl, entry + i, gpa,
> >> +  iommu_tce_direction(tce));
> >> +  if (WARN_ON_ONCE(ret == H_HARDWARE))
> >
> > I don't think you need the WARN() here - the only H_HARDWARE failure
> > path in iommu_map() already includes a WARN().
> 
> 
>  True, I can drop it here.
> 
> 
> >
> >> +  kvmppc_rm_clear_tce(stit->tbl, entry);
> >> +  else if (ret != H_SUCCESS)
> >> +  goto unlock_exit;
> >
> > It's also not clear to me why the H_HARDWARE error path clears the
> > entry, but the other failure paths don't.  Or why an H_HARDWARE will
> > result in continuing to set the rest of the TCEs, but other failures
> > won't.
> 
> 
>  The idea was that other failures still have some chance that handling may
>  succeed in virtual mode or via QEMU, H_HARDWARE is fatal.
> >>>
> >>> Um... yes.. but the logic seems to be backwards for that: on
> >>> H_HARDWARE you warn and keep going, on other errors you bail out
> >>> entirely.
> >>
> >> By "fatal" I means fatal for this particular hardware TCE(s), no hope in
> >> trying this particular TCE in virtual mode.
> > 
> > Ok... still not following why that means the "fatal" error results in
> > continuing to attempt for the rest of the updated TCEs, whereas the
> > "non fatal" one bails out.
> 
> I was applying the principle that if after all checks done we still cannot
> update the hardware table, then just clear the TCE and move on. Or I
> misunderstood the idea?

*Still* not seeing why if we cannot update the hardware table we keep
trying with the rest of the entries, but on other failures we don't.

> > Especially since the bail out will only go
> > to virtual mode if ret == H_TOO_HARD, which it isn't clear is the only
> > possibility.
> 
> 
> H_TOO_HARD goes to virtual mode, H_TOO_HARD in virtual goes to the
> userspace (QEMU).
> 
> Will "if (WARN_ON_ONCE(ret != H_SUCCESS && ret != H_TOO_HARD))" make more
> sense?

Probably, but depends what's in the if.

> > 
>  I am just 

Re: [PATCH kernel v5 10/10] KVM: PPC: VFIO: Add in-kernel acceleration for VFIO

[Alexey Kardashevskiy]

On 27/02/17 12:53, David Gibson wrote:
> On Fri, Feb 24, 2017 at 02:43:05PM +1100, Alexey Kardashevskiy wrote:
>> On 24/02/17 14:36, David Gibson wrote:
>>> On Fri, Feb 24, 2017 at 02:29:14PM +1100, Alexey Kardashevskiy wrote:
 On 24/02/17 13:14, David Gibson wrote:
> On Wed, Feb 22, 2017 at 07:21:33PM +1100, Alexey Kardashevskiy
>> wrote:
> [snip]
>> +static long kvmppc_rm_tce_iommu_unmap(struct kvm *kvm,
>> +struct iommu_table *tbl, unsigned long entry)
>> +{
>> +enum dma_data_direction dir = DMA_NONE;
>> +unsigned long hpa = 0;
>> +long ret;
>> +
>> +if (iommu_tce_xchg_rm(tbl, entry, , ))
>> +return H_HARDWARE;
>
> To avoid a double WARN() (and to make the warnings easier to
> understand) I'd suggest putting a WARN_ON() here, rather than in the
> callers when they receieve an H_HARDWARE.  IIUC this really shouldn't
> ever happen, and it certainly can't be the guest's fault?


 Makes sense.
>>>
>>> I guess it might want WARN_ON_ONCE() to avoid spamming the user with
>>> errors for every TCE, though.
>>
>>
>> We do not expect this to happen at all :) I can convert all of them to
>> _ONCE really as the purpose of WARN_ON is mostly to document what we do not
>> expect.
> 
> Sure, seems reasonable.
> 
> [snip]
>> @@ -220,9 +338,10 @@ long kvmppc_rm_h_put_tce_indirect(struct kvm_vcpu 
>> *vcpu,
>>  {
>>  struct kvmppc_spapr_tce_table *stt;
>>  long i, ret = H_SUCCESS;
>> -unsigned long tces, entry, ua = 0;
>> +unsigned long tces, entry, ua = 0, tce, gpa;
>>  unsigned long *rmap = NULL;
>>  bool prereg = false;
>> +struct kvmppc_spapr_tce_iommu_table *stit;
>>  
>>  stt = kvmppc_find_table(vcpu->kvm, liobn);
>>  if (!stt)
>> @@ -287,12 +406,24 @@ long kvmppc_rm_h_put_tce_indirect(struct kvm_vcpu 
>> *vcpu,
>>  }
>>  
>>  for (i = 0; i < npages; ++i) {
>> -unsigned long tce = be64_to_cpu(((u64 *)tces)[i]);
>> +tce = be64_to_cpu(((u64 *)tces)[i]);
>>  
>>  ret = kvmppc_tce_validate(stt, tce);
>>  if (ret != H_SUCCESS)
>>  goto unlock_exit;
>>  
>> +gpa = tce & ~(TCE_PCI_READ | TCE_PCI_WRITE);
>> +
>> +list_for_each_entry_lockless(stit, >iommu_tables, 
>> next) {
>> +ret = kvmppc_rm_tce_iommu_map(vcpu->kvm,
>> +stit->tbl, entry + i, gpa,
>> +iommu_tce_direction(tce));
>> +if (WARN_ON_ONCE(ret == H_HARDWARE))
>
> I don't think you need the WARN() here - the only H_HARDWARE failure
> path in iommu_map() already includes a WARN().


 True, I can drop it here.


>
>> +kvmppc_rm_clear_tce(stit->tbl, entry);
>> +else if (ret != H_SUCCESS)
>> +goto unlock_exit;
>
> It's also not clear to me why the H_HARDWARE error path clears the
> entry, but the other failure paths don't.  Or why an H_HARDWARE will
> result in continuing to set the rest of the TCEs, but other failures
> won't.


 The idea was that other failures still have some chance that handling may
 succeed in virtual mode or via QEMU, H_HARDWARE is fatal.
>>>
>>> Um... yes.. but the logic seems to be backwards for that: on
>>> H_HARDWARE you warn and keep going, on other errors you bail out
>>> entirely.
>>
>> By "fatal" I means fatal for this particular hardware TCE(s), no hope in
>> trying this particular TCE in virtual mode.
> 
> Ok... still not following why that means the "fatal" error results in
> continuing to attempt for the rest of the updated TCEs, whereas the
> "non fatal" one bails out.

I was applying the principle that if after all checks done we still cannot
update the hardware table, then just clear the TCE and move on. Or I
misunderstood the idea?


> Especially since the bail out will only go
> to virtual mode if ret == H_TOO_HARD, which it isn't clear is the only
> possibility.


H_TOO_HARD goes to virtual mode, H_TOO_HARD in virtual goes to the
userspace (QEMU).

Will "if (WARN_ON_ONCE(ret != H_SUCCESS && ret != H_TOO_HARD))" make more
sense?



> 
 I am just not sure if H_PARAMETER is what I want to return at [1], to make
 the calling code simplier, I could return H_HARDWARE there as well (instead
 of H_PARAMETER).
>>>
>>> That sounds right, IIUC the gpa to ua translation shouldn't ever
>>> fail because of something the guest did. 
>>
>>
>> The guest can easily pass bad TCE/GPA which is not in any registered slot.
>> So it is rather H_PARAMETER.
> 
> Ah, yes.
> 

Re: [PATCH kernel v5 10/10] KVM: PPC: VFIO: Add in-kernel acceleration for VFIO

[David Gibson]

On Fri, Feb 24, 2017 at 02:43:05PM +1100, Alexey Kardashevskiy wrote:
> On 24/02/17 14:36, David Gibson wrote:
> > On Fri, Feb 24, 2017 at 02:29:14PM +1100, Alexey Kardashevskiy wrote:
> >> On 24/02/17 13:14, David Gibson wrote:
> >>> On Wed, Feb 22, 2017 at 07:21:33PM +1100, Alexey Kardashevskiy
> wrote:
[snip]
>  +static long kvmppc_rm_tce_iommu_unmap(struct kvm *kvm,
>  +struct iommu_table *tbl, unsigned long entry)
>  +{
>  +enum dma_data_direction dir = DMA_NONE;
>  +unsigned long hpa = 0;
>  +long ret;
>  +
>  +if (iommu_tce_xchg_rm(tbl, entry, , ))
>  +return H_HARDWARE;
> >>>
> >>> To avoid a double WARN() (and to make the warnings easier to
> >>> understand) I'd suggest putting a WARN_ON() here, rather than in the
> >>> callers when they receieve an H_HARDWARE.  IIUC this really shouldn't
> >>> ever happen, and it certainly can't be the guest's fault?
> >>
> >>
> >> Makes sense.
> > 
> > I guess it might want WARN_ON_ONCE() to avoid spamming the user with
> > errors for every TCE, though.
> 
> 
> We do not expect this to happen at all :) I can convert all of them to
> _ONCE really as the purpose of WARN_ON is mostly to document what we do not
> expect.

Sure, seems reasonable.

[snip]
>  @@ -220,9 +338,10 @@ long kvmppc_rm_h_put_tce_indirect(struct kvm_vcpu 
>  *vcpu,
>   {
>   struct kvmppc_spapr_tce_table *stt;
>   long i, ret = H_SUCCESS;
>  -unsigned long tces, entry, ua = 0;
>  +unsigned long tces, entry, ua = 0, tce, gpa;
>   unsigned long *rmap = NULL;
>   bool prereg = false;
>  +struct kvmppc_spapr_tce_iommu_table *stit;
>   
>   stt = kvmppc_find_table(vcpu->kvm, liobn);
>   if (!stt)
>  @@ -287,12 +406,24 @@ long kvmppc_rm_h_put_tce_indirect(struct kvm_vcpu 
>  *vcpu,
>   }
>   
>   for (i = 0; i < npages; ++i) {
>  -unsigned long tce = be64_to_cpu(((u64 *)tces)[i]);
>  +tce = be64_to_cpu(((u64 *)tces)[i]);
>   
>   ret = kvmppc_tce_validate(stt, tce);
>   if (ret != H_SUCCESS)
>   goto unlock_exit;
>   
>  +gpa = tce & ~(TCE_PCI_READ | TCE_PCI_WRITE);
>  +
>  +list_for_each_entry_lockless(stit, >iommu_tables, 
>  next) {
>  +ret = kvmppc_rm_tce_iommu_map(vcpu->kvm,
>  +stit->tbl, entry + i, gpa,
>  +iommu_tce_direction(tce));
>  +if (WARN_ON_ONCE(ret == H_HARDWARE))
> >>>
> >>> I don't think you need the WARN() here - the only H_HARDWARE failure
> >>> path in iommu_map() already includes a WARN().
> >>
> >>
> >> True, I can drop it here.
> >>
> >>
> >>>
>  +kvmppc_rm_clear_tce(stit->tbl, entry);
>  +else if (ret != H_SUCCESS)
>  +goto unlock_exit;
> >>>
> >>> It's also not clear to me why the H_HARDWARE error path clears the
> >>> entry, but the other failure paths don't.  Or why an H_HARDWARE will
> >>> result in continuing to set the rest of the TCEs, but other failures
> >>> won't.
> >>
> >>
> >> The idea was that other failures still have some chance that handling may
> >> succeed in virtual mode or via QEMU, H_HARDWARE is fatal.
> > 
> > Um... yes.. but the logic seems to be backwards for that: on
> > H_HARDWARE you warn and keep going, on other errors you bail out
> > entirely.
> 
> By "fatal" I means fatal for this particular hardware TCE(s), no hope in
> trying this particular TCE in virtual mode.

Ok... still not following why that means the "fatal" error results in
continuing to attempt for the rest of the updated TCEs, whereas the
"non fatal" one bails out.  Especially since the bail out will only go
to virtual mode if ret == H_TOO_HARD, which it isn't clear is the only
possibility.

> >> I am just not sure if H_PARAMETER is what I want to return at [1], to make
> >> the calling code simplier, I could return H_HARDWARE there as well (instead
> >> of H_PARAMETER).
> > 
> > That sounds right, IIUC the gpa to ua translation shouldn't ever
> > fail because of something the guest did. 
> 
> 
> The guest can easily pass bad TCE/GPA which is not in any registered slot.
> So it is rather H_PARAMETER.

Ah, yes.

> > So I'd expect either
> > H_HARDWARE, or H_TOO_HARD (if there's some hope that virtual mode can
> > make the translation when real mode couldn't).
> 
> No, virtual mode uses the exact same helper.

Ok.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!

Re: [PATCH kernel v5 10/10] KVM: PPC: VFIO: Add in-kernel acceleration for VFIO

[Alexey Kardashevskiy]

On 24/02/17 14:43, Alexey Kardashevskiy wrote:
> On 24/02/17 14:36, David Gibson wrote:
>> On Fri, Feb 24, 2017 at 02:29:14PM +1100, Alexey Kardashevskiy wrote:
>>> On 24/02/17 13:14, David Gibson wrote:
 On Wed, Feb 22, 2017 at 07:21:33PM +1100, Alexey Kardashevskiy wrote:
> This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
> and H_STUFF_TCE requests targeted an IOMMU TCE table used for VFIO
> without passing them to user space which saves time on switching
> to user space and back.
>
> This adds H_PUT_TCE/H_PUT_TCE_INDIRECT/H_STUFF_TCE handlers to KVM.
> KVM tries to handle a TCE request in the real mode, if failed
> it passes the request to the virtual mode to complete the operation.
> If it a virtual mode handler fails, the request is passed to
> the user space; this is not expected to happen though.
>
> To avoid dealing with page use counters (which is tricky in real mode),
> this only accelerates SPAPR TCE IOMMU v2 clients which are required
> to pre-register the userspace memory. The very first TCE request will
> be handled in the VFIO SPAPR TCE driver anyway as the userspace view
> of the TCE table (iommu_table::it_userspace) is not allocated till
> the very first mapping happens and we cannot call vmalloc in real mode.
>
> If we fail to update a hardware IOMMU table unexpected reason, we just
> clear it and move on as there is nothing really we can do about it -
> for example, if we hot plug a VFIO device to a guest, existing TCE tables
> will be mirrored automatically to the hardware and there is no interface
> to report to the guest about possible failures.
>
> This adds new attribute - KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE - to
> the VFIO KVM device. It takes a VFIO group fd and SPAPR TCE table fd
> and associates a physical IOMMU table with the SPAPR TCE table (which
> is a guest view of the hardware IOMMU table). The iommu_table object
> is cached and referenced so we do not have to look up for it in real mode.
>
> This does not implement the UNSET counterpart as there is no use for it -
> once the acceleration is enabled, the existing userspace won't
> disable it unless a VFIO container is destroyed; this adds necessary
> cleanup to the KVM_DEV_VFIO_GROUP_DEL handler.
>
> As this creates a descriptor per IOMMU table-LIOBN couple (called
> kvmppc_spapr_tce_iommu_table), it is possible to have several
> descriptors with the same iommu_table (hardware IOMMU table) attached
> to the same LIOBN; we do not remove duplicates though as
> iommu_table_ops::exchange not just update a TCE entry (which is
> shared among IOMMU groups) but also invalidates the TCE cache
> (one per IOMMU group).
>
> This advertises the new KVM_CAP_SPAPR_TCE_VFIO capability to the user
> space.
>
> This finally makes use of vfio_external_user_iommu_id() which was
> introduced quite some time ago and was considered for removal.
>
> Tests show that this patch increases transmission speed from 220MB/s
> to 750..1020MB/s on 10Gb network (Chelsea CXGB3 10Gb ethernet card).
>
> Signed-off-by: Alexey Kardashevskiy 

 I have some comments on this patch, but all the definite ones are
 pretty minor and could be done as later cleanups.

 I have some more serious queries, but they are just queries and
 requests for clarification.  If there are satisfactory answers to
 them, I'll add my R-b.


 ---
> Changes:
> v5:
> * changed error codes in multiple places
> * added bunch of WARN_ON() in places which should not really happen
> * adde a check that an iommu table is not attached already to LIOBN
> * dropped explicit calls to iommu_tce_clear_param_check/
> iommu_tce_put_param_check as kvmppc_tce_validate/kvmppc_ioba_validate
> call them anyway (since the previous patch)
> * if we fail to update a hardware IOMMU table for unexpected reason,
> this just clears the entry
>
> v4:
> * added note to the commit log about allowing multiple updates of
> the same IOMMU table;
> * instead of checking for if any memory was preregistered, this
> returns H_TOO_HARD if a specific page was not;
> * fixed comments from v3 about error handling in many places;
> * simplified TCE handlers and merged IOMMU parts inline - for example,
> there used to be kvmppc_h_put_tce_iommu(), now it is merged into
> kvmppc_h_put_tce(); this allows to check IOBA boundaries against
> the first attached table only (makes the code simpler);
>
> v3:
> * simplified not to use VFIO group notifiers
> * reworked cleanup, should be cleaner/simpler now
>
> v2:
> * reworked to use new VFIO notifiers
> * now same iommu_table may appear in the list several times, to be fixed 
> later
> 

Re: [PATCH kernel v5 10/10] KVM: PPC: VFIO: Add in-kernel acceleration for VFIO

[Alexey Kardashevskiy]

On 24/02/17 14:36, David Gibson wrote:
> On Fri, Feb 24, 2017 at 02:29:14PM +1100, Alexey Kardashevskiy wrote:
>> On 24/02/17 13:14, David Gibson wrote:
>>> On Wed, Feb 22, 2017 at 07:21:33PM +1100, Alexey Kardashevskiy wrote:
 This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
 and H_STUFF_TCE requests targeted an IOMMU TCE table used for VFIO
 without passing them to user space which saves time on switching
 to user space and back.

 This adds H_PUT_TCE/H_PUT_TCE_INDIRECT/H_STUFF_TCE handlers to KVM.
 KVM tries to handle a TCE request in the real mode, if failed
 it passes the request to the virtual mode to complete the operation.
 If it a virtual mode handler fails, the request is passed to
 the user space; this is not expected to happen though.

 To avoid dealing with page use counters (which is tricky in real mode),
 this only accelerates SPAPR TCE IOMMU v2 clients which are required
 to pre-register the userspace memory. The very first TCE request will
 be handled in the VFIO SPAPR TCE driver anyway as the userspace view
 of the TCE table (iommu_table::it_userspace) is not allocated till
 the very first mapping happens and we cannot call vmalloc in real mode.

 If we fail to update a hardware IOMMU table unexpected reason, we just
 clear it and move on as there is nothing really we can do about it -
 for example, if we hot plug a VFIO device to a guest, existing TCE tables
 will be mirrored automatically to the hardware and there is no interface
 to report to the guest about possible failures.

 This adds new attribute - KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE - to
 the VFIO KVM device. It takes a VFIO group fd and SPAPR TCE table fd
 and associates a physical IOMMU table with the SPAPR TCE table (which
 is a guest view of the hardware IOMMU table). The iommu_table object
 is cached and referenced so we do not have to look up for it in real mode.

 This does not implement the UNSET counterpart as there is no use for it -
 once the acceleration is enabled, the existing userspace won't
 disable it unless a VFIO container is destroyed; this adds necessary
 cleanup to the KVM_DEV_VFIO_GROUP_DEL handler.

 As this creates a descriptor per IOMMU table-LIOBN couple (called
 kvmppc_spapr_tce_iommu_table), it is possible to have several
 descriptors with the same iommu_table (hardware IOMMU table) attached
 to the same LIOBN; we do not remove duplicates though as
 iommu_table_ops::exchange not just update a TCE entry (which is
 shared among IOMMU groups) but also invalidates the TCE cache
 (one per IOMMU group).

 This advertises the new KVM_CAP_SPAPR_TCE_VFIO capability to the user
 space.

 This finally makes use of vfio_external_user_iommu_id() which was
 introduced quite some time ago and was considered for removal.

 Tests show that this patch increases transmission speed from 220MB/s
 to 750..1020MB/s on 10Gb network (Chelsea CXGB3 10Gb ethernet card).

 Signed-off-by: Alexey Kardashevskiy 
>>>
>>> I have some comments on this patch, but all the definite ones are
>>> pretty minor and could be done as later cleanups.
>>>
>>> I have some more serious queries, but they are just queries and
>>> requests for clarification.  If there are satisfactory answers to
>>> them, I'll add my R-b.
>>>
>>>
>>> ---
 Changes:
 v5:
 * changed error codes in multiple places
 * added bunch of WARN_ON() in places which should not really happen
 * adde a check that an iommu table is not attached already to LIOBN
 * dropped explicit calls to iommu_tce_clear_param_check/
 iommu_tce_put_param_check as kvmppc_tce_validate/kvmppc_ioba_validate
 call them anyway (since the previous patch)
 * if we fail to update a hardware IOMMU table for unexpected reason,
 this just clears the entry

 v4:
 * added note to the commit log about allowing multiple updates of
 the same IOMMU table;
 * instead of checking for if any memory was preregistered, this
 returns H_TOO_HARD if a specific page was not;
 * fixed comments from v3 about error handling in many places;
 * simplified TCE handlers and merged IOMMU parts inline - for example,
 there used to be kvmppc_h_put_tce_iommu(), now it is merged into
 kvmppc_h_put_tce(); this allows to check IOBA boundaries against
 the first attached table only (makes the code simpler);

 v3:
 * simplified not to use VFIO group notifiers
 * reworked cleanup, should be cleaner/simpler now

 v2:
 * reworked to use new VFIO notifiers
 * now same iommu_table may appear in the list several times, to be fixed 
 later
 ---
  Documentation/virtual/kvm/devices/vfio.txt |  22 ++-
  arch/powerpc/include/asm/kvm_host.h|   8 +
  

Re: [PATCH kernel v5 10/10] KVM: PPC: VFIO: Add in-kernel acceleration for VFIO

[David Gibson]

On Fri, Feb 24, 2017 at 02:29:14PM +1100, Alexey Kardashevskiy wrote:
> On 24/02/17 13:14, David Gibson wrote:
> > On Wed, Feb 22, 2017 at 07:21:33PM +1100, Alexey Kardashevskiy wrote:
> >> This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
> >> and H_STUFF_TCE requests targeted an IOMMU TCE table used for VFIO
> >> without passing them to user space which saves time on switching
> >> to user space and back.
> >>
> >> This adds H_PUT_TCE/H_PUT_TCE_INDIRECT/H_STUFF_TCE handlers to KVM.
> >> KVM tries to handle a TCE request in the real mode, if failed
> >> it passes the request to the virtual mode to complete the operation.
> >> If it a virtual mode handler fails, the request is passed to
> >> the user space; this is not expected to happen though.
> >>
> >> To avoid dealing with page use counters (which is tricky in real mode),
> >> this only accelerates SPAPR TCE IOMMU v2 clients which are required
> >> to pre-register the userspace memory. The very first TCE request will
> >> be handled in the VFIO SPAPR TCE driver anyway as the userspace view
> >> of the TCE table (iommu_table::it_userspace) is not allocated till
> >> the very first mapping happens and we cannot call vmalloc in real mode.
> >>
> >> If we fail to update a hardware IOMMU table unexpected reason, we just
> >> clear it and move on as there is nothing really we can do about it -
> >> for example, if we hot plug a VFIO device to a guest, existing TCE tables
> >> will be mirrored automatically to the hardware and there is no interface
> >> to report to the guest about possible failures.
> >>
> >> This adds new attribute - KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE - to
> >> the VFIO KVM device. It takes a VFIO group fd and SPAPR TCE table fd
> >> and associates a physical IOMMU table with the SPAPR TCE table (which
> >> is a guest view of the hardware IOMMU table). The iommu_table object
> >> is cached and referenced so we do not have to look up for it in real mode.
> >>
> >> This does not implement the UNSET counterpart as there is no use for it -
> >> once the acceleration is enabled, the existing userspace won't
> >> disable it unless a VFIO container is destroyed; this adds necessary
> >> cleanup to the KVM_DEV_VFIO_GROUP_DEL handler.
> >>
> >> As this creates a descriptor per IOMMU table-LIOBN couple (called
> >> kvmppc_spapr_tce_iommu_table), it is possible to have several
> >> descriptors with the same iommu_table (hardware IOMMU table) attached
> >> to the same LIOBN; we do not remove duplicates though as
> >> iommu_table_ops::exchange not just update a TCE entry (which is
> >> shared among IOMMU groups) but also invalidates the TCE cache
> >> (one per IOMMU group).
> >>
> >> This advertises the new KVM_CAP_SPAPR_TCE_VFIO capability to the user
> >> space.
> >>
> >> This finally makes use of vfio_external_user_iommu_id() which was
> >> introduced quite some time ago and was considered for removal.
> >>
> >> Tests show that this patch increases transmission speed from 220MB/s
> >> to 750..1020MB/s on 10Gb network (Chelsea CXGB3 10Gb ethernet card).
> >>
> >> Signed-off-by: Alexey Kardashevskiy 
> > 
> > I have some comments on this patch, but all the definite ones are
> > pretty minor and could be done as later cleanups.
> > 
> > I have some more serious queries, but they are just queries and
> > requests for clarification.  If there are satisfactory answers to
> > them, I'll add my R-b.
> > 
> > 
> > ---
> >> Changes:
> >> v5:
> >> * changed error codes in multiple places
> >> * added bunch of WARN_ON() in places which should not really happen
> >> * adde a check that an iommu table is not attached already to LIOBN
> >> * dropped explicit calls to iommu_tce_clear_param_check/
> >> iommu_tce_put_param_check as kvmppc_tce_validate/kvmppc_ioba_validate
> >> call them anyway (since the previous patch)
> >> * if we fail to update a hardware IOMMU table for unexpected reason,
> >> this just clears the entry
> >>
> >> v4:
> >> * added note to the commit log about allowing multiple updates of
> >> the same IOMMU table;
> >> * instead of checking for if any memory was preregistered, this
> >> returns H_TOO_HARD if a specific page was not;
> >> * fixed comments from v3 about error handling in many places;
> >> * simplified TCE handlers and merged IOMMU parts inline - for example,
> >> there used to be kvmppc_h_put_tce_iommu(), now it is merged into
> >> kvmppc_h_put_tce(); this allows to check IOBA boundaries against
> >> the first attached table only (makes the code simpler);
> >>
> >> v3:
> >> * simplified not to use VFIO group notifiers
> >> * reworked cleanup, should be cleaner/simpler now
> >>
> >> v2:
> >> * reworked to use new VFIO notifiers
> >> * now same iommu_table may appear in the list several times, to be fixed 
> >> later
> >> ---
> >>  Documentation/virtual/kvm/devices/vfio.txt |  22 ++-
> >>  arch/powerpc/include/asm/kvm_host.h|   8 +
> >>  arch/powerpc/include/asm/kvm_ppc.h |   4 +
> >>  

Re: [PATCH kernel v5 10/10] KVM: PPC: VFIO: Add in-kernel acceleration for VFIO

[Alexey Kardashevskiy]

On 24/02/17 13:14, David Gibson wrote:
> On Wed, Feb 22, 2017 at 07:21:33PM +1100, Alexey Kardashevskiy wrote:
>> This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
>> and H_STUFF_TCE requests targeted an IOMMU TCE table used for VFIO
>> without passing them to user space which saves time on switching
>> to user space and back.
>>
>> This adds H_PUT_TCE/H_PUT_TCE_INDIRECT/H_STUFF_TCE handlers to KVM.
>> KVM tries to handle a TCE request in the real mode, if failed
>> it passes the request to the virtual mode to complete the operation.
>> If it a virtual mode handler fails, the request is passed to
>> the user space; this is not expected to happen though.
>>
>> To avoid dealing with page use counters (which is tricky in real mode),
>> this only accelerates SPAPR TCE IOMMU v2 clients which are required
>> to pre-register the userspace memory. The very first TCE request will
>> be handled in the VFIO SPAPR TCE driver anyway as the userspace view
>> of the TCE table (iommu_table::it_userspace) is not allocated till
>> the very first mapping happens and we cannot call vmalloc in real mode.
>>
>> If we fail to update a hardware IOMMU table unexpected reason, we just
>> clear it and move on as there is nothing really we can do about it -
>> for example, if we hot plug a VFIO device to a guest, existing TCE tables
>> will be mirrored automatically to the hardware and there is no interface
>> to report to the guest about possible failures.
>>
>> This adds new attribute - KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE - to
>> the VFIO KVM device. It takes a VFIO group fd and SPAPR TCE table fd
>> and associates a physical IOMMU table with the SPAPR TCE table (which
>> is a guest view of the hardware IOMMU table). The iommu_table object
>> is cached and referenced so we do not have to look up for it in real mode.
>>
>> This does not implement the UNSET counterpart as there is no use for it -
>> once the acceleration is enabled, the existing userspace won't
>> disable it unless a VFIO container is destroyed; this adds necessary
>> cleanup to the KVM_DEV_VFIO_GROUP_DEL handler.
>>
>> As this creates a descriptor per IOMMU table-LIOBN couple (called
>> kvmppc_spapr_tce_iommu_table), it is possible to have several
>> descriptors with the same iommu_table (hardware IOMMU table) attached
>> to the same LIOBN; we do not remove duplicates though as
>> iommu_table_ops::exchange not just update a TCE entry (which is
>> shared among IOMMU groups) but also invalidates the TCE cache
>> (one per IOMMU group).
>>
>> This advertises the new KVM_CAP_SPAPR_TCE_VFIO capability to the user
>> space.
>>
>> This finally makes use of vfio_external_user_iommu_id() which was
>> introduced quite some time ago and was considered for removal.
>>
>> Tests show that this patch increases transmission speed from 220MB/s
>> to 750..1020MB/s on 10Gb network (Chelsea CXGB3 10Gb ethernet card).
>>
>> Signed-off-by: Alexey Kardashevskiy 
> 
> I have some comments on this patch, but all the definite ones are
> pretty minor and could be done as later cleanups.
> 
> I have some more serious queries, but they are just queries and
> requests for clarification.  If there are satisfactory answers to
> them, I'll add my R-b.
> 
> 
> ---
>> Changes:
>> v5:
>> * changed error codes in multiple places
>> * added bunch of WARN_ON() in places which should not really happen
>> * adde a check that an iommu table is not attached already to LIOBN
>> * dropped explicit calls to iommu_tce_clear_param_check/
>> iommu_tce_put_param_check as kvmppc_tce_validate/kvmppc_ioba_validate
>> call them anyway (since the previous patch)
>> * if we fail to update a hardware IOMMU table for unexpected reason,
>> this just clears the entry
>>
>> v4:
>> * added note to the commit log about allowing multiple updates of
>> the same IOMMU table;
>> * instead of checking for if any memory was preregistered, this
>> returns H_TOO_HARD if a specific page was not;
>> * fixed comments from v3 about error handling in many places;
>> * simplified TCE handlers and merged IOMMU parts inline - for example,
>> there used to be kvmppc_h_put_tce_iommu(), now it is merged into
>> kvmppc_h_put_tce(); this allows to check IOBA boundaries against
>> the first attached table only (makes the code simpler);
>>
>> v3:
>> * simplified not to use VFIO group notifiers
>> * reworked cleanup, should be cleaner/simpler now
>>
>> v2:
>> * reworked to use new VFIO notifiers
>> * now same iommu_table may appear in the list several times, to be fixed 
>> later
>> ---
>>  Documentation/virtual/kvm/devices/vfio.txt |  22 ++-
>>  arch/powerpc/include/asm/kvm_host.h|   8 +
>>  arch/powerpc/include/asm/kvm_ppc.h |   4 +
>>  include/uapi/linux/kvm.h   |   8 +
>>  arch/powerpc/kvm/book3s_64_vio.c   | 307 
>> -
>>  arch/powerpc/kvm/book3s_64_vio_hv.c| 152 +-
>>  arch/powerpc/kvm/powerpc.c |   2 +
>>  

Re: [PATCH kernel v5 10/10] KVM: PPC: VFIO: Add in-kernel acceleration for VFIO

[David Gibson]

On Wed, Feb 22, 2017 at 07:21:33PM +1100, Alexey Kardashevskiy wrote:
> This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
> and H_STUFF_TCE requests targeted an IOMMU TCE table used for VFIO
> without passing them to user space which saves time on switching
> to user space and back.
> 
> This adds H_PUT_TCE/H_PUT_TCE_INDIRECT/H_STUFF_TCE handlers to KVM.
> KVM tries to handle a TCE request in the real mode, if failed
> it passes the request to the virtual mode to complete the operation.
> If it a virtual mode handler fails, the request is passed to
> the user space; this is not expected to happen though.
> 
> To avoid dealing with page use counters (which is tricky in real mode),
> this only accelerates SPAPR TCE IOMMU v2 clients which are required
> to pre-register the userspace memory. The very first TCE request will
> be handled in the VFIO SPAPR TCE driver anyway as the userspace view
> of the TCE table (iommu_table::it_userspace) is not allocated till
> the very first mapping happens and we cannot call vmalloc in real mode.
> 
> If we fail to update a hardware IOMMU table unexpected reason, we just
> clear it and move on as there is nothing really we can do about it -
> for example, if we hot plug a VFIO device to a guest, existing TCE tables
> will be mirrored automatically to the hardware and there is no interface
> to report to the guest about possible failures.
> 
> This adds new attribute - KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE - to
> the VFIO KVM device. It takes a VFIO group fd and SPAPR TCE table fd
> and associates a physical IOMMU table with the SPAPR TCE table (which
> is a guest view of the hardware IOMMU table). The iommu_table object
> is cached and referenced so we do not have to look up for it in real mode.
> 
> This does not implement the UNSET counterpart as there is no use for it -
> once the acceleration is enabled, the existing userspace won't
> disable it unless a VFIO container is destroyed; this adds necessary
> cleanup to the KVM_DEV_VFIO_GROUP_DEL handler.
> 
> As this creates a descriptor per IOMMU table-LIOBN couple (called
> kvmppc_spapr_tce_iommu_table), it is possible to have several
> descriptors with the same iommu_table (hardware IOMMU table) attached
> to the same LIOBN; we do not remove duplicates though as
> iommu_table_ops::exchange not just update a TCE entry (which is
> shared among IOMMU groups) but also invalidates the TCE cache
> (one per IOMMU group).
> 
> This advertises the new KVM_CAP_SPAPR_TCE_VFIO capability to the user
> space.
> 
> This finally makes use of vfio_external_user_iommu_id() which was
> introduced quite some time ago and was considered for removal.
> 
> Tests show that this patch increases transmission speed from 220MB/s
> to 750..1020MB/s on 10Gb network (Chelsea CXGB3 10Gb ethernet card).
> 
> Signed-off-by: Alexey Kardashevskiy 

I have some comments on this patch, but all the definite ones are
pretty minor and could be done as later cleanups.

I have some more serious queries, but they are just queries and
requests for clarification.  If there are satisfactory answers to
them, I'll add my R-b.


---
> Changes:
> v5:
> * changed error codes in multiple places
> * added bunch of WARN_ON() in places which should not really happen
> * adde a check that an iommu table is not attached already to LIOBN
> * dropped explicit calls to iommu_tce_clear_param_check/
> iommu_tce_put_param_check as kvmppc_tce_validate/kvmppc_ioba_validate
> call them anyway (since the previous patch)
> * if we fail to update a hardware IOMMU table for unexpected reason,
> this just clears the entry
> 
> v4:
> * added note to the commit log about allowing multiple updates of
> the same IOMMU table;
> * instead of checking for if any memory was preregistered, this
> returns H_TOO_HARD if a specific page was not;
> * fixed comments from v3 about error handling in many places;
> * simplified TCE handlers and merged IOMMU parts inline - for example,
> there used to be kvmppc_h_put_tce_iommu(), now it is merged into
> kvmppc_h_put_tce(); this allows to check IOBA boundaries against
> the first attached table only (makes the code simpler);
> 
> v3:
> * simplified not to use VFIO group notifiers
> * reworked cleanup, should be cleaner/simpler now
> 
> v2:
> * reworked to use new VFIO notifiers
> * now same iommu_table may appear in the list several times, to be fixed later
> ---
>  Documentation/virtual/kvm/devices/vfio.txt |  22 ++-
>  arch/powerpc/include/asm/kvm_host.h|   8 +
>  arch/powerpc/include/asm/kvm_ppc.h |   4 +
>  include/uapi/linux/kvm.h   |   8 +
>  arch/powerpc/kvm/book3s_64_vio.c   | 307 
> -
>  arch/powerpc/kvm/book3s_64_vio_hv.c| 152 +-
>  arch/powerpc/kvm/powerpc.c |   2 +
>  virt/kvm/vfio.c|  60 ++
>  8 files changed, 555 insertions(+), 8 deletions(-)
> 
> diff --git