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 <pal...@sifive.com> wrote: > On Thu, 15 Aug 2019 14:37:52 PDT (-0700), alistai...@gmail.com wrote: > > On Thu, Aug 15, 2019 at 2:07 AM Peter Maydell <peter.mayd...@linaro.org> > wrote: > >> > >> On Thu, 15 Aug 2019 at 09:53, Aleksandar Markovic > >> <aleksandar.m.m...@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 > >
