[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 13/25] argo: implement the register op

On Sun, Dec 2, 2018 at 12:11 PM Julien Grall <Julien.Grall@xxxxxxx> wrote:
> On 01/12/2018 01:32, Christopher Clark wrote:
> > diff --git a/xen/include/public/argo.h b/xen/include/public/argo.h
> > index 20dabc0..5ad8e2b 100644
> > --- a/xen/include/public/argo.h
> > +++ b/xen/include/public/argo.h
> > @@ -21,6 +21,20 @@
> >
> >   #include "xen.h"
> >
> > +#define ARGO_RING_MAGIC      0xbd67e163e7777f2fULL
> > +
> > +#define ARGO_DOMID_ANY           DOMID_INVALID
> > +
> > +/*
> > + * The maximum size of an Argo ring is defined to be: 16GB
> > + *  -- which is 0x1000000 or 16777216 bytes.
> > + * A byte index into the ring is at most 24 bits.
> > + */
> > +#define ARGO_MAX_RING_SIZE  (16777216ULL)
> > +
> > +/* pfn type: 64-bit on all architectures to aid avoiding a compat ABI */
> > +typedef uint64_t argo_pfn_t;
> As you always use 64-bit, can we just use an address? This would make
> the ABI agnostic to the hypervisor page granularity.

Thanks for reviewing this series.

I'm not sure yet that switching to using addresses instead would be
for the best, so have been working through some reasoning about your
suggestion. This interface is for the guest to identify to the
hypervisor the list of frames of memory to use as the ring, and the
purpose of a frame number is to uniquely identify a frame. Frame
numbers, as opposed to addresses, are going to remain the same across
all processors, independent of the page tables that happen to
currently be in use.

Where possible, translation should be performed by the guest rather
than the hypervisor, minimizing the hypervisor logic (good for several
reasons) - so it would be better to avoid adding the
address-to-page-number walk and granularity handling in the hypervisor
here. In this case, the guest has the incentive to do that work, given
that it wants to register the ring.

(Slightly out of scope, but hopefully not for long: We have a
near-term interest in using argo to communicate between VMs at
different levels of nesting in L0/L1 nested hypervisors, and I suspect
that frame number translation will end up being easier to handle
across L0/L1 than translation of guest addresses in a VM running at
the other level.)

Could you give a specific scenario you have in mind that is prompting a concern?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.