Previously device ids in libxl were treated as integers meaning they
were being initialized to 0, which is a valid device id. This patch
makes devid its own type in libxl and initializes it to -1, an invalid
value.
This fixes a bug where if you try to do a xl DEV-attach multiple
time it will continuously try to reattach device 0 instead of
generating a new device id.
Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
Add sanity check for input vcpu so that malicious value would not
return 0. Add comments since vcpu=-1 (broadcast) is some implicit to
code reader.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Suggested-by: Christoph Egger <Christoph.Egger@amd.com>
Acked-by: Christoph Egger <Christoph.Egger@amd.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
Public headers should include one another only via self-relative
include directives (violated by 25955:07d0d5b3a005).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
This allows Xen to walk the l1 hypervisor's shadow pagetable
correctly. Not needed for hap-on-hap guests because they are handled
at lookup time. Problem found with 64bit Win7 and 32bit XPMode where Win7
switches forth and back between long mode and PAE legacy pagetables.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
[Adjusted to update in all cases where the l1 vmm uses shadows]
Signed-off-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>
During debugging of another problem I found that in x2APIC mode, the
destination field of the low address value wasn't passed back
correctly. While this is benign in most cases (as the value isn't being
used anywhere), it can be confusing (and misguiding) when printing the
value read or when comparing it to the one previously passed into the
inverse function.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Rather than doing this in multiple places, have a single central
function (decode_register()) to be used by all other code.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
.. with respect to behavior when there is no HPET broadcast support
(for using the PIT broadcast instead, it requires explicitly enabling
CPU idle management).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Add a trace record for every hypercall inside a multicall. These use
a new event ID (with a different sub-class ) so they may be filtered
out if only the calls into hypervisor are of interest.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
Trace hypercalls using a more useful trace record format.
The EIP field is removed (it was always somewhere in the hypercall
page) and include selected hypercall arguments (e.g., the number of
calls in a multicall, and the number of PTE updates in an mmu_update
etc.). 12 bits in the first extra word are used to indicate which
arguments are present in the record and what size they are (32 or
64-bit).
This is an incompatible record format so a new event ID is used so
tools can distinguish between the two formats.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
We want to add additional sub-classes for TRC_PV tracepoints and to be
able to only capture these new sub-classes. This cannot currently be
done as the existing tracepoints all use a sub-class of 0xf.
So, redefine the PV events to use a new sub-class. All the current
tracepoints are tracing entry points to the hypervisor so the
sub-class is named TRC_PV_ENTRY.
This change does not affect xenalyze as that only looks at the main
class and the event number and does not use the sub-class field.
Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
This is already in use despite never being registereed.
See XEN_IOPORT_LINUX_PRODNUM in include/xen/platform_pci.h
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
These product numbers are used by the QEMU blacklisting protocol in
traditional QEMU and are currently coded directly into the xenstore.c
source module. Since there are now multiple QEMUs this information
should be pulled into a public header to avoid duplication/conflict.
hvm-emulated-unplug.markdown has also been adjusted to reference the
new header.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
The sched_credit_default_yield option was added when the behavior of
"SCHEDOP_yield" was changed in 4.1, to allow any users who had
problems to revert to the old behavior. The new behavior has been in
Xen.org xen since 4.1, and in XenServer even longer, and there is no
evidence of anyone having trouble with it. Remove the option.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
This patch adds a new 'w' debug-key, chosen from the limited remaining
keys only due to its proximity to 'q', that dumps the console ring to
configured console devices. It's useful to for tracking down how an
unresponsive system got into a broken state via serial console.
Signed-off-by: Matt Wilson <msw@amazon.com>
Committed-by: Keir Fraser <keir@xen.org>
Currently it is assumed PCI device BAR access < 4G memory. If there is
such a device whose BAR size is larger than 4G, it must access > 4G
memory address. This patch enable the 64bits big BAR support on
hvmloader.
Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Committed-by: Keir Fraser <keir@xen.org>
This is based upon my inspection of a system with a single PV domain
and a single HVM domain running and is therefore very incomplete.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
In various cases, 256 was being used instead of NR_VECTORS or a derived
ARRAY_SIZE() expression. In one case (guest_has_trap_callback()), a
wrong (unrelated) constant was used instead of NR_VECTORS.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
The problem this was working around should be resolved with c/s
25961:6a5812129094 (x86/HPET: don't disable interrupt delivery right
after setting it up).
Checking the stored version doesn't tell us anything about the need to
apply the update (during resume, what is stored doesn't necessarily
match what is loaded).
Note that the check can be removed altogether because once switched to
use what was read from the CPU (uci->cpu_sig.rev, as used in the
subsequent pr_debug()), it would become redundant with the checks that
lead to microcode_update_match() returning the indication that an
update should be applied.
Note further that this was not an issue on APs since they start with
uci->mc.mc_intel being NULL.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Ben Guthro <ben@guthro.net>
Acked-by: Keir Fraser <keir@xen.org>
On the AMD side, anything prior to family 0xf can now be ignored, as
well as very low model numbers of family 6 on the Intel side.
Apart from that, there were several made up CPU features that turned
out entirely unused throughout the tree.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
When there are more FSB delivery capable HPET channels than CPU cores
(or threads), we can simply use a dedicated channel per CPU. This
avoids wasting the resources to handle the excess channels (including
the pointless triggering of the respective interrupt on each
wraparound) as well as the ping-pong of the interrupts' affinities
(when getting assigned to different CPUs).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
There are two greater-than-zero checks for the old vector retrieved,
which don't work when a negative value got stashed into the respective
arch_irq_desc field. The effect of this was that for interrupts that
are intended to get their affinity adjusted the first time before the
first interrupt occurs, the affinity change would fail, because the
original vector assignment would have caused the move_in_progress flag
to get set (which causes subsequent re-assignments to fail until it
gets cleared, which only happens from the ->ack() actor, i.e. when an
interrupt actually occurred).
This addresses a problem introduced in c/s 23816:7f357e1ef60a (by
changing IRQ_VECTOR_UNASSIGNED from 0 to -1).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
We shouldn't clear HPET_TN_FSB right after we (indirectly, via
request_irq()) enabled it for the channels we intend to use for
broadcasts.
This fixes a regression introduced by c/s 25103:0b0e42dc4f0a.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Without ARAT, and apparently only when using HPET broadcast mode as
replacement, CPUs occasionally fail to wake up, causing the system to
(transiently) hang. Until the reason is understood, disable the driver
on such systems.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Intel latest SDM (17.13.3) release a new MSR CPUID.7.0.EBX[1]=1
indicates TSC_ADJUST MSR 0x3b is supported.
This patch expose it to hvm guest.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
IA32_TSC_ADJUST MSR is maintained separately for each logical
processor. A logical processor maintains and uses the IA32_TSC_ADJUST
MSR as follows:
1). On RESET, the value of the IA32_TSC_ADJUST MSR is 0;
2). If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR adds
(or subtracts) value X from the TSC, the logical processor also
adds (or subtracts) value X from the IA32_TSC_ADJUST MSR;
3). If an execution of WRMSR to the IA32_TSC_ADJUST MSR adds (or
subtracts) value X from that MSR, the logical processor also adds
(or subtracts) value X from the TSC.
This patch provides tsc adjust support for hvm guest, with it guest OS
would be happy when sync tsc.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
Add vMCE support for AMD. Add vmce namespace to Intel specific vMCE MSR
functions. Move vMCE prototypes from mce.h to vmce.h.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
- fix inverted return values from vmce_amd_{rd,wr}msr()
- remove bogus printk()-s from those functions
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
This patch provides vMCE save/restore when migration.
1. MCG_CAP is well-defined. However, considering future cap extension,
we keep save/restore logic that Jan implement at c/s 24887;
2. MCi_CTL2 initialized by guestos when booting, so need save/restore
otherwise guest would surprise;
3. Other MSRs do not need save/restore since they are either error-
related and pointless to save/restore, or, unified among all vMCE
platform;
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
- fix handling of partial data in XEN_DOMCTL_set_ext_vcpucontext
- fix adjustment of xen_domctl_ext_vcpucontext
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
In our test for win8 guest mce, we find a bug that no matter what
SRAO/SRAR error xen inject to win8 guest, it always reboot.
The root cause is, current Xen vMCE logic inject vMCE# only to vcpu0,
this is not correct for Intel MCE (Under Intel arch, h/w generate MCE#
to all CPUs).
This patch fixes vMCE injection bug, injecting vMCE# to all vcpus on
Intel platforms.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
- increase flexibility be making new second argument of inject_vmce() a
VCPU ID rather than just a boolean
Acked-by: Christoph Egger <Christoph.Egger@amd.com> (on just this change)
- fix condition evaluation order in inject_vmce()
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
This patch provides virtual MCE support to guest. It emulates a simple
and clean MCE MSRs interface to guest by faking caps to guest if needed
and masking caps if unnecessary:
1. Providing a well-defined MCG_CAP to guest, filter out un-necessary
caps and provide only guest needed caps;
2. Disabling MCG_CTL to avoid model specific;
3. Sticking all 1's to MCi_CTL to guest to avoid model specific;
4. Enabling CMCI cap but never really inject to guest to prevent
polling periodically;
5. Masking MSCOD field of MCi_STATUS to avoid model specific;
6. Keeping natural semantics by per-vcpu instead of per-domain
variables;
7. Using bank1 and reserving bank0 to work around 'bank0 quirk' of some
very old processors;
8. Cleaning some vMCE# injection logic which shared by Intel and AMD
but useless under new vMCE implement;
9. Keeping compatilbe w/ old xen version which has been backported to
SLES11 SP2, so that old vMCE would not blocked when migrate to new
vMCE;
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
- make printing consistent (and non-exploitable)
- fix return values of intel_mce_{rd,wr}msr() for out of range banks
- miscellaneous cleanup
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
When a domain is mapping pages from a different pg_owner domain, the
iomem_access checks are currently only applied to the pg_owner domain,
potentially allowing a domain with a more restrictive iomem_access
policy to have the pages mapped into its page tables. To catch this,
also check the owner of the page tables. The current domain does not
need to be checked because the ability to manipulate a domain's page
tables implies full access to the target domain, so checking that
domain's permission is sufficient.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Committed-by: Jan Beulich <jbeulich@suse.com>
As was rather obvious from crashes recently happening in stage testing,
the debug hypervisor, in that special case, has a drawback compared to
the non-debug one: When a call through a bad pointer happens, there's
no frame, and the top level (and frequently most important for
analysis) stack entry would get skipped:
(XEN) ----[ Xen-4.3-unstable x86_64 debug=y Not tainted ]----
(XEN) CPU: 1
(XEN) RIP: e008:[<0000000000000000>] ???
(XEN) RFLAGS: 0000000000010046 CONTEXT: hypervisor
(XEN) rax: 0000000000000008 rbx: 0000000000000001 rcx: 0000000000000003
(XEN) rdx: 0000003db54eb700 rsi: 7fffffffffffffff rdi: 0000000000000001
(XEN) rbp: ffff8302357e7ee0 rsp: ffff8302357e7e58 r8: 0000000000000000
(XEN) r9: 000000000000003e r10: ffff8302357e7f18 r11: ffff8302357e7f18
(XEN) r12: ffff8302357ee340 r13: ffff82c480263980 r14: ffff8302357ee3d0
(XEN) r15: 0000000000000001 cr0: 000000008005003b cr4: 00000000000026f0
(XEN) cr3: 00000000bf473000 cr2: 0000000000000000
(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008
(XEN) Xen stack trace from rsp=ffff8302357e7e58:
(XEN) ffff82c4801a3d05 ffff8302357eca70 0000000800000020 ffff82c4802ead60
(XEN) 0000000000000001 ffff8302357e7ea0 ffff82c48016bf07 0000000000000000
(XEN) 0000000000000000 ffff8302357e7ee0 fffff830fffff830 0000000000000046
(XEN) ffff8302357e7f18 ffff82c480263980 ffff8302357e7f18 0000000000000000
(XEN) 0000000000000000 ffff8302357e7f10 ffff82c48015c2be 8302357dc0000fff
...
(XEN) Xen call trace:
(XEN) [<0000000000000000>] ???
(XEN) [<ffff82c48015c2be>] idle_loop+0x6c/0x7a
(XEN)
(XEN) Pagetable walk from 0000000000000000:
Since the bad pointer is being printed anyway (as part of the register
state), replace it with the top of stack value in such a case.
With the introduction of is_active_kernel_text(), use it also at the
(few) other suitable places (I intentionally didn't replace the use in
xen/arch/arm/mm.c - while it would be functionally correct, the
dependency on system_state wouldn't be from an abstract perspective).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Apart from moving some code that is only used here from the header file
to the actual source one, this also
- moves interrupt[] into .init.data,
- prevents generating (unused) stubs for vectors below
FIRST_DYNAMIC_VECTOR, and
- shortens and sanitizes the names of the stubs.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
This follows the same idea as the previous patch, just that the effect
is much more visible here: With a half-way [dr]ecent gcc this reduced
.text size by over 12k for me.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
The use of "or" in GET_CPUINFO_FIELD so far wasn't ideal, as it doesn't
lend itself to folding this operation with a possibly subsequent one
(e.g. the well known mov+add=lea conversion). Split out the sub-
operations, and shorten assembly code slightly with this.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
If a bootloader entry in menu.lst has no additional kernel command line
options listed and the domU.cfg has 'bootargs="--args=something"' the
additional arguments from the config file are not passed to the kernel.
The reason for that incorrect behaviour is that run_grub appends arg
only if the parsed config file has arguments listed.
Fix this by appending args from image section and the config file separatly.
To avoid adding to a NoneType initialize grubcfg['args'] to an empty string.
This does not change behaviour but simplifies the code which appends the
string.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
Secondary CPUs, between doing their final memory writes (particularly
updating cpu_initialized) and getting a subsequent INIT, may not write
back all modified data. The INIT itself then causes those modifications
to be lost, so in the cpu_initialized case the CPU would find itself
already initialized, (intentionally) entering an infinite loop instead
of actually coming online.
Signed-off-by: Ben Guthro <ben@guthro.net>
Make acpi_dead_idle() call default_dead_idle() rather than duplicating
the logic there.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Committed-by: Jan Beulich <jbeulich@suse.com>
lapic_timer_{on,off} need to get initialized in this case. This in turn
requires getting HPET broadcast setup to be carried out earlier (and
hence preventing double initialization there).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Matthew Fioravante