* [Qemu-devel] RISC-V: Vector && DSP Extension @ 2019-08-08 9:39 liuzhiwei 2019-08-08 11:29 ` Aleksandar Markovic 2019-08-10 1:54 ` Alistair Francis 0 siblings, 2 replies; 17+ messages in thread From: liuzhiwei @ 2019-08-08 9:39 UTC (permalink / raw) To: qemu-devel, qemu-riscv; +Cc: palmer, Alistair.Francis, sagark, bastian Hi all, My workmate and I have been working on Vector & Dsp extension, and I'd like to share develop status with folks. The spec references for Vector extension is riscv-v-spec-0.7.1, and riscv-p-spec-0.5 for DSP extension. The code of vector extension is ready and under testing, the first patch will be sent about two weeks later. After that we will forward working on DSP extension, and send the first patch in middle October. Could the maintainers tell me whether the specs referenced are appropriate? Is anyone working on these extensions? I'd like to get your status, and maybe discuss questions and work togather. Best Regards LIU Zhiwei ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] RISC-V: Vector && DSP Extension 2019-08-08 9:39 [Qemu-devel] RISC-V: Vector && DSP Extension liuzhiwei @ 2019-08-08 11:29 ` Aleksandar Markovic 2019-08-08 13:48 ` Chih-Min Chao 2019-08-10 1:54 ` Alistair Francis 1 sibling, 1 reply; 17+ messages in thread From: Aleksandar Markovic @ 2019-08-08 11:29 UTC (permalink / raw) To: liuzhiwei Cc: Peter Maydell, qemu-riscv, sagark, bastian, Palmer Dabbelt, QEMU Developers, Alistair Francis On Thu, Aug 8, 2019 at 11:52 AM liuzhiwei <zhiwei_liu@c-sky.com> wrote: > Hi all, > > My workmate and I have been working on Vector & Dsp extension, and > I'd like to share develop status with folks. > > The spec references for Vector extension is riscv-v-spec-0.7.1, and > riscv-p-spec-0.5 for DSP extension. Hello, Liu. I will not answer your questions directly, however I want to bring to you and others another perspective on this situation. First, please provide the link to the specifications. Via Google, I found that "riscv-v-spec-0.7.1" is titled "Working draft of the proposed RISC-V V vector extension". I could not find "riscv-p-spec-0.5". I am not sure what the QEMU policy towards "working draft proposal" type of specification is. Peter, can you perhaps clarify that or any other related issue? I would advice some caution in these cases. The major issue is backward compatibility, but there are other issues too. Let's say, fairness. If we let emulation of a component based on a "working draft proposal" be integrated into QEMU, this will set a precedent, and many other developer would rightfully ask for their contributions based on drafts to be integrated into QEMU. Our policy should be as equal as possible to all contribution, large or small, riscv or alpha, cpu or device, tcg or kvm - in my honest opinion. QEMU upstream should not be a collecting place for all imaginable experimentations, certain criteria on what is appropriate for upstreaming exist and must continue to exist. Yours, Aleksandar > The code of vector extension is > ready and under testing, the first patch will be sent about two weeks > later. After that we will forward working on DSP extension, and send the > first patch in middle October. > > Could the maintainers tell me whether the specs referenced are > appropriate? Is anyone working on these extensions? I'd like to get > your status, and maybe discuss questions and work togather. > > Best Regards > > LIU Zhiwei > > > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] RISC-V: Vector && DSP Extension 2019-08-08 11:29 ` Aleksandar Markovic @ 2019-08-08 13:48 ` Chih-Min Chao 2019-08-08 14:19 ` Aleksandar Markovic 2019-08-10 13:35 ` LIU ZhiWei 0 siblings, 2 replies; 17+ messages in thread From: Chih-Min Chao @ 2019-08-08 13:48 UTC (permalink / raw) To: Aleksandar Markovic Cc: Peter Maydell, open list:RISC-V, Sagar Karandikar, bastian, Palmer Dabbelt, QEMU Developers, Alistair Francis, liuzhiwei On Thu, Aug 8, 2019 at 7:29 PM Aleksandar Markovic < aleksandar.m.mail@gmail.com> wrote: > On Thu, Aug 8, 2019 at 11:52 AM liuzhiwei <zhiwei_liu@c-sky.com> wrote: > > > Hi all, > > > > My workmate and I have been working on Vector & Dsp extension, and > > I'd like to share develop status with folks. > > > > The spec references for Vector extension is riscv-v-spec-0.7.1, and > > riscv-p-spec-0.5 for DSP extension. > > > Hello, Liu. > > I will not answer your questions directly, however I want to bring to you > and others another perspective on this situation. > > First, please provide the link to the specifications. Via Google, I found > that "riscv-v-spec-0.7.1" is titled "Working draft of the proposed RISC-V V > vector extension". I could not find "riscv-p-spec-0.5". > > I am not sure what the QEMU policy towards "working draft proposal" type of > specification is. Peter, can you perhaps clarify that or any other related > issue? > Hi Aleksandar, As for riscv-v-spec 0.7.1, it is first stable spec for target software development though the name is working draft. The architecture skeleton is fix and most of work are focusing the issues related to micro-architecture implementation complexity. Sifive has released an open source implementation on spike simulation and Imperas also provides another implementation with its binary simulator. I think it is worth to include the extension in Qemu at this moment. As for riscv-p-spec-0.5, I think Andes has fully supported this extension and should release more detailed spec in the near future (described Riscv Technical Update 2019/06). They have implement lots of DSP kernel based on this extension and also provided impressed performance result. It is also worth to be reviewed (at least [RFC]) if the detailed spec is public. ref: 1. https://content.riscv.org/wp-content/uploads/2019/06/17.40-Vector_RISCV-20190611-Vectors.pdf 2. https://content.riscv.org/wp-content/uploads/2019/06/17.20-P-ext-RVW-Zurich-20190611.pdf 3. https://content.riscv.org/wp-content/uploads/2019/06/10.05-TechCommitteeUpdate-June-2019-Copy.pdf chihmin I would advice some caution in these cases. The major issue is backward > compatibility, but there are other issues too. Let's say, fairness. If we > let emulation of a component based on a "working draft proposal" be > integrated into QEMU, this will set a precedent, and many other developer > would rightfully ask for their contributions based on drafts to be > integrated into QEMU. Our policy should be as equal as possible to all > contribution, large or small, riscv or alpha, cpu or device, tcg or kvm - > in my honest opinion. QEMU upstream should not be a collecting place for > all imaginable experimentations, certain criteria on what is appropriate > for upstreaming exist and must continue to exist. > > Yours, > Aleksandar > > > > > > The code of vector extension is > > ready and under testing, the first patch will be sent about two weeks > > later. After that we will forward working on DSP extension, and send the > > first patch in middle October. > > > > Could the maintainers tell me whether the specs referenced are > > appropriate? Is anyone working on these extensions? I'd like to get > > your status, and maybe discuss questions and work togather. > > > > Best Regards > > > > LIU Zhiwei > > > > > > > > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] RISC-V: Vector && DSP Extension 2019-08-08 13:48 ` Chih-Min Chao @ 2019-08-08 14:19 ` Aleksandar Markovic 2019-08-10 13:35 ` LIU ZhiWei 1 sibling, 0 replies; 17+ messages in thread From: Aleksandar Markovic @ 2019-08-08 14:19 UTC (permalink / raw) To: Chih-Min Chao Cc: Peter Maydell, open list:RISC-V, Sagar Karandikar, bastian, Palmer Dabbelt, QEMU Developers, Alistair Francis, liuzhiwei On Thu, Aug 8, 2019 at 3:48 PM Chih-Min Chao <chihmin.chao@sifive.com> wrote: > > > On Thu, Aug 8, 2019 at 7:29 PM Aleksandar Markovic < > aleksandar.m.mail@gmail.com> wrote: > >> On Thu, Aug 8, 2019 at 11:52 AM liuzhiwei <zhiwei_liu@c-sky.com> wrote: >> >> > Hi all, >> > >> > My workmate and I have been working on Vector & Dsp extension, and >> > I'd like to share develop status with folks. >> > >> > The spec references for Vector extension is riscv-v-spec-0.7.1, and >> > riscv-p-spec-0.5 for DSP extension. >> >> >> Hello, Liu. >> >> I will not answer your questions directly, however I want to bring to you >> and others another perspective on this situation. >> >> First, please provide the link to the specifications. Via Google, I found >> that "riscv-v-spec-0.7.1" is titled "Working draft of the proposed RISC-V >> V >> vector extension". I could not find "riscv-p-spec-0.5". >> >> I am not sure what the QEMU policy towards "working draft proposal" type >> of >> specification is. Peter, can you perhaps clarify that or any other related >> issue? >> > > Hi Aleksandar, > > As for riscv-v-spec 0.7.1, it is first stable spec for target software > development > though the name is working draft. > Hello, Chih-Min. Too many unclear points here. What does this sentence mean? What is "stable"? Is that the same as "final"? If the document is stable, why the title "draft/proposal"? Can a "draft" be stable? Can you, or anybody else, guarantee that the final version of this document will not affect QEMU implementation, if it is done by the current document? If not, why would you like QEMU upstream to support something not fully specified? Why has the final document not been released, if the situation is stable?..... Yours, Aleksandar The architecture skeleton is fix and most of > work are focusing the issues related to micro-architecture implementation > complexity. > Sifive has released an open source implementation on spike simulation and > Imperas also > provides another implementation with its binary simulator. I think it is > worth to include the extension > in Qemu at this moment. > > As for riscv-p-spec-0.5, I think Andes has fully supported this extension > and should release more > detailed spec in the near future (described Riscv Technical Update > 2019/06). > They have implement lots of DSP kernel based on this extension and also > provided impressed > performance result. It is also worth to be reviewed (at least [RFC]) if > the detailed spec is public. > > > ref: > 1. > https://content.riscv.org/wp-content/uploads/2019/06/17.40-Vector_RISCV-20190611-Vectors.pdf > 2. > https://content.riscv.org/wp-content/uploads/2019/06/17.20-P-ext-RVW-Zurich-20190611.pdf > 3. > https://content.riscv.org/wp-content/uploads/2019/06/10.05-TechCommitteeUpdate-June-2019-Copy.pdf > > > chihmin > > > I would advice some caution in these cases. The major issue is backward >> compatibility, but there are other issues too. Let's say, fairness. If we >> let emulation of a component based on a "working draft proposal" be >> integrated into QEMU, this will set a precedent, and many other developer >> would rightfully ask for their contributions based on drafts to be >> integrated into QEMU. Our policy should be as equal as possible to all >> contribution, large or small, riscv or alpha, cpu or device, tcg or kvm - >> in my honest opinion. QEMU upstream should not be a collecting place for >> all imaginable experimentations, certain criteria on what is appropriate >> for upstreaming exist and must continue to exist. >> >> Yours, >> Aleksandar >> >> >> >> >> > The code of vector extension is >> > ready and under testing, the first patch will be sent about two weeks >> > later. After that we will forward working on DSP extension, and send the >> > first patch in middle October. >> > >> > Could the maintainers tell me whether the specs referenced are >> > appropriate? Is anyone working on these extensions? I'd like to get >> > your status, and maybe discuss questions and work togather. >> > >> > Best Regards >> > >> > LIU Zhiwei >> > >> > >> > >> > >> > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] RISC-V: Vector && DSP Extension 2019-08-08 13:48 ` Chih-Min Chao 2019-08-08 14:19 ` Aleksandar Markovic @ 2019-08-10 13:35 ` LIU ZhiWei 1 sibling, 0 replies; 17+ messages in thread From: LIU ZhiWei @ 2019-08-10 13:35 UTC (permalink / raw) To: Chih-Min Chao Cc: Peter Maydell, open list:RISC-V, Sagar Karandikar, Palmer Dabbelt, QEMU Developers, Alistair Francis, Aleksandar Markovic On 8/8/19 6:48 AM, Chih-Min Chao wrote: > > > On Thu, Aug 8, 2019 at 7:29 PM Aleksandar Markovic > <aleksandar.m.mail@gmail.com <mailto:aleksandar.m.mail@gmail.com>> wrote: > > On Thu, Aug 8, 2019 at 11:52 AM liuzhiwei <zhiwei_liu@c-sky.com > <mailto:zhiwei_liu@c-sky.com>> wrote: > > > Hi all, > > > > My workmate and I have been working on Vector & Dsp > extension, and > > I'd like to share develop status with folks. > > > > The spec references for Vector extension is > riscv-v-spec-0.7.1, and > > riscv-p-spec-0.5 for DSP extension. > > > Hello, Liu. > > I will not answer your questions directly, however I want to bring > to you > and others another perspective on this situation. > > First, please provide the link to the specifications. Via Google, > I found > that "riscv-v-spec-0.7.1" is titled "Working draft of the proposed > RISC-V V > vector extension". I could not find "riscv-p-spec-0.5". > > I am not sure what the QEMU policy towards "working draft > proposal" type of > specification is. Peter, can you perhaps clarify that or any other > related > issue? > > > Hi Aleksandar, > > As for riscv-v-spec 0.7.1, it is first stable spec for target software > development > though the name is working draft. The architecture skeleton is fix > and most of > work are focusing the issues related to micro-architecture > implementation complexity. > Sifive has released an open source implementation on spike simulation > and Imperas also > provides another implementation with its binary simulator. I think it > is worth to include the extension > in Qemu at this moment. > > As for riscv-p-spec-0.5, I think Andes has fully supported this > extension and should release more > detailed spec in the near future (described Riscv Technical Update > 2019/06). > They have implement lots of DSP kernel based on this extension and > also provided impressed > performance result. It is also worth to be reviewed (at least [RFC]) > if the detailed spec is public. > > > ref: > 1. > https://content.riscv.org/wp-content/uploads/2019/06/17.40-Vector_RISCV-20190611-Vectors.pdf > 2. > https://content.riscv.org/wp-content/uploads/2019/06/17.20-P-ext-RVW-Zurich-20190611.pdf > 3. > https://content.riscv.org/wp-content/uploads/2019/06/10.05-TechCommitteeUpdate-June-2019-Copy.pdf > > > chihmin > Hi chihmin, Thank you for the detailed and informative response. You have a very good understanding of the specifications. I will modify the code according to the latest spec(currently riscv-v-spec 0.7.2) from the ISA spec git repo as Alistair advised. Yours, Zhiwei > > I would advice some caution in these cases. The major issue is > backward > compatibility, but there are other issues too. Let's say, > fairness. If we > let emulation of a component based on a "working draft proposal" be > integrated into QEMU, this will set a precedent, and many other > developer > would rightfully ask for their contributions based on drafts to be > integrated into QEMU. Our policy should be as equal as possible to all > contribution, large or small, riscv or alpha, cpu or device, tcg > or kvm - > in my honest opinion. QEMU upstream should not be a collecting > place for > all imaginable experimentations, certain criteria on what is > appropriate > for upstreaming exist and must continue to exist. > > Yours, > Aleksandar > > > > > > The code of vector extension is > > ready and under testing, the first patch will be sent about two > weeks > > later. After that we will forward working on DSP extension, and > send the > > first patch in middle October. > > > > Could the maintainers tell me whether the specs referenced are > > appropriate? Is anyone working on these extensions? I'd like to get > > your status, and maybe discuss questions and work togather. > > > > Best Regards > > > > LIU Zhiwei > > > > > > > > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] RISC-V: Vector && DSP Extension 2019-08-08 9:39 [Qemu-devel] RISC-V: Vector && DSP Extension liuzhiwei 2019-08-08 11:29 ` Aleksandar Markovic @ 2019-08-10 1:54 ` Alistair Francis 2019-08-10 13:55 ` LIU ZhiWei 1 sibling, 1 reply; 17+ messages in thread From: Alistair Francis @ 2019-08-10 1:54 UTC (permalink / raw) To: liuzhiwei Cc: open list:RISC-V, Sagar Karandikar, bastian, Palmer Dabbelt, qemu-devel@nongnu.org Developers, Alistair Francis On Thu, Aug 8, 2019 at 2:52 AM liuzhiwei <zhiwei_liu@c-sky.com> wrote: > > Hi all, > > My workmate and I have been working on Vector & Dsp extension, and > I'd like to share develop status with folks. Cool! > > The spec references for Vector extension is riscv-v-spec-0.7.1, and > riscv-p-spec-0.5 for DSP extension. The code of vector extension is > ready and under testing, the first patch will be sent about two weeks > later. After that we will forward working on DSP extension, and send the > first patch in middle October. What code are you talking about? Is this QEMU code? > > Could the maintainers tell me whether the specs referenced are > appropriate? Is anyone working on these extensions? I'd like to get > your status, and maybe discuss questions and work togather. Just use the latest (master) from the ISA spec git repo. I don't know anyone doing vector work for QEMU. It would be very useful, but everyone is busy with something at the moment unfortunately. Alistair > > Best Regards > > LIU Zhiwei > > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] RISC-V: Vector && DSP Extension 2019-08-10 1:54 ` Alistair Francis @ 2019-08-10 13:55 ` LIU ZhiWei 2019-08-11 16:50 ` Alistair Francis 0 siblings, 1 reply; 17+ messages in thread From: LIU ZhiWei @ 2019-08-10 13:55 UTC (permalink / raw) To: Alistair Francis Cc: open list:RISC-V, Sagar Karandikar, bastian, Palmer Dabbelt, qemu-devel@nongnu.org Developers, Alistair Francis On 8/9/19 6:54 PM, Alistair Francis wrote: > On Thu, Aug 8, 2019 at 2:52 AM liuzhiwei <zhiwei_liu@c-sky.com> wrote: >> Hi all, >> >> My workmate and I have been working on Vector & Dsp extension, and >> I'd like to share develop status with folks. > Cool! > >> The spec references for Vector extension is riscv-v-spec-0.7.1, and >> riscv-p-spec-0.5 for DSP extension. The code of vector extension is >> ready and under testing, the first patch will be sent about two weeks >> later. After that we will forward working on DSP extension, and send the >> first patch in middle October. > What code are you talking about? Is this QEMU code? Hi Alistair, It's the QEMU code I have been working on these days, which implements Vector extension. It is under testing, and will be sent later. >> Could the maintainers tell me whether the specs referenced are >> appropriate? Is anyone working on these extensions? I'd like to get >> your status, and maybe discuss questions and work togather. > Just use the latest (master) from the ISA spec git repo. I will follow your advice.Thanks for your attention to this matter. Best Regards, Zhiwei > > I don't know anyone doing vector work for QEMU. It would be very > useful, but everyone is busy with something at the moment > unfortunately. > > Alistair > >> Best Regards >> >> LIU Zhiwei >> >> >> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] RISC-V: Vector && DSP Extension 2019-08-10 13:55 ` LIU ZhiWei @ 2019-08-11 16:50 ` Alistair Francis 2019-08-15 8:53 ` Aleksandar Markovic 0 siblings, 1 reply; 17+ messages in thread From: Alistair Francis @ 2019-08-11 16:50 UTC (permalink / raw) To: LIU ZhiWei Cc: open list:RISC-V, Sagar Karandikar, bastian, Palmer Dabbelt, qemu-devel@nongnu.org Developers, Alistair Francis On Sat, Aug 10, 2019 at 6:55 AM LIU ZhiWei <zhiwei_liu@c-sky.com> wrote: > > > On 8/9/19 6:54 PM, Alistair Francis wrote: > > On Thu, Aug 8, 2019 at 2:52 AM liuzhiwei <zhiwei_liu@c-sky.com> wrote: > > Hi all, > > My workmate and I have been working on Vector & Dsp extension, and > I'd like to share develop status with folks. > > Cool! > > The spec references for Vector extension is riscv-v-spec-0.7.1, and > riscv-p-spec-0.5 for DSP extension. The code of vector extension is > ready and under testing, the first patch will be sent about two weeks > later. After that we will forward working on DSP extension, and send the > first patch in middle October. > > What code are you talking about? Is this QEMU code? > > Hi Alistair, > > It's the QEMU code I have been working on these days, which implements Vector extension. It is under testing, > and will be sent later. Great! Please send it when you have it ready. We can accept draft extensions in QEMU as long as they are disabled by default. Alistair > > Could the maintainers tell me whether the specs referenced are > appropriate? Is anyone working on these extensions? I'd like to get > your status, and maybe discuss questions and work togather. > > Just use the latest (master) from the ISA spec git repo. > > I will follow your advice.Thanks for your attention to this matter. > > Best Regards, > > Zhiwei > > I don't know anyone doing vector work for QEMU. It would be very > useful, but everyone is busy with something at the moment > unfortunately. > > Alistair > > Best Regards > > LIU Zhiwei > > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] RISC-V: Vector && DSP Extension 2019-08-11 16:50 ` Alistair Francis @ 2019-08-15 8:53 ` Aleksandar Markovic 2019-08-15 9:07 ` Peter Maydell 0 siblings, 1 reply; 17+ messages in thread From: Aleksandar Markovic @ 2019-08-15 8:53 UTC (permalink / raw) To: Alistair Francis Cc: open list:RISC-V, Sagar Karandikar, bastian, Palmer Dabbelt, qemu-devel@nongnu.org Developers, Alistair Francis, LIU ZhiWei > We can accept draft > extensions in QEMU as long as they are disabled by default. > > Alistair > Hi, Alistair, Palmer, Is this an official stance of QEMU community, or perhaps Alistair's personal judgement, or maybe a rule within risv subcomunity? Yours, Aleksandar ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] RISC-V: Vector && DSP Extension 2019-08-15 8:53 ` Aleksandar Markovic @ 2019-08-15 9:07 ` Peter Maydell 2019-08-15 10:32 ` Aleksandar Markovic 2019-08-15 21:37 ` Alistair Francis 0 siblings, 2 replies; 17+ messages in thread From: Peter Maydell @ 2019-08-15 9:07 UTC (permalink / raw) To: Aleksandar Markovic Cc: open list:RISC-V, Sagar Karandikar, bastian, Palmer Dabbelt, qemu-devel@nongnu.org Developers, Alistair Francis, Alistair Francis, LIU ZhiWei On Thu, 15 Aug 2019 at 09:53, Aleksandar Markovic <aleksandar.m.mail@gmail.com> wrote: > > > We can accept draft > > extensions in QEMU as long as they are disabled by default. > Hi, Alistair, Palmer, > > Is this an official stance of QEMU community, or perhaps Alistair's > personal judgement, or maybe a rule within risv subcomunity? Alistair asked on a previous thread; my view was: https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg03364.html and nobody else spoke up disagreeing (summary: should at least be disabled-by-default and only enabled by setting an explicit property whose name should start with the 'x-' prefix). In general QEMU does sometimes introduce experimental extensions (we've had them in the block layer, for example) and so the 'x-' property to enable them is a reasonably established convention. I think it's a reasonable compromise to allow this sort of work to start and not have to live out-of-tree for a long time, without confusing users or getting into a situation where some QEMU versions behave differently or to obsolete drafts of a spec without it being clear from the command line that experimental extensions are being enabled. There is also an element of "submaintainer judgement" to be applied here -- upstream is probably not the place for a draft extension to be implemented if it is: * still fast moving or subject to major changes of design direction * major changes to the codebase (especially if it requires changes to core code) that might later need to be redone entirely differently * still experimental thanks -- PMM ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] RISC-V: Vector && DSP Extension 2019-08-15 9:07 ` Peter Maydell @ 2019-08-15 10:32 ` Aleksandar Markovic 2019-08-15 21:37 ` Alistair Francis 1 sibling, 0 replies; 17+ messages in thread From: Aleksandar Markovic @ 2019-08-15 10:32 UTC (permalink / raw) To: Peter Maydell Cc: open list:RISC-V, Sagar Karandikar, bastian, Palmer Dabbelt, qemu-devel@nongnu.org Developers, Alistair Francis, Alistair Francis, LIU ZhiWei 15.08.2019. 11.07, "Peter Maydell" <peter.maydell@linaro.org> је написао/ла: > > On Thu, 15 Aug 2019 at 09:53, Aleksandar Markovic > <aleksandar.m.mail@gmail.com> wrote: > > > > > We can accept draft > > > extensions in QEMU as long as they are disabled by default. > > > Hi, Alistair, Palmer, > > > > Is this an official stance of QEMU community, or perhaps Alistair's > > personal judgement, or maybe a rule within risv subcomunity? > > Alistair asked on a previous thread; my view was: > https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg03364.html > and nobody else spoke up disagreeing (summary: should at least be > disabled-by-default and only enabled by setting an explicit > property whose name should start with the 'x-' prefix). > > In general QEMU does sometimes introduce experimental extensions > (we've had them in the block layer, for example) and so the 'x-' > property to enable them is a reasonably established convention. > I think it's a reasonable compromise to allow this sort of work > to start and not have to live out-of-tree for a long time, without > confusing users or getting into a situation where some QEMU > versions behave differently or to obsolete drafts of a spec > without it being clear from the command line that experimental > extensions are being enabled. > > There is also an element of "submaintainer judgement" to be applied > here -- upstream is probably not the place for a draft extension > to be implemented if it is: > * still fast moving or subject to major changes of design direction > * major changes to the codebase (especially if it requires > changes to core code) that might later need to be redone > entirely differently > * still experimental > OK. Thanks for detailed response. Aleksandar > thanks > -- PMM ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] RISC-V: Vector && DSP Extension 2019-08-15 9:07 ` Peter Maydell 2019-08-15 10:32 ` Aleksandar Markovic @ 2019-08-15 21:37 ` Alistair Francis 2019-08-21 19:31 ` Palmer Dabbelt 1 sibling, 1 reply; 17+ messages in thread From: Alistair Francis @ 2019-08-15 21:37 UTC (permalink / raw) To: Peter Maydell Cc: open list:RISC-V, Sagar Karandikar, bastian, Palmer Dabbelt, qemu-devel@nongnu.org Developers, Alistair Francis, LIU ZhiWei, Aleksandar Markovic On Thu, Aug 15, 2019 at 2:07 AM Peter Maydell <peter.maydell@linaro.org> wrote: > > On Thu, 15 Aug 2019 at 09:53, Aleksandar Markovic > <aleksandar.m.mail@gmail.com> wrote: > > > > > We can accept draft > > > extensions in QEMU as long as they are disabled by default. > > > Hi, Alistair, Palmer, > > > > Is this an official stance of QEMU community, or perhaps Alistair's > > personal judgement, or maybe a rule within risv subcomunity? > > Alistair asked on a previous thread; my view was: > https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg03364.html > and nobody else spoke up disagreeing (summary: should at least be > disabled-by-default and only enabled by setting an explicit > property whose name should start with the 'x-' prefix). Agreed! > > In general QEMU does sometimes introduce experimental extensions > (we've had them in the block layer, for example) and so the 'x-' > property to enable them is a reasonably established convention. > I think it's a reasonable compromise to allow this sort of work > to start and not have to live out-of-tree for a long time, without > confusing users or getting into a situation where some QEMU > versions behave differently or to obsolete drafts of a spec > without it being clear from the command line that experimental > extensions are being enabled. > > There is also an element of "submaintainer judgement" to be applied > here -- upstream is probably not the place for a draft extension > to be implemented if it is: > * still fast moving or subject to major changes of design direction > * major changes to the codebase (especially if it requires > changes to core code) that might later need to be redone > entirely differently > * still experimental Yep, agreed. For RISC-V I think this would extend to only allowing extensions that have backing from the foundation and are under active discussion. Alistair > > thanks > -- PMM ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] RISC-V: Vector && DSP Extension 2019-08-15 21:37 ` Alistair Francis @ 2019-08-21 19:31 ` Palmer Dabbelt 2019-08-21 23:10 ` [Qemu-devel] [Qemu-riscv] " Jonathan Behrens 2019-08-22 1:50 ` [Qemu-devel] " liuzhiwei 0 siblings, 2 replies; 17+ messages in thread From: Palmer Dabbelt @ 2019-08-21 19:31 UTC (permalink / raw) To: alistair23 Cc: Peter Maydell, qemu-riscv, sagark, bastian, qemu-devel, Alistair Francis, zhiwei_liu, aleksandar.m.mail On Thu, 15 Aug 2019 14:37:52 PDT (-0700), alistair23@gmail.com wrote: > On Thu, Aug 15, 2019 at 2:07 AM Peter Maydell <peter.maydell@linaro.org> wrote: >> >> On Thu, 15 Aug 2019 at 09:53, Aleksandar Markovic >> <aleksandar.m.mail@gmail.com> wrote: >> > >> > > We can accept draft >> > > extensions in QEMU as long as they are disabled by default. >> >> > Hi, Alistair, Palmer, >> > >> > Is this an official stance of QEMU community, or perhaps Alistair's >> > personal judgement, or maybe a rule within risv subcomunity? >> >> Alistair asked on a previous thread; my view was: >> https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg03364.html >> and nobody else spoke up disagreeing (summary: should at least be >> disabled-by-default and only enabled by setting an explicit >> property whose name should start with the 'x-' prefix). > > Agreed! > >> >> In general QEMU does sometimes introduce experimental extensions >> (we've had them in the block layer, for example) and so the 'x-' >> property to enable them is a reasonably established convention. >> I think it's a reasonable compromise to allow this sort of work >> to start and not have to live out-of-tree for a long time, without >> confusing users or getting into a situation where some QEMU >> versions behave differently or to obsolete drafts of a spec >> without it being clear from the command line that experimental >> extensions are being enabled. >> >> There is also an element of "submaintainer judgement" to be applied >> here -- upstream is probably not the place for a draft extension >> to be implemented if it is: >> * still fast moving or subject to major changes of design direction >> * major changes to the codebase (especially if it requires >> changes to core code) that might later need to be redone >> entirely differently >> * still experimental > > Yep, agreed. For RISC-V I think this would extend to only allowing > extensions that have backing from the foundation and are under active > discussion. My general philosophy here is that we'll take anything written down in an official RISC-V ISA manual (ie, the ones actually released by the foundation). This provides a single source of truth for what an extension name / version means, which is important to avoid confusion. If it's a ratified extension then I see no reason not to support it on my end. For frozen extensions we should probably just wait the 45 days until they go up for a ratification vote, but I'd be happy to start reviewing patches then (or earlier :)). If the spec is a draft in the ISA manual then we need to worry about the support burden, which I don't have a fixed criteria for -- generally there shouldn't be issues here, but early drafts can be in a state where they're going to change extensively and are unlikely to be used by anyone. There's also the question of "what is an official release of a draft specification?". That's a bit awkward right now: the current ratified ISA manual contains version 0.3 of the hypervisor extension, but I just talked to Andrew and the plan is to remove the draft extensions from the ratified manuals because these drafts are old and the official manuals update slowly. For now I guess we'll need an an-hoc way of determining if a draft extension has been officially versioned or not, which is a bit of a headache. We already have examples of supporting draft extensions, including priv-1.9.1. This does cause some pain for us on the QEMU side (CSR bits have different semantics between the specs), but there's 1.9.1 hardware out there and the port continues to be useful so I'd be in favor of keeping it around for now. I suppose there is an implicit risk that draft extensions will be deprecated, but the "x-" prefix, draft status, and long deprecation period should be sufficient to inform users of the risk. I wouldn't be opposed to adding a "this is a draft ISA" warning, but I feel like it might be a bit overkill. > > Alistair > >> >> thanks >> -- PMM ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] [Qemu-riscv] RISC-V: Vector && DSP Extension 2019-08-21 19:31 ` Palmer Dabbelt @ 2019-08-21 23:10 ` Jonathan Behrens 2019-08-22 1:50 ` [Qemu-devel] " liuzhiwei 1 sibling, 0 replies; 17+ messages in thread From: Jonathan Behrens @ 2019-08-21 23:10 UTC (permalink / raw) To: Palmer Dabbelt Cc: Peter Maydell, open list:RISC-V, Sagar Karandikar, bastian, qemu-devel@nongnu.org Developers, Alistair Francis, Alistair Francis, zhiwei_liu, aleksandar.m.mail Is there a reason to guarantee support of a particular draft extension version once it has been superseded by a subsequent version? I understand why it was done for priv-1.9.1, but going forward I'm skeptical there will be much/any code out in the wild that depends on old draft versions of extensions. The main reason people seem interested in implementing extensions in QEMU is to test them before going through the trouble of manufacturing hardware, and I don't really see why anyone would want to test a design that is no longer under consideration. Jonathan On Wed, Aug 21, 2019 at 3:31 PM Palmer Dabbelt <palmer@sifive.com> wrote: > On Thu, 15 Aug 2019 14:37:52 PDT (-0700), alistair23@gmail.com wrote: > > On Thu, Aug 15, 2019 at 2:07 AM Peter Maydell <peter.maydell@linaro.org> > wrote: > >> > >> On Thu, 15 Aug 2019 at 09:53, Aleksandar Markovic > >> <aleksandar.m.mail@gmail.com> wrote: > >> > > >> > > We can accept draft > >> > > extensions in QEMU as long as they are disabled by default. > >> > >> > Hi, Alistair, Palmer, > >> > > >> > Is this an official stance of QEMU community, or perhaps Alistair's > >> > personal judgement, or maybe a rule within risv subcomunity? > >> > >> Alistair asked on a previous thread; my view was: > >> https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg03364.html > >> and nobody else spoke up disagreeing (summary: should at least be > >> disabled-by-default and only enabled by setting an explicit > >> property whose name should start with the 'x-' prefix). > > > > Agreed! > > > >> > >> In general QEMU does sometimes introduce experimental extensions > >> (we've had them in the block layer, for example) and so the 'x-' > >> property to enable them is a reasonably established convention. > >> I think it's a reasonable compromise to allow this sort of work > >> to start and not have to live out-of-tree for a long time, without > >> confusing users or getting into a situation where some QEMU > >> versions behave differently or to obsolete drafts of a spec > >> without it being clear from the command line that experimental > >> extensions are being enabled. > >> > >> There is also an element of "submaintainer judgement" to be applied > >> here -- upstream is probably not the place for a draft extension > >> to be implemented if it is: > >> * still fast moving or subject to major changes of design direction > >> * major changes to the codebase (especially if it requires > >> changes to core code) that might later need to be redone > >> entirely differently > >> * still experimental > > > > Yep, agreed. For RISC-V I think this would extend to only allowing > > extensions that have backing from the foundation and are under active > > discussion. > > My general philosophy here is that we'll take anything written down in an > official RISC-V ISA manual (ie, the ones actually released by the > foundation). > This provides a single source of truth for what an extension name / > version > means, which is important to avoid confusion. If it's a ratified > extension > then I see no reason not to support it on my end. For frozen extensions > we > should probably just wait the 45 days until they go up for a ratification > vote, > but I'd be happy to start reviewing patches then (or earlier :)). > > If the spec is a draft in the ISA manual then we need to worry about the > support burden, which I don't have a fixed criteria for -- generally there > shouldn't be issues here, but early drafts can be in a state where they're > going to change extensively and are unlikely to be used by anyone. > There's > also the question of "what is an official release of a draft > specification?". > > That's a bit awkward right now: the current ratified ISA manual contains > version 0.3 of the hypervisor extension, but I just talked to Andrew and > the > plan is to remove the draft extensions from the ratified manuals because > these > drafts are old and the official manuals update slowly. For now I guess > we'll > need an an-hoc way of determining if a draft extension has been officially > versioned or not, which is a bit of a headache. > > We already have examples of supporting draft extensions, including > priv-1.9.1. > This does cause some pain for us on the QEMU side (CSR bits have different > semantics between the specs), but there's 1.9.1 hardware out there and the > port > continues to be useful so I'd be in favor of keeping it around for now. I > suppose there is an implicit risk that draft extensions will be > deprecated, but > the "x-" prefix, draft status, and long deprecation period should be > sufficient > to inform users of the risk. I wouldn't be opposed to adding a "this is a > draft ISA" warning, but I feel like it might be a bit overkill. > > > > > Alistair > > > >> > >> thanks > >> -- PMM > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] RISC-V: Vector && DSP Extension 2019-08-21 19:31 ` Palmer Dabbelt 2019-08-21 23:10 ` [Qemu-devel] [Qemu-riscv] " Jonathan Behrens @ 2019-08-22 1:50 ` liuzhiwei 2019-08-22 22:37 ` Alistair Francis 1 sibling, 1 reply; 17+ messages in thread From: liuzhiwei @ 2019-08-22 1:50 UTC (permalink / raw) To: Palmer Dabbelt, alistair23, Jonathan Behrens Cc: Peter Maydell, qemu-riscv, sagark, bastian, qemu-devel, Alistair Francis, aleksandar.m.mail On 2019/8/22 上午3:31, Palmer Dabbelt wrote: > On Thu, 15 Aug 2019 14:37:52 PDT (-0700), alistair23@gmail.com wrote: >> On Thu, Aug 15, 2019 at 2:07 AM Peter Maydell >> <peter.maydell@linaro.org> wrote: >>> >>> On Thu, 15 Aug 2019 at 09:53, Aleksandar Markovic >>> <aleksandar.m.mail@gmail.com> wrote: >>> > >>> > > We can accept draft >>> > > extensions in QEMU as long as they are disabled by default. >>> >>> > Hi, Alistair, Palmer, >>> > >>> > Is this an official stance of QEMU community, or perhaps Alistair's >>> > personal judgement, or maybe a rule within risv subcomunity? >>> >>> Alistair asked on a previous thread; my view was: >>> https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg03364.html >>> and nobody else spoke up disagreeing (summary: should at least be >>> disabled-by-default and only enabled by setting an explicit >>> property whose name should start with the 'x-' prefix). >> >> Agreed! >> >>> >>> In general QEMU does sometimes introduce experimental extensions >>> (we've had them in the block layer, for example) and so the 'x-' >>> property to enable them is a reasonably established convention. >>> I think it's a reasonable compromise to allow this sort of work >>> to start and not have to live out-of-tree for a long time, without >>> confusing users or getting into a situation where some QEMU >>> versions behave differently or to obsolete drafts of a spec >>> without it being clear from the command line that experimental >>> extensions are being enabled. >>> >>> There is also an element of "submaintainer judgement" to be applied >>> here -- upstream is probably not the place for a draft extension >>> to be implemented if it is: >>> * still fast moving or subject to major changes of design direction >>> * major changes to the codebase (especially if it requires >>> changes to core code) that might later need to be redone >>> entirely differently >>> * still experimental >> >> Yep, agreed. For RISC-V I think this would extend to only allowing >> extensions that have backing from the foundation and are under active >> discussion. > > My general philosophy here is that we'll take anything written down in > an official RISC-V ISA manual (ie, the ones actually released by the > foundation). This provides a single source of truth for what an > extension name / version means, which is important to avoid > confusion. If it's a ratified extension then I see no reason not to > support it on my end. For frozen extensions we should probably just > wait the 45 days until they go up for a ratification vote, but I'd be > happy to start reviewing patches then (or earlier :)). > > If the spec is a draft in the ISA manual then we need to worry about > the support burden, which I don't have a fixed criteria for -- > generally there shouldn't be issues here, but early drafts can be in a > state where they're going to change extensively and are unlikely to be > used by anyone. There's also the question of "what is an official > release of a draft specification?". > That's a bit awkward right now: the current ratified ISA manual > contains version 0.3 of the hypervisor extension, but I just talked to > Andrew and the plan is to remove the draft extensions from the > ratified manuals because these drafts are old and the official manuals > update slowly. For now I guess we'll need an an-hoc way of > determining if a draft extension has been officially versioned or not, > which is a bit of a headache. > > We already have examples of supporting draft extensions, including > priv-1.9.1. This does cause some pain for us on the QEMU side (CSR > bits have different semantics between the specs), but there's 1.9.1 > hardware out there and the port continues to be useful so I'd be in > favor of keeping it around for now. I suppose there is an implicit > risk that draft extensions will be deprecated, but the "x-" prefix, > draft status, and long deprecation period should be sufficient to > inform users of the risk. I wouldn't be opposed to adding a "this is > a draft ISA" warning, but I feel like it might be a bit overkill. > Hi, Palmer Maybe it is the headache of open source hardware. Everyone cooperates to build a better architecture. In my opinion, we should focus on the future. The code in QEMU mainline should evolve to the ratified extension step by step, and only support the best extension at last. At that time, even many hardwares just support the deprecated draft extension, the draft codes should be in the wild and maintained by the hardware manufactures. But before that, it is better to have a draft implementation. So that We can work step by step to accelerate the coming of the ratified extension. Even at last draft extension implementation are deprecated, they are not meaningless. The manufactures may use the history commit to support their hardwares that only support drafted extension. Best Regards, Zhiwei >> >> Alistair >> >>> >>> thanks >>> -- PMM > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] RISC-V: Vector && DSP Extension 2019-08-22 1:50 ` [Qemu-devel] " liuzhiwei @ 2019-08-22 22:37 ` Alistair Francis 2019-08-28 0:25 ` Palmer Dabbelt 0 siblings, 1 reply; 17+ messages in thread From: Alistair Francis @ 2019-08-22 22:37 UTC (permalink / raw) To: liuzhiwei Cc: Peter Maydell, open list:RISC-V, Sagar Karandikar, bastian, Palmer Dabbelt, Jonathan Behrens, qemu-devel@nongnu.org Developers, Alistair Francis, Aleksandar Markovic On Wed, Aug 21, 2019 at 6:56 PM liuzhiwei <zhiwei_liu@c-sky.com> wrote: > > > On 2019/8/22 上午3:31, Palmer Dabbelt wrote: > > On Thu, 15 Aug 2019 14:37:52 PDT (-0700), alistair23@gmail.com wrote: > >> On Thu, Aug 15, 2019 at 2:07 AM Peter Maydell > >> <peter.maydell@linaro.org> wrote: > >>> > >>> On Thu, 15 Aug 2019 at 09:53, Aleksandar Markovic > >>> <aleksandar.m.mail@gmail.com> wrote: > >>> > > >>> > > We can accept draft > >>> > > extensions in QEMU as long as they are disabled by default. > >>> > >>> > Hi, Alistair, Palmer, > >>> > > >>> > Is this an official stance of QEMU community, or perhaps Alistair's > >>> > personal judgement, or maybe a rule within risv subcomunity? > >>> > >>> Alistair asked on a previous thread; my view was: > >>> https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg03364.html > >>> and nobody else spoke up disagreeing (summary: should at least be > >>> disabled-by-default and only enabled by setting an explicit > >>> property whose name should start with the 'x-' prefix). > >> > >> Agreed! > >> > >>> > >>> In general QEMU does sometimes introduce experimental extensions > >>> (we've had them in the block layer, for example) and so the 'x-' > >>> property to enable them is a reasonably established convention. > >>> I think it's a reasonable compromise to allow this sort of work > >>> to start and not have to live out-of-tree for a long time, without > >>> confusing users or getting into a situation where some QEMU > >>> versions behave differently or to obsolete drafts of a spec > >>> without it being clear from the command line that experimental > >>> extensions are being enabled. > >>> > >>> There is also an element of "submaintainer judgement" to be applied > >>> here -- upstream is probably not the place for a draft extension > >>> to be implemented if it is: > >>> * still fast moving or subject to major changes of design direction > >>> * major changes to the codebase (especially if it requires > >>> changes to core code) that might later need to be redone > >>> entirely differently > >>> * still experimental > >> > >> Yep, agreed. For RISC-V I think this would extend to only allowing > >> extensions that have backing from the foundation and are under active > >> discussion. > > > > My general philosophy here is that we'll take anything written down in > > an official RISC-V ISA manual (ie, the ones actually released by the > > foundation). This provides a single source of truth for what an > > extension name / version means, which is important to avoid > > confusion. If it's a ratified extension then I see no reason not to > > support it on my end. For frozen extensions we should probably just > > wait the 45 days until they go up for a ratification vote, but I'd be > > happy to start reviewing patches then (or earlier :)). > > > > If the spec is a draft in the ISA manual then we need to worry about > > the support burden, which I don't have a fixed criteria for -- > > generally there shouldn't be issues here, but early drafts can be in a > > state where they're going to change extensively and are unlikely to be > > used by anyone. There's also the question of "what is an official > > release of a draft specification?". > > That's a bit awkward right now: the current ratified ISA manual > > contains version 0.3 of the hypervisor extension, but I just talked to > > Andrew and the plan is to remove the draft extensions from the > > ratified manuals because these drafts are old and the official manuals > > update slowly. For now I guess we'll need an an-hoc way of > > determining if a draft extension has been officially versioned or not, > > which is a bit of a headache. > > > > We already have examples of supporting draft extensions, including > > priv-1.9.1. This does cause some pain for us on the QEMU side (CSR > > bits have different semantics between the specs), but there's 1.9.1 > > hardware out there and the port continues to be useful so I'd be in > > favor of keeping it around for now. I suppose there is an implicit > > risk that draft extensions will be deprecated, but the "x-" prefix, > > draft status, and long deprecation period should be sufficient to > > inform users of the risk. I wouldn't be opposed to adding a "this is > > a draft ISA" warning, but I feel like it might be a bit overkill. > > > Hi, Palmer > > Maybe it is the headache of open source hardware. Everyone cooperates to > build a better architecture. > > In my opinion, we should focus on the future. The code in QEMU mainline > should evolve to the ratified extension step by step, and only support > the best extension at last. > > At that time, even many hardwares just support the deprecated draft > extension, the draft codes should be in the wild and maintained by the > hardware manufactures. > > But before that, it is better to have a draft implementation. So that > We can work step by step to accelerate the coming of the ratified > extension. > > Even at last draft extension implementation are deprecated, they are not > meaningless. The manufactures may use the history commit to support > their hardwares that > > only support drafted extension. Overall I agree with Palmer that we should accept all extensions in the RISC-V foundations ISA manual once the extension has reached some level of maturity. I think it then makes sense to only keep the latest version of these drafts until they are ratified. At that point we do have to support the ratified version for longer. Alistair > > Best Regards, > > Zhiwei > > >> > >> Alistair > >> > >>> > >>> thanks > >>> -- PMM > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] RISC-V: Vector && DSP Extension 2019-08-22 22:37 ` Alistair Francis @ 2019-08-28 0:25 ` Palmer Dabbelt 0 siblings, 0 replies; 17+ messages in thread From: Palmer Dabbelt @ 2019-08-28 0:25 UTC (permalink / raw) To: alistair23 Cc: Peter Maydell, qemu-riscv, sagark, bastian, fintelia, qemu-devel, Alistair Francis, zhiwei_liu, aleksandar.m.mail On Thu, 22 Aug 2019 15:37:15 PDT (-0700), alistair23@gmail.com wrote: > On Wed, Aug 21, 2019 at 6:56 PM liuzhiwei <zhiwei_liu@c-sky.com> wrote: >> >> >> On 2019/8/22 上午3:31, Palmer Dabbelt wrote: >> > On Thu, 15 Aug 2019 14:37:52 PDT (-0700), alistair23@gmail.com wrote: >> >> On Thu, Aug 15, 2019 at 2:07 AM Peter Maydell >> >> <peter.maydell@linaro.org> wrote: >> >>> >> >>> On Thu, 15 Aug 2019 at 09:53, Aleksandar Markovic >> >>> <aleksandar.m.mail@gmail.com> wrote: >> >>> > >> >>> > > We can accept draft >> >>> > > extensions in QEMU as long as they are disabled by default. >> >>> >> >>> > Hi, Alistair, Palmer, >> >>> > >> >>> > Is this an official stance of QEMU community, or perhaps Alistair's >> >>> > personal judgement, or maybe a rule within risv subcomunity? >> >>> >> >>> Alistair asked on a previous thread; my view was: >> >>> https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg03364.html >> >>> and nobody else spoke up disagreeing (summary: should at least be >> >>> disabled-by-default and only enabled by setting an explicit >> >>> property whose name should start with the 'x-' prefix). >> >> >> >> Agreed! >> >> >> >>> >> >>> In general QEMU does sometimes introduce experimental extensions >> >>> (we've had them in the block layer, for example) and so the 'x-' >> >>> property to enable them is a reasonably established convention. >> >>> I think it's a reasonable compromise to allow this sort of work >> >>> to start and not have to live out-of-tree for a long time, without >> >>> confusing users or getting into a situation where some QEMU >> >>> versions behave differently or to obsolete drafts of a spec >> >>> without it being clear from the command line that experimental >> >>> extensions are being enabled. >> >>> >> >>> There is also an element of "submaintainer judgement" to be applied >> >>> here -- upstream is probably not the place for a draft extension >> >>> to be implemented if it is: >> >>> * still fast moving or subject to major changes of design direction >> >>> * major changes to the codebase (especially if it requires >> >>> changes to core code) that might later need to be redone >> >>> entirely differently >> >>> * still experimental >> >> >> >> Yep, agreed. For RISC-V I think this would extend to only allowing >> >> extensions that have backing from the foundation and are under active >> >> discussion. >> > >> > My general philosophy here is that we'll take anything written down in >> > an official RISC-V ISA manual (ie, the ones actually released by the >> > foundation). This provides a single source of truth for what an >> > extension name / version means, which is important to avoid >> > confusion. If it's a ratified extension then I see no reason not to >> > support it on my end. For frozen extensions we should probably just >> > wait the 45 days until they go up for a ratification vote, but I'd be >> > happy to start reviewing patches then (or earlier :)). >> > >> > If the spec is a draft in the ISA manual then we need to worry about >> > the support burden, which I don't have a fixed criteria for -- >> > generally there shouldn't be issues here, but early drafts can be in a >> > state where they're going to change extensively and are unlikely to be >> > used by anyone. There's also the question of "what is an official >> > release of a draft specification?". >> > That's a bit awkward right now: the current ratified ISA manual >> > contains version 0.3 of the hypervisor extension, but I just talked to >> > Andrew and the plan is to remove the draft extensions from the >> > ratified manuals because these drafts are old and the official manuals >> > update slowly. For now I guess we'll need an an-hoc way of >> > determining if a draft extension has been officially versioned or not, >> > which is a bit of a headache. >> > >> > We already have examples of supporting draft extensions, including >> > priv-1.9.1. This does cause some pain for us on the QEMU side (CSR >> > bits have different semantics between the specs), but there's 1.9.1 >> > hardware out there and the port continues to be useful so I'd be in >> > favor of keeping it around for now. I suppose there is an implicit >> > risk that draft extensions will be deprecated, but the "x-" prefix, >> > draft status, and long deprecation period should be sufficient to >> > inform users of the risk. I wouldn't be opposed to adding a "this is >> > a draft ISA" warning, but I feel like it might be a bit overkill. >> > >> Hi, Palmer >> >> Maybe it is the headache of open source hardware. Everyone cooperates to >> build a better architecture. >> >> In my opinion, we should focus on the future. The code in QEMU mainline >> should evolve to the ratified extension step by step, and only support >> the best extension at last. >> >> At that time, even many hardwares just support the deprecated draft >> extension, the draft codes should be in the wild and maintained by the >> hardware manufactures. >> >> But before that, it is better to have a draft implementation. So that >> We can work step by step to accelerate the coming of the ratified >> extension. >> >> Even at last draft extension implementation are deprecated, they are not >> meaningless. The manufactures may use the history commit to support >> their hardwares that >> >> only support drafted extension. > > Overall I agree with Palmer that we should accept all extensions in > the RISC-V foundations ISA manual once the extension has reached some > level of maturity. > > I think it then makes sense to only keep the latest version of these > drafts until they are ratified. At that point we do have to support > the ratified version for longer. My number one constraint here is that QEMU remains a useful tool. I'd love to support every version of every extension ever published (along with allowing for control of all the optional features), but there are just more important things to do so that's not going to happen. That said, I also want to make sure that there is some stability in QEMU -- specifically because having a RISC-V implementation that supports multiple targets is very useful. I started hacking on QEMU because I wanted to test my other software and it's just too cumbersome to keep around a pile of RISC-V implementations to test everything against. In terms of which drafts we keep, I think it's best to just play this by ear -- for example, I'd be in favor of keeping draft extensions around if they end up widely implemented, and doubly so if they're similar to the ratified extension. The CLIC would be a good candidate for this: it's in all sorts of hardware, but the actual ratified spec may be a bit different than the drafts. In that case I'd be in favor of keeping around the draft specs for a long time, as they're probably going to be pretty easy to support. > Alistair > >> >> Best Regards, >> >> Zhiwei >> >> >> >> >> Alistair >> >> >> >>> >> >>> thanks >> >>> -- PMM >> > ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2019-08-28 0:26 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-08-08 9:39 [Qemu-devel] RISC-V: Vector && DSP Extension liuzhiwei 2019-08-08 11:29 ` Aleksandar Markovic 2019-08-08 13:48 ` Chih-Min Chao 2019-08-08 14:19 ` Aleksandar Markovic 2019-08-10 13:35 ` LIU ZhiWei 2019-08-10 1:54 ` Alistair Francis 2019-08-10 13:55 ` LIU ZhiWei 2019-08-11 16:50 ` Alistair Francis 2019-08-15 8:53 ` Aleksandar Markovic 2019-08-15 9:07 ` Peter Maydell 2019-08-15 10:32 ` Aleksandar Markovic 2019-08-15 21:37 ` Alistair Francis 2019-08-21 19:31 ` Palmer Dabbelt 2019-08-21 23:10 ` [Qemu-devel] [Qemu-riscv] " Jonathan Behrens 2019-08-22 1:50 ` [Qemu-devel] " liuzhiwei 2019-08-22 22:37 ` Alistair Francis 2019-08-28 0:25 ` Palmer Dabbelt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).