* arch/riscv/staging @ 2021-05-21 2:05 Damien Le Moal 2021-05-21 2:08 ` arch/riscv/staging Damien Le Moal 0 siblings, 1 reply; 16+ messages in thread From: Damien Le Moal @ 2021-05-21 2:05 UTC (permalink / raw) To: linux-riscv, Palmer Dabbelt, Anup Patel, Paolo Bonzini Palmer, I hope you are doing well. It would be great if you could be more active on the list and share your views about the current situation regarding unreasonably-late specification freezing and kernel patch acceptance policy. For the hypervisor extension and KVM support, the specifications are now very stable and while changes due to the advanced interrupt controller specs work, among other, are still possible, the changes will likely be small and should not cause much headache in the kernel. Given that there is already HW (and QEMU) supporting H extension, we really need to move forward with merging riscv KVM support. That will reduce the risk of seeing forks pop out here and there and greatly facilitate Paolo and Anup work. For this, I propose that we create arch/riscv/staging as a temporary location for on-going work for supporting ISA extensions that are being drafted but not yet frozen. That will allow the community to share a common code base for the support code, and also allow more eyes to look at the extension themselves. This way we can both facilitate and accelerate riscv ecosystem development while also speeding up the specification work by providing constant feedback. If managing this staging ground is too much work for you, I am sure that Anup could handle it as a sub-maintainer. Thoughts ? Note: this needs a resolution ASAP. So please respond. Best regards. -- Damien Le Moal Western Digital Research _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 16+ messages in thread
* arch/riscv/staging 2021-05-21 2:05 arch/riscv/staging Damien Le Moal @ 2021-05-21 2:08 ` Damien Le Moal 2021-05-21 17:22 ` arch/riscv/staging Paul Walmsley 0 siblings, 1 reply; 16+ messages in thread From: Damien Le Moal @ 2021-05-21 2:08 UTC (permalink / raw) To: linux-riscv, Anup Patel, Paolo Bonzini, Palmer Dabbelt; +Cc: Palmer Dabbelt [resending, I used Palmer's old email address] Palmer, I hope you are doing well. It would be great if you could be more active on the list and share your views about the current situation regarding unreasonably-late specification freezing and kernel patch acceptance policy. For the hypervisor extension and KVM support, the specifications are now very stable and while changes due to the advanced interrupt controller specs work, among other, are still possible, the changes will likely be small and should not cause much headache in the kernel. Given that there is already HW (and QEMU) supporting H extension, we really need to move forward with merging riscv KVM support. That will reduce the risk of seeing forks pop out here and there and greatly facilitate Paolo and Anup work. For this, I propose that we create arch/riscv/staging as a temporary location for on-going work for supporting ISA extensions that are being drafted but not yet frozen. That will allow the community to share a common code base for the support code, and also allow more eyes to look at the extension themselves. This way we can both facilitate and accelerate riscv ecosystem development while also speeding up the specification work by providing constant feedback. If managing this staging ground is too much work for you, I am sure that Anup could handle it as a sub-maintainer. Thoughts ? Note: this needs a resolution ASAP. So please respond. Best regards. -- Damien Le Moal Western Digital Research _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: arch/riscv/staging 2021-05-21 2:08 ` arch/riscv/staging Damien Le Moal @ 2021-05-21 17:22 ` Paul Walmsley 2021-05-22 3:05 ` arch/riscv/staging Anup Patel 0 siblings, 1 reply; 16+ messages in thread From: Paul Walmsley @ 2021-05-21 17:22 UTC (permalink / raw) To: Damien Le Moal Cc: linux-riscv, Anup Patel, Paolo Bonzini, Palmer Dabbelt, Palmer Dabbelt Hi Damien, Thanks for the thoughtful and considered E-mail. I know you addressed this to Palmer, but maybe you'd be willing to discuss this a little bit with me? On Fri, 21 May 2021, Damien Le Moal wrote: > For the hypervisor extension and KVM support, the specifications are now very > stable and while changes due to the advanced interrupt controller specs work, > among other, are still possible, the changes will likely be small and should not > cause much headache in the kernel. This is the part that I don't quite understand. If everyone -- including the architecture folks working on the ISA extension at riscv.org -- agrees that the H extension isn't going to change significantly, why don't they freeze the extension? Could it be that the RVI folks are worried that they may need to make significant changes, and that's why they haven't frozen it yet? > Given that there is already HW (and QEMU) supporting H extension, we > really need to move forward with merging riscv KVM support. This is maybe a side question, but: has someone actually put the H extension into silicon? My understanding so far is that it's only been implemented into an experimental FPGA soft-core so far. > That will reduce the risk of seeing forks pop out here and there and > greatly facilitate Paolo and Anup work. When you write about forks, are you worried about architecture forks, forks of Anup's patchset, or some other kind of fork here? I ask because in the past, it sounds like there's been some concern from WDC that someone else will come along and submit an alternative RISC-V KVM patch set that we'd somehow prefer over Anup's. That's pretty unlikely; I think everyone involved -- certainly including Palmer and I -- know that you guys have done the foundational work here, and you guys would certainly have clear precedence here, unless there turned out to be something wrong with the WDC patchset that you all wouldn't be willing to fix. But maybe I'm misunderstanding your concern? > For this, I propose that we create arch/riscv/staging as a temporary location > for on-going work for supporting ISA extensions that are being drafted but not > yet frozen. That will allow the community to share a common code base for the > support code, and also allow more eyes to look at the extension themselves. > This way we can both facilitate and accelerate riscv ecosystem development while > also speeding up the specification work by providing constant feedback. If the goal is to create a common code base for testing and discussing draft extensions, we'd be happy to maintain another branch or another k.org tree to hold these. But in terms of the suggestion to create arch/riscv/staging, I think that's just going to create the same problems that the RISC-V patch acceptance guidelines were intended to solve. To put it differently, from my point of view, it's a feature, not a bug, that we don't send code for discussion drafts of ISA changes upstream to Linus. But maybe I'm misunderstanding what you're looking for ? regards, - Paul _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: arch/riscv/staging 2021-05-21 17:22 ` arch/riscv/staging Paul Walmsley @ 2021-05-22 3:05 ` Anup Patel 2021-05-28 1:06 ` arch/riscv/staging Paul Walmsley 0 siblings, 1 reply; 16+ messages in thread From: Anup Patel @ 2021-05-22 3:05 UTC (permalink / raw) To: Paul Walmsley Cc: Damien Le Moal, linux-riscv, Anup Patel, Paolo Bonzini, Palmer Dabbelt, Palmer Dabbelt, Greg Kroah-Hartman +GregKH On Fri, May 21, 2021 at 10:53 PM Paul Walmsley <paul.walmsley@sifive.com> wrote: > > Hi Damien, > > Thanks for the thoughtful and considered E-mail. I know you addressed > this to Palmer, but maybe you'd be willing to discuss this a little bit > with me? > > On Fri, 21 May 2021, Damien Le Moal wrote: > > > For the hypervisor extension and KVM support, the specifications are now very > > stable and while changes due to the advanced interrupt controller specs work, > > among other, are still possible, the changes will likely be small and should not > > cause much headache in the kernel. > > This is the part that I don't quite understand. If everyone -- including > the architecture folks working on the ISA extension at riscv.org -- agrees > that the H extension isn't going to change significantly, why don't they > freeze the extension? Could it be that the RVI folks are worried that > they may need to make significant changes, and that's why they haven't > frozen it yet? I have been involved in the H-extension spec development for the past few years working with RISC-V ISA architects (Andrew and John.) I am also involved in the RISC-V AIA specification as chair. I confirm that all required provisions are already there in the RISC-V H-extension to support an external interrupt controller with virtualization acceleration (such as RISC-V AIA). In fact, Paolo (with his years of experience in KVM virtualization) also confirmed that current H-extension have all required features. Clearly, significant changes are very very unlikely. > > > Given that there is already HW (and QEMU) supporting H extension, we > > really need to move forward with merging riscv KVM support. > > This is maybe a side question, but: has someone actually put the H > extension into silicon? My understanding so far is that it's only been > implemented into an experimental FPGA soft-core so far. > > > That will reduce the risk of seeing forks pop out here and there and > > greatly facilitate Paolo and Anup work. > > When you write about forks, are you worried about architecture forks, > forks of Anup's patchset, or some other kind of fork here? > > I ask because in the past, it sounds like there's been some concern from > WDC that someone else will come along and submit an alternative RISC-V KVM > patch set that we'd somehow prefer over Anup's. That's pretty > unlikely; I think everyone involved -- certainly including Palmer and I -- > know that you guys have done the foundational work here, and you guys > would certainly have clear precedence here, unless there turned out to be > something wrong with the WDC patchset that you all wouldn't be willing to > fix. But maybe I'm misunderstanding your concern? This is certainly your misunderstanding. Like Paolo mentioned in other thread, the current KVM RISC-V is in good shape and as-per expectations of the KVM core maintainer. > > > For this, I propose that we create arch/riscv/staging as a temporary location > > for on-going work for supporting ISA extensions that are being drafted but not > > yet frozen. That will allow the community to share a common code base for the > > support code, and also allow more eyes to look at the extension themselves. > > This way we can both facilitate and accelerate riscv ecosystem development while > > also speeding up the specification work by providing constant feedback. > > If the goal is to create a common code base for testing and discussing > draft extensions, we'd be happy to maintain another branch or another > k.org tree to hold these. Having a staging branch or separate tree does not work for KVM RISC-V because we have lot's of user-space tools (QEMU, KVMTOOL, etc) which expect the KVM UAPI header to be available in the upstream kernel. These user-space tools will not accept patches until the KVM UAPI header is available in the upstream kernel. Same thing was mentioned by Paolo in other thread. > > But in terms of the suggestion to create arch/riscv/staging, I think > that's just going to create the same problems that the RISC-V patch > acceptance guidelines were intended to solve. To put it differently, from > my point of view, it's a feature, not a bug, that we don't send code for > discussion drafts of ISA changes upstream to Linus. But maybe I'm > misunderstanding what you're looking for ? For KVM RISC-V, the arch/riscv/staging directory is a perfect solution because: 1) The KVM RISC-V UAPI is header is indeed based on the latest ratified RISC-V privilege spec v1.11 hence the KVM RISC-V UAPI header complies with current RISC-V patch acceptance policy. 2) All usage of RISC-V H-extension is contained within the KVM RISC-V sources only. Rest of the Linux RISC-V kernel does not use H-extension at all. The current RISC-V patch acceptance policy should make an exception for draft extensions where the UAPI headers are based on ratified RISC-V specs and sources for such draft extension should be placed in arch/riscv/staging directory. Regards, Anup _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: arch/riscv/staging 2021-05-22 3:05 ` arch/riscv/staging Anup Patel @ 2021-05-28 1:06 ` Paul Walmsley 2021-05-28 8:29 ` arch/riscv/staging Paolo Bonzini 2021-05-28 8:50 ` arch/riscv/staging Paolo Bonzini 0 siblings, 2 replies; 16+ messages in thread From: Paul Walmsley @ 2021-05-28 1:06 UTC (permalink / raw) To: Anup Patel Cc: Damien Le Moal, linux-riscv, Anup Patel, Paolo Bonzini, Palmer Dabbelt, Palmer Dabbelt, Greg Kroah-Hartman Hi Anup, On Sat, 22 May 2021, Anup Patel wrote: > On Fri, May 21, 2021 at 10:53 PM Paul Walmsley <paul.walmsley@sifive.com> wrote: > > > On Fri, 21 May 2021, Damien Le Moal wrote: > > > > > For the hypervisor extension and KVM support, the specifications are now very > > > stable and while changes due to the advanced interrupt controller specs work, > > > among other, are still possible, the changes will likely be small and should not > > > cause much headache in the kernel. > > > > This is the part that I don't quite understand. If everyone -- including > > the architecture folks working on the ISA extension at riscv.org -- agrees > > that the H extension isn't going to change significantly, why don't they > > freeze the extension? Could it be that the RVI folks are worried that > > they may need to make significant changes, and that's why they haven't > > frozen it yet? > > I have been involved in the H-extension spec development for the past > few years working with RISC-V ISA architects (Andrew and John.) I am also > involved in the RISC-V AIA specification as chair. Sounds like you've got great connections with the right people at RISC-V International as far as virtualization is concerned. > I confirm that all required provisions are already there in the RISC-V > H-extension to support an external interrupt controller with > virtualization acceleration (such as RISC-V AIA). > > In fact, Paolo (with his years of experience in KVM virtualization) also > confirmed that current H-extension have all required features. > > Clearly, significant changes are very very unlikely. Earlier this year, there was a post where someone asked on the RISC-V International lists whether the ISA architects were ready to freeze the H extension: https://lists.riscv.org/g/tech-privileged/topic/80346318#465 Many of the same points were made that you and Damien and Paolo have brought up on the Linux kernel mailing lists. Two engineers working on the RISC-V ISA responded, representing two different companies. They wrote in the thread above that it's "far from certain" that no changes will need to be need to be made, and that "it's a good (and necessary compromise)" to "[wait] a little longer to see [the AIA specification] at least stabilize". So it sounds like there's still a diversity of opinions here. Since it sounds like you've got a lot of influence with the RVI folks working on virtualization, seems like you'd be an ideal person to try to convince them that you're right and that they should freeze the hypervisor ISA extension right now? Then we could just merge your patch set and we could all skip the next round of Linux kernel E-mails about this topic. > > > That will reduce the risk of seeing forks pop out here and there and > > > greatly facilitate Paolo and Anup work. > > > > When you write about forks, are you worried about architecture forks, > > forks of Anup's patchset, or some other kind of fork here? > > > > I ask because in the past, it sounds like there's been some concern > > from WDC that someone else will come along and submit an alternative > > RISC-V KVM patch set that we'd somehow prefer over Anup's. That's > > pretty unlikely; I think everyone involved -- certainly including > > Palmer and I -- know that you guys have done the foundational work > > here, and you guys would certainly have clear precedence here, unless > > there turned out to be something wrong with the WDC patchset that you > > all wouldn't be willing to fix. But maybe I'm misunderstanding your > > concern? > > This is certainly your misunderstanding. OK, well, maybe you and Damien can get together and spell out what you all are concerned about regarding forks. Then we can see if there's anything that should be done to address it. Right now the only fork risk that I can see is related to the architecture itself. > > But in terms of the suggestion to create arch/riscv/staging, I think > > that's just going to create the same problems that the RISC-V patch > > acceptance guidelines were intended to solve. To put it differently, from > > my point of view, it's a feature, not a bug, that we don't send code for > > discussion drafts of ISA changes upstream to Linus. But maybe I'm > > misunderstanding what you're looking for ? > > For KVM RISC-V, the arch/riscv/staging directory is a perfect solution > because: > 1) The KVM RISC-V UAPI is header is indeed based on the latest > ratified RISC-V privilege spec v1.11 hence the KVM RISC-V UAPI > header complies with current RISC-V patch acceptance policy. > 2) All usage of RISC-V H-extension is contained within the KVM RISC-V > sources only. Rest of the Linux RISC-V kernel does not use H-extension > at all. > > The current RISC-V patch acceptance policy should make an exception > for draft extensions where the UAPI headers are based on ratified > RISC-V specs and sources for such draft extension should be placed > in arch/riscv/staging directory. Others have already covered why arch/riscv/staging is a bad idea, so no point in rehashing that here. - Paul _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: arch/riscv/staging 2021-05-28 1:06 ` arch/riscv/staging Paul Walmsley @ 2021-05-28 8:29 ` Paolo Bonzini 2021-05-28 8:53 ` arch/riscv/staging Greg Kroah-Hartman 2021-05-28 8:50 ` arch/riscv/staging Paolo Bonzini 1 sibling, 1 reply; 16+ messages in thread From: Paolo Bonzini @ 2021-05-28 8:29 UTC (permalink / raw) To: Paul Walmsley, Anup Patel Cc: Damien Le Moal, linux-riscv, Anup Patel, Palmer Dabbelt, Palmer Dabbelt, Greg Kroah-Hartman On 28/05/21 03:06, Paul Walmsley wrote: > OK, well, maybe you and Damien can get together and spell out what you all > are concerned about regarding forks. Then we can see if there's anything > that should be done to address it. > > Right now the only fork risk that I can see is related to the architecture > itself. The risk is that improvements to KVM RISC-V are developed in forks rather than in a single git tree. Paolo _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: arch/riscv/staging 2021-05-28 8:29 ` arch/riscv/staging Paolo Bonzini @ 2021-05-28 8:53 ` Greg Kroah-Hartman 2021-05-28 8:58 ` arch/riscv/staging Damien Le Moal 0 siblings, 1 reply; 16+ messages in thread From: Greg Kroah-Hartman @ 2021-05-28 8:53 UTC (permalink / raw) To: Paolo Bonzini Cc: Paul Walmsley, Anup Patel, Damien Le Moal, linux-riscv, Anup Patel, Palmer Dabbelt, Palmer Dabbelt On Fri, May 28, 2021 at 10:29:16AM +0200, Paolo Bonzini wrote: > On 28/05/21 03:06, Paul Walmsley wrote: > > OK, well, maybe you and Damien can get together and spell out what you all > > are concerned about regarding forks. Then we can see if there's anything > > that should be done to address it. > > > > Right now the only fork risk that I can see is related to the architecture > > itself. > > The risk is that improvements to KVM RISC-V are developed in forks rather > than in a single git tree. Eventually they need to come back into the mainline tree, so that should not be that big of an issue. If it is, again, get the spec finished, what is preventing that from happening this week? thanks, greg k-h _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: arch/riscv/staging 2021-05-28 8:53 ` arch/riscv/staging Greg Kroah-Hartman @ 2021-05-28 8:58 ` Damien Le Moal 2021-05-28 9:24 ` arch/riscv/staging Greg Kroah-Hartman 0 siblings, 1 reply; 16+ messages in thread From: Damien Le Moal @ 2021-05-28 8:58 UTC (permalink / raw) To: Greg Kroah-Hartman, Paolo Bonzini Cc: Paul Walmsley, Anup Patel, linux-riscv, Anup Patel, Palmer Dabbelt, Palmer Dabbelt On 2021/05/28 17:53, Greg Kroah-Hartman wrote: > On Fri, May 28, 2021 at 10:29:16AM +0200, Paolo Bonzini wrote: >> On 28/05/21 03:06, Paul Walmsley wrote: >>> OK, well, maybe you and Damien can get together and spell out what you all >>> are concerned about regarding forks. Then we can see if there's anything >>> that should be done to address it. >>> >>> Right now the only fork risk that I can see is related to the architecture >>> itself. >> >> The risk is that improvements to KVM RISC-V are developed in forks rather >> than in a single git tree. > > Eventually they need to come back into the mainline tree, so that should > not be that big of an issue. > > If it is, again, get the spec finished, what is preventing that from > happening this week? We (kernel & riscv software developers) do not get to decide alone. RISC-V International specification group decides. And our input does not seem to have much effect on the completion timing. See this thread: https://lists.riscv.org/g/tech-privileged/topic/80346318#465 -- Damien Le Moal Western Digital Research _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: arch/riscv/staging 2021-05-28 8:58 ` arch/riscv/staging Damien Le Moal @ 2021-05-28 9:24 ` Greg Kroah-Hartman 2021-05-28 9:37 ` arch/riscv/staging Paolo Bonzini 0 siblings, 1 reply; 16+ messages in thread From: Greg Kroah-Hartman @ 2021-05-28 9:24 UTC (permalink / raw) To: Damien Le Moal Cc: Paolo Bonzini, Paul Walmsley, Anup Patel, linux-riscv, Anup Patel, Palmer Dabbelt, Palmer Dabbelt On Fri, May 28, 2021 at 08:58:07AM +0000, Damien Le Moal wrote: > On 2021/05/28 17:53, Greg Kroah-Hartman wrote: > > On Fri, May 28, 2021 at 10:29:16AM +0200, Paolo Bonzini wrote: > >> On 28/05/21 03:06, Paul Walmsley wrote: > >>> OK, well, maybe you and Damien can get together and spell out what you all > >>> are concerned about regarding forks. Then we can see if there's anything > >>> that should be done to address it. > >>> > >>> Right now the only fork risk that I can see is related to the architecture > >>> itself. > >> > >> The risk is that improvements to KVM RISC-V are developed in forks rather > >> than in a single git tree. > > > > Eventually they need to come back into the mainline tree, so that should > > not be that big of an issue. > > > > If it is, again, get the spec finished, what is preventing that from > > happening this week? > > We (kernel & riscv software developers) do not get to decide alone. RISC-V > International specification group decides. And our input does not seem to have > much effect on the completion timing. See this thread: > > https://lists.riscv.org/g/tech-privileged/topic/80346318#465 Ok, as it sounds like this isn't going anywhere until the spec group gets their work done, you all should just wait as there's no real need for any kernel code here either, given that there can't be any hardware made until the spec is finished anyway. thanks, greg k-h _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: arch/riscv/staging 2021-05-28 9:24 ` arch/riscv/staging Greg Kroah-Hartman @ 2021-05-28 9:37 ` Paolo Bonzini 2021-05-28 10:59 ` arch/riscv/staging Greg Kroah-Hartman 0 siblings, 1 reply; 16+ messages in thread From: Paolo Bonzini @ 2021-05-28 9:37 UTC (permalink / raw) To: Greg Kroah-Hartman, Damien Le Moal Cc: Paul Walmsley, Anup Patel, linux-riscv, Anup Patel, Palmer Dabbelt, Palmer Dabbelt On 28/05/21 11:24, Greg Kroah-Hartman wrote: > Ok, as it sounds like this isn't going anywhere until the spec group > gets their work done, you all should just wait as there's no real need > for any kernel code here either, given that there can't be any hardware > made until the spec is finished anyway. There's need for kernel code so that userspace tooling can be built upon it. Not having the header files in Linus's tree makes it harder to merge RISC-V KVM support in userspace. KVM shields userspace from any future changes to the hypervisor specification; the userspace API *is* based exclusively on ratified specifications and there's no risk of breaking the ABI. I'd like RISC-V KVM to be feature complete when hardware does come out, and not having the code upstream makes it harder to both write and review new features and optimizations (e.g. finish support for hugetlb and transparent huge pages, possibly parallel page faults). For now you can test the code on both simulators and emulators. Paolo _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: arch/riscv/staging 2021-05-28 9:37 ` arch/riscv/staging Paolo Bonzini @ 2021-05-28 10:59 ` Greg Kroah-Hartman 2021-05-28 11:19 ` arch/riscv/staging Anup Patel 2021-05-28 11:28 ` arch/riscv/staging Paolo Bonzini 0 siblings, 2 replies; 16+ messages in thread From: Greg Kroah-Hartman @ 2021-05-28 10:59 UTC (permalink / raw) To: Paolo Bonzini Cc: Damien Le Moal, Paul Walmsley, Anup Patel, linux-riscv, Anup Patel, Palmer Dabbelt, Palmer Dabbelt On Fri, May 28, 2021 at 11:37:02AM +0200, Paolo Bonzini wrote: > On 28/05/21 11:24, Greg Kroah-Hartman wrote: > > Ok, as it sounds like this isn't going anywhere until the spec group > > gets their work done, you all should just wait as there's no real need > > for any kernel code here either, given that there can't be any hardware > > made until the spec is finished anyway. > > There's need for kernel code so that userspace tooling can be built upon it. > Not having the header files in Linus's tree makes it harder to merge RISC-V > KVM support in userspace. KVM shields userspace from any future changes to > the hypervisor specification; the userspace API *is* based exclusively on > ratified specifications and there's no risk of breaking the ABI. The "risk" is the kernel/hardware api, that seems to not be solid yet given the spec is not released so I understand why the riscv maintainers do not want to accept it. Work to make that solid/released and then no one will be complaining here, greg k-h _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: arch/riscv/staging 2021-05-28 10:59 ` arch/riscv/staging Greg Kroah-Hartman @ 2021-05-28 11:19 ` Anup Patel 2021-05-28 11:45 ` arch/riscv/staging Paolo Bonzini 2021-05-28 11:28 ` arch/riscv/staging Paolo Bonzini 1 sibling, 1 reply; 16+ messages in thread From: Anup Patel @ 2021-05-28 11:19 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Paolo Bonzini, Damien Le Moal, Paul Walmsley, linux-riscv, Anup Patel, Palmer Dabbelt, Palmer Dabbelt Hi Greg, On Fri, May 28, 2021 at 4:29 PM Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > On Fri, May 28, 2021 at 11:37:02AM +0200, Paolo Bonzini wrote: > > On 28/05/21 11:24, Greg Kroah-Hartman wrote: > > > Ok, as it sounds like this isn't going anywhere until the spec group > > > gets their work done, you all should just wait as there's no real need > > > for any kernel code here either, given that there can't be any hardware > > > made until the spec is finished anyway. > > > > There's need for kernel code so that userspace tooling can be built upon it. > > Not having the header files in Linus's tree makes it harder to merge RISC-V > > KVM support in userspace. KVM shields userspace from any future changes to > > the hypervisor specification; the userspace API *is* based exclusively on > > ratified specifications and there's no risk of breaking the ABI. > > The "risk" is the kernel/hardware api, that seems to not be solid yet > given the spec is not released so I understand why the riscv maintainers > do not want to accept it. > > Work to make that solid/released and then no one will be complaining > here, There is no "risk" in the kernel/hardware api exposed by the KVM RISC-V because the KVM RISC-V UAPI header is based on the latest ratified RISC-V privilege v1.11 specification. Refer: https://github.com/avpatel/linux/blob/riscv_kvm_v17/arch/riscv/include/uapi/asm/kvm.h https://github.com/riscv/riscv-isa-manual/releases/download/Ratified-IMFDQC-and-Priv-v1.11/riscv-privileged-20190608.pdf The unratified hypervisor extension part of RISC-V privilege spec is only used by the arch/riscv/kvm sources. Refer: https://github.com/avpatel/linux/tree/riscv_kvm_v17/arch/riscv/kvm In other words, the KVM RISC-V UAPI header is solid and based on released/ratified RISC-V specification but the KVM RISC-V implementation internal to the kernel uses unratified hypervisor extension. If the hypervisor extension changes (which is very very unlikely) then still the KVM RISC-V UAPI header will remain the same because it is based on released specification. Regards, Anup _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: arch/riscv/staging 2021-05-28 11:19 ` arch/riscv/staging Anup Patel @ 2021-05-28 11:45 ` Paolo Bonzini 0 siblings, 0 replies; 16+ messages in thread From: Paolo Bonzini @ 2021-05-28 11:45 UTC (permalink / raw) To: Anup Patel, Greg Kroah-Hartman Cc: Damien Le Moal, Paul Walmsley, linux-riscv, Anup Patel, Palmer Dabbelt, Palmer Dabbelt On 28/05/21 13:19, Anup Patel wrote: > There is no "risk" in the kernel/hardware api exposed by the KVM RISC-V > because the KVM RISC-V UAPI header is based on the latest ratified > RISC-V privilege v1.11 specification. Greg is referring the kernel->hardware API, i.e. the instructions, the page table formats, etc. Paolo _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: arch/riscv/staging 2021-05-28 10:59 ` arch/riscv/staging Greg Kroah-Hartman 2021-05-28 11:19 ` arch/riscv/staging Anup Patel @ 2021-05-28 11:28 ` Paolo Bonzini 2021-05-28 11:35 ` arch/riscv/staging Greg Kroah-Hartman 1 sibling, 1 reply; 16+ messages in thread From: Paolo Bonzini @ 2021-05-28 11:28 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Damien Le Moal, Paul Walmsley, Anup Patel, linux-riscv, Anup Patel, Palmer Dabbelt, Palmer Dabbelt On 28/05/21 12:59, Greg Kroah-Hartman wrote: > On Fri, May 28, 2021 at 11:37:02AM +0200, Paolo Bonzini wrote: >> On 28/05/21 11:24, Greg Kroah-Hartman wrote: >>> Ok, as it sounds like this isn't going anywhere until the spec group >>> gets their work done, you all should just wait as there's no real need >>> for any kernel code here either, given that there can't be any hardware >>> made until the spec is finished anyway. >> >> There's need for kernel code so that userspace tooling can be built upon it. >> Not having the header files in Linus's tree makes it harder to merge RISC-V >> KVM support in userspace. KVM shields userspace from any future changes to >> the hypervisor specification; the userspace API *is* based exclusively on >> ratified specifications and there's no risk of breaking the ABI. > > The "risk" is the kernel/hardware api, that seems to not be solid yet > given the spec is not released so I understand why the riscv maintainers > do not want to accept it. The key word is "seems". We _have_ worked on making the spec solid; no one that has actually done work on hypervisors for RISC-V believes that it is not solid. No work has been done on the spec for one year *because there's no work to be done*. So the people who actually do the work are twiddling thumbs and waiting for the freezing of all the dependent specs (of which there's a new one every time I check, because the goalposts for freezing the spec keep on being moved). And at this point probably waiting for hell to freeze as well. Anyway---I understand that you don't care (you shouldn't). Just from my point of view it's ridiculous that I cannot merge code that is completely standalone just because it has one file in arch/riscv/include/asm/uapi, and that RISC-V maintainers cannot participate in the community the same way everyone else does. Paolo _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: arch/riscv/staging 2021-05-28 11:28 ` arch/riscv/staging Paolo Bonzini @ 2021-05-28 11:35 ` Greg Kroah-Hartman 0 siblings, 0 replies; 16+ messages in thread From: Greg Kroah-Hartman @ 2021-05-28 11:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Damien Le Moal, Paul Walmsley, Anup Patel, linux-riscv, Anup Patel, Palmer Dabbelt, Palmer Dabbelt On Fri, May 28, 2021 at 01:28:16PM +0200, Paolo Bonzini wrote: > Anyway---I understand that you don't care (you shouldn't). Just from my > point of view it's ridiculous that I cannot merge code that is completely > standalone just because it has one file in arch/riscv/include/asm/uapi, and > that RISC-V maintainers cannot participate in the community the same way > everyone else does. I don't care, but I do agree with the riscv maintainers not wanting to merge this now. I would do the same thing if I were them. thanks, greg k-h _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: arch/riscv/staging 2021-05-28 1:06 ` arch/riscv/staging Paul Walmsley 2021-05-28 8:29 ` arch/riscv/staging Paolo Bonzini @ 2021-05-28 8:50 ` Paolo Bonzini 1 sibling, 0 replies; 16+ messages in thread From: Paolo Bonzini @ 2021-05-28 8:50 UTC (permalink / raw) To: Paul Walmsley, Anup Patel Cc: Damien Le Moal, linux-riscv, Anup Patel, Palmer Dabbelt, Palmer Dabbelt, Greg Kroah-Hartman On 28/05/21 03:06, Paul Walmsley wrote: > Earlier this year, there was a post where someone asked on the RISC-V > International lists whether the ISA architects were ready to freeze the H > extension: > > https://lists.riscv.org/g/tech-privileged/topic/80346318#465 That someone was Anup. :) > Many of the same points were made that you and Damien and Paolo have > brought up on the Linux kernel mailing lists. Two engineers working on > the RISC-V ISA responded, representing two different companies. They > wrote in the thread above that it's "far from certain" that no changes > will need to be need to be made, and that "it's a good (and necessary > compromise)" to "[wait] a little longer to see [the AIA specification] at > least stabilize". So it sounds like there's still a diversity of opinions > here. Quoting from that thread: "So, in my own opinion, we're getting close. Not a few weeks, but not quarters either". At this point it's been a quarter and no freezing is in sight. The author was even pushing for stabilizing H together with pointer-masking, even though pointer masking is basically being developed with the assumption that H goes in before (it already includes CSRs like vsmte, vspmmask and vspmbase). At this pace, I would be (gladly) surprised if the H extension is frozen within the next 6 months. Paolo _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2021-05-28 12:03 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-05-21 2:05 arch/riscv/staging Damien Le Moal 2021-05-21 2:08 ` arch/riscv/staging Damien Le Moal 2021-05-21 17:22 ` arch/riscv/staging Paul Walmsley 2021-05-22 3:05 ` arch/riscv/staging Anup Patel 2021-05-28 1:06 ` arch/riscv/staging Paul Walmsley 2021-05-28 8:29 ` arch/riscv/staging Paolo Bonzini 2021-05-28 8:53 ` arch/riscv/staging Greg Kroah-Hartman 2021-05-28 8:58 ` arch/riscv/staging Damien Le Moal 2021-05-28 9:24 ` arch/riscv/staging Greg Kroah-Hartman 2021-05-28 9:37 ` arch/riscv/staging Paolo Bonzini 2021-05-28 10:59 ` arch/riscv/staging Greg Kroah-Hartman 2021-05-28 11:19 ` arch/riscv/staging Anup Patel 2021-05-28 11:45 ` arch/riscv/staging Paolo Bonzini 2021-05-28 11:28 ` arch/riscv/staging Paolo Bonzini 2021-05-28 11:35 ` arch/riscv/staging Greg Kroah-Hartman 2021-05-28 8:50 ` arch/riscv/staging Paolo Bonzini
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.