Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1460492 > unrolled thread

Re: [PATCH] vfio: Enable VFIO device for powerpc

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] vfio: Enable VFIO device for powerpc Paolo Bonzini <pbonzini@redhat.com> - 2016-08-11 15:00 +0200
    Re: [PATCH] vfio: Enable VFIO device for powerpc Cornelia Huck <cornelia.huck@de.ibm.com> - 2016-08-11 15:30 +0200
      Re: [PATCH] vfio: Enable VFIO device for powerpc Alexey Kardashevskiy <aik@ozlabs.ru> - 2016-08-11 16:10 +0200
      Re: [PATCH] vfio: Enable VFIO device for powerpc David Gibson <david@gibson.dropbear.id.au> - 2016-08-12 09:00 +0200

#1460492 — Re: [PATCH] vfio: Enable VFIO device for powerpc

On 26/08/2015 20:54, Paul Mackerras wrote:
> On Wed, Aug 26, 2015 at 11:34:26AM +0200, Alexander Graf wrote:
>> On 13.08.15 03:15, David Gibson wrote:
>>> ec53500f "kvm: Add VFIO device" added a special KVM pseudo-device which is
>>> used to handle any necessary interactions between KVM and VFIO.
>>>
>>> Currently that device is built on x86 and ARM, but not powerpc, although
>>> powerpc does support both KVM and VFIO.  This makes things awkward in
>>> userspace
>>>
>>> Currently qemu prints an alarming error message if you attempt to use VFIO
>>> and it can't initialize the KVM VFIO device.  We don't want to remove the
>>> warning, because lack of the KVM VFIO device could mean coherency problems
>>> on x86.  On powerpc, however, the error is harmless but looks disturbing,
>>> and a test based on host architecture in qemu would be ugly, and break if
>>> we do need the KVM VFIO device for something important in future.
>>>
>>> There's nothing preventing the KVM VFIO device from being built for
>>> powerpc, so this patch turns it on.  It won't actually do anything, since
>>> we don't define any of the arch_*() hooks, but it will make qemu happy and
>>> we can extend it in future if we need to.
>>>
>>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>>> Reviewed-by: Eric Auger <eric.auger@linaro.org>

