Message ID | 20230316031732.3591455-1-npiggin@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | KVM: PPC: support kvm selftests | expand |
Nicholas Piggin <npiggin@gmail.com> writes: > Hi, > > This series adds initial KVM selftests support for powerpc > (64-bit, BookS). Awesome. > It spans 3 maintainers but it does not really > affect arch/powerpc, and it is well contained in selftests > code, just touches some makefiles and a tiny bit headers so > conflicts should be unlikely and trivial. > > I guess Paolo is the best point to merge these, if no comments > or objections? Yeah. If it helps: Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) cheers
On Thu, Mar 16, 2023, Michael Ellerman wrote: > Nicholas Piggin <npiggin@gmail.com> writes: > > Hi, > > > > This series adds initial KVM selftests support for powerpc > > (64-bit, BookS). > > Awesome. > > > It spans 3 maintainers but it does not really > > affect arch/powerpc, and it is well contained in selftests > > code, just touches some makefiles and a tiny bit headers so > > conflicts should be unlikely and trivial. > > > > I guess Paolo is the best point to merge these, if no comments > > or objections? > > Yeah. If it helps: > > Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) What is the long term plan for KVM PPC maintenance? I was under the impression that KVM PPC was trending toward "bug fixes only", but the addition of selftests support suggests otherwise. I ask primarily because routing KVM PPC patches through the PPC tree is going to be problematic if KVM PPC sees signficiant development. The current situation is ok because the volume of patches is low and KVM PPC isn't trying to drive anything substantial into common KVM code, but if that changes... My other concern is that for selftests specifically, us KVM folks are taking on more maintenance burden by supporting PPC. AFAIK, none of the people that focus on KVM selftests in any meaningful capacity have access to PPC hardware, let alone know enough about the architecture to make intelligent code changes. Don't get me wrong, I'm very much in favor of more testing, I just don't want KVM to get left holding the bag.
On Thu Mar 23, 2023 at 3:41 AM AEST, Sean Christopherson wrote: > On Thu, Mar 16, 2023, Michael Ellerman wrote: > > Nicholas Piggin <npiggin@gmail.com> writes: > > > Hi, > > > > > > This series adds initial KVM selftests support for powerpc > > > (64-bit, BookS). > > > > Awesome. > > > > > It spans 3 maintainers but it does not really > > > affect arch/powerpc, and it is well contained in selftests > > > code, just touches some makefiles and a tiny bit headers so > > > conflicts should be unlikely and trivial. > > > > > > I guess Paolo is the best point to merge these, if no comments > > > or objections? > > > > Yeah. If it helps: > > > > Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) > > What is the long term plan for KVM PPC maintenance? I was under the impression > that KVM PPC was trending toward "bug fixes only", but the addition of selftests > support suggests otherwise. We plan to continue maintaining it. New support and features has been a bit low in the past couple of years, hopefully that will pick up a bit though. > I ask primarily because routing KVM PPC patches through the PPC tree is going to > be problematic if KVM PPC sees signficiant development. The current situation is > ok because the volume of patches is low and KVM PPC isn't trying to drive anything > substantial into common KVM code, but if that changes... Michael has done KVM topic branches to pull from a few times when such conflicts came up (at smaller scale). If we end up with larger changes or regular conflicts we might start up a kvm-ppc tree again I guess. > My other concern is that for selftests specifically, us KVM folks are taking on > more maintenance burden by supporting PPC. AFAIK, none of the people that focus > on KVM selftests in any meaningful capacity have access to PPC hardware, let alone > know enough about the architecture to make intelligent code changes. > > Don't get me wrong, I'm very much in favor of more testing, I just don't want KVM > to get left holding the bag. Understood. I'll be happy to maintain powerpc part of kvm selftests and do any fixes that are needed for core code changes.If support fell away you could leave it broken (or rm -rf it if you prefer) -- I wouldn't ask anybody to work on archs they don't know or aren't paid to. Not sure if anything more can be done to help your process or ease your mind. It (KVM and kvm-selftests) can run in QEMU at least. Thanks, Nick
On Mon, Mar 27, 2023, Nicholas Piggin wrote: > On Thu Mar 23, 2023 at 3:41 AM AEST, Sean Christopherson wrote: > > On Thu, Mar 16, 2023, Michael Ellerman wrote: > > > Nicholas Piggin <npiggin@gmail.com> writes: > > > > Hi, > > > > > > > > This series adds initial KVM selftests support for powerpc > > > > (64-bit, BookS). > > > > > > Awesome. > > > > > > > It spans 3 maintainers but it does not really > > > > affect arch/powerpc, and it is well contained in selftests > > > > code, just touches some makefiles and a tiny bit headers so > > > > conflicts should be unlikely and trivial. > > > > > > > > I guess Paolo is the best point to merge these, if no comments > > > > or objections? > > > > > > Yeah. If it helps: > > > > > > Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) > > > > What is the long term plan for KVM PPC maintenance? I was under the impression > > that KVM PPC was trending toward "bug fixes only", but the addition of selftests > > support suggests otherwise. > > We plan to continue maintaining it. New support and features has been a > bit low in the past couple of years, hopefully that will pick up a bit > though. Partly out of curiosity, but also to get a general feel for what types of changes we might see, what are the main use cases for KVM PPC these days? E.g. is it mainly a vehicle for developing and testing, hosting VMs in the cloud, something else? > > I ask primarily because routing KVM PPC patches through the PPC tree is going to > > be problematic if KVM PPC sees signficiant development. The current situation is > > ok because the volume of patches is low and KVM PPC isn't trying to drive anything > > substantial into common KVM code, but if that changes... > > Michael has done KVM topic branches to pull from a few times when such > conflicts came up (at smaller scale). If we end up with larger changes > or regular conflicts we might start up a kvm-ppc tree again I guess. A wait-and-see approach works for me. I don't have any complaints with the current process, I was just caught off guard. > > My other concern is that for selftests specifically, us KVM folks are taking on > > more maintenance burden by supporting PPC. AFAIK, none of the people that focus > > on KVM selftests in any meaningful capacity have access to PPC hardware, let alone > > know enough about the architecture to make intelligent code changes. > > > > Don't get me wrong, I'm very much in favor of more testing, I just don't want KVM > > to get left holding the bag. > > Understood. I'll be happy to maintain powerpc part of kvm selftests and > do any fixes that are needed for core code changes.If support fell away > you could leave it broken (or rm -rf it if you prefer) -- I wouldn't ask > anybody to work on archs they don't know or aren't paid to. > > Not sure if anything more can be done to help your process or ease your > mind. It (KVM and kvm-selftests) can run in QEMU at least. Updating the KVM/powerpc to include selftests would be very helpful, e.g F: tools/testing/selftests/kvm/*/powerpc/ F: tools/testing/selftests/kvm/powerpc/ and ideally there would be one or more M: (and R:) entries as well. I'm not all that concerned about the selftests support being abandoned, but the lack of specific contacts makes it look like KVM PPC is in maintenance-only mode, and it sounds like that's not the case. Thanks!
On Tue Mar 28, 2023 at 3:43 AM AEST, Sean Christopherson wrote: > On Mon, Mar 27, 2023, Nicholas Piggin wrote: > > On Thu Mar 23, 2023 at 3:41 AM AEST, Sean Christopherson wrote: > > > On Thu, Mar 16, 2023, Michael Ellerman wrote: > > > > Nicholas Piggin <npiggin@gmail.com> writes: > > > > > Hi, > > > > > > > > > > This series adds initial KVM selftests support for powerpc > > > > > (64-bit, BookS). > > > > > > > > Awesome. > > > > > > > > > It spans 3 maintainers but it does not really > > > > > affect arch/powerpc, and it is well contained in selftests > > > > > code, just touches some makefiles and a tiny bit headers so > > > > > conflicts should be unlikely and trivial. > > > > > > > > > > I guess Paolo is the best point to merge these, if no comments > > > > > or objections? > > > > > > > > Yeah. If it helps: > > > > > > > > Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) > > > > > > What is the long term plan for KVM PPC maintenance? I was under the impression > > > that KVM PPC was trending toward "bug fixes only", but the addition of selftests > > > support suggests otherwise. > > > > We plan to continue maintaining it. New support and features has been a > > bit low in the past couple of years, hopefully that will pick up a bit > > though. > > Partly out of curiosity, but also to get a general feel for what types of changes > we might see, what are the main use cases for KVM PPC these days? E.g. is it mainly > a vehicle for developing and testing, hosting VMs in the cloud, something else? I didn't have too much specific in mind, just generally a bit more development activity. As for use cases, I think broadly KVM is increasingly seen as a Linux feature and expected to be there, even in so-called enterprise world. For software and workflows designed around Linux virt, it can be difficult or impossible to substitue the proprietary partitioning layer in our firmware. So there is always someone who wants KVM for something. It could be all of the above, and even just as a traditional hypervisor hosting VMs in-house, there are people who would like to use KVM. > > > > I ask primarily because routing KVM PPC patches through the PPC tree is going to > > > be problematic if KVM PPC sees signficiant development. The current situation is > > > ok because the volume of patches is low and KVM PPC isn't trying to drive anything > > > substantial into common KVM code, but if that changes... > > > > Michael has done KVM topic branches to pull from a few times when such > > conflicts came up (at smaller scale). If we end up with larger changes > > or regular conflicts we might start up a kvm-ppc tree again I guess. > > A wait-and-see approach works for me. I don't have any complaints with the current > process, I was just caught off guard. Okay. Complaints and suggestions to improve the process are always welcome, so if something could be done better, feel free to ping the list or powerpc maintainers offline. > > > My other concern is that for selftests specifically, us KVM folks are taking on > > > more maintenance burden by supporting PPC. AFAIK, none of the people that focus > > > on KVM selftests in any meaningful capacity have access to PPC hardware, let alone > > > know enough about the architecture to make intelligent code changes. > > > > > > Don't get me wrong, I'm very much in favor of more testing, I just don't want KVM > > > to get left holding the bag. > > > > Understood. I'll be happy to maintain powerpc part of kvm selftests and > > do any fixes that are needed for core code changes.If support fell away > > you could leave it broken (or rm -rf it if you prefer) -- I wouldn't ask > > anybody to work on archs they don't know or aren't paid to. > > > > Not sure if anything more can be done to help your process or ease your > > mind. It (KVM and kvm-selftests) can run in QEMU at least. > > Updating the KVM/powerpc to include selftests would be very helpful, e.g > > F: tools/testing/selftests/kvm/*/powerpc/ > F: tools/testing/selftests/kvm/powerpc/ Oh good point, I should have included that. I'll send a patch. > and ideally there would be one or more M: (and R:) entries as well. I'm not > all that concerned about the selftests support being abandoned, but the lack of > specific contacts makes it look like KVM PPC is in maintenance-only mode, and it > sounds like that's not the case. Yeah, I guess the intention was to bring it a bit more under general arch/powerpc maintainership but it does look a bit odd having a top level entry and no contacts. We'll reconsider what to do with that. Thanks, Nick
"Nicholas Piggin" <npiggin@gmail.com> writes: > On Tue Mar 28, 2023 at 3:43 AM AEST, Sean Christopherson wrote: >> On Mon, Mar 27, 2023, Nicholas Piggin wrote: >> > On Thu Mar 23, 2023 at 3:41 AM AEST, Sean Christopherson wrote: ... >> > > >> > > What is the long term plan for KVM PPC maintenance? I was under the impression >> > > that KVM PPC was trending toward "bug fixes only", but the addition of selftests >> > > support suggests otherwise. ... > >> and ideally there would be one or more M: (and R:) entries as well. I'm not >> all that concerned about the selftests support being abandoned, but the lack of >> specific contacts makes it look like KVM PPC is in maintenance-only mode, and it >> sounds like that's not the case. > > Yeah, I guess the intention was to bring it a bit more under general > arch/powerpc maintainership but it does look a bit odd having a top > level entry and no contacts. We'll reconsider what to do with that. Yeah I agree it ends up looking a bit weird. The intention was just to make it clear that Paul's tree was no longer where patches were being handled, and that they'd be handled as regular powerpc patches. At the time I hoped we'd relatively quickly be able to add someone as at least a KVM "R:"eviewer, but circumstances intervened. Hopefully we can fix that soon. cheers