From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 314A4C433EF for ; Wed, 18 May 2022 06:49:09 +0000 (UTC) Received: from localhost ([::1]:45870 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nrDUZ-0006Wy-Rx for qemu-devel@archiver.kernel.org; Wed, 18 May 2022 02:49:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54592) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nrDKg-0002H5-Ux for qemu-devel@nongnu.org; Wed, 18 May 2022 02:39:04 -0400 Received: from mail-yw1-x112c.google.com ([2607:f8b0:4864:20::112c]:41413) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nrDKe-0007h1-81 for qemu-devel@nongnu.org; Wed, 18 May 2022 02:38:54 -0400 Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-2ebf4b91212so13656977b3.8 for ; Tue, 17 May 2022 23:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atishpatra.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dTW8eraBVxpmYsGNcjAJZmD5qCizZxUHHqabUGjRha8=; b=fLBhwm4IG//4zdcK9/RTVPGdIcne1+2LMdtBLKW6YcfGGEVMPHvnGmfNz0MGeV7plp f8oCmYX+MFm2p6iwn1IdTht0q/Nvkny75go5l1FbBvgVdentB3xJF9hYo/OTMjlBUWh1 1VMjgDQ/70/MClg6v2B8PLcOnQ2nxEsABj1a4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dTW8eraBVxpmYsGNcjAJZmD5qCizZxUHHqabUGjRha8=; b=IM3luLsW9GHkr8MWw8el96OI11nekcvkS8XtwwudJJbxujCXUGvw04lqNXsNHs0hfX WqCvD4vYvgD9QBEIHkT6QA7aP6yQH5qYV5MSaO5bu5nzeXTSe3mDIyK4ROc3/UzMZkqz FeB0tG/S76okXaC8dfNyhfUCl6Bq2WvwA0/3p0+hvBbdY5O8kEr5T6wRYUtDOvaaKC0G YVSzLiLnk4U1fx0cOuM+1Ww7gK1LiKos2a4/0bnWCjUJkXuSTokAjuLHoaulZFXqkpa+ ipSSzNxYXgFh7QjZGcCVnZ2ckqTnYvega7Y/K9ZM5fWB4LjuiJQjAqFioS5wNs1nYMnJ Kcbw== X-Gm-Message-State: AOAM5304KhfpCaW3sE4Rj8M+F5QV/NZpcF9Yo9SsnkvZncL1OJEqs2el 6vyjzD0lgeUlJ8ufMwhvOv8td+6ipEvdJXXUW//z X-Google-Smtp-Source: ABdhPJxQ3Iqtsqfvz/i02B4yfZF4XJupSjFshGRybEb/AiO9huUohfWehFFbiTZJ2mdZLYyHA58Mi87/sy5alIhowzc= X-Received: by 2002:a0d:e88c:0:b0:2fe:da96:1b77 with SMTP id r134-20020a0de88c000000b002feda961b77mr19438917ywe.262.1652855929928; Tue, 17 May 2022 23:38:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Atish Patra Date: Tue, 17 May 2022 23:38:39 -0700 Message-ID: Subject: Re: [RFC 0/3] Introduce a new Qemu machine for RISC-V To: Alistair Francis Cc: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , Atish Kumar Patra , Peter Maydell , "open list:RISC-V" , "Michael S. Tsirkin" , Bin Meng , "qemu-devel@nongnu.org Developers" , Alistair Francis , Paolo Bonzini , Palmer Dabbelt Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::112c; envelope-from=atishp@atishpatra.org; helo=mail-yw1-x112c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Tue, May 17, 2022 at 1:54 PM Alistair Francis wro= te: > > On Tue, May 17, 2022 at 6:52 PM Daniel P. Berrang=C3=A9 wrote: > > > > On Tue, May 17, 2022 at 03:03:38PM +1000, Alistair Francis wrote: > > > On Sat, May 7, 2022 at 6:30 AM Atish Kumar Patra wrote: > > > > > > > > On Fri, May 6, 2022 at 4:00 AM Peter Maydell wrote: > > > > > > > > > > On Fri, 6 May 2022 at 09:18, Daniel P. Berrang=C3=A9 wrote: > > > > > > > > > > > > On Fri, May 06, 2022 at 06:34:47AM +1000, Alistair Francis wrot= e: > > > > > > > Even if we didn't worry about backwards compatibility the cur= rent virt > > > > > > > machine would still be what most users want. It's just a smal= l number > > > > > > > of users who don't want MMIO devices and instead want to use = PCIe for > > > > > > > everything. Realistically it's only HPC users who would want = this type > > > > > > > of machine, at least that's my understanding. > > > > > > > > > > > > I'm not so sure about that. Every other architecture has ended = up > > > > > > standardizing on PCI for general purpose virtual machines. IIRC= , > > > > > > aarch64 started off with MMIO, but switched to PCI as it mature= d. > > > > > > > > > > > > In terms of having VM mgmt tools "just work" for risc-v, I thin= k > > > > > > it will be very compelling for the general 'virt' machine to be > > > > > > PCI based, otherwise all the assumptions about PCI in mgmt apps > > > > > > are going to break requiring never ending riscv fixes. > > > > > > > > > > Mmm, my experience with aarch64 virt is that PCI is much nicer > > > > > as a general preference. aarch64 virt has some MMIO devices > > > > > for historical reasons and some because you can't reasonably > > > > > do the necessary things with PCI, but I'm actively trying to > > > > > push people who submit new MMIO device features for virt to > > > > > try to use a PCI-based solution instead if they possibly can. > > > > > > Interesting... > > > > > > Ok, maybe calling this "virt-pcie" might be a good start, with the > > > expectation to eventually replace the current virt with the new > > > virt-pcie at some point. > > > > Delaying the inevitable by leaving PCIE support in a separate > > machine type initially is going to be more painful long term. > > > > > The other option would be to try and gradually change from the curren= t > > > virt machine to this new virt machine > > > > Yes, I really think the 'virt' machine type needs to aim for PCIE > > support sooner rather than later, if RISC-V wants to get on part > > with other architectures. The best time to have added PCIE support > > to 'virt' was when it was first created, the next best time is now. > > So maybe instead we lock in the current virt machine as the 7.1 virt > machine for QEMU 7.1, then work on migrating to a PCIe only machine > with versions (similar to the other archs) > I am not quite sure what exactly you mean here. Do you mean to modify the current virt machine to be PCIE only after QEMU 7.1 or the new PCIE only machine (with the versioning) which will be the default machine in the future If you intend to say the former, few issues with that approach. 1. virt machine is not well documented and already bloated. There is no specification for virt machine as such. Putting restrictions after a certain release will lead to confusion. 2. Do we support existing MMIO devices after that specific version or not ? 3. The user has to be aware of which version of virt machine it is running in order to test specific features (i.e. flash, reset, wired interrupts) 4. Based on the version of the virt machine, the command line options will change. This may also be confusing. On the other hand, the second approach will be much cleaner without any baggage. The RISC-V eco-system is still maturing and this is the right time to start something fresh. Let's call the new machine virt-pcie for now. Here are a few things that can be implemented for this machine. 1. It must support versioning and any changes to the machine code must modify the version of the machine. 2. It must only support MSI based PCIe devices. No support for wired interr= upts. The only allowed MMIO devices are -- mtimer/mtimecmp (there is no other option provided in ISA) -- reset/rtc device (If there is a way we can emulate these two over PCIe, that would be great) -- flash Beyond this, adding any other MMIO device must be strongly discouraged. 3. The virt-pcie machine must be well documented similar to a hardware specification (including address range, restrictions and implemented/allowed devices) 4. No dependence on virtio framework but must work with virtio-pcie backend= . 5. Migration must be supported. 6. No command line option is required. 7. Any other ? Once we have these policies in place, this can be the preferred virt machine and the current virt machine can be phased out or continue to co-exist as a more flexible experimental platform. Thoughts ? > Alistair > > > > > With regards, > > Daniel > > -- > > |: https://berrange.com -o- https://www.flickr.com/photos/dberr= ange :| > > |: https://libvirt.org -o- https://fstop138.berrange= .com :| > > |: https://entangle-photo.org -o- https://www.instagram.com/dberr= ange :| > > --=20 Regards, Atish