pa_range_info has only 8 elements and is accessed using pa_range as
index. pa_range is initialized to 16, potentially causing out of bound
access errors. Fix the issue by checking that pa_range is not greater
than the size of the array. Remove the now superfluous pa_range&0x8
check.
Coverity-ID: 1381865
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Julien Grall <julien.grall@arm.com>
HorizontalResolution and VerticalResolution are 32bit, while size is
64bit. As it stands multiplications are evaluated with 32bit arithmetic,
which could overflow. Cast HorizontalResolution to 64bit to avoid that.
Coverity-ID: 1381858
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Some recent change in x86_emulate.c has simplified the callgraph sufficiently
for Coverity to notice these, rather than hitting its upper path limit.
All are legitimate fallthoughs. Annotate them as such.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
... from serial console so that one doesn't always need to reboot to
see more / less messages.
Note that upper thresholds are sticky, i.e. while they get adjusted
upwards when the lower threshold would otherwise end up above the upper
one, they don't get adjusted when reducing the lower one. Full
flexibility is available only via a future sysctl interface.
Note further that (meaningless) large threshold values aren't being
rejected, for the sake of not adding more checks to the code than are
really necessary for safe operation.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Move the looking at EFLAGS.DF into the macro (being renamed to no
longer suggest a particular direction, rendering all call sites more
readable.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Currently, the driver uses the APIC ID to index into the ioapic_sbdf array.
The current MAX_IO_APICS is 128, which causes the driver initialization
to fail on the system with IOAPIC ID >= 128.
Instead, this patch adds APIC ID in the struct ioapic_sbdf,
which is used to match the entry when searching through the array.
Also, this patch removes the use of ioapic_cmdline bit-map, which is
used to track the ivrs_ioapic options via command line.
Instead, it introduces the cmdline flag in the struct ioapic_sbdf,
to identify if the entry is created during ivrs_ioapic command-line parsing.
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Allow the use of both the emulated local APIC and IO APIC for the hardware
domain.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
From the make documentation:
"$* [...] If the target is `dir/a.foo.b' and the target pattern is
`a.%.b' then the stem is `dir/foo'. In a static pattern rule, the
stem is part of the file name that matched the `%' in the target
pattern."
The rule generating the c types files from the idl ones is not
a static pattern rule, but rather an implicit rule. Thus the value
of $* is preceded by the file path, instead of only what matches %.
In order to get this fixed, drop the path using a $(notdir $*).
Signed-off-by: Cédric Bosdonnat <cbosdonnat@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Commit 20b75251d9 introduced an erroneous
negation which gave the isstubdom bool the opposite semantics, causing
the subsequent code to take the wrong code path, which breaks HVM
pci-passthrough.
Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>
Acked-by: Cedric Bosdonnat <cbosdonnat@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Avoid doing so if the domain is not under construction.
If upstream QEMU is in use then it will explicitly create an ioreq server
rather than implicitly creating the default ioreq server, which is a
side-effect of reading HVM_PARAM_IOREQ_PFN, HVM_PARAM_BUFIOREQ_PFN,
or HVM_PARAM_BUFIOREQ_EVTCHN (as is done by legacy QEMUs).
However, if the domain is subsequently saved/migrated then those parameters
are read and hence the default server will be unnecessarily instantiated.
This patch adds an extra check of the 'creation_finished' flag when those
HVM params are read and will only instantiate the server if the domain is
under construction, which will always be the case when QEMU is invoked.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Zhang Chen <zhangchen.fnst@cn.fujitsu.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
LODS, SCAS, and STOS all use the accumulator as one of their operands.
This avoids some open coding of things, but requires switching around
operands of SCAS.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
TSC_DEADLINE in particular depends on both; take the opportunity to add
a few more.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
As said in the code comment being added, only adjustments affecting
further processing prior to the x86_decode_*() calls really belong into
x86_decode() itself.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Let's try to limit #ifdef-ery, or else more of these would need to
appear later.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
... to avoid introducing further redundancy when adding further feature
flag checks, and to bring its use better in line with its host_and_*()
sibling.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
mode == ARRAY_SIZE(mode_strings) causes an out of bound access to
the mode_strings array.
Coverity-ID: 1381859
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Julien Grall <julien.grall@arm.com>
This reduces the net complexity of CPUID handling by having all adjustments in
the same place. Remove the now-unused hvm_funcs.hypervisor_cpuid_leaf()
infrastructure.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This reduces the net complexity of CPUID handling by having all adjustments in
the same place. Remove the now-unused hvm_funcs.cpuid_intercept
infrastructure.
The SYSCALL feature hiding is tweaked when moved. In principle, an
administrator can choose to explicitly hide the SYSCALL feature from the
guest, as it has a separate feature bit. If this is the case, the feature
shouldn't be set behind the back of the administrators wishes. (Not that many
64bit OSes would function in this scenario.) In reality, SYSCALL will always
be set in edx at this point.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
core2_no_vpmu_ops exists solely to work around the default-leaking of CPUID/MSR
values in Xen.
With CPUID handling removed from arch_vpmu_ops, the RDMSR handling is the last
remaining hook. Since core2_no_vpmu_ops's introduction in c/s 25250ed7 "vpmu
intel: Add cpuid handling when vpmu disabled", a lot of work has been done and
the nop path in vpmu_do_msr() now suffices.
vpmu_do_msr() also falls into the nop path for un-configured or unprivileged
domains, which enables the removal the duplicate logic in priv_op_read_msr().
Finally, make all arch_vpmu_ops structures const as they are never modified,
and make them static as they are not referred to externally.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
This reduces the net complexity of CPUID handling by having all adjustments in
the same place. Remove the now-unused vpmu_do_cpuid() infrastructure.
This involves introducing a vpmu_enabled() predicate, and making the Intel
specific VPMU_CPU_HAS_* constants public.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
When a 32-bit address override is in effect these zero-extend all
registers which would also get updated in case of non-zero repeat
count.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Rename _get_rep_prefix() to make it more visibly fit other use cases
and introduce a companion "put". Use them for repeated string insn
handling as well as LOOP/J?CXZ instead of open coding the same logic a
couple of times.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Unconditionally reporting a skipped test in 64-bit builds is not very
useful, especially when quite a few more tests are about to be added.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Since I stumbled across this while looking for further constification
opportunities, also correct the insn_fetch() related comment.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
This is a prereq particularly to eventually supporting UMIP emulation,
but also for LAR/LSL/VERR/VERW.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Now that segment registers are numbered naturally this can be easily
done to achieve some code size reduction.
Also consistently use X86EMUL_OKAY in the code being touched.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
By putting it after all instruction fetching has been done, we can both
simplify the existing handling of immediate operands and take care of
any future instructions allowing rIP-relative operands and getting
additional bytes fetched in x86_decode_*() (the current cases of extra
bytes getting fetched there are only for operands without ModR/M bytes,
or with them only allowing their register forms).
Similarly the new placement of truncate_ea() will take care of any
future cases of non-standard memory operands (the one existing case -
opcodes A0...A3 - are fine with and without this, as they fetch an
ad_bytes sized unsigned address anyway).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Accessing an 8-byte (or perhaps just 4-byte in the test harness when
built as 32-bit app) field to read/write 10 bytes (leveraging the
successive field) is a latent bug, as the compiler could copy things
around. Use the 32 bytes large SSE/AVX slot instead.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Pulling out the {get,put}_fpu() invocations from individual emulation
paths leads to a couple of kb code size reduction in my builds. Note
that this is fine exception-wise:
- #UD and #NM have implementation defined order relative to one
another,
- data read #GP/#SS/#PF now properly are delivered after #NM/#UD.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Consolidate the copying of ea to dst: There's no need to set the type
to OP_MEM, and instead the load cases setting it to OP_NONE allows the
copying to be done just once per major opcode.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Consistently use ea instead of src for passing the memory address to
->read(). This eliminates the need to copy ea to src, resulting in a
couple of hundred bytes smaller binary size.
In addition for opcode DE we can leverage SrcMem16 to eliminate a call
of the ->read() hook. At the same time drop the stray Mov attributes
from D8, DA, DC, and DE: They're meaningful for memory writes only.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
First of all there are a number of secondary encodings both Intel and
AMD support, but which aren't formally documented. See e.g.
www.sandpile.org/x86/opc_fpu.htm for inofficial documentation.
Next there are a few more no-ops - instructions which served a purpose
only on 8087 or 287.
Further switch from fail_if() to raising of #UD in a couple of places
(as the decoding of FPU opcodes should now be complete except where
explicitly marked as todo).
Also adjust a few comments.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
This reverts commit a01b6d464f
as needing further adjustment (namely to properly avoid a
divide by zero issue spotted by Coverity and reported by
Andrew).
Commit 75066cd4ea ("x86emul: fix {,i}mul and {,i}div") can be had with
less code: Simply do the destination register override depending on
DstEax being in effect (the four other ModRM.reg encoded operations of
these two opcodes all use DstMem).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
->read is required to be non-NULL, and is not being checked anywhere else.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
There's no point reading CS - all of the fields get set from scratch
right afterwards. Also correct a wrong comment.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
AArch32 guest will use co-processor registers to access the GICv3 (see
8.5 in IHI 0069C). Some of the registers have to be trapped and emulated
(e.g ICC_SGI1R), this is the purpose of this patch.
The rest of the emulation already supports access required for AArch32
so nothing has to be changed there.
Note this is only enabling 32-bit guest using GICv3 on Xen ARM64. Further
work would be required to compile GICv3 and vGICv3 for Xen ARM32.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The emulation of the co-processor register ICC_SGI1R is the same as the
system register ICC_SGI1R_EL1. So move the emulation outside and use the
newly introduced helper vreg_emulate_sysreg64 to abstract the access.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
We will want to emulate co-processor registers access in a follow-up
patch.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Factorize the code to emulate 32-bit and 64-bit access to a co-processor
in specific helpers.
The new helpers will be used in different components to simplify the
emulation.
Finally, the prototypes for the callbacks to emulate 32-bit and 64-bit
co-processor access are the same as the sysreg one. Rather than
introducing new ones, repurpose the existent prototypes.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Stefano Stabellini
Stefano Stabellini
Andrew Cooper
Jan Beulich
Suravee Suthikulpanit
Roger Pau Monné
Wei Liu
Zhang Chen
Cédric Bosdonnat
Sander Eikelenboom
Paul Durrant
Oleksandr Tyshchenko
Julien Grall