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>
Add Nathan Studer as co-maintainer.
I am departing DornerWorks. I will still be working with Xen in my next
role, and I still have an interest in co-maintaining the ARINC 653
scheduler, so change to my personal email address.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@dornerworks.com>
Acked-by: Nathan Studer <nathan.studer@dornerworks.com>
While mail hasn't been bouncing, Daniel De Graaf has not been
responding to patch submissions or otherwise interacting with the
community for several years. Daniel Smith has at least been working
with the code, and is a regular member of our community; and he has
agreed to step up into the role.
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
I'm the main contributor for Mini-OS since several years now.
Add myself as reviewer.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Introduce a way to create different cpupools at boot time, this is
particularly useful on ARM big.LITTLE system where there might be the
need to have different cpupools for each type of core, but also
systems using NUMA can have different cpu pools for each node.
The feature on arm relies on a specification of the cpupools from the
device tree to build pools and assign cpus to them.
ACPI is not supported for this feature.
With this patch, cpupool0 can now have less cpus than the number of
online ones, so update the default case for opt_dom0_max_vcpus.
Documentation is created to explain the feature.
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Juergen Gross <jgross@suse.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Add Rahul as ARM SMMU maintainer. Create a new explicit entry for "ARM
SMMU" also with Julien which is the original contributor of the code and
continues to maintain it.
Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Acked-by: Rahul Singh <rahul.singh@arm.com>
Acked-by: Julien Grall <julien@xen.org>
I have contributed all the ARM tests to gitlab-ci. After checking with
Doug, I am happy to volunteer to co-maintain Continuous Integration.
Also take the opportunity to remove the stale travis-ci entries.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Doug Goldstein <cardoe@cardoe.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
ARM has proposed Henry Wang as a release manager for 4.17. Signify
this by giving him maintainership over CHANGELOG.md.
Below is an introduction given by Bertrand Marquis:
Henry Wang is an open-source software engineer at Arm focusing on the
hypervisor and virtualization technology. Before joining the
AIS-Hypervisor team, he was one of the leading Arm contributors of the
Rust-VMM and the Cloud Hypervisor community. He is the Arm reviewer
of the Cloud Hypervisor project. His work includes basic project
enabling on Arm platform, Arm device emulation, advanced features
support on Arm and bug fixes.
After joining the AIS-Hypervisor team at Arm, he has been involved in Xen feature
development on Arm in various areas, including:
1. Xen Arm MPAM extension research and PoC: Ongoing, the design will
share in xen-devel soon.
2. Port of Xen to Arm MPU systems: Working together with Penny Zheng
on coding and testing, will be soon sent to xen-devel.
3. Static Xen heap on Arm: Work done but depend on the direct mapping
series from Penny Zheng, will be upstreamed in the next weeks.
4. Virtio PoC for Xen on Arm using kvmtool as the Xen virtio backend:
Work done, including the enabling of the virtio and the virtio
performance tuning.
5. Participated in code reviews and discussions in xen-devel,
including the foreign memory mapping series from EPAM, etc.
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Henry Wang <Henry.Wang@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Since Lukasz has left Intel, they have suggested a replacement contact.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Mateusz Mówka <mateusz.mowka@intel.com>
This avoid the need to create the symbolic link "include/asm".
Whenever a comment refer to an "asm" headers, this patch avoid
spelling the arch when not needed to avoid some code churn.
One unrelated change is to sort entries in MAINTAINERS for "INTEL(R)
VT FOR X86 (VT-X)"
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Paul Durrant <paul@xen.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
As was briefly discussed on the December Community Call, I'd like to
propose to widen Anthony's maintainership to all of tools/. This then
means that the special LIBXENLIGHT entry can go away.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Jackson <iwj@xenproject.org>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
The designated maintainer email address for the remus entry is
bouncing, so remove it and declare the entry as orphaned as there's no
other maintainer.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Ian Jackson <iwj@xenproject.org>
The LIBS section doesn't mention the headers associated with the
libraries, same for LIBXENLIGHT section.
They aren't any ':' in other section names, so remove it.
Fixes: 4664034cdc ("tools/libs: move official headers to common directory")
Fixes: f7079d7ef6 ("MAINTAINERS: add myself as tools/libs reviewer")
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
I would like to help reviewing Xenstored patches. It is more convenient
to find them if I am CCed.
Signed-off-by: Julien Grall <julien@xen.org>
Acked-by: Juergen Gross <jgross@suse.com>
I have touched most of the Xen libraries in the past, and there is a
clear lack of reviewer band width in the tools area.
Add myself as a tools/libs reviewer for that reason.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Ian Jackson <iwj@xenproject.org>
Add arch-specific makefiles and configs needed to build for
riscv. Also add a minimal head.S that is a simple infinite loop.
head.o can be built with
$ make XEN_TARGET_ARCH=riscv64 SUBSYSTEMS=xen -C xen tiny64_defconfig
$ make XEN_TARGET_ARCH=riscv64 SUBSYSTEMS=xen -C xen TARGET=riscv64/head.o
No other TARGET is supported at the moment.
Signed-off-by: Connor Davis <connojdavis@gmail.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Acked-by: Bobby Eshleman <bobbyeshleman@gmail.com>
Better reflect reality: Andrew and Jan are active maintainers
and I review patches. Keep myself as a reviewer so I can help
with historical context &c.
Signed-off-by: Tim Deegan <tim@xen.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
As I have contributed all the code for hypfs, it would be natural to
be the maintainer.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Ian Jackson <iwj@xenproject.org>
As a lot of x86 code can be re-used on Arm later on, this patch
moves previously prepared IOREQ support to the common code
(the code movement is verbatim copy).
The "legacy" mechanism of mapping magic pages for the IOREQ servers
remains x86 specific and not exposed to the common code.
The common IOREQ feature is supposed to be built with IOREQ_SERVER
option enabled, which is selected for x86's config HVM for now.
In order to avoid having a gigantic patch here, the subsequent
patches will update remaining bits in the common code step by step:
- Make IOREQ related structs/materials common
- Drop the "hvm" prefixes and infixes
- Remove layering violation by moving corresponding fields
out of *arch.hvm* or abstracting away accesses to them
Introduce asm/ioreq.h wrapper to be included by common ioreq.h
instead of asm/hvm/ioreq.h to avoid HVM-ism in the code common.
Also include <xen/domain_page.h> which will be needed on Arm
to avoid touch the common code again when introducing Arm specific bits.
This support is going to be used on Arm to be able run device
emulator outside of Xen hypervisor.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Paul Durrant <paul@xen.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
CC: Julien Grall <julien.grall@arm.com>
[On Arm only]
Tested-by: Wei Chen <Wei.Chen@arm.com>
When splitting libxl into libs/light and libs/util the related
MAINTAINERS entry was modified in a wrong way.
Reported-by: Jan Beulich <jbeulich@suse.com>
Fixes: 032a96e5ef ("maintainers: fix libxl paths")
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Add support for ARM architected SMMUv3 implementation. It is based on
the Linux SMMUv3 driver.
Driver is currently supported as Tech Preview.
Major differences with regard to Linux driver are as follows:
2. Only Stage-2 translation is supported as compared to the Linux driver
that supports both Stage-1 and Stage-2 translations.
3. Use P2M page table instead of creating one as SMMUv3 has the
capability to share the page tables with the CPU.
4. Tasklets are used in place of threaded IRQ's in Linux for event queue
and priority queue IRQ handling.
5. Latest version of the Linux SMMUv3 code implements the commands queue
access functions based on atomic operations implemented in Linux.
Atomic functions used by the commands queue access functions are not
implemented in XEN therefore we decided to port the earlier version
of the code. Atomic operations are introduced to fix the bottleneck
of the SMMU command queue insertion operation. A new algorithm for
inserting commands into the queue is introduced, which is lock-free
on the fast-path.
Consequence of reverting the patch is that the command queue
insertion will be slow for large systems as spinlock will be used to
serializes accesses from all CPUs to the single queue supported by
the hardware. Once the proper atomic operations will be available in
XEN the driver can be updated.
6. Spin lock is used in place of mutex when attaching a device to the
SMMU, as there is no blocking locks implementation available in XEN.
This might introduce latency in XEN. Need to investigate before
driver is out for tech preview.
7. PCI ATS functionality is not supported, as there is no support
available in XEN to test the functionality. Code is not tested and
compiled. Code is guarded by the flag CONFIG_PCI_ATS.
8. MSI interrupts are not supported as there is no support available in
XEN to request MSI interrupts. Code is not tested and compiled. Code
is guarded by the flag CONFIG_MSI.
Signed-off-by: Rahul Singh <rahul.singh@arm.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
xen-access is a tool for a human to use, rather than a test. Move it
into misc/ as a more appropriate location to live.
Move the -DXC_WANT_COMPAT_DEVICEMODEL_API from CFLAGS into xen-access.c itself
to avoid adding Makefile complexity.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
I have been the major contributor for C Xenstore the past few years.
Add me as a maintainer for tools/xenstore/.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
The mails for Yang Hongyang are bouncing, remove him from MAINTAINERS
file.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Today tools/libxc needs to be built after tools/libs as libxenctrl is
depending on some libraries in tools/libs. This in turn blocks moving
other libraries depending on libxenctrl below tools/libs.
So carve out libxenctrl from tools/libxc and move it into
tools/libs/ctrl.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org> (stubdom parts)
Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> (python parts)
Acked-by: Wei Liu <wl@xen.org>
I probably don't have much time to actually review patches, but I do
want to be CC'ed such that I can commit patches in a timely manner.
Signed-off-by: Wei Liu <wl@xen.org>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Unfortunately I need to stop using all my Amazon email addresses for all
open source work.
Signed-off-by: Paul Durrant <paul@xen.org>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
.due to -ENOTIME. Been busy with management and have had
not much chance to do anything besides that.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Having just a single maintainer is not helpful anywhere, and can be
avoided here quite easily, seeing that Paul has been doing quite a bit
of IOMMU work lately.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <julien@xen.org>
Reviewed-by: Paul Durrant <pdurrant@amazon.com>
With having to take over Lars' role as community manager, I don't have
the necessary time to review the mm/ subsystem. Step back to being only
a designated reviewer, reverting mantainership to the x86 maintianers.
While here, fix my e-mail address in other places.
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wl@xen.org>
The "nesting" section in the MAINTAINERS file was not initially
intended to describe the check-in policy for patches, but only how
nesting worked; but since there was no check-in policy, it has been
acting as a de-facto policy.
One problem with this is that the policy is not complete: It doesn't
cover open objections, time to check-in, or so on. The other problem
with the policy is that, as written, it doesn't account for
maintainers submitting patches to files which they themselves
maintain. This is fine for situations where there are are multiple
maintainers, but not for situations where there is only one
maintainer.
Add an explicit "Check-in policy" section to the MAINTAINERS document
to serve as the canonical reference for the check-in policy. Move
paragraphs not explicitly related to nesting into it.
While here, "promote" the "The meaning of nesting" section title.
DISCUSSION
This seems to be a change from people's understanding of the current
policy. Most people's understanding of the current policy seems to be:
1. In order to get a change to a given file committed, it must have
an Ack or Review from at least one *maintainer* of that file other
than the submitter.
2. In the case where a file has only one maintainer, it must have an
Ack or Review from a "nested" maintainer.
I.e., if I submitted something to x86/mm, it would require an Ack from
Jan or Andy, or (in exceptional circumstances) The Rest; but an Ack from
(say) Roger or Juergen wouldn't suffice.
Let's call this the "maintainer-ack" approach (because it must have an
ack or r-b from a maintainer to be checked in), and the proposal in
this patch the "maintainer-approval" (since SoB from a maintainer
indicates approval).
The core issue I have with "maintainer-ack" is that it makes the
maintainer less privileged with regard to writing code than
non-maintainers. If component X has maintainers A and B, then a
non-maintainer can have code checked in if reviewed either by A or B.
If A or B wants code checked in, they have to wait for exactly one
person to review it.
In fact, if B is quite busy, the easiest way for A really to get their
code checked in might be to hand it to a non-maintainer N, and ask N
to submit it as their own. Then A can Ack the patches and check them
in.
The current system, therefore, either sets up a perverse incentive (if
you think the behavior described above is unacceptable) or unnecessary
bureaucracy (if you think it's acceptable). Either way I think we
should set up our system to avoid it.
Other variations on "maintainer-ack" have been proposed:
- Allow maintainer's patches to go in with an R-b from "designated
reviewers"
- Allow maintainer's patches to go in with an Ack from more general
maintainer
Both fundamentally make it harder for maintainers to get their code in
and/or reviewed effectively than non-maintainers, setting up the
perverse incentive / unnecessary bureaucracy.
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The purpose of the change-log is to be a human-readable list of notable
changes and, as such, additions to it are likely of interest to the
community manager in preparing blog entries, release summaries, etc.
Signed-off-by: Paul Durrant <pdurrant@amazon.com>
Acked-by: Wei Liu <wl@xen.org>
Acked-by: Julien Grall <julien@xen.org>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
George Dunlap