| Message ID | 1439428546-13416-1-git-send-email-david@gibson.dropbear.id.au (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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> Paul is going to take care of the kvm-ppc tree for 4.3. Also, ppc kvm patches should get CC on the kvm-ppc@vger mailing list ;). Paul, could you please pick this one up? Thanks! Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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> > > Paul is going to take care of the kvm-ppc tree for 4.3. Also, ppc kvm > patches should get CC on the kvm-ppc@vger mailing list ;). > > Paul, could you please pick this one up? Sure, I'll do that once I get home (end of this week). Paul. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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> >> >> Paul is going to take care of the kvm-ppc tree for 4.3. Also, ppc kvm >> patches should get CC on the kvm-ppc@vger mailing list ;). >> >> Paul, could you please pick this one up? > > Sure, I'll do that once I get home (end of this week). This was not in the 4.3 pull request, but I think we can apply it after the end of the merge window. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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/
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.
diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile index 0570eef..7f7b6d8 100644 --- a/arch/powerpc/kvm/Makefile +++ b/arch/powerpc/kvm/Makefile @@ -8,7 +8,7 @@ ccflags-y := -Ivirt/kvm -Iarch/powerpc/kvm KVM := ../../../virt/kvm common-objs-y = $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o \ - $(KVM)/eventfd.o + $(KVM)/eventfd.o $(KVM)/vfio.o CFLAGS_e500_mmu.o := -I. CFLAGS_e500_mmu_host.o := -I.