Re: [openxt-dev] VirtIO-Argo initial development proposal

[Julien Grall <julien.grall.oss@xxxxxxxxx>]

On Thu, 31 Dec 2020 at 08:46, Roger Pau Monné <roger.pau@xxxxxxxxxx> 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 <jpo@xxxxxx> wrote:
> > > > > On Wed, Dec 16, 2020 at 2:37 PM Christopher Clark
> > > > > <christopher.w.clark@xxxxxxxxx> 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,