On Thu, 31 Dec 2020 at 08:46, Roger Pau Monné <roger....@citrix.com> wrote: > > On Wed, Dec 30, 2020 at 11:30:03AM +0000, Julien Grall wrote: > > Hi Roger, > > > > On 29/12/2020 09:17, Roger Pau Monné wrote: > > > On Wed, Dec 23, 2020 at 04:32:01PM -0500, Rich Persaud wrote: > > > > On Dec 17, 2020, at 07:13, Jean-Philippe Ouellet <j...@vt.edu> wrote: > > > > > On Wed, Dec 16, 2020 at 2:37 PM Christopher Clark > > > > > <christopher.w.cl...@gmail.com> wrote: > > > > > > Hi all, > > > > > > > > > > > > I have written a page for the OpenXT wiki describing a proposal for > > > > > > initial development towards the VirtIO-Argo transport driver, and > > > > > > the > > > > > > related system components to support it, destined for OpenXT and > > > > > > upstream projects: > > > > > > > > > > > > https://openxt.atlassian.net/wiki/spaces/~cclark/pages/1696169985/VirtIO-Argo+Development+Phase+1 > > > > > > Thanks for the detailed document, I've taken a look and there's indeed > > > 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 implemented > > > right now is using hypercalls, which is a mechanism specific to Xen. > > The concept of hypervisor call is not Xen specific. Any other hypervisor 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 mind > > 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,
