|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [RFC][PATCH 00/13] Fix RMRR
RMRR is an acronym for Reserved Memory Region Reporting, expected to
be used for legacy usages (such as USB, UMA Graphics, etc.) requiring
reserved memory. Special treatment is required in system software to
setup those reserved regions in IOMMU translation structures, otherwise
passing through a device with RMRR reported may not work correctly.
This patch set tries to enhance existing Xen RMRR implementation to fix
various reported and theoretical problems. Most noteworthy changes are
to setup identity mapping in p2m layer and handle possible conflicts between
reported regions and gfn space. Initial proposal can be found at:
http://lists.xenproject.org/archives/html/xen-devel/2015-01/msg00524.html
and after a long discussion a summarized agreement is here:
http://lists.xen.org/archives/html/xen-devel/2015-01/msg01580.html
Below is a key summary of this patch set according to agreed proposal:
1. Use RDM (Reserved Device Memory) name in user space as a general
description instead of using ACPI RMRR name directly.
2. Introduce configuration parameters to allow user control both per-device
and global RDM resources along with desired policies upon a detected conflict.
3. Introduce a new hypercall to query global and per-device RDM resources.
4. Extend libxl to be a central place to manage RDM resources and handle
potential conflicts between reserved regions and gfn space. One simplification
goal is made to keep existing lowmem / mmio / highmem layout which is
passed around various function blocks. So a reasonable assumption
is made, that conflicts falling into below areas are not re-arranged otherwise
it will result in a more scattered layout:
a) in highmem region (>4G)
b) in lowmem region, and below a predefined boundary (default 2G)
a) is a new assumption not discussed before. From VT-d spec this is
possible but no such observation in real-world. So we can make this
reasonable assumption until there's real usage on it.
5. Extend XENMEM_set_memory_map usable for HVM guest, and then have
libxl to use that hypercall to carry RDM information to hvmloader. There
is one difference from original discussion. Previously we discussed to
introduce a new E820 type specifically for RDM entries. After more thought
we think it's OK to just tag them as E820_reserved. Actually hvmloader
doesn't need to know whether the reserved entries come from RDM or
from other purposes.
6. Then in hvmloader the change is generic for XENMEM_memory_map
change. Given a predefined memory layout, hvmloader should avoid
allocating all reserved entries for other usages (opregion, mmio, etc.)
7. Extend existing device passthrough hypercall to carry conflict handling
policy.
8. Setup identity map in p2m layer for RMRRs reported for the given
device. And conflicts are handled according to specified policy in hypercall.
Current patch set contains core enhancements calling for comments.
There are still several tasks not implemented now. We'll include them
in final version after RFC is agreed:
- remove existing USB hack
- detect and fail assigning device which has a shared RMRR with another device
- add a config parameter to configure that memory boundary flexibly
- In the case of hotplug we also need to figure out a way to fix that policy
conflict between the per-pci policy and the global policy but firstly we think
we'd better collect some good or correct ideas to step next in RFC.
So here I made this as RFC to collect your any comments.
----------------------------------------------------------------
Jan Beulich (1):
introduce XENMEM_reserved_device_memory_map
Tiejun Chen (12):
tools: introduce some new parameters to set rdm policy
tools/libxc: Expose new hypercall xc_reserved_device_memory_map
tools/libxl: detect and avoid conflicts with RDM
xen/x86/p2m: introduce set_identity_p2m_entry
xen:vtd: create RMRR mapping
xen/passthrough: extend hypercall to support rdm reservation policy
tools: extend xc_assign_device() to support rdm reservation policy
xen: enable XENMEM_set_memory_map in hvm
tools: extend XENMEM_set_memory_map
hvmloader: get guest memory map into memory_map[]
hvmloader/pci: skip reserved ranges
hvmloader/e820: construct guest e820 table
docs/man/xl.cfg.pod.5 | 44 +++++
docs/misc/vtd.txt | 34 ++++
tools/firmware/hvmloader/e820.c | 40 ++--
tools/firmware/hvmloader/e820.h | 7 +
tools/firmware/hvmloader/hvmloader.c | 36 ++++
tools/firmware/hvmloader/pci.c | 19 +-
tools/firmware/hvmloader/util.c | 25 +++
tools/firmware/hvmloader/util.h | 10 +
tools/libxc/include/xenctrl.h | 19 +-
tools/libxc/include/xenguest.h | 3 +-
tools/libxc/xc_domain.c | 80 +++++++-
tools/libxc/xc_hvm_build_x86.c | 28 +--
tools/libxl/libxl_create.c | 7 +-
tools/libxl/libxl_dm.c | 195 ++++++++++++++++++++
tools/libxl/libxl_dom.c | 99 +++++++++-
tools/libxl/libxl_internal.h | 11 +-
tools/libxl/libxl_pci.c | 11 +-
tools/libxl/libxl_types.idl | 25 +++
tools/libxl/libxlu_pci.c | 78 ++++++++
tools/libxl/libxlutil.h | 4 +
tools/libxl/xl_cmdimpl.c | 44 ++++-
tools/libxl/xl_cmdtable.c | 2 +-
tools/ocaml/libs/xc/xenctrl_stubs.c | 17 +-
tools/python/xen/lowlevel/xc/xc.c | 29 ++-
xen/arch/x86/hvm/hvm.c | 2 -
xen/arch/x86/mm.c | 6 -
xen/arch/x86/mm/p2m.c | 30 +++
xen/common/compat/memory.c | 66 +++++++
xen/common/memory.c | 63 +++++++
xen/drivers/passthrough/amd/pci_amd_iommu.c | 3 +-
xen/drivers/passthrough/iommu.c | 10 +
xen/drivers/passthrough/pci.c | 10 +-
xen/drivers/passthrough/vtd/dmar.c | 32 ++++
xen/drivers/passthrough/vtd/extern.h | 1 +
xen/drivers/passthrough/vtd/iommu.c | 37 +++-
xen/include/asm-x86/p2m.h | 4 +
xen/include/public/domctl.h | 4 +
xen/include/public/memory.h | 32 +++-
xen/include/xen/iommu.h | 6 +-
xen/include/xen/pci.h | 2 +
xen/include/xlat.lst | 3 +-
41 files changed, 1101 insertions(+), 77 deletions(-)
Thanks
Tiejun
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |