The call to iommu_pte_flush() between the two hunks uses &ept_entry->epte
which is a pointer into the mapped page.
It is eventually passed to `clflush` instruction which will suffer a pagefault
if the virtual mapping has fallen out of the TLB.
(XEN) ----[ Xen-4.5.0-xs102594-d x86_64 debug=y Not tainted ]----
(XEN) CPU: 7
(XEN) RIP: e008:[<ffff82d0801572f0>] cacheline_flush+0x4/0x9
<snip>
(XEN) Xen call trace:
(XEN) [<ffff82d0801572f0>] cacheline_flush+0x4/0x9
(XEN) [<ffff82d08014ffff>] __iommu_flush_cache+0x4a/0x6a
(XEN) [<ffff82d0801532e2>] iommu_pte_flush+0x2b/0xd5
(XEN) [<ffff82d0801f909a>] ept_set_entry+0x4bc/0x61f
(XEN) [<ffff82d0801f0c25>] p2m_set_entry+0xd1/0x112
(XEN) [<ffff82d0801f25b1>] clear_mmio_p2m_entry+0x1a0/0x200
(XEN) [<ffff82d0801f4aac>] unmap_mmio_regions+0x49/0x73
(XEN) [<ffff82d080106292>] do_domctl+0x15bd/0x1edb
(XEN) [<ffff82d080234fcb>] syscall_enter+0xeb/0x145
(XEN)
(XEN) Pagetable walk from ffff820040004ae0:
(XEN) L4[0x104] = 00000008668a5063 ffffffffffffffff
(XEN) L3[0x001] = 00000008668a3063 ffffffffffffffff
(XEN) L2[0x000] = 000000086689c063 ffffffffffffffff
(XEN) L1[0x004] = 000000056f078063 000000000007f678
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 7:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=0000]
(XEN) Faulting linear address: ffff820040004ae0
(XEN) ****************************************
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Some of the generic hooks were unused altogether - drop them.
Some of the hooks were used only to handle calls from the specific
vendor's code (SVM) - drop them too.
Several more hooks were pointlessly implementaed as out-of-line
functions, when most (all?) other HVM hooks use inline ones - make
them inlines. None of them are implemented by only one of SVM or VMX,
so also drop the conditionals. Funnily nhvm_vmcx_hap_enabled(), having
return type bool_t, nevertheless returned -EOPNOTSUPP.
nhvm_vmcx_guest_intercepts_trap() and its hook and implementations are
being made return bool_t, as they should have been from the beginning
(its sole caller only checks for a non-zero result).
Finally, make static whatever can as a result be static.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
- remove vcpu_info from xlat.lst (it isn't and can't be checked)
- drop pointless (redundant) casts
- make dummy_vcpu_info static
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
- drop pointless nr_grant_entries() check from loop over reserved
entries (adding suitable BUILD_BUG_ON()s to validate that)
- adjust types
- rename d to currd
- formatting
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
hvm_info->signature is not a string, but an 64 bit int, and is not
NULL terminated. The use of strncpy to populate it is inappropriate and
potentially misleading. A cursory glance might have you thinking someone
had miscounted the length of the string literal - not realising it was
intentionally cropping of the null termination.
Also, since we wish to initialise all of hvm_info->signature, and
certainly no more, the use of sizeof is safer.
Coverity-ID: 1198710
Signed-off-by: Jennifer Herbert <jennifer.herbert@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
This field have been set but not used since Xen 4.5. Slim down Xen by
about 4K by removing it.
Also fix comment coding style.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
domain config output goes to
before after
xl create nowhere nowhere
xl create -d stderr stderr
xl -N create stdout stdout
xl -N create -d stderr stdout
It is not sensible that adding -d would cause different output on
stdout. And that -N would produce less debug output is hardly
surprising in general and not really a problem in this case.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: New patch in this version of the mini-series.
Currently, xl -N create produces:
{
"domid": null,
"config": {
"c_info": {
"type": "pv",
[etc]
}
The domid is always NULL (as the domain has not been created at this
stage).
This is annoying if you want to take this output and use it for some
actually useful purpose like domain creation: either it needs to be
massaged, or the the consuming tool needs to be taught to look inside
the json object for the `config' element (which IMO makes no sense as
an interface).
We would like to be able to pass libxl json configs around sensibly.
In the future maybe xl will grow an option to create a domain from a
json config, and this is currently something I want to be able to have
a test tool do.
Note that this change is NOT BACKWARDS COMPATIBLE. But it would only
adversely affects anyone who uses `xl -N create' and then saves and
processes the JSON. (The output from xl list et al is not changed; it
normally needs the domid.) Such a user should probably have already
have complained about the infelicitous output. If they haven't it
would be simple enough for them to bookend the output so as to provide
compatible output.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Euan Harris <euan.harris@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Print json output to correct filehandle
(Using newly introduced flush_stream.)
We are going to want to reuse this. Adjust the code slightly to
detect right away call sites that pass something other than stdout or
stderr.
No resulting functional change.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: New patch in this version of the mini-series
Also contains a fix from Thomas Leonard (to use %u for "4 + 32", not
%lu) previously posted as part of "mini-os: enable compiler check for
printk format types" but with mini-os now having been split a separate
repo most of that change has been applied there.
This fixes the 32-bit build with updated mini-os which includes format
string checking.
Signed-off-by: Thomas Leonard <talex5@gmail.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>
Acked-By: Samuel Thibault <samuel.thibault@ens-lyon.org>
[ ijc -- Updated MINIOS_UPSTREAM_REVISION ]
After we have increased the size of GICR in address space for guest
and made use of both AFF0 and AFF1 in (v)MPIDR, we are now able to
support up to 4096 vCPUs in theory. However, it will cost 512M
address space for GICR region, which is unnecessarily big at the
moment. Considering the max CPU number that GIC-500 can support and
the old value of MAX_VIRT_CPUS before commit aa25a61, we increase
its value to 128.
Signed-off-by: Chen Baozi <baozich@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Each vGIC driver supports different maximum numbers of vCPU. For
example, GICv2 is limited to 8 vCPUs, while GICv3 can support up
to 4096 vCPUs if we use both AFF0 and AFF1. Thus, domain_max_vcpus
should depend on not only MAX_VIRT_CPUS but also the version
of vGIC that the guest uses.
Since evtchn_init would call domain_max_vcpus to allocate poll_mask
when the vgic_ops haven't been initialised yet, we make it return
MAX_VIRT_CPUS at that time. On ARM32, event channel doesn't need
to allocate the poll_mask because MAX_VIRT_CPUS < BITS_PER_LONG,
while allocating more memory (2 unsigned long rather than 1) only
for poll_mask on arm64 with GICv2 looks not so expensive.
We didn't keep it as the old static inline form because it will break
compilation when access the member of struct domain:
In file included from xen/include/xen/domain.h:6:0,
from xen/include/xen/sched.h:10,
from arm64/asm-offsets.c:10:
xen/include/asm/domain.h: In function ‘domain_max_vcpus’:
xen/include/asm/domain.h:266:10: error: dereferencing pointer to incomplete type
if (d->arch.vgic.version == GIC_V2)
^
Signed-off-by: Chen Baozi <baozich@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
According to ARM CPUs bindings, the reg field should match the MPIDR's
affinity bits. We will use AFF0 and AFF1 when constructing the reg value
of the guest at the moment, for it is enough for the current max vcpu
number.
Signed-off-by: Chen Baozi <baozich@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
[ ijc -- use PRIx64 to format mpidr_aff in node name, fixing 32-bit
build ]
According to ARM CPUs bindings, the reg field should match the MPIDR's
affinity bits. We will use AFF0 and AFF1 when constructing the reg value
of the guest at the moment, for it is enough for the current max vcpu
number.
Signed-off-by: Chen Baozi <baozich@gmail.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The old unsigned long type of vcpu_mask can only express 64 cpus at the
most, which might not be enough for the guest which used vGICv3. We
introduce a new struct sgi_target for the target cpu list of SGI, which
holds the affinity path information (only level 1 at the moment). For
GICv2 that has no affinity level, we can just set the corresponding
fields to be 0.
Signed-off-by: Chen Baozi <baozich@gmail.com>
There are 3 places to change:
* Initialise vMPIDR value in vcpu_initialise()
* Find the vCPU from vMPIDR affinity information when accessing GICD
registers in vGIC
* Find the vCPU from vMPIDR affinity information when booting with vPSCI
in vGIC
- Both PSCI 0.1 and PSCI 0.2 are modified to respect the MPIDR like.
Signed-off-by: Chen Baozi <baozich@gmail.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
GICv3 restricts that the maximum number of CPUs in affinity 0 (one
cluster) is 16. (See the note of 'Bits[15:0]' in '5.7.29 ICC_SGI0R_EL1
ICC_SGI1R_EL1 and ICC_ASGI1R_EL1, GICv3 Architecture Specification')
That is to say the upper 4 bits of affinity 0 is unused. Current
implementation considers that AFF0 is equal to vCPUID, which makes all
vCPUs in one cluster, limiting its number to 16. If we would like to
support more than 16 number of vCPU in one guest, we need to make use
of AFF1. Considering the unused upper 4 bits, we need to create a pair
of functions mapping the vCPUID and virtual affinity.
Signed-off-by: Chen Baozi <baozich@gmail.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Currently it only supports up to 8 vCPUs. Increase the region to hold
up to 128 vCPUs, which is the maximum number that GIC-500 supports.
Signed-off-by: Chen Baozi <baozich@gmail.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
so that, if the same config is reused later, the following
two (good) things happen:
- we do not trip over warnings because node and/or vcpu
soft affinity now exist (as a consequence of the
successful placement), but numa_placement is still
true;
- we end up always using the results of the original
execution of the placement algorithm, rather than
re-running it at each re-use of the same config,
which is what most users expects and wants.
This fixes the bug reported here:
http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg04454.html
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
instead than errors. More specifically, in libxl,
b_info->numa_autoplacement is meant as a way to
disable automatic NUMA placement, if one does not
want it to happen. It is, however, useful for
consistency checking as well, i.e., to ensure that
the user provided configuration (such as, for instance,
vcpu hard or soft affinity) and NUMA placement itself
will not clash.
However, right now, if such a clash happens we abort
domain creation and error out, which is too much! It
is, in fact, enough to infom the user/caller that NUMA
placement won't be performed, with a WARN, and that's
what this commit does.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Currently, it's hard to decide whether a part of the domain
initialization should live in gicv_setup (part of the GIC
driver) and domain_init (part of the vGIC driver).
The code to initialize the domain for a specific vGIC version is always
the same no matter the version of the GIC.
Move all the domain initialization code for the vGIC in the respective
domain_init callback of each vGIC drivers.
New structures have been introduced to store HW information per vGIC.
Each vGIC HW structure contains a boolean to indicate if the current GIC is
able to support this specific version of virtual GIC.
Helpers have been introduced in order to help the GIC correctly setup
the vGIC. The GIC will have to call them to announce support for this
specific version.
Also drop fields that become unnecessary in each global state.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The driver only needs to know the base address of the hypervisor
register during the GIC initialization (see {gicv2,hip04}_init).
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>
- Print all the redistributor regions rather than only the first
one...
- Add # in the format to print 0x for hexadecimal. It's easier to
differentiate from decimal
- Re-order information printed
- Drop print of the virtual addresses. It makes the log more
difficult to read and don't improve user debugging experience (the
value can't be used like as it is).
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
It's not necessary to get from the hardware DT the redistributor
informations again. We already have it stored in the gic_info and
the domain.
Use the latter to be consistent with the rest of the function.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
On GICv3, the default size of the distributor region is 64kB (see 5.3
in PRD03-GENC-010745 24.0). This region can be extended to provide an
implementation defined set of pages containing additional aliases for MSI.
Although, the GICv3 driver only access to register within the default
distributor region.
Furthermore, our vGIC driver implementation doesn't support the extended
distributor. Therefore there is no reason to expose it to DOM0.
Finally drop the field dbase_size which is not useful anymore.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The domain_init callback can return error. Check it and progate the
error if necessary.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Making it clear that the callback is only used to make the device tree node
for the hardware domain.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
for clarity and it will be easier to understand some follow-up patches.
Also gate gic_v3 structure with HAS_GICV3.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Currently, the grant table region is hardcoded per-platform. When a new
board is coming up, we have to check the spec in order to find a space
in the memory layout free. Depending on the platform it may be tedious.
A good candidate for the gnttab region is the one used by Xen binary as
some part will never be mapped to the DOM0 address, MMIO are mapped 1:1
and the RAM will be either:
- direct mapped: 1:1 mapping is used => no problem
- non direct mapped: Xen always relocates himself as high as possible
(limited to 4GB on ARM32) and the RAM bank are filled from the first
one. It's very unlikely that the gnttab region will overlap with the
RAM. Although for safety a check may be necessary when we will reenable
the option.
Furthermore, there is plenty of space to contain a big gnttab, the default
size is 32 frame (i.e 128KB) but it can be changed via a command option.
It's not possible to use the whole region used by Xen, as some part of
the binary will be freed after Xen boot and can be used by DOM0 and other
guest. A sensible choice is the text secion as it will always reside in
memory never be mapped to the guest and the size is big enough (~300KB
on ARM64). It could be extended later to use other contiguous sections
such as data...
Note that on ARM64, the grant table region may be after 4GB (Xen is
relocated to the highest address) using DOM0 32 bit with short page table
may not work. Although, I don't think this is a big deal as device may not
work and/or the RAM is too high due to the 1:1 mapping.
This patch also drop the platforms thunderx and xilinx-zynqmp which became
dummy by dropping the hardcoding DOM0 grant table region.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Fix example code in comment. libxl_event_check() can return
ERROR_NOT_READY; LIBXL_NOT_READY does not exist.
Signed-off-by: Euan Harris <euan.harris@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
If the host EPT entry is changed, the nested EPT should be updated.
the current code does not do this, and it's wrong.
I have tested this patch, the L2 guest can boot and run as normal.
Signed-off-by: Liang Li <liang.z.li@intel.com>
Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>
Reported-by: Tim Deegan <tim@xen.org>
Reviewed-by: Tim Deegan <tim@xen.org>
xen-*-syms cannot actually be booted, so putting it in /boot is a bit
misleading. It also happens to cause a warning from update-grub (so at
least it doesn't end up in grub.cfg)
/usr/lib/debug seems to be a pretty common path for installing such
debug info.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
[ ijc -- fixed typos ]
A few folks have been caught out by OSes which call e.g.
HYPERVISOR_event_channel_op_compat which has been deprecated since
3.2.2 (i.e. long before Xen on ARM). Existing x86 code can still
safely and quietly using those calls, waiting for an unsuspecting ARM
porter to turn up and trip over it. This turns out to be rather
perplexing when it happens, since it can be obscured e.g. by various
conditionals like __XEN_INTERFACE_VERSION__ what is actually being
called.
Note that I'm making a distinction here between hypercalls which are
simply not used/implemented on arm (yet) and those which were
deprecated and replaced by a newer variant prior to Xen on ARM even
being invented. The latter will never be implemented on ARM and have
non-deprecated aliases leading to confusion so those are the ones for
which a warning is useful.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: Ard Biesheuvel <ard@linaro.org>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
A find option was forgotten in commit 6592bf60be
"docs: Look for documentation in sub-directories" resulting to get some
docs duplicated and other missing.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Andrew Cooper
Jan Beulich
Feng Wu
Jennifer Herbert
Ian Campbell
Julien Grall
Ian Jackson
Chen Baozi
Dario Faggioli
Euan Harris
Wei Liu
Liang Li
Tiejun Chen
Wen Congyang