Guy Zana
2007-May-31 23:05 UTC
[Xen-devel] [RFC][PATCH 3/6] HVM PCI Passthrough (non-IOMMU)
1to1.patch:
- Added functionality in libxc / Hypervisor in order to populate a
HVM P2M
table in a 1:1 fashion. This is imperative for DMA to function
correctly.
- Early setup of the e820 memory map table is done in order to
"steal"
memory from dom0 and mark that stolen memory as NEO_1TO1, later
those
would be given to NativeDom.
- The first 12MB of NativDom are remapped, because Xen resides in
this region in x86_32. If a DMA address is to be allocated in that
region, there could be unpredicted result. This could be solved by
moving
Xen up in the x86_32 arch, or by abandoning it and using x86_64
where Xen
is already relocated to high memory (currently, Neocleus'' patches
support
x86_32).
- Memory protection: Regions that are marked "usable" for Dom0,
are
being
marked "reserved" for NativeDom and the corresponding mfns are
not
being
populated in NativeDom''s P2M table, whenever the guest accesses
those
addresses, a mm_access callback is called, which is calling
domain_crash_synchronic: this is used for debugging purposes only.
A more
mature implementation should inject a #GPF or crash the NativeDom.
- New hypercalls:
HVMOP_copy_nativedom_e820_map
XENMEM_populate_1to1_physmap
- Known bugs:
- domain destruction isn''t handled, so you have only one chance
to launch NativeDom on each boot.
- Known issue: this haven''t been figured out completely yet,
but
it
seems that the 32bit bios relocation code exceeds available
memory.
Search for "NEO TODO: (hack) malloc size multipled by 20" to
see the
temporary hack that overcomes this...
Signed-off-by: Guy Zana <guy@neocleus.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel