Which of course has a different model number and sports two
serial outputs.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Keir Fraser <keir@xen.org>
Make it so this is easier to extend, and move the parsing code/data
into .init.* sections.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Aravind Gopalakrishnan<aravind.gopalakrishnan@amd.com>
- make sure UC- is only used for PAT purposes (MTRRs and hence EPT
don't have this type)
- add order input to "get", and properly handle conflict case (forcing
an EPT page split)
- properly detect (and refuse) overlaps during "set"
- properly use RCU constructs
- support deleting ranges through a special type input to "set"
- set ignore-PAT flag in epte_get_entry_emt() when "get" succeeds
- set "get" output to ~0 (invalid) rather than 0 (UC) on error (the
caller shouldn't be looking at it anyway)
- move struct hvm_mem_pinned_cacheattr_range from header to C file
(used only there)
Note that the code (before and after this change) implies the GFN
ranges passed to the hypercall to be inclusive, which is in contrast
to the sole current user in qemu (all variants). It is not clear to me
at which layer (qemu, libxc, hypervisor) this would best be fixed.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Acked-by: Kevin Tian <kevin.tian@intel.com>
This capability solely makes a statement on cache coherency guarantees
by the IOMMU. It does specifically not imply any further guarantees
implied by certain memory types (cachability, ordering).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
... between constituent pages. To indicate such, the page order is
being passed down to the vMTRR routines, with a negative return value
(possible only on order-non-zero pages) indicating such collisions.
Some code redundancy reduction is being done to ept_set_entry() along
the way, allowing the new handling to be centralized to a single place
there.
In order to keep ept_set_entry() fast and simple, the actual splitting
is being deferred to the EPT_MISCONFIG VM exit handler.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Acked-by: Kevin Tian <kevin.tian@intel.com>
The main goal here is to drop the bogus dependency of
epte_get_entry_emt() on d->arch.hvm_domain.params[HVM_PARAM_IDENT_PT].
Any change to state influencing epte_get_entry_emt()'s decision needs
to result in re-calculation. Do this by using the EPT_MISCONFIG VM
exit, storing an invalid memory type into EPT's emt field (leaving the
IOMMU, which doesn't care about memory types, unaffected).
This is being done in a hierarchical manner to keep execution time
down: Initially only the top level directory gets invalidated this way.
Upon access, the involved intermediate page table levels get cleared
back to zero, and the leaf entry gets its field properly set. For 4k
leaves all other entries in the same directory also get processed to
amortize the cost of the extra VM exit (which halved the number of
these VM exits in my testing).
This restoring can result in spurious EPT_MISCONFIG VM exits (since
two vCPU-s may access addresses involving identical page table
structures). Rather than simply returning in such cases (and risking
that such a VM exit results from a real mis-configuration, which
would then result in an endless loop rather than killing the VM), a
per-vCPU flag is being introduced indicating when such a spurious VM
exit might validly happen - if another one occurs right after VM re-
entry, the flag would generally end up being clear, causing the VM
to be killed as before on such VM exits.
Note that putting a reserved memory type value in the EPT structures
isn't formally sanctioned by the specification. Intel isn't willing to
adjust the specification to make this or a similar use of the
EPT_MISCONFIG VM exit formally possible, but they have indicated that
us using this is low risk wrt forward compatibility.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Acked-by: Kevin Tian <kevin.tian@intel.com>
This now uses the same decision tree as libxc (which is much easier to test).
The main change is to explicitly handle the placement at 128MB or end of RAM
as two cases, rather than combining with MIN. The effect is the same but the
code is clearer.
Secondly the attempt to place the modules right after the kernel is removed,
since it is redundant with the case where placing them at the end of RAM ends
up abutting the kernel.
Also round the kernel size up to a 2MB boundary.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
The placement algorithm should be effectively the same and using different
variable names makes my head hurt when I try to compare.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
314c9815e2 "tools: implement initial ramdisk support for ARM." broke starting
guests with <= 128 MB ram by placing the boot modules (dtb and initrd)
immediately after the kernel in this case, running the risk of them being
overwritten. Instead place the modules at the end of RAM, as the hypervisor
does for dom0.
The hypervisor also falls back to placing things before the kernel as a last
resort before failing, so add that here too.
Tested with the Debian installer initrd and guests of 96MB, 128MB, 256MB and
1GB. All work, also tested with 64MB but the installer doesn't run with so
little RAM (but our placement of the initrd is correct).
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
According to http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
__builtin_expect has the prototype:
long __builtin_expect (long exp, long c)
If sizeof(exp) > sizeof(long) then this will effectively mask off the top bits
of exp, meaning that the if in "if (unlikey(x))" will see the masked version,
which might be false when true was expected, likely has the same issue.
This is mostly likely to affect x86_32 and arm32 builds. x86_32 is not
present on 4.3 onwards and a quick grep of current staging shows that all the
existing arm32 uses of both likely and unlikely already pass a boolean. I
noticed this with an as yet unposted patch which did not have this property.
Also the defintion of likely might not have had the expected affect for cases
where a true value > 1 might be passed.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
We haven't shipped a XenoLinux kernel for more releases than I can remember.
We held onto these because osstest was using them but this is no longer the
case.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
These were added by 7dbfc2f8b0 "docs: Honour --{en, dis}able-xend when
building docs" between v1 and the (eventually committed) v2 of 9e8672f1c3
"tools: remove xend and associated python modules" and were missed when
rebasing for v2.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Parameter "destroy" in function client_flush() and pool_flush() is unneeded
because it was always set to 1.
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reorg the code to make it more readable.
Check the return value of shared_pool_join() and drop a unneeded call to
it. Disable creating a shared & persistant pool in an advance place.
Note that one might be tempted to delay the creation of the pool even
further in the code. That however would break the behavior of the code
- that is if we ended up creating a shared pool and the
'uuid_lo == -1L && uuid_hi == -1L' logic stands we still need to
create a pool - just not shared type.
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Make function tmemc_shared_pool_auth() more readable.
Note that the previous check for free being set the first time
'(free == -1)' in the loop is now removed. That is OK because
when we set free the first time ('free = i;') we follow it
immediately with a break to get out of the loop.
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Parameters "selective" and "no_rebalance" are meaningless in obj
destroy path, this patch remove them. No place uses
no_rebalance=1. In the obj_destroy path we always call it with
no_balance=0.
Note that this will now free it only if:
obj->last_client == cli_id
Which is OK - even if we allocate a non-shared pool we set by
default the obj->last_client to TMEM_CLI_ID_NULL so even if
the pool is never used, the pool_flush will take care of removing
those.
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
tmemc_set_var() calls tmemc_set_var_one() but without taking its return value,
this patch fix this issue.
Also rename tmemc_set_var_one() to __tmemc_set_var().
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
No need to maintain a global pool list, nobody use it.
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Function client_freeze() only set client->frozen = freeze, the caller can do
this work directly.
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
There are several functions related with pgp free, but their relationships are
not clear enough for understanding. This patch made some cleanup by remove
pgp_delist() and pgp_free_from_inv_list().
The call trace is simple now:
pgp_delist_free()
> pgp_free()
> __pgp_free()
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
The only difference of the "from_delete" parameter in pgp_free() is one line
ASSERT(), this patch moves it the caller to make code more clean.
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
The parameter "eph_lock" is only needed for function tmem_evict(). Embeded the
delist code into tmem_evict() directly so as to drop the eph_lock parameter. By
this change, the eph list lock can also be released a bit earier.
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
[v2: A fix for an assertion of 'client->eph_count >= 0' was rolled in]
There is a potential bug in the obj allocate path. When there are parallel
callers allocate a obj and insert it to pool->obj_rb_root, an unexpected
obj might be returned (both callers use the same oid).
Caller A: Caller B:
obj_find(oidp) == NULL obj_find(oidp) == NULL
write_lock(&pool->pool_rwlock)
obj_new():
objA = tmem_malloc()
obj_rb_insert(objA)
wirte_unlock()
write_lock(&pool->pool_rwlock)
obj_new():
objB = tmem_malloc()
obj_rb_insert(objB)
write_unlock()
Continue write data to objA
But in future obj_find(), objB
will always be returned.
The route cause is the allocate path didn't check the return value of
obj_rb_insert(). This patch fix it and replace obj_new() with better name
obj_alloc().
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
This is done so PVH guests can use PHYSDEVOP_pirq_eoi_gmfn_v{1/2}.
Update users of this fields, to reflect that this has been moved and
it is now also available to other kind of guests.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Move auto_unmask ahead of the other two fields, to reduce padding.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
This add a set of trace events that track the setup of various
emulated devices related to timers in domU.
This set is hpet, pit (i8253, i8254), rtc (MC146818), apic (lapic),
and pic (i8259). The pmtimer is not traced since it does not have a
changeable rate.
Signed-off-by: Don Slutz <dslutz@verizon.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Currently __cmpxchg_mb is only marked inline. The compiler can decide to not
inline this function. In this case, the call to __cmpxchg will be inlined
but not optimised. This will result linking failure because of __bad_cmpxchg.
Caught by clang 3.5.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The ramdisk is passed to the kernel as a property in the chosen node of the
device tree. This is somewhat tricky since in order to place the ramdisk and
dtb in ram we first need to know the size of the dtb. So we initially create a
DTB with placeholders for the ramdisk and finalise the value (which doesn't
change the size) once we know where everything is.
Rename libxl__arch_domain_configure to xl__arch_domain_init_hw_description to
better reflect its use and to be consistent with the new
libxl__arch_domain_finalise_hw_description.
The common xc_dom_build_image() function did not support explicit placement of
the ramdisk, instead passing 0 to xc_dom_alloc_segment, meaning "pick
somewhere". This change instead passes ramdisk_seg.vstart. If nothing has set
vstart then it will be zero because the entire dom struct is zeroed on
allocation in xc_dom_allocate(). Therefore there is no change to the behaviour
on x86. This is also consistent with how other segments (kernel, dtb) are
handled.
Furthermore if the ramdisk has been explicitly placed then xc_dom_build_image()
assumes that it is not to be decompressed (since that would muck up the sizings
used on placement).
With all that I'm able to boot a domain using the current Debian Jessie armhf
installer initrd and have it complete successfully.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
[ ijc -- s/itherwise/otherwise and dropped bogus emacs magic change ]
Intel recently released some new features, including RDSEED, ADX, and
PREFETCHW. This patch exposes these new features to pv and hvm.
Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Guest's configuration parameters (e.g. timer_mode) are used by the hypervisor
during runtime. We should therefore set them during restore.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Using xzalloc to alloc client and pool, so some extra initialization
are dropped.
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Pagesize is always the same as PAGE_SIZE in tmem, so remove pageshift from
struct tmem_pool and use POOL_PAGESHIFT and PAGE_SIZE directly.
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Refactor function do_tmem_op() to make it more readable.
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
[v2: Fixed up tab vs spaces, also removed dead code and added gulped code]
This is some coverity-inspired tidying.
Coverity has some grief analysing the call sites of atomic_read(). This is
believed to be a bug in Coverity itself when expanding the nested macros, but
there is no legitimate reason for it to be a macro in the first place.
This patch changes {,_}atomic_{read,set}() from being macros to being static
inline functions, thus gaining some type safety.
One issue which is not immediately obvious is that the non-atomic variants take
their atomic_t at a different level of indirection to the atomic variants.
This is not suitable for _atomic_set() (when used to initialise an atomic_t)
which is converted to take its parameter as a pointer. One callsite of
_atomic_set() is updated, while the other two callsites are updated to
ATOMIC_INIT().
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan<tim@xen.org>
Acked-by: Keir Fraser <keir@xen.org>
[For the arm bits:]
Acked-by: Ian Campbell <ian.campbell@citrix.com>
do_tmem_destroy_pool is checking if pools == NULL. But, pools is a fixed
array.
Clang 3.5 will fail to compile xen/common/tmem.c with the following error:
tmem.c:1848:18: error: comparison of array 'client->pools' equal to a null
pointer is always false [-Werror,-Wtautological-pointer-compare]
if ( client->pools == NULL )
Coverity-ID:1055632
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
...otherwise if pcd_associate fails due to out-of-memory, the caller of
do_tmem_put will think the call was successful.
While at it, fix up the style issue.
Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
Reviewed-by: Bob Liu <bob.liu@oracle.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
The list of function above are only used internally in common/tmem:
- oid_compare
- oid_set_invalid
- oid_hash
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
print_special() uses the width argument to both select output format
and array size. So by passing 4 it expects an array of uint32_t.
But an array of uint64_t is passed.
So copy and mask the registers to 32 bits.
Signed-off-by: Don Slutz <dslutz@verizon.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Konrad Rzeszutek Wilk
Jan Beulich
Liu Jinsong
Ian Campbell
Wei Liu
Bob Liu
Bob Liu
Roger Pau Monné
Don Slutz
Julien Grall
Liu Jinsong
Boris Ostrovsky
Andrew Cooper
Matthew Daley