c/s 21040 and 21044 used to break cpu number limit (<=64).
However, they result in bug under ia32pae model:
1. things will go wrong for affinity, making all vcpus pin to a same
cpu with same time;
2. when 'xm vcpu-pin' vpu to cpu, xend will exit abnormally.
This patch is to fix the bugs described above.
Signed-off-by: Xu, Jiajun <jiajun.xu@intel.com>
Signed-off-by: Zhang, Jianwu <jianwu.zhang@inte.com>
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Attached patch enumerates vmcb intercepts with hexadecimal numbers
additionally. This makes looking up the intercept number easier.
No functional changes.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
When generating new threshold value, we must firstly clean old value
before or the new set value since the new value might be different
with the old (BIOS might pre-set some threshold).
Signed-off-by: Liping Ke <liping.ke@intel.com>
Signed-off-by: Ying Huang <ying.huang@intel.com>
The same is true for EPT flushes.
We noticed sometime system hang on cpu online/offline stress test. The
reason is because flush_tlb_mask from __get_page_type is deadloop.
This should be caused by a small windows in cpu offline. The
cpu_online_map is changed and the interrupt is disabled at
take_cpu_down() for the to-be-offline CPU.
However, the __sync_lazy_execstate() called from idle_task_exit() in
the idle_loop() for the to-be-offline CPU. At that time, the
stop_machine_run is finished already, and __get_page_type may be
called in other CPU before the __sync_lazy_execstate().
Thanks Jan pointing out issue in my original patch.
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
cpufreq_statistic_lock should not only protect the statistic memory
pointed by cpufreq_statistic_data[cpu], but also have to protect the
pointer in cpufreq_statistic_data[cpu] itself. So move the read
operation of cpufreq_statistic_data[cpu] after
spin_lock(cpufreq_statistic_lock).
Signed-off-by: Wei Gang <gang.wei@intel.com>
There are two new return cases from hvm_copy_from_guest_virt() to deal
with paging or shared memory -- retry the emulation rather than
crash.
Signed-off-by: Steven Hand <steven.hand@cl.cam.ac.uk>
Now 4 DMAR structure types are supported (type value 0 ~ 3). Type
values > 3 are reserved for future use. Current implementation
disables VT-d when find unknown DMAR structure type, this may lead to
VT-d disabling on future platforms before supporting new types on
Xen. For forward compatibility, just skip unknown structures by
skipping the appropriate number of bytes indicated by the Length
field, and then VT-d still can be used.
Signed-off-by: Weidong Han <weidong.han@intel.com>
When Interrupt Remapping is used, after Dom0 S3, Dom0's filesystem
might become inaccessible as the SATA disk's MSI interrupt becomes
buggy. The cause is: After set_msi_affinity() or setup_msi_irq()
invokes write_msi_msg(), entry->msg records the remappable format
message; during S3 resume, Dom0 invokes the PHYSDEVOP_restore_msi
hypercall to restore the MSI registers of devices, and in
pci_restore_msi_state() -> write_msi_msg(), the 'entry->msg' of
remappable format is passed, but in write_msi_msg() -> ... ->
msi_msg_to_remap_entry(), the 'msg' is assumed to be in compatibility
format. As a result, after s3, the IRTE is corrupted.
Actually the only users of 'entry->msg' are pci_restore_msi_state()
and dump_msi(). That's why we don't have issue except Dom0 S3.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
'Reserved' field is missed in current RHSA structure, and move the
'proximity domain' field to the bottom. In addition, fix some indent
issues.
Signed-off-by: Weidong Han <weidong.han@intel.com>
The xc_ptrace API relies on errno for passing success/failure
indication back to callers. However, mapping operations that fall
back on legacy APIs may leave errno set to a non-zero result even
thought the operation is successful. This patch resets errno after
successful map operations so that xc_ptrace doesn't inadvertently
return a failure.
Signed-off-by: Justin Gibbs <gibbs@scsiguy.com>
While apparently only a theoretical possibility (domain_kill() has a
BUG_ON() that wasn't reported to trigger so far), I still think it is
better to have the code cleaned up.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Copy the modules in ascending order in memory, rather than decsending
order. This reduces the likelihood of the second relocation (in
setup.c) corrupting modules through accidental overwriting.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
In c/s 21027 I overlooked that using this function when bad table data
was found requires the function to also do some range checking.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Changeset 21045: 7751288b1386 introduces a potential issue: CR4.MCE is
enabled before mcheck_init() -- thought looks I don't meet with an
actual issue with this, we'd better fix it.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Otherwise Xen cannot access them later during boot. GRUB2 places
modules as high as possible below 4GB, which has been causing boot
failure.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
The do_boot_cpu() will be called when system booting or CPU
online. When system booting, we don't need hold this lock. When system
online, the lock is held already by cpu_up.
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Currently stop_machine_run() will try to bring all CPUs to softirq
context, with some locks held, like xenpf_lock or cpu_add_remove_lock
etc. However, if another CPU is trying to get these locks, it may
cause deadlock.
This patch replace all such spin_lock with spin_trylock. For
xenpf_lock and sysctl_lock, we try to use hypercall_continuation, so
that we will not cause trouble to user space tools. For
cpu_hot_remove_lock, we simply return EBUSY if failure, since it will
only impact small number of user space tools.
In the end, we should try to make the stop_machine_run as spinlock
free.
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Currently qemu has a bug: When maxvcpus > 64, qemu will get wrong
vcpu bitmap (s->cpus_sts[i]) since it only get bitmap from a long
variable.
This patch, cooperate with another qemu patch, is to fix this bug.
This patch transfer a vcpu_avail string in a hex string format, so
that at qemu side it's more easier to get vcpu bitmap from hex string,
especially when many vcpus, like more than 64.
(Also update QEMU_TAG for matching qemu-side update)
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
1) Some variables and functions in xen/arch/x86/genapic/x2apic.c
should not be marked with __init* as they will be used during s3
resume;
2) In do_suspend_lowlevel -> restore_rest_processor_state ->
mcheck_init, lapic is accessed, but x2apic hasn't been re-enabled yet
(x2apic is re-enabled() in device_power_up -> lapic_resume). The patch
moves mcheck_init to a later place.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
As it is pretty pointless to clear unused parts of a line over and
over again, keep track of how much of a line was actually written
to and avoid clearing parts of the screen that are known to already
be clear. With this, scrolling speed becomes comparable to that of
Linux' VESA console.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Previously, these messages were only issued when old and new RTE
differed. Make it so again (requiring adjustment of the guest provided
RTE as that no longer holds a real vector).
While at it, also make the "allocated vector for irq" message more
useful and occur when what it says really happened.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
There are more than 64 cpus on new intel platform especially on NUMA
system, so that we need break the pcpu limit (that is 64) when set
affinity of a VCPU.
Signed-off-by: James (song wei) <jsong@novell.com>
Introduce a new sub-option "verbose" to "iommu=", and hide most
(debugging) messages when that option is not specified. Particularly
messages printed after time management was initialized can, on
sufficiently large systems and with a graphical console, lead to
time management issues (therefore a call to process_pending_softirqs()
also gets added in case the new sub-option is being used).
While touching that code, also convert all improper uses of gdprintk()
to dprintk(), and convert all boolean iommu config variables to bool_t
residing in the .data.read_mostly section.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
In order to have better chance that relevant messages fit into the
ring buffer, allocate a dynamic (larger) one in more cases, and make
the default allocation size depend on both the number of CPUs and the
log level. Also free the static buffer if a dynamic one was obtained.
In order for "xm dmesg" to retrieve larger buffers, eliminate
pyxc_readconsolering()'s 32k limitation resulting from the use of a
statically allocated buffer.
Finally, suppress on x86 most per-CPU boot time messages (by default,
most of them can be re-enabled with a new command line option
"cpuinfo", some others are now only printed more than once when there
are inconsistencies between CPUs). This reduces both boot time (namely
when a graphical console is in use) and pressure on the console ring
and serial transmit buffers.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Keir Fraser