These are supposed to reset to the value of the underlying hardware
but appears not to be on at least some v8 models. There's no harm in
setting them explicitly.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
No optimised versions are available in Linux yet (meaning I couldn't
copy them).
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Obviously nothing is actually making multicalls even on 32-bit so
this isn't tested.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Also, don't crash the host if we fail to emulate a vtimer access,
just kill the guest.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
This still only builds a 32-bit dom0, although it lays a bit of
simple ground work for 64-bit dom0.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
One side effect of this is that we now save the full 64-bit
TTBR[0,1] even on a 32-bit hypervisor. This is needed anyway to
support LPAE guests (although this patch doesn't implement anything
other than the context switch).
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
struct cpu_user_regs is currently used as both internal state
(specifically at the base of the stack) and a guest/toolstack
visible API (via struct vcpu_guest_context used by
XEN_DOMCTL_{g,s}etvcpucontext and VCPUOP_initialise).
This causes problems when we want to make the API 64-bit clean since
we don't really want to change the size of the on-stack struct.
So split into vcpu_guest_core_regs which is the API facing struct
and keep cpu_user_regs purely internal, translate between the two.
In the user API arrange for both 64- and 32-bit registers to be
included in a layout which does not differ depending on toolstack
architecture. Also switch to using the more formal banked register
names (e.g. with the _usr suffix) for clarity.
This is an ABI change. Note that the kernel doesn't currently use
this data structure so it affects the tools interface only.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
The main change is that the 4-bit register specifiers are extended
to 5 bits by taking in an adjacent SBZP bit.
Also 64-bit has two other properties indicting whether or not the
target register was 64-bit (x<n>) or 32-bit (w<n>) and whether the
instruction has acquire/release semantics.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Use "dsb sy" instead of bare "dsb", they mean the same on 32-bit but only the
former is valid on 64-bit.
Abstract the actual flush operation into a macro.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
AArch64 has removed the concept of co-processors replacing them with a
combination of specific instructions (cache and tlb flushes etc) and
system registers (which are understood by name in the assembler).
However most system registers are equivalent to a particular AArch32
co-pro register and can be used by generic code in the same way. Note
that the names of the registers differ (often only slightly)
For consistency it would be better to use only set of names in the
common code. Therefore move the {READ,WRITE}_CP{32,64} accessors into
arm32/processor.h and provide {READ,WRITE}_SYSREG. Where the names
differ #defines will be provided on 32-bit.
HSR_CPREG and friends are required even on 64-bit in order to decode
traps from 32 bit guests.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
The 64-bit bitops are taken from the Linux asm-generic implementations. They
should be replaced with optimised versions from the Linux arm64 port when they
become available.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
arm64 is going to add another one shortly, so take control now.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Acked-by: Keir Fraser <keir@xen.org>
"dsb" must be written "dsb sy" on arm64. "dsb sy" is also valid (and
synonymous) on arm32 but we have a macro so lets use it.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Texinfo 5 breaks QEMU builds. As we do not need documents from QEMU, just
disable it.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Tested-by: jacek burghardt <jaceksburghardt@gmail.com>
- force use of physical APIC mode if indicated so (as we don't support
xAPIC cluster mode, the respective flag is taken to force physical
mode too)
- don't use MSI if indicated so (implies no IOMMU)
Both can be overridden on the command line, for the MSI case this at
once adds a new command line option allowing to turn off PCI MSI (IOMMU
and HPET are unaffected by this).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Note that this also fixes a broken input check in acpi_enter_sleep()
(previously validating the sleep->pm1[ab]_cnt_val relationship based
on acpi_sinfo.pm1b_cnt_val, which however gets set only subsequently).
Also adjust a few minor issues with the pre-v5 handling in
acpi_fadt_parse_sleep_info().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
FADT is now larger than 256 bytes, so all FADT offsets must be
changed from 8 bits to 16 bits.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
If HW-reduced flag is set in the FADT, do not attempt to access
or initialize any ACPI hardware, including SCI and global lock.
No FACS will be present.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Also adjust acpi_fadt_parse_sleep_info().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Ian Campbell
Wei Liu
Jan Beulich
Bob Moore