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>
... and make it tunable via the command line.
1/8 of RAM is 128M on a 1GB system and 256M on a 2GB system etc,
which is a lot. 1/32 of RAM seems more reasonable. Also drop the
minimum to 32M.
Leave the maximum at 1GB.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
Cc: Jintack Lim <jintack@cs.columbia.edu>
Cc: Jan Beulich <JBeulich@suse.com>
When building hvmloader for Xen tools the ipxe objects are also linked
into the binary. Unfortunately the linker will place them in the order
found in the archive. Since this order is random the resulting hvmloader
binary differs when it was built from identical sources but on different
build hosts. To help with creating a reproducible binary the elements in
blib.a must simply be sorted before passing them to $(AR).
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Don't kill xenstored as part of the usual service shutdown process to
prevent hangs on shutdown where the kernel tries to unplug a VIF
after xenstored has exited.
In an ideal case with all guests cooperating, xendomains will have shut
down all guests before xenstored is killed.
However in the uncooperative case, malicious or crashed guests may still
be running after xendomains has exited and this should not block the
shutdown/reboot of dom0.
Xenstored has no state to sync to disk, and never used to be killed in
the sysvinit case; observe the warning in xencommons. Our testing has
shown regressions caused by the change in behaviour between sysvinit and
systemd when it comes to killing xenstored.
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
[ ijc -- added systemd to title ]
Each class can contains 32 permisions which are encoded on a word (one
bit per permission).
Currently the awk script will generate an hexadecimal value for each
permission. This may result to generate an invalid value on some version
of awk.
For instance debian jessie is using a version of mawk where (1 << 31)
will result to 0x7fffffff.
This is because the awk specification requires to do the arithmetic with
float. So the resulting integer may vary following the implementation.
As the generated headers are only used by C code, generate the
permission define via "1UL << n".
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Coverity uses several heuristics to identify when one case statement
legitimately falls through into the next, and a comment as the final item in a
case statement is one heuristic (the assumption being that it is a
justification for the fallthrough).
Use this to perform an audit of defects and hide the legitimate fallthroughs.
There are two bugfixes identified in the audit, both minor:
* 'n' command line handling for gtracestat
* BKSPC handling in xentop
All other identified defaults are legitimate fallthoughs
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Coverity-IDs: 1055464, 1055465, 1055467, 1055468, 1055481, 1055482
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Xen Coverity Team <coverity@xen.org>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Don Koch <dkoch@verizon.com>
by providing the definition of the {w,r}rmsr_tsc_msr counters,
used within Viridian implementation.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
There existed some codepaths which had a domain in their hand, but needed a
vcpu to drive the shadow interface.
Now that these interfaces have changed to be domain based, the hoop-jumping
can be removed.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
This allows the removal an improper use of d->vcpu[0] from toolstack context
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
This allows the removal an improper use of d->vcpu[0] from toolstack context
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
This allows the removal of 3 improper uses of d->vcpu[0] from toolstack context
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
This involves introducing the domain variant of hash_foreach()
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Each of these functions will have their vcpu paramters replaced with domain
parameters because they are part of domain-generic rather than vcpu specific
codepaths, which means that the use of 'v' will have to change. 'current' can
be used to obtain a vcpu when in an appropriate context.
The 'curr->domain == d' test is less restrictive than 'v == current'. The end
result is still safe as the code still only runs in the context of the correct
domain, but is now valid to run in cases where previously 'v' was some other
vcpu in the same domin.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
This enum was used for matching a specific class of device and not to get the
type of device.
Hence the name device_type will be used for another purpose later.
Also rename device_get_type into device_get_class to reflect the change.
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>
Some drivers may want to configure differently the device depending on
the compatible string. For this purpose, add a new field in the
dt_device_match to store the data.
Also modify the return type of dt_match_node to return the matching
structure.
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>
The header asm/device.h has been included in the vgic code during
splitting to support multiple version. But no code within those files
requires it.
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>
- Drop wrong comment about the default stride. It's not always 2 * SZ_64K.
When the re-distributor support VLPIs (from GICv4), the default
stride is 4 * SZ_64K
- Explain why SZ_64K * 2
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The current VGIC code doesn't support to change the pending and active status
of an IRQ via the (re-)distributor.
Futhermore, all the access size wasn't support correctly and some
registers was implemented as write-ignore. The latter make very
difficult for a kernel developer to find that we don't support R/W to
those registers.
Make the support consistent:
- read will return 0 (RAZ)
- write will print an error and inject a data abort to the guest
Also, those fields was never set and field such as ipend and pendsgi was
doing the same jobs.
Rather than wasting memory, we should better drop it. We could re-introduce
them if we need it when the support will be made.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- s/XENLOG_ERR/XENLOG_G_ERR/g ]
This register is shared between every vCPUs and the lock was already
taken for read.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
All the GICv2 registers are word-accessible. Some them are also
byte-accessible (see GICD_IPRIORITYR*).
Those registers are incorrectly implemented when they should be RAZ. Only
word-access size are currently allowed for them.
To avoid further issues, introduce different label following the access-size
of the registers:
- read_as_zero_32 and write_ignore_32: Used for registers accessible
via a word.
- read_as_zero: Used when we don't have to check the access size.
The latter is used when the access size has already been checked in the
register emulation and/or when the register offset is reserved/implementation
defined.
Note that, only used labels has been introduced.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The number of implemented CPU interfaces is one more than the value of
this field.
Also avoid hardcoding the shift and remove useless mask.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The messages in the common emulation doesn't specify which distributor
(redistributor or distributor) is used. This make difficult to find the
correct registers.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>