This patch (commit 178a787502123) did not select CONFIG_KVM_VFIO, so the
patch did nothing---except causing build failures which I fixed in
commit 0af574be32cdd ("KVM: PPC: do not compile in vfio.o
unconditionally", 2016-03-21) by making the patch a total no-op.

Is KVM_VFIO really needed, and if so can this patch be fixed?

Thanks,

Paolo

[toc] | [next] | [standalone]

#1460515

On Thu, 11 Aug 2016 14:57:24 +0200
Paolo Bonzini <pbonzini@redhat.com> wrote:

> On 26/08/2015 20:54, Paul Mackerras wrote:
> > On Wed, Aug 26, 2015 at 11:34:26AM +0200, Alexander Graf wrote:
> >> On 13.08.15 03:15, David Gibson wrote:
> >>> ec53500f "kvm: Add VFIO device" added a special KVM pseudo-device which is
> >>> used to handle any necessary interactions between KVM and VFIO.
> >>>
> >>> Currently that device is built on x86 and ARM, but not powerpc, although
> >>> powerpc does support both KVM and VFIO.  This makes things awkward in
> >>> userspace
> >>>
> >>> Currently qemu prints an alarming error message if you attempt to use VFIO
> >>> and it can't initialize the KVM VFIO device.  We don't want to remove the
> >>> warning, because lack of the KVM VFIO device could mean coherency problems
> >>> on x86.  On powerpc, however, the error is harmless but looks disturbing,
> >>> and a test based on host architecture in qemu would be ugly, and break if
> >>> we do need the KVM VFIO device for something important in future.
> >>>
> >>> There's nothing preventing the KVM VFIO device from being built for
> >>> powerpc, so this patch turns it on.  It won't actually do anything, since
> >>> we don't define any of the arch_*() hooks, but it will make qemu happy and
> >>> we can extend it in future if we need to.
> >>>
> >>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> >>> Reviewed-by: Eric Auger <eric.auger@linaro.org>
> 
> This patch (commit 178a787502123) did not select CONFIG_KVM_VFIO, so the
> patch did nothing---except causing build failures which I fixed in
> commit 0af574be32cdd ("KVM: PPC: do not compile in vfio.o
> unconditionally", 2016-03-21) by making the patch a total no-op.
> 
> Is KVM_VFIO really needed, and if so can this patch be fixed?

FWIW, we enabled building vfio.o on s390 in 14b0b4a ("KVM: s390: Enable
the KVM-VFIO device") with the rationale "while we don't need it, be
like everybody else".

Should powerpc (and every other architecture supporting kvm and vfio)
select KVM_VFIO so that really everybody does the same thing?

[toc] | [prev] | [next] | [standalone]

#1460541

On 11/08/16 23:19, Cornelia Huck wrote:
> On Thu, 11 Aug 2016 14:57:24 +0200
> Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
>> On 26/08/2015 20:54, Paul Mackerras wrote:
>>> On Wed, Aug 26, 2015 at 11:34:26AM +0200, Alexander Graf wrote:
>>>> On 13.08.15 03:15, David Gibson wrote:
>>>>> ec53500f "kvm: Add VFIO device" added a special KVM pseudo-device which is
>>>>> used to handle any necessary interactions between KVM and VFIO.
>>>>>
>>>>> Currently that device is built on x86 and ARM, but not powerpc, although
>>>>> powerpc does support both KVM and VFIO.  This makes things awkward in
>>>>> userspace
>>>>>
>>>>> Currently qemu prints an alarming error message if you attempt to use VFIO
>>>>> and it can't initialize the KVM VFIO device.  We don't want to remove the
>>>>> warning, because lack of the KVM VFIO device could mean coherency problems
>>>>> on x86.  On powerpc, however, the error is harmless but looks disturbing,
>>>>> and a test based on host architecture in qemu would be ugly, and break if
>>>>> we do need the KVM VFIO device for something important in future.
>>>>>
>>>>> There's nothing preventing the KVM VFIO device from being built for
>>>>> powerpc, so this patch turns it on.  It won't actually do anything, since
>>>>> we don't define any of the arch_*() hooks, but it will make qemu happy and
>>>>> we can extend it in future if we need to.
>>>>>
>>>>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>>>>> Reviewed-by: Eric Auger <eric.auger@linaro.org>
>>
>> This patch (commit 178a787502123) did not select CONFIG_KVM_VFIO, so the
>> patch did nothing---except causing build failures which I fixed in
>> commit 0af574be32cdd ("KVM: PPC: do not compile in vfio.o
>> unconditionally", 2016-03-21) by making the patch a total no-op.
>>
>> Is KVM_VFIO really needed, and if so can this patch be fixed?
> 
> FWIW, we enabled building vfio.o on s390 in 14b0b4a ("KVM: s390: Enable
> the KVM-VFIO device") with the rationale "while we don't need it, be
> like everybody else".
> 
> Should powerpc (and every other architecture supporting kvm and vfio)
> select KVM_VFIO so that really everybody does the same thing?
> 

I recently posted one for ppc64/book3s:
https://patchwork.ozlabs.org/patch/655305/




-- 
Alexey

[toc] | [prev] | [next] | [standalone]

#1460974

[Multipart message — attachments visible in raw view] — view raw

On Thu, Aug 11, 2016 at 03:19:57PM +0200, Cornelia Huck wrote:
> On Thu, 11 Aug 2016 14:57:24 +0200
> Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> > On 26/08/2015 20:54, Paul Mackerras wrote:
> > > On Wed, Aug 26, 2015 at 11:34:26AM +0200, Alexander Graf wrote:
> > >> On 13.08.15 03:15, David Gibson wrote:
> > >>> ec53500f "kvm: Add VFIO device" added a special KVM pseudo-device which is
> > >>> used to handle any necessary interactions between KVM and VFIO.
> > >>>
> > >>> Currently that device is built on x86 and ARM, but not powerpc, although
> > >>> powerpc does support both KVM and VFIO.  This makes things awkward in
> > >>> userspace
> > >>>
> > >>> Currently qemu prints an alarming error message if you attempt to use VFIO
> > >>> and it can't initialize the KVM VFIO device.  We don't want to remove the
> > >>> warning, because lack of the KVM VFIO device could mean coherency problems
> > >>> on x86.  On powerpc, however, the error is harmless but looks disturbing,
> > >>> and a test based on host architecture in qemu would be ugly, and break if
> > >>> we do need the KVM VFIO device for something important in future.
> > >>>
> > >>> There's nothing preventing the KVM VFIO device from being built for
> > >>> powerpc, so this patch turns it on.  It won't actually do anything, since
> > >>> we don't define any of the arch_*() hooks, but it will make qemu happy and
> > >>> we can extend it in future if we need to.
> > >>>
> > >>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > >>> Reviewed-by: Eric Auger <eric.auger@linaro.org>
> > 
> > This patch (commit 178a787502123) did not select CONFIG_KVM_VFIO, so the
> > patch did nothing---except causing build failures which I fixed in
> > commit 0af574be32cdd ("KVM: PPC: do not compile in vfio.o
> > unconditionally", 2016-03-21) by making the patch a total no-op.
> > 
> > Is KVM_VFIO really needed, and if so can this patch be fixed?
> 
> FWIW, we enabled building vfio.o on s390 in 14b0b4a ("KVM: s390: Enable
> the KVM-VFIO device") with the rationale "while we don't need it, be
> like everybody else".
> 
> Should powerpc (and every other architecture supporting kvm and vfio)
> select KVM_VFIO so that really everybody does the same thing?

Yes, I think it should.  That was my intention when I sent that patch
- I just messed it up.

-- 
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_!
http://www.ozlabs.org/~dgibson

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web