This patch adds a new 'designs' subdirectory under docs as a repository for this and future design proposals.
Signed-off-by: Paul Durrant <paul.durr...@citrix.com> --- For convenience this document can also be viewed in PDF at: http://xenbits.xen.org/people/pauldu/hvmmem_ioreq_server.pdf --- docs/designs/hvmmem_ioreq_server.md | 63 +++++++++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100755 docs/designs/hvmmem_ioreq_server.md diff --git a/docs/designs/hvmmem_ioreq_server.md b/docs/designs/hvmmem_ioreq_server.md new file mode 100755 index 0000000..47fa715 --- /dev/null +++ b/docs/designs/hvmmem_ioreq_server.md @@ -0,0 +1,63 @@ +HVMMEM\_ioreq\_serverX +---------------------- + +Background +========== + +The concept of the IOREQ server was introduced to allow multiple distinct +device emulators to a single VM. The XenGT project uses an IOREQ server to +provide mediated pass-through of Intel GPUs to guests and, as part of the +mediation, needs to intercept accesses to GPU page-tables (or GTTs) that +reside in guest RAM. + +The current implementation of this sets the type of GTT pages to type +HVMMEM\_mmio\_write\_dm, which causes Xen to emulate writes to such pages, +and then maps the guest physical addresses of those pages to the XenGT +IOREQ server using the HVMOP\_map\_io\_range\_to\_ioreq\_server hypercall. +However, because the number of GTTs is potentially large, using this +approach does not scale well. + +Proposal +======== + +Because the number of spare types available in the P2M type-space is +currently very limited it is proposed that HVMMEM\_mmio\_write\_dm be +replaced by a single new type HVMMEM\_ioreq\_server. In future, if the +P2M type-space is increased, this can be renamed to HVMMEM\_ioreq\_server0 +and new HVMMEM\_ioreq\_server1, HVMMEM\_ioreq\_server2, etc. types +can be added. + +Accesses to a page of type HVMMEM\_ioreq\_serverX should be the same as +HVMMEM\_ram\_rw until the type is _claimed_ by an IOREQ server. Furthermore +it should only be possible to set the type of a page to +HVMMEM\_ioreq\_serverX if that page is currently of type HVMMEM\_ram\_rw. + +To allow an IOREQ server to claim or release a claim to a type a new pair +of hypercalls will be introduced: + +- HVMOP\_map\_mem\_type\_to\_ioreq\_server +- HVMOP\_unmap\_mem\_type\_from\_ioreq\_server + +and an associated argument structure: + + struct hvm_ioreq_mem_type { + domid_t domid; /* IN - domain to be serviced */ + ioservid_t id; /* IN - server id */ + hvmmem_type_t type; /* IN - memory type */ + uint32_t flags; /* IN - types of access to be + intercepted */ + + #define _HVMOP_IOREQ_MEM_ACCESS_READ 0 + #define HVMOP_IOREQ_MEM_ACCESS_READ \ + (1 << _HVMOP_IOREQ_MEM_ACCESS_READ) + + #define _HVMOP_IOREQ_MEM_ACCESS_WRITE 1 + #define HVMOP_IOREQ_MEM_ACCESS_WRITE \ + (1 << _HVMOP_IOREQ_MEM_ACCESS_WRITE) + + }; + + +Once the type has been claimed then the requested types of access to any +page of the claimed type will be passed to the IOREQ server for handling. +Only HVMMEM\_ioreq\_serverX types may be claimed. -- 2.1.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel