arch/riscv/staging

arch/riscv/staging

[Damien Le Moal]

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

arch/riscv/staging

[Damien Le Moal]

[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

Re: arch/riscv/staging

[Paul Walmsley]

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

Re: arch/riscv/staging

[Anup Patel]

+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

Re: arch/riscv/staging

[Paul Walmsley]

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

Re: arch/riscv/staging

[Paolo Bonzini]

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

Re: arch/riscv/staging

[Paolo Bonzini]

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

Re: arch/riscv/staging

[Greg Kroah-Hartman]

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

Re: arch/riscv/staging

[Damien Le Moal]

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

Re: arch/riscv/staging

[Greg Kroah-Hartman]

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

Re: arch/riscv/staging

[Paolo Bonzini]

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

Re: arch/riscv/staging

[Greg Kroah-Hartman]

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

Re: arch/riscv/staging

[Anup Patel]

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

Re: arch/riscv/staging

[Paolo Bonzini]

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

Re: arch/riscv/staging

[Greg Kroah-Hartman]

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

Re: arch/riscv/staging

[Paolo Bonzini]

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