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

[Xen-devel] Re: xencomm address space API

This means that the hypervisor must track multiple registered buffers
per domain. (In the general case this could be an arbitrary number, but
I guess it would need to be limited to prevent a domain from exhausting
the Xen heap.)

I would expect all registering to be done by the guest kernel. The guest kernel has to register pages of memory that belong to the guest, and specify a location in the hypercall address space to register them at. There is memory usage in Xen to store the translation from hypercall address to physical address, but the transfer memory itself is provided by the guest.

That also means that each hcall must somehow indicate which buffer
should be used with its arguments. I think that could be done by
encoding the buffer ID into the memory reference, necessitating an API
like this:

The alloc_buf() routine returns a handle. We provide a function for turning that into a pointer for the application/kernel to dereference. The handle is poked into hypercall structures/arguments where raw pointers would currently be passed.

By the way -- I mean that alloc_buf() is decoupled from registering hypercall memory. I expect the kernel to register a chunk of memory at start of day, and then run an allocator over that chunk. Only register more/bigger chunks when alloc_buf() cannot succeed.

In Xen, copy_from_user(xenbuf, memref) would then decode memref to
figure out what buffer was being referred to. copy_from_user would then
need to understand the data structures used by userland to track the
memory references within the buffer.

Callers of copy_from_user() already know where the user pointers/handles are that need special treatment.

Problem #2: Spanning pages is still really difficult. One possible
solution (different from above) would be to have the kernel reserve some
physically contiguous pages, and then export that area by having
userland mmap some device.

Easy for application/kernel where the pages can be mapped contiguously. Only a problem for ppc xen which does not run with paging enabled. But page crossings can be hidden inside copy_to_user/copy_from_user.

Problem #3: We need to know beforehand the maximum number of bytes
needed for the buffer.

Nope I don't think so.

Problem #4: The kernel must track the buffers that userland registered,
and unregister them when the process dies, since it may not have been
able to unregister them properly.

Yes. Applications should get hypercall-capable memory by mmap()ing a device file (e.g., privcmd). That can then be resource tracked.

This mail isn't comprehensive, but I think gives some idea of the
complexity involved. So a solution like replacing pointers with embedded
structures is far more attractive.

Not sure what you mean. Can you give an example?

 -- Keir

Hollis Blanchard
IBM Linux Technology Center

Xen-devel mailing list



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