common/vsprintf: Explicitly treat negative lengths as 'unlimited'

The old code relied on implictly casting negative numbers to size_t
making a very large limit, which was correct but non-obvious.

Coverity CID 1128575

Signed-off-by: Tim Deegan <tim@xen.org>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
x86/shadow: Drop shadow_mode_trap_reads()

This was never actually implemented, and is confusing coverity.

Coverity CID 1090354

Signed-off-by: Tim Deegan <tim@xen.org>
x86/mem_sharing: drop unused variable.

Coverity CID 1087198

Signed-off-by: Tim Deegan <tim@xen.org>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
bitmaps/bitops: Clarify tests for small constant size.

No semantic changes, just makes the control flow a bit clearer.

I was looking at this bcause the (-!__builtin_constant_p(x) | x__)
formula is too clever for Coverity, but in fact it always takes me a
minute or two to understand it too. :)

Signed-off-by: Tim Deegan <tim@xen.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
x86/hvm: assert that we we saved a sane number of MSRs.

Just as a backstop measure against later changes that add MSRs to the
save function without updating the count in the init function.

Signed-off-by: Tim Deegan <tim@xen.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
credit: change default timeslice to 5ms

The 30ms timeslice was chosen nearly a decade ago now, with cpu
"burning" workloads in mind.  In the mean time, processors have gotten
faster and VMEXITs have gotten faster.  A timeslice of 30ms has a
major cost when running latency-sensitive workloads like network or
audio streaming: getting caught behind just one or two other VMs can
introduce a processing delay of up to 60ms, and the "round-robin"
nature of the credit scheduler means this delay may be introduced
every time the VM yields for periods of time.

The XenServer performance team at Citrix have done extensive testing
with various timeslices, including 30ms, 10ms, 5ms, and 2ms.  None of
the workloads exhibited any performance degradation with a 5ms
timeslice.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
tmem: drop a gross goto usage

No need to do it that way.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Revert "credit: change default timeslice to 5ms"

This reverts commit 348dee3b8afb72cb4713d2e6600b4e86e0cc1723
(retracted by author/maintainer).
x86/shadow: add a clarifying assertion

... documenting that we don't have to worry about merging guest
provided flags with the ones we want to enforce ourselves.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>