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 X-Spam-Level: X-Spam-Status: No, score=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DF77DC433E0 for ; Thu, 31 Dec 2020 11:03:15 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9215420780 for ; Thu, 31 Dec 2020 11:03:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9215420780 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.60511.106209 (Exim 4.92) (envelope-from ) id 1kuvjK-0008Fb-Jy; Thu, 31 Dec 2020 11:02:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 60511.106209; Thu, 31 Dec 2020 11:02:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kuvjK-0008FU-GG; Thu, 31 Dec 2020 11:02:54 +0000 Received: by outflank-mailman (input) for mailman id 60511; Thu, 31 Dec 2020 11:02:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kuvjJ-0008FP-MH for xen-devel@lists.xenproject.org; Thu, 31 Dec 2020 11:02:53 +0000 Received: from mail-wr1-x42c.google.com (unknown [2a00:1450:4864:20::42c]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ebe8e422-2334-4798-9250-f90471252faf; Thu, 31 Dec 2020 11:02:52 +0000 (UTC) Received: by mail-wr1-x42c.google.com with SMTP id i9so19830315wrc.4 for ; Thu, 31 Dec 2020 03:02:52 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ebe8e422-2334-4798-9250-f90471252faf DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xvYCiRm40T+IOndfILisAAlIvqeZAGx2ftumdhEjG58=; b=liXJ/Hhfcmaymy/3WHUZRo3qF9uEUdg1iPeGW+uSCirhhPUeuq7DjMoiSQ8ulwhEul H8/Q6aR5diKgAHj2sNu/F0sr7SJIvvdyRA4cyaanntdOM0z0/61M9qe4kX4Jj30SGINQ s8JG3TR2PYu4R0nBDdMAr/4KP6WQdIK2uJZERGSkmHs8KkXYDC7P9ZH/sqBaMn/rlxUw ycQdw29byDJwBPMXLOaDAi9BiQJf66MCY2Tvz8gtvkdFqq3tp+ms59V/KZvCBr6jWAYo mTkeK8VDsTEeHe4Y4qGaWtD0zsyQsTp4Pn/J+g5kf/8kQj2tUAQzDueMEZDqJ/m7zvQA sz1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xvYCiRm40T+IOndfILisAAlIvqeZAGx2ftumdhEjG58=; b=LiJ42MtCvr4Ml6h6HxVmGgbCajShhnaOBlRiiV43f6gfFDSNVRZBezwFDYWyTJK8S7 NZVLXVQib8MIFl/2YxiVEO54m2lrcUk/U5NjPpP8v2EjFx8Zp4HHsnjZ8VuFmnJn5Mlj 49Md1Hv+5abO2hP0y5pBjVEJYugSA4Ymk04zme4EY1cDv+mi1SOfR7DydRNcrXwLBvxX SGtoXpSWhK52hUuRjQTbD/WoQXn12seEbktaf+pS63YDRnsh9n7v/FYCIlmIMCbEZx0j ORqR/tIR8iSLrvp4UADY7AMTOmphSQ+M1EPurCd3jeYS/G5SSuCUMIE9w7vO4r1Em6hT 5+ZQ== X-Gm-Message-State: AOAM5333ArASD4O6aThxIwaKU0FI+kIxchIXyKGIljsUIfTaoSJSkVRV /WcvuSniSpWnDdA1JDsy8np0qSm3qP7+Na7LSTk= X-Google-Smtp-Source: ABdhPJwzgh3ckWmJJYQkSbenwffHePG+RSFmUgjh2OCViwgB7Y03yquEOlAC8V11OBDBgUpyBFXIJtsDS1WL5r9v1Jg= X-Received: by 2002:a5d:43d2:: with SMTP id v18mr64418085wrr.326.1609412571831; Thu, 31 Dec 2020 03:02:51 -0800 (PST) MIME-Version: 1.0 References: <20201229091730.owgpdeekb7pcex7t@Air-de-Roger> <20201231084556.ogvltixgd6ovlja2@Air-de-Roger> In-Reply-To: <20201231084556.ogvltixgd6ovlja2@Air-de-Roger> From: Julien Grall Date: Thu, 31 Dec 2020 11:02:40 +0000 Message-ID: Subject: Re: [openxt-dev] VirtIO-Argo initial development proposal To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Rich Persaud , Jean-Philippe Ouellet , Christopher Clark , openxt , xen-devel , Oleksandr Tyshchenko , Julien Grall , James McKenzie , Andrew Cooper , Paul Durrant Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 31 Dec 2020 at 08:46, Roger Pau Monn=C3=A9 w= rote: > > On Wed, Dec 30, 2020 at 11:30:03AM +0000, Julien Grall wrote: > > Hi Roger, > > > > On 29/12/2020 09:17, Roger Pau Monn=C3=A9 wrote: > > > On Wed, Dec 23, 2020 at 04:32:01PM -0500, Rich Persaud wrote: > > > > =EF=BB=BFOn Dec 17, 2020, at 07:13, Jean-Philippe Ouellet wrote: > > > > > =EF=BB=BFOn Wed, Dec 16, 2020 at 2:37 PM Christopher Clark > > > > > wrote: > > > > > > Hi all, > > > > > > > > > > > > I have written a page for the OpenXT wiki describing a proposal= for > > > > > > initial development towards the VirtIO-Argo transport driver, a= nd the > > > > > > related system components to support it, destined for OpenXT an= d > > > > > > upstream projects: > > > > > > > > > > > > https://openxt.atlassian.net/wiki/spaces/~cclark/pages/16961699= 85/VirtIO-Argo+Development+Phase+1 > > > > > > Thanks for the detailed document, I've taken a look and there's indee= d > > > a lot of work to do listed there :). I have some suggestion and > > > questions. > > > > > > Overall I think it would be easier for VirtIO to take a new transport > > > if it's not tied to a specific hypervisor. The way Argo is implemente= d > > > right now is using hypercalls, which is a mechanism specific to Xen. > > The concept of hypervisor call is not Xen specific. Any other hyperviso= r can > > easily implement them. At least this is the case on Arm because we have= an > > instruction 'hvc' that acts the same way as a syscall but for the > > hypervisor. > > > > What we would need to do is reserving a range for Argos. It should be > > possible to do it on Arm thanks to the SMCCC (see [1]). > > > > I am not sure whether you have something similar on x86. > > On x86 Intel has vmcall and AMD vmmcall, but those are only available > to HVM guests. Right, as it would for other architecture if one decided to implement PV (or binary translated) guests. While it may be possible to use a different way to communicate on x86 (see more below), I am not sure this would be the case for other architectures. The closest thing to MSR on Arm would be the System Registers. But I am not aware of a range of IDs that could be used by the software. > > > > IMO it might be easier to start by having an Argo interface using > > > MSRs, that all hypervisors can implement, and then base the VirtIO > > > implementation on top of that interface. > > My concern is the interface would need to be arch-specific. Would you m= ind > > to explain what's the problem to implement something based on vmcall? > > More of a recommendation than a concern, but I think it would be more > attractive for upstream if we could provide an interface to Argo (or > hypervisor mediated data exchange) that's no too tied into Xen > specifics. I agree with this statement. We also need an interface that is ideally not to arch-specific otherwise it will be more complicated to get adopted on other arch. For instance, at the moment, I don't really see what else can be used on Arm (other that MMIO and PCI) if you want to care about PV (or binary translated) guests. > My suggestion for using MSRs was because I think every x86 hypervisor > must have the logic to trap and handle some of those, and also every > OS has the helpers to read/write MSRs, and those instructions are not > vendor specific. In order to use MSRs, you would need to reserve a range of IDs. Do x86 have a range of ID that can be used for software purposes (i.e. the current and future processors will not use it)? Cheers,