Re: [Xen-devel] [PATCH v2 11/18] argo: implement the register op

[Julien Grall <julien.grall@xxxxxxx>]

Hi Christopher,

On 12/20/18 6:39 AM, Christopher Clark wrote:
> Used by a domain to register a region of memory for receiving messages from
> either a specified other domain, or, if specifying a wildcard, any domain.
>
> This operation creates a mapping within Xen's private address space that
> will remain resident for the lifetime of the ring. In subsequent commits,
> the hypervisor will use this mapping to copy data from a sending domain into
> this registered ring, making it accessible to the domain that registered the
> ring to receive data.
>
> In this code, the p2m type of the memory supplied by the guest for the ring
> must be p2m_ram_rw, which is a conservative choice made to defer the need to
> reason about the other p2m types with this commit.
>
> xen_argo_page_descr_t type is introduced as a page descriptor, to convey
> both the physical address of the start of the page and its granularity. The
> smallest granularity page is assumed to be 4096 bytes and the lower twelve
> bits of the type are used for indicate an enumerated page size.
I haven't seen any reply from you on my concern with this approach (see 
[1]).
For convenience, I will duplicate the message here.

If you let the user the choice of the granularity, then, I believe, you 
will prevent the hypervisor to do some optimization.
For instance, if the guest supplies only 4KB page but the hypervisor is 
64KB. There are no way to easily map them contiguously in the hypervisor 
(e.g using vmap).
Is there a particular reason to allow the ring buffer to be 
non-contiguous in the guest physical address?
Depending on the answer, there are different way to handle that:
1) Request the guest to allocate memory using 64KB (on Arm) chunk and 
pass the base address for each chunk
2) Request the guest to allocate contiguously the buffer and pass the 
base address and size
Cheers,

[1] https://lists.xen.org/archives/html/xen-devel/2018-12/msg01038.html

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel