mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 02:01:24 +01:00
George Dunlap
c9e4365d34
There was a question raised recently about the requirements for checking in a patch which was originally written by one maintainer, then picked up and modified by a second maintainer, and which they now both agree should be checked in. It was proposed that in that case, the following set of tags would suffice: Signed-off-by: First Author <...> Signed-off-by: Second Author <...> Reviewed-by: First Author <...> The rationale was as follows: 1. The patch will be a mix of code, whose copyright is owned by the various authors (or the companies they work for). It's important to keep this information around in the event, for instance, of a license change or something else requiring knowledge of the copyright owner. 2. The Signed-off-by of the Second Author approves not only their own code, but First Author's code; the Reviewed-by of the First Author approves not only their own code, but the Second Author's code. Thus all the code has been approved by a maintainer, as well as someone who was not the author. In support of this, several arguments were put forward: * We shouldn't make it harder for maintainers to get their code in than for non-maintainers * The system we set up should not add pointless bureaucracy; nor discourage collaboration; nor encourage contributors to get around the rules by dropping important information. (For instance, by removing the first SoB, so that the patch appears to have been written entirely by Second Author.) Concerns were raised about two maintainers from the same company colluding to get a patch in from their company; but such maintainers could already collude, by working on the patch in secret, and posting it publicly with only a single author's SoB, and having the other person review it. There's also something slightly strange about adding "Reviewed-by" to code that you've written; but in the end you're reviewing not only the code itself, but the final arrangement of it. There's no need to overcomplicate things. Encode this in MAINTAINERS as follows: * Refine the wording of requirement #2 in the check-in policy; such that *each change* must have approval from someone other than *the person who wrote it*. * Add a paragraph explicitly stating that the multiple-SoB-approval system satisfies the requirements, and why. Signed-off-by: George Dunlap <george.dunlap@cloud.com> Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Julien Grall <jgrall@amazon.com>
685 lines
20 KiB
Plaintext
685 lines
20 KiB
Plaintext
|
|
List of maintainers and how to submit changes
|
|
=============================================
|
|
|
|
Please try to follow the guidelines below. This will make things
|
|
easier on the maintainers. Not all of these guidelines matter for every
|
|
trivial patch so apply some common sense.
|
|
|
|
1. Always _test_ your changes, however small, on at least 4 or
|
|
5 people, preferably many more.
|
|
|
|
2. Make sure your changes compile correctly in multiple
|
|
configurations. For example, both 32- and 64-bit x86.
|
|
|
|
3. Make a patch available to the relevant maintainer in the list. Use
|
|
'diff -u' to make the patch easy to merge. Be prepared to get your
|
|
changes sent back with seemingly silly requests about formatting
|
|
and variable names. These aren't as silly as they seem. One
|
|
job the maintainers do is to keep things looking the same.
|
|
|
|
PLEASE see https://wiki.xenproject.org/wiki/Submitting_Xen_Patches for
|
|
hints on how to submit a patch to xen-unstable in a suitable
|
|
form.
|
|
|
|
PLEASE try to include any credit lines you want added with the
|
|
patch. It avoids people being missed off by mistake and makes
|
|
it easier to know who wants adding and who doesn't.
|
|
|
|
PLEASE document known bugs. If it doesn't work for everything
|
|
or does something very odd once a month document it.
|
|
|
|
PLEASE remember that submissions must be made under the terms
|
|
of the "Developer's Certificate of Origin" (DCO) and should include
|
|
a Signed-off-by: line.
|
|
|
|
4. Make sure you have the right to send any changes you make. If you
|
|
do changes at work you may find your employer owns the patch
|
|
not you.
|
|
|
|
5. Happy hacking.
|
|
|
|
|
|
Stable Release Maintenance
|
|
==========================
|
|
|
|
The policy for inclusion in a Xen stable release is different to that
|
|
for inclusion in xen-unstable.
|
|
|
|
Please see https://wiki.xenproject.org/wiki/Xen_Maintenance_Releases for more
|
|
information.
|
|
|
|
Backport requests should be made on the xen-devel@lists.xenproject.org
|
|
list. Remember to copy the appropriate stable branch maintainer who
|
|
will be listed in this section of the MAINTAINERS file in the
|
|
appropriate branch.
|
|
|
|
Unstable Subsystem Maintainers
|
|
==============================
|
|
|
|
Descriptions of section entries:
|
|
|
|
M: Maintainer: FullName <address@domain>
|
|
Maintainers should be CCed on patches. At least one of them
|
|
needs to approve changes to the covered files.
|
|
R: Designated reviewer: FullName <address@domain>
|
|
Reviewers should be CCed on patches. However, they do not
|
|
have a formal governance role, and are listed here
|
|
simply because of their own request.
|
|
L: Mailing list that is relevant to this area
|
|
W: Web-page with status/info
|
|
T: SCM tree type and location. Type is one of: git, hg, quilt, stgit.
|
|
S: Status, one of the following:
|
|
Supported: Someone is actually paid to look after this.
|
|
Maintained: Someone actually looks after it.
|
|
Odd Fixes: It has a maintainer but they don't have time to do
|
|
much other than throw the odd patch in. See below..
|
|
Orphan: No current maintainer [but maybe you could take the
|
|
role as you write your new code].
|
|
Obsolete: Old code. Something tagged obsolete generally means
|
|
it has been replaced by a better system and you
|
|
should be using that.
|
|
F: Files and directories with wildcard patterns.
|
|
A trailing slash includes all files and subdirectory files.
|
|
F: drivers/net/ all files in and below drivers/net
|
|
F: drivers/net/* all files in drivers/net, but not below
|
|
F: */net/* all files in "any top level directory"/net
|
|
One pattern per line. Multiple F: lines acceptable.
|
|
X: Files and directories that are NOT maintained, same rules as F:
|
|
Files exclusions are tested before file matches.
|
|
Can be useful for excluding a specific subdirectory, for instance:
|
|
F: net/
|
|
X: net/ipv6/
|
|
matches all files in and below net excluding net/ipv6/
|
|
K: Keyword perl extended regex pattern to match content in a
|
|
patch or file. For instance:
|
|
K: of_get_profile
|
|
matches patches or files that contain "of_get_profile"
|
|
K: \b(printk|pr_(info|err))\b
|
|
matches patches or files that contain one or more of the words
|
|
printk, pr_info or pr_err
|
|
One regex pattern per line. Multiple K: lines acceptable.
|
|
V: Version identifier that must be under THE REST and follows
|
|
the format:
|
|
xen-maintainers-<version format number of this file>
|
|
|
|
|
|
Check-in policy
|
|
===============
|
|
|
|
In order for a patch to be checked in, in general, several conditions
|
|
must be met:
|
|
|
|
1. In order to get a change to a given file committed, it must have
|
|
the approval of at least one maintainer of that file.
|
|
|
|
A patch of course needs Acks from the maintainers of each file that
|
|
it changes; so a patch which changes xen/arch/x86/traps.c,
|
|
xen/arch/x86/mm/p2m.c, and xen/arch/x86/mm/shadow/multi.c would
|
|
require an Ack from each of the three sets of maintainers.
|
|
|
|
See below for rules on nested maintainership.
|
|
|
|
2. Each change must have appropriate approval from someone other than
|
|
the person who wrote it. This can be either:
|
|
|
|
a. An Acked-by from a maintainer of the code being touched (a
|
|
co-maintainer if available, or a more general level maintainer if
|
|
not available; see the secton on nested maintainership)
|
|
|
|
b. A Reviewed-by by anyone of suitable stature in the community
|
|
|
|
3. Sufficient time must have been given for anyone to respond. This
|
|
depends in large part upon the urgency and nature of the patch.
|
|
For a straightforward uncontroversial patch, a day or two may be
|
|
sufficient; for a controversial patch, a week or two may be better.
|
|
|
|
4. There must be no "open" objections.
|
|
|
|
In a case where one person submits a patch and a maintainer gives an
|
|
Ack, the Ack stands in for both the approval requirement (#1) and the
|
|
Acked-by-non-submitter requirement (#2).
|
|
|
|
In a case where a maintainer themselves submits a patch, the
|
|
Signed-off-by meets the approval requirement (#1); so a Review
|
|
from anyone in the community suffices for requirement #2.
|
|
|
|
Before a maintainer checks in their own patch with another community
|
|
member's R-b but no co-maintainer Ack, it is especially important to
|
|
give their co-maintainer opportunity to give feedback, perhaps
|
|
declaring their intention to check it in without their co-maintainers
|
|
ack a day before doing so.
|
|
|
|
In the case where two people collaborate on a patch, at least one of
|
|
whom is a maintainer -- typically where one maintainer will do an
|
|
early version of the patch, and another maintainer will pick it up and
|
|
revise it -- there should be two Signed-off-by's and one Acked-by or
|
|
Reviewed-by; with the maintainer who did the most recent change
|
|
sending the patch, and an Acked-by or Reviewed-by coming from the
|
|
maintainer who did not most recently edit the patch. This satisfies
|
|
the requirement #2 because a) the Signed-off-by of the sender approves
|
|
the final version of the patch; including all parts of the patch that
|
|
the sender did not write b) the Reviewed-by approves the final version
|
|
of the patch, including all patches that the reviewer did not write.
|
|
Thus all code in the patch has been approved by someone who did not
|
|
write it.
|
|
|
|
Maintainers may choose to override non-maintainer objections in the
|
|
case that consensus can't be reached.
|
|
|
|
As always, no policy can cover all possible situations. In
|
|
exceptional circumstances, committers may commit a patch in absence of
|
|
one or more of the above requirements, if they are reasonably
|
|
confident that the other maintainers will approve of their decision in
|
|
retrospect.
|
|
|
|
The meaning of nesting
|
|
======================
|
|
|
|
Many maintainership areas are "nested": for example, there are entries
|
|
for xen/arch/x86 as well as xen/arch/x86/mm, and even
|
|
xen/arch/x86/mm/shadow; and there is a section at the end called "THE
|
|
REST" which lists all committers. The meaning of nesting is that:
|
|
|
|
1. Under normal circumstances, the Ack of the most specific maintainer
|
|
is both necessary and sufficient to get a change to a given file
|
|
committed. So a change to xen/arch/x86/mm/shadow/multi.c requires the
|
|
the Ack of the xen/arch/x86/mm/shadow maintainer for that part of the
|
|
patch, but would not require the Ack of the xen/arch/x86 maintainer or
|
|
the xen/arch/x86/mm maintainer.
|
|
|
|
2. In unusual circumstances, a more general maintainer's Ack can stand
|
|
in for or even overrule a specific maintainer's Ack. Unusual
|
|
circumstances might include:
|
|
- The patch is fixing a high-priority issue causing immediate pain,
|
|
and the more specific maintainer is not available.
|
|
- The more specific maintainer has not responded either to the
|
|
original patch, nor to "pings", within a reasonable amount of time.
|
|
- The more general maintainer wants to overrule the more specific
|
|
maintainer on some issue. (This should be exceptional.)
|
|
- In the case of a disagreement between maintainers, THE REST can
|
|
settle the matter by majority vote. (This should be very exceptional
|
|
indeed.)
|
|
|
|
|
|
Maintainers List (try to look for most precise areas first)
|
|
|
|
-----------------------------------
|
|
|
|
ACPI
|
|
M: Jan Beulich <jbeulich@suse.com>
|
|
S: Supported
|
|
F: xen/arch/x86/acpi/
|
|
F: xen/drivers/acpi/
|
|
F: xen/include/acpi/
|
|
F: tools/libacpi/
|
|
|
|
AMD IOMMU
|
|
M: Jan Beulich <jbeulich@suse.com>
|
|
M: Andrew Cooper <andrew.cooper3@citrix.com>
|
|
S: Maintained
|
|
F: xen/drivers/passthrough/amd/
|
|
|
|
AMD SVM
|
|
M: Jan Beulich <jbeulich@suse.com>
|
|
M: Andrew Cooper <andrew.cooper3@citrix.com>
|
|
S: Supported
|
|
F: xen/arch/x86/hvm/svm/
|
|
F: xen/arch/x86/cpu/vpmu_amd.c
|
|
|
|
ARGO
|
|
M: Christopher Clark <christopher.w.clark@gmail.com>
|
|
S: Maintained
|
|
F: xen/include/public/argo.h
|
|
F: xen/include/xen/argo.h
|
|
F: xen/common/argo.c
|
|
|
|
ARINC653 SCHEDULER
|
|
M: Nathan Studer <nathan.studer@dornerworks.com>
|
|
M: Stewart Hildebrand <stewart@stew.dk>
|
|
S: Supported
|
|
L: xen-devel@dornerworks.com
|
|
F: xen/common/sched/arinc653.c
|
|
F: tools/libs/ctrl/xc_arinc653.c
|
|
|
|
ARM (W/ VIRTUALISATION EXTENSIONS) ARCHITECTURE
|
|
M: Stefano Stabellini <sstabellini@kernel.org>
|
|
M: Julien Grall <julien@xen.org>
|
|
M: Bertrand Marquis <bertrand.marquis@arm.com>
|
|
R: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
|
|
S: Supported
|
|
L: xen-devel@lists.xenproject.org
|
|
F: docs/misc/arm/
|
|
F: xen/arch/arm/
|
|
F: xen/drivers/char/arm-uart.c
|
|
F: xen/drivers/char/cadence-uart.c
|
|
F: xen/drivers/char/exynos4210-uart.c
|
|
F: xen/drivers/char/meson-uart.c
|
|
F: xen/drivers/char/mvebu-uart.c
|
|
F: xen/drivers/char/omap-uart.c
|
|
F: xen/drivers/char/pl011.c
|
|
F: xen/drivers/char/scif-uart.c
|
|
F: xen/drivers/passthrough/arm/
|
|
F: xen/include/public/arch-arm/
|
|
F: xen/include/public/arch-arm.h
|
|
|
|
ARM SMMU
|
|
M: Julien Grall <julien@xen.org>
|
|
M: Rahul Singh <rahul.singh@arm.com>
|
|
S: Supported
|
|
F: xen/drivers/passthrough/arm/smmu.c
|
|
|
|
ARM SMMUv3
|
|
M: Bertrand Marquis <bertrand.marquis@arm.com>
|
|
M: Rahul Singh <rahul.singh@arm.com>
|
|
S: Supported
|
|
F: xen/drivers/passthrough/arm/smmu-v3.c
|
|
|
|
Change Log
|
|
M: Henry Wang <Henry.Wang@arm.com>
|
|
R: Community Manager <community.manager@xenproject.org>
|
|
S: Maintained
|
|
F: CHANGELOG.md
|
|
|
|
Continuous Integration (CI)
|
|
M: Doug Goldstein <cardoe@cardoe.com>
|
|
M: Stefano Stabellini <sstabellini@kernel.org>
|
|
W: https://gitlab.com/xen-project/xen
|
|
S: Supported
|
|
F: .gitlab-ci.yml
|
|
F: automation/
|
|
|
|
CPU POOLS
|
|
M: Juergen Gross <jgross@suse.com>
|
|
M: Dario Faggioli <dfaggioli@suse.com>
|
|
S: Supported
|
|
F: xen/common/sched/*cpupool.c
|
|
|
|
DEVICE TREE
|
|
M: Stefano Stabellini <sstabellini@kernel.org>
|
|
M: Julien Grall <julien@xen.org>
|
|
S: Supported
|
|
F: xen/common/libfdt/
|
|
F: xen/common/device_tree.c
|
|
F: xen/include/xen/libfdt/
|
|
F: xen/include/xen/device_tree.h
|
|
F: xen/drivers/passthrough/device_tree.c
|
|
|
|
EFI
|
|
M: Jan Beulich <jbeulich@suse.com>
|
|
S: Supported
|
|
F: xen/arch/x86/efi/
|
|
F: xen/arch/x86/include/asm/efi*.h
|
|
F: xen/arch/x86/include/asm/x86_*/efi*.h
|
|
F: xen/common/efi/
|
|
F: xen/include/efi/
|
|
|
|
GDBSX DEBUGGER
|
|
M: Elena Ufimtseva <elena.ufimtseva@oracle.com>
|
|
S: Supported
|
|
F: xen/arch/x86/debug.c
|
|
F: tools/debugger/gdbsx/
|
|
|
|
GOLANG BINDINGS
|
|
M: George Dunlap <george.dunlap@citrix.com>
|
|
M: Nick Rosbrook <rosbrookn@gmail.com>
|
|
S: Maintained
|
|
F: tools/golang
|
|
|
|
HYPFS
|
|
M: Juergen Gross <jgross@suse.com>
|
|
S: Supported
|
|
F: tools/include/xenhypfs.h
|
|
F: tools/libs/hypfs/
|
|
F: tools/misc/xenhypfs.c
|
|
F: xen/common/hypfs.c
|
|
F: xen/include/xen/hypfs.h
|
|
|
|
INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)
|
|
R: Lukasz Hawrylko <lukasz@hawrylko.pl>
|
|
R: Daniel P. Smith <dpsmith@apertussolutions.com>
|
|
R: Mateusz Mówka <mateusz.mowka@intel.com>
|
|
S: Odd Fixes
|
|
F: xen/arch/x86/include/asm/tboot.h
|
|
F: xen/arch/x86/tboot.c
|
|
|
|
INTEL(R) VT FOR DIRECTED I/O (VT-D)
|
|
M: Kevin Tian <kevin.tian@intel.com>
|
|
S: Supported
|
|
F: xen/drivers/passthrough/vtd/
|
|
|
|
INTEL(R) VT FOR X86 (VT-X)
|
|
M: Jun Nakajima <jun.nakajima@intel.com>
|
|
M: Kevin Tian <kevin.tian@intel.com>
|
|
S: Supported
|
|
F: xen/arch/x86/cpu/vpmu_intel.c
|
|
F: xen/arch/x86/hvm/vmx/
|
|
F: xen/arch/x86/include/asm/hvm/vmx/
|
|
F: xen/arch/x86/mm/p2m-ept.c
|
|
|
|
IOMMU VENDOR INDEPENDENT CODE
|
|
M: Jan Beulich <jbeulich@suse.com>
|
|
M: Paul Durrant <paul@xen.org>
|
|
R: Roger Pau Monné <roger.pau@citrix.com>
|
|
S: Supported
|
|
F: xen/drivers/passthrough/
|
|
X: xen/drivers/passthrough/amd/
|
|
X: xen/drivers/passthrough/arm/
|
|
X: xen/drivers/passthrough/vtd/
|
|
X: xen/drivers/passthrough/device_tree.c
|
|
F: xen/include/xen/iommu.h
|
|
|
|
I/O EMULATION (IOREQ)
|
|
M: Paul Durrant <paul@xen.org>
|
|
S: Supported
|
|
F: xen/common/ioreq.c
|
|
F: xen/include/xen/ioreq.h
|
|
F: xen/include/public/hvm/ioreq.h
|
|
|
|
KCONFIG
|
|
M: Doug Goldstein <cardoe@cardoe.com>
|
|
S: Supported
|
|
F: docs/misc/kconfig{,-language}.txt
|
|
F: xen/tools/kconfig/
|
|
|
|
KDD DEBUGGER
|
|
M: Tim Deegan <tim@xen.org>
|
|
S: Odd Fixes
|
|
F: tools/debugger/kdd/
|
|
|
|
KEXEC
|
|
M: Andrew Cooper <andrew.cooper3@citrix.com>
|
|
S: Supported
|
|
F: xen/common/{kexec,kimage}.c
|
|
F: xen/include/xen/{kexec,kimage}.h
|
|
F: xen/arch/x86/machine_kexec.c
|
|
F: xen/arch/x86/x86_64/kexec_reloc.S
|
|
|
|
LIBS
|
|
M: Wei Liu <wl@xen.org>
|
|
M: Anthony PERARD <anthony.perard@citrix.com>
|
|
R: Juergen Gross <jgross@suse.com>
|
|
S: Supported
|
|
F: tools/include/libxenvchan.h
|
|
F: tools/include/libxl*.h
|
|
F: tools/include/xencall.h
|
|
F: tools/include/xenctrl*.h
|
|
F: tools/include/xendevicemodel.h
|
|
F: tools/include/xenevtchn.h
|
|
F: tools/include/xenforeignmemory.h
|
|
F: tools/include/xengnttab.h
|
|
F: tools/include/xenguest.h
|
|
F: tools/include/xenhypfs.h
|
|
F: tools/include/xenstat.h
|
|
F: tools/include/xenstore*.h
|
|
F: tools/include/xenstore-compat/*.h
|
|
F: tools/include/xentoolcore*.h
|
|
F: tools/include/xentoollog.h
|
|
F: tools/libs/
|
|
|
|
LIVEPATCH
|
|
M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
|
M: Ross Lagerwall <ross.lagerwall@citrix.com>
|
|
S: Supported
|
|
F: docs/misc/livepatch.pandoc
|
|
F: tools/misc/xen-livepatch.c
|
|
F: xen/arch/*/include/asm/livepatch.h
|
|
F: xen/arch/*/livepatch*
|
|
F: xen/arch/*/*/livepatch*
|
|
F: xen/common/livepatch*
|
|
F: xen/include/xen/livepatch*
|
|
F: xen/test/livepatch/*
|
|
|
|
MINI-OS
|
|
M: Samuel Thibault <samuel.thibault@ens-lyon.org>
|
|
R: Wei Liu <wl@xen.org>
|
|
R: Juergen Gross <jgross@suse.com>
|
|
S: Supported
|
|
L: minios-devel@lists.xenproject.org
|
|
T: git https://xenbits.xenproject.org/git-http/mini-os.git
|
|
F: config/MiniOS.mk
|
|
|
|
OCAML TOOLS
|
|
M: Christian Lindig <christian.lindig@citrix.com>
|
|
M: David Scott <dave@recoil.org>
|
|
S: Supported
|
|
F: tools/ocaml/
|
|
|
|
OVMF UPSTREAM
|
|
M: Anthony PERARD <anthony.perard@citrix.com>
|
|
M: Wei Liu <wl@xen.org>
|
|
S: Supported
|
|
T: git https://xenbits.xenproject.org/git-http/ovmf.git
|
|
|
|
POWER MANAGEMENT
|
|
M: Jan Beulich <jbeulich@suse.com>
|
|
S: Supported
|
|
F: xen/arch/x86/acpi/
|
|
X: xen/arch/x86/acpi/boot.c
|
|
X: xen/arch/x86/acpi/lib.c
|
|
F: xen/drivers/cpufreq/
|
|
F: xen/include/acpi/cpufreq/
|
|
|
|
PUBLIC I/O INTERFACES AND PV DRIVERS DESIGNS
|
|
M: Juergen Gross <jgross@suse.com>
|
|
S: Supported
|
|
F: xen/include/public/io/
|
|
|
|
PYTHON BINDINGS
|
|
M: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
|
|
S: Supported
|
|
F: tools/python
|
|
|
|
QEMU-DM
|
|
S: Supported
|
|
T: git https://xenbits.xenproject.org/git-http/qemu-xen-traditional.git
|
|
|
|
QEMU UPSTREAM
|
|
M: Stefano Stabellini <sstabellini@kernel.org>
|
|
M: Anthony Perard <anthony.perard@citrix.com>
|
|
S: Supported
|
|
T: git https://xenbits.xenproject.org/git-http/qemu-xen.git
|
|
|
|
REMUS
|
|
S: Orphan
|
|
F: docs/README.remus
|
|
F: tools/libs/light/libxl_remus_*
|
|
F: tools/libs/light/libxl_netbuffer.c
|
|
F: tools/libs/light/libxl_nonetbuffer.c
|
|
F: tools/hotplug/Linux/remus-netbuf-setup
|
|
F: tools/hotplug/Linux/block-drbd-probe
|
|
|
|
RISCV
|
|
M: Bob Eshleman <bobbyeshleman@gmail.com>
|
|
M: Alistair Francis <alistair.francis@wdc.com>
|
|
R: Connor Davis <connojdavis@gmail.com>
|
|
S: Supported
|
|
F: config/riscv64.mk
|
|
F: xen/arch/riscv/
|
|
|
|
RTDS SCHEDULER
|
|
M: Dario Faggioli <dfaggioli@suse.com>
|
|
M: Meng Xu <mengxu@cis.upenn.edu>
|
|
S: Supported
|
|
F: xen/common/sched/rt.c
|
|
|
|
SCHEDULING
|
|
M: George Dunlap <george.dunlap@citrix.com>
|
|
M: Dario Faggioli <dfaggioli@suse.com>
|
|
S: Supported
|
|
F: xen/common/sched/
|
|
|
|
SEABIOS UPSTREAM
|
|
M: Wei Liu <wl@xen.org>
|
|
S: Supported
|
|
T: git https://xenbits.xenproject.org/git-http/seabios.git
|
|
|
|
STUB DOMAINS
|
|
M: Samuel Thibault <samuel.thibault@ens-lyon.org>
|
|
S: Supported
|
|
F: config/Stubdom.mk.in
|
|
F: m4/stubdom.m4
|
|
F: stubdom/
|
|
|
|
TEE MEDIATORS
|
|
M: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
|
|
S: Supported
|
|
F: xen/arch/arm/include/asm/tee
|
|
F: xen/arch/arm/tee/
|
|
|
|
TOOLSTACK
|
|
M: Wei Liu <wl@xen.org>
|
|
M: Anthony PERARD <anthony.perard@citrix.com>
|
|
S: Supported
|
|
F: autogen.sh
|
|
F: config/*.in
|
|
F: install.sh
|
|
F: m4/
|
|
F: configure
|
|
F: docs/Makefile
|
|
F: docs/man/
|
|
F: stubdom/Makefile
|
|
F: *.ac
|
|
F: */configure
|
|
F: */*.ac
|
|
F: tools/
|
|
|
|
VM EVENT, MEM ACCESS and MONITOR
|
|
M: Tamas K Lengyel <tamas@tklengyel.com>
|
|
R: Alexandru Isaila <aisaila@bitdefender.com>
|
|
R: Petre Pircalabu <ppircalabu@bitdefender.com>
|
|
S: Supported
|
|
F: tools/misc/xen-access.c
|
|
F: xen/arch/*/monitor.c
|
|
F: xen/arch/*/vm_event.c
|
|
F: xen/arch/arm/mem_access.c
|
|
F: xen/arch/x86/include/asm/hvm/monitor.h
|
|
F: xen/arch/x86/include/asm/hvm/vm_event.h
|
|
F: xen/arch/x86/mm/mem_access.c
|
|
F: xen/arch/x86/hvm/monitor.c
|
|
F: xen/arch/x86/hvm/vm_event.c
|
|
F: xen/common/mem_access.c
|
|
F: xen/common/monitor.c
|
|
F: xen/common/vm_event.c
|
|
F: xen/include/*/mem_access.h
|
|
F: xen/include/*/monitor.h
|
|
F: xen/include/*/vm_event.h
|
|
|
|
VPCI
|
|
M: Roger Pau Monné <roger.pau@citrix.com>
|
|
S: Supported
|
|
F: xen/drivers/vpci/
|
|
F: xen/include/xen/vpci.h
|
|
|
|
VTPM
|
|
M: Daniel De Graaf <dgdegra@tycho.nsa.gov>
|
|
M: Quan Xu <quan.xu0@gmail.com>
|
|
S: Supported
|
|
F: extras/mini-os/tpm*
|
|
F: extras/mini-os/include/tpm*
|
|
F: stubdom/vtpm/
|
|
F: stubdom/vtpmmgr/
|
|
F: docs/misc/vtpm-platforms.txt
|
|
|
|
X86 ARCHITECTURE
|
|
M: Jan Beulich <jbeulich@suse.com>
|
|
M: Andrew Cooper <andrew.cooper3@citrix.com>
|
|
M: Roger Pau Monné <roger.pau@citrix.com>
|
|
R: Wei Liu <wl@xen.org>
|
|
S: Supported
|
|
L: xen-devel@lists.xenproject.org
|
|
F: xen/arch/x86/
|
|
F: xen/include/public/arch-x86/
|
|
F: xen/include/xen/lib/x86
|
|
F: xen/lib/x86
|
|
F: tools/firmware/hvmloader/
|
|
F: tools/firmware/rombios/
|
|
F: tools/firmware/vgabios/
|
|
F: tools/fuzz/cpu-policy/
|
|
F: tools/fuzz/x86_instruction_emulator/
|
|
F: tools/misc/xen-cpuid.c
|
|
F: tools/tests/cpu-policy/
|
|
F: tools/tests/x86_emulator/
|
|
|
|
X86 I/O EMULATION
|
|
M: Paul Durrant <paul@xen.org>
|
|
S: Supported
|
|
F: xen/arch/x86/hvm/emulate.c
|
|
F: xen/arch/x86/hvm/intercept.c
|
|
F: xen/arch/x86/hvm/io.c
|
|
F: xen/arch/x86/hvm/ioreq.c
|
|
F: xen/arch/x86/include/asm/hvm/emulate.h
|
|
F: xen/arch/x86/include/asm/hvm/io.h
|
|
F: xen/arch/x86/include/asm/hvm/ioreq.h
|
|
F: xen/arch/x86/include/asm/ioreq.h
|
|
|
|
X86 MEMORY MANAGEMENT
|
|
M: Jan Beulich <jbeulich@suse.com>
|
|
M: Andrew Cooper <andrew.cooper3@citrix.com>
|
|
R: George Dunlap <george.dunlap@citrix.com>
|
|
S: Supported
|
|
F: xen/arch/x86/mm/
|
|
|
|
X86 MEMORY PAGING
|
|
S: Orphaned
|
|
F: xen/arch/x86/mm/mem_paging.c
|
|
|
|
X86 MEMORY SHARING
|
|
M: Tamas K Lengyel <tamas@tklengyel.com>
|
|
S: Odd Fixes
|
|
F: xen/arch/x86/mm/mem_sharing.c
|
|
F: tools/tests/mem-sharing/
|
|
|
|
X86 SHADOW PAGETABLES
|
|
M: Jan Beulich <jbeulich@suse.com>
|
|
M: Andrew Cooper <andrew.cooper3@citrix.com>
|
|
R: Tim Deegan <tim@xen.org>
|
|
S: Maintained
|
|
F: xen/arch/x86/mm/shadow/
|
|
|
|
X86 VIRIDIAN ENLIGHTENMENTS
|
|
M: Paul Durrant <paul@xen.org>
|
|
M: Wei Liu <wl@xen.org>
|
|
S: Supported
|
|
F: xen/arch/x86/guest/hyperv/
|
|
F: xen/arch/x86/hvm/viridian/
|
|
F: xen/arch/x86/include/asm/guest/hyperv.h
|
|
F: xen/arch/x86/include/asm/guest/hyperv-hcall.h
|
|
F: xen/arch/x86/include/asm/guest/hyperv-tlfs.h
|
|
F: xen/arch/x86/include/asm/hvm/viridian.h
|
|
|
|
XENSTORE
|
|
M: Wei Liu <wl@xen.org>
|
|
M: Juergen Gross <jgross@suse.com>
|
|
R: Julien Grall <julien@xen.org>
|
|
S: Supported
|
|
F: tools/xenstore/
|
|
|
|
XENTRACE
|
|
M: George Dunlap <george.dunlap@citrix.com>
|
|
S: Supported
|
|
F: tools/xentrace/
|
|
F: xen/common/trace.c
|
|
F: xen/include/xen/trace.h
|
|
|
|
XSM/FLASK
|
|
M: Daniel P. Smith <dpsmith@apertussolutions.com>
|
|
S: Supported
|
|
F: tools/flask/
|
|
F: xen/include/xsm/
|
|
F: xen/xsm/
|
|
F: docs/misc/xsm-flask.txt
|
|
|
|
THE REST
|
|
M: Andrew Cooper <andrew.cooper3@citrix.com>
|
|
M: George Dunlap <george.dunlap@citrix.com>
|
|
M: Jan Beulich <jbeulich@suse.com>
|
|
M: Julien Grall <julien@xen.org>
|
|
M: Stefano Stabellini <sstabellini@kernel.org>
|
|
M: Wei Liu <wl@xen.org>
|
|
L: xen-devel@lists.xenproject.org
|
|
S: Supported
|
|
F: *
|
|
F: */
|
|
V: xen-maintainers-1
|