Original the structure was memset to a poison value. That prevented
_dispose to be made idempotent. We should stop doing so.
Memseting the structure to 0 makes all pointers in structure become
NULL, which can be handled by free().
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The commit 61d6a84 "xen: arm: Warn if timer interrupts are not level
triggered" added a check to ensure the timer interrupts are level.
Although, the check is only done on low-level interrupts. This will
result to a strange warning on platform using high-level ("WARNING [..]
IRQ is not level triggered").
As high-level interrupt is valid, don't warn on both high-level and
low-level interrupt.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
When SMMU doesn't support coherent table walk, Xen may need to clean
updated PT (see commit 4c5f4cb "xen/arm: p2m: Clean cache PT when the
IOMMU doesn't support coherent walk").
If one SMMU of the platform doesn't support coherent table walk, the
feature is disabled for the whole platform. This is because device is
assigned to a domain after the page table are populated.
This could impact performance on domain which doesn't use device
passthrough. But, as the spec strongly recommends the support of this
feature for mainstream platform, I expect server will always have SMMUs
supporting coherent table walk. If not, we may need to enable this feature
per-domain.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
When reading back the ICFG register we cannot know the polarity of the
configuration, just that it is level or edge.
Since falling edge and low level are invalid for SPIs we should assume
rising edge and high level (we have no better information for PPIs, so
it'll have to do).
We already assumed rising edge, switch to high level as well.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
In libxl_set_memory_target when setting the new maxmem, retain the same
offset on top of the current target. In the future the offset will
include memory allocated by QEMU for rom files.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Clean and distclean targets need not depend on existence of the mini-os
tree. Don't check for mini-os and don't try to blindly include
mini-os's Config.mk when doing clean and distclean.
Note that one subtle issue is that $(XEN_ROOT)/Config.mk tries to
include $(XEN_ROOT)/config/$(XEN_OS).mk. In stubdom's case XEN_OS is
"MiniOS". Then $(XEN_ROOT)/config/MiniOS.mk tries to include mini-os's
Config.mk.
Since clean and distclean don't enforce existence of mini-os tree, don't
include $(XEN_ROOT)/Config.mk to avoid getting error due to the
aforementioned issue.
Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
XenServer's VM density testing uncovered a regression when moving from
sysvinit to systemd where the file descriptor limit dropped from 4096 to
1024. (XenServer had previously inserted a ulimit statement into its
initscripts.)
One solution is to use LimitNOFILE=4096 in xenconsoled.service to match the
lost ulimit, but that is only a stopgap solution.
As Xenconsoled genuinely needs a large number of file descriptors if a large
number of domains are running, attempt to increase the limit.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Translated addresses (in d->arch.vgic.{c,d}base) are bus addresses
which are not always correct in the context of a subnode in the DTB
exposed to domain 0 since they would then be subject to retranslation.
Copy the original addresses from DT directly to get the original
untranslated reg property which will give same d->arch.vgic.{c,d}base
values once translated again by the guest.
Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- attempt to clarify the commit message ]
freemem_slack accounts for the amount of memory to be left free in the
system because empirical experiments seem to demonstrate that is needed
for "stability reasons".
As we don't have any actual data on these stability issues, remove it.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: mlatimer@suse.com
CC: ian.campbell@citrix.com
Acked-by: Mike Latimer <mlatimer@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Make some internal routines common so that total/local memory bandwidth
monitoring in the next patch can make use of them.
Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
- space: remove space after '(' or before ')' in 'if' condition;
- indention: align function definition/call arguments;
Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
The main goal is to modify as little the Linux code to be able to port
easily new feature added in Linux repo for the driver.
To achieve that we:
- Add helpers to Linux function not implemented on Xen
- Add callbacks used by Xen to do our own stuff and call Linux ones
- Only modify when required the code which comes from Linux. If so a
comment has been added with /* Xen: ... */ explaining why it's
necessary.
The support for PCI has been commented because it's not yet supported by
Xen ARM and therefore won't compile.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- fix a couple of typos in comments ]
Based on commit e6b5be2be4e30037eb551e0ed09dd97bd00d85d3.
It's a verbatim of the Linux SMMU drivers code. No Xen code has yet been added
and the file is not built.
Compare to the previous drivers it gains support of PCI. Though it will
need a bit of plumbing for Xen.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Xen is currently using a list of compatible strings to match drivers again
device nodes. This leads to having double definitions in the GIC
code.
Furthermore Linux drivers are using dt_device_match (actually called
of_device_id in Linux) to list device supported by the drivers.
Remove the exisiting compatible field and replace with a dt_match field
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
On ARM, the way to assign device tree node is exactly the same as PCI.
Futhermore, all devices can be represented by a 'device_t'.
Therefore there is no need to add separate ops.
The x86 iommu drivers has not been modified to replace 'struct pci_dev'
by "device_t" because the latter is an alias of the former.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>\
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Currently, Xen is supporting PCI and Platform device (based on Device Tree).
While Xen only supports Platform device on ARM, Xen will gain support of
PCI soon.
Some drivers, such as IOMMU drivers, may handle PCI and platform device in
the same way. Only few lines of code differs.
Rather than requesting to provide 2 set of functions (one for PCI and
one for platform device), introduce a generic structure "device" which
is embedded in each specialized device.
As x86 only supports PCI, introduce a new type device_t which will be an
alias to pci_dev for this architecture. It will avoid to add a new field
for this place.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
Provide mini-os url and revision in Config.mk
Make stubdom targets depend on mini-os-dir target. Make
subtree-force-update{,-all} depend on mini-os-dir-force-update.
Also make mktarball script generate mini-os archive.
Original mini-os directory is renamed to mini-os-intree to help reduce
patch length. That directory will be deleted in a separate patch.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
Changes in v3:
1. Put mini-os targets in main Makefile.
2. Stubdom clean and distclean don't depend on mini-os-dir.
Changes in v2:
1. Use hash in Config.mk.
In order to keep the tree bisectable all the changes are done in one
single commit.
Things done in this commit:
1. Import necessary .mk files from Xen.
2. Move all XEN_ related variables to MINIOS_ namespace.
3. Import Xen public header files.
4. Import BSD's list.h and helper script.
Mini-OS's vanilla Config.mk is modified to contain some macros copied
from Xen's Config.mk. It also contains compatibility handling logic for
Xen's stubdom build environment.
Files modified:
Config.mk
Makefile
arch/x86/Makefile
arch/x86/arch.mk
minios.mk
All other files are just imported from Xen.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Settle on just using one variable (val), and move the other into
WRMSR's local scope. Chain up further success paths to the
rdmsr_writeback label rather than open coding them.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
... when calculating how many pages to allocate for Dom0. This is
basically equivalent to the already present IOMMU related adjustment.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
While converting to __cpumask_set_cpu() was correct, the first argument
passed should have been corrected to be "cpu" instead of "nr" at once.
The wrong construct results in problems on systems with relatively few
CPUs.
Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citirx.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Add a check, like the existing check for non-ANSI C in the public
headers, that runs the public headers through a C++ compiler to
flag non-C++-friendly constructs.
Unlike the ANSI C check, we accept GCC-isms (gnu++98), and we also
check various tools-only headers.
Also tidy up the runes for these checks to be a bit more readable.
io/ring.h uses 'private' as a field name, which is a keyword in C++;
this patch doesn't change that. Instead the check works around it.
Reported-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Signed-off-by: Tim Deegan <tim@xen.org>
Acked-by: Jan Beulich <JBeulich@suse.com>
Tested-by: Don Slutz <dslutz@verizon.com>
Instead of using a hardcoded constant to extract nodeID from
memflags use a macro whose value is based on nodeid_t size.
Also provide a macro for extracting nodeID from memflags so that
users don't need to remember to decrement the value.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
MASK_EXTR() can't be used in MEMF2NODE() (also renamed to
MEMF_get_node()).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Use u8-sized node IDs and unsigned PXMs consistently throughout
code (and introduce nodeid_t type).
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
ACPI defines proximity domain identifier as a 32-bit integer. While
in most cases the values will be zero-based this is not guaranteed,
making current pxm2node[256] mapping structure not appropriate.
We will instead use MAX_NUMNODES-sized array of struct pxm2node to
store PXM-to-node mapping. To accommodate common case of zero-based
and contiguios PXMs we will, whenever possible, try to use PXM as
index into this array for fast lookups.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Use ARRAY_SIZE(pxm2node) instead of MAX_NUMNODES in bounds checks.
Rename struct pxm_to_node to struct pxm2node (the structure tag
aliasing with the array defined using it is better than it aliasing
with a function name).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
In fact: vnode_to_pnode is an array, not a mask; there was a
typo in the one about vmemrange; there was no indication
of the data directions.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Remove a redundant statement from parse_dom0_mem() and refuse bogus
ranges (with a separator other than a dash) passed to
parse_dom0_max_vcpus(). Fix coding style issues in the latter function
at the same time.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Non-anonymous allocations with this flag set should - for the purpose
of the availability check - be treated just like anonymous ones, as
they wouldn't lead to a reduction of ->outstanding_pages.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Moved the definition of struct xenpf_efi_guid and struct
xenpf_efi_time to file scope to avoid compilation errors with C++
(structs defined inside unnamed structs become unavailable
outside their scope with C++). The change allows C++ applications
to use platform.h with no consequences for current C clients.
Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Use the new vgic interface to know which virtual PPI is free and use it
for the event channel code.
At the DOM0 creation time, Xen doesn't know which vIRQ will be free.
All the vIRQ will be reserved when we parse the device tree. So we can
allocate the vIRQ just after the device tree has been parsed.
It's safe to defer the allocation because no vIRQ can be injected as
long as the vCPU is not online.
As the device tree node "hypervisor" containing the description of the
event channel interrupt is created earlier, add a placeholder which will
be fix up once Xen has allocated the PPI.
Also correct the check in arch_domain_create to use is_hardware_domain.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
While it's easy to know which hardware IRQ is assigned to a domain, there
is no way to know which vIRQ is allocated by Xen for a specific domain.
Introduce a bitmap to keep track of every vIRQ used by a domain. This
will be used later to find free vIRQ for interrupt device assignment and
emulated interrupt.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Edge trigger arch timer interrupts really don't make much sense, so if
we discover we are booting on such a system issue a warning.
So far this has only been seen on the fast model emulators which have
both an incorrect DT description of the interrupt and a writeable
ICFGR allowing us to program the incorrect configuration. Other
platforms have incorrect DT descriptions (warned about by previous
patch) but the corresponding ICFGR isn't actually writeable so the
eventual configuration is level as desired.
I did consider overriding the incorrect DT on such systems but since
so far it has only been observed on emulators and we have code in
place to deal with edge triggering here I think warning is sufficient
for now.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
[ ijc -- s/contoller/controller twice ]
The ICFGR register is not necessarily writeable, in particular it is
IMPLEMENTATION DEFINED for a PPI if the configuration register is
writeable. Log a warning if the hardware has ignored our write and
update the actual type in the irq descriptor so subsequent code can do
the right thing.
This most likely implies a buggy firmware description (e.g.
device-tree).
The issue is observed for example on the APM Mustang board where the
device tree (as shipped by Linux) describes all 3 timer interrupts as
rising edge but the PPI is hard-coded to level triggered (as makes
sense for an arch timer interrupt).
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
Cc: Pranavkumar Sawargaonkar <psawargaonkar@apm.com>