Tmem has been in-tree for about seven months, but disabled
by default. Enabling it should be entirely harmless
unless a running PV domain has been tmem-modified.
I'd like to confirm that by enabling it now, so that
it can be enabled by default for the 4.0.0 release.
Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Changeset 20514 implemented deallocation for msi interrupt remapping
entries. This patch adds the same support for amd iommu to fix a xen
crash on amd iommu systems.
Signed-off-by: Wei Wang <wei.wang2@amd.com>
Restart iommu event logging if EventOverFlow bit is set to prevent
event logging from being disabled after event overflows.
Signed-off-by: Wei Wang <wei.wang2@amd.com>
When booted with iommu=on, io_apic_read/write functions call into the
interrupt remapping code to update the IRTEs. Unfortunately, on boot
and shutdown, we really want clear_IO_APIC() to sanitize the actual
IOAPIC RTE, and not just the bits that are active when interrupt
remapping is enabled. This is particularly a problem on older
versions of Xen which used the IOAPIC RTE as the canonical source for
the IRTE index. In that case, clear_IO_APIC() actually causes
whatever happens to be stored in the RTEs to be used as an IRTE index,
which can come back and bite us in ioapic_guest_write() if we attempt
to remove an interrupt that didn't actually exist. Current upstream
appears less susceptible to errors since the IRTE index is stored in
an array, but it's still a good idea to sanitize the IOAPIC state.
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
- Put the guest rdtscp cpuid logic in xc_cpuid_x86.c.
- MSR_TSC_AUX's high 32bit is reserved, so only write the low 32bit.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
This restores backwards compatibility with older XSM policy. Policies
built with older versions of checkpolicy will once again work in Xen.
Signed-off-by : Paul Nuzzi <pjnuzzi@tycho.ncsc.mil>
If a user tries to use opcontrol with option --active-domains in dom0
and then run opcontrol in a guest, no samples are generated. When the
guest calls the xenoprof interface it resets the internal Xenoprof
state machine and profiling does not start
Signed-off-by: Jose Renato Santos <jsantos@hpl.hp.com>
F12 introduces a tool to automatically report bugs when there are core
dumps. Since xen-detect relies on fork+waitpid in order to trap a
SIGILL from a child, every time someone runs xen-detect on a bare
metal kernel a bug is reported into Red Hat's Bugzilla. :-)
However, even without this contingent need, leaving core dumps around
is not nice. So this patch just traps SIGILL using
signal/sentjmp/longjmp, without the need to fork.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
The return value of Xenbus routines xenbus_transaction_start(),
xenbus_printf(), xenbus_transaction_end(), etc. is a pointer of error
message. This pointer should be passed to free() to release the
allocated memory when it is no longer needed.
Signed-off-by: Yu Zhiguo <yuzg@cn.fujitsu.com>
accordingly
-- currently firmware has got 'vcpus' from xend, this patch add parse
'vcpu_avail' to firmware;
-- setup madt 'lapic' subitems of processors accoring to vcpus and
vcpu_avail which finally come from config;
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
In order to support HVM vcpu add/remove, we need set dsdt
infrastructure.
-- By using mk_dsdt.c, it auto-produce related asl code when
compiling.
-- It define processor related objects and control methods (_MAT,
_EJ0, _STA, etc).
-- It also define GPE _L02 and Notify control method for SCI
interrupt, which will trigger HVM acpi driver to add/remove cpu.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
/etc/xen/xmexample.hvm says "" means "leave to Xen to pick", but we
get a "Error: string index out of range" currently.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
This fixes a timekeeping issue for 32 bit guests running XCP Windows
paravirtual drivers on a 64 bit hypervisor where their clock was set
to the 1970s after live migration or restore. Thanks to Paul Durrant
for helping track this down.
>From the original XCP patch:
Arrange that the wallclock time fields in the shared_info structure
are set correctly in 32 bit HVM guests on a 64 bit hypervisor. HVM
guests on a 64 bit hypervisor always start with a 64 bit shared info,
and then change to a 32 bit one if they're using 32 bit drivers. The
32-bit and 64-bit shared info structures put their wallclock times in
slightly different places, and so the wallclock time needs to be
regenerated when you do the conversion.
It can be argued that we should convert the other fields of shared
info at the same time (e.g. if an event channel is pending beforehand,
it should be pending afterwards), but that's much harder to arrange,
because the 32 bit structure can't represent all the states which the
64 bit one can. Just setting the time seems to be sufficient for
our purposes.
Signed-off-by: Steven Smith <steven.smith@citrix.com>
Signed-off-by: Keith Coleman <keith@scaltro.com>
this is a revised version of linux upstream commit
69d25870f20c4b2563304f2b79c5300dd60a067e:
"
cpuidle: fix the menu governor to boost IO performance
Fix the menu idle governor which balances power savings, energy
efficiency
and performance impact.
The reason for a reworked governor is that there have been
serious
performance issues reported with the existing code on Nehalem
server
systems.
To show this I'm sure Andrew wants to see benchmark results:
(benchmark is "fio", "no cstates" is using "idle=3Dpoll")
no cstates current linux new algorithm
1 disk 107 Mb/s 85 Mb/s 105 Mb/s
2 disks 215 Mb/s 123 Mb/s 209 Mb/s
12 disks 590 Mb/s 320 Mb/s 585 Mb/s
In various power benchmark measurements, no degredation was found
by our
measurement&diagnostics team. Obviously a small percentage more
power was
used in the "fio" benchmark, due to the much higher performance.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Yanmin Zhang <yanmin_zhang@linux.intel.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
"
in Xen version, most logic is similar and with only one exception:
linux use nr_iowait and loadavg to track the pending I/O request,
which however is not visible to Xen. so Xen use the do_irq frequency
to estimate the I/O pressure. this is not as accurate as linux, and
the better approach is to convey guest latency requirement to
hypervisor by virtual C state. this can be the future enhancement.
the detail algorithm description is in code comment. with this new
algorithm, fio benchmark performance improve ~5% with 1 disk. and no
power degration is found in idle case.
Signed-off-by: Yu Ke <ke.yu@intel.com>
RDTSCP is introduced in Nehalem processor on Intel platform. Like
RDTSC, RDTSCP will return the TSC value, besides, it will return the
low 32bit of TSC_AUX MSR. Currently Linux kernel will write (node_id
<< 12 | process_id) into that MSR, so that when guest execs RDTSCP, it
will also get processor information. - This instruction is supported
for HVM only when the hardware has this capability (indicated by
cpuid).
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Currently write_rdtscp_aux() is placed in update_vcpu_system_time(),
which is called by schedule() before context_switch(). This will break
the HVM guest TSC_AUX state because at this point, MSR hasn't beed
saved for HVM guests.So put the function in the point when a PV vcpu
is really scheduled in.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
xenbus_read() and xenbus_write() will allocate memory for error
message if any error occurs, this memory should be freed.
Signed-off-by: Yu Zhiguo <yuzg@cn.fujitsu.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
If we want to avoid that a C++ compiler becomes a requirement for a
Xen build, we should disable the (unneeded) C++ library generation for
the embedded libconfig.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
the "guest to a single NUMA node" constrain algorithm does not work
well when we do ballooning. Ballooning and NUMA don't play together
anyway, as Dom0 and thus ballooning is not NUMA aware, I am working on
this but it will not be ready for the Xen 4.0 release window. The
usual ballooning situation will result in an empty candidate list, as
no node has enough free memory to host the guest. In this case the
code will simply pick the first node: again and again, because all
nodes without enough memory will be ultimately penalized with the same
maxint value (regardless of the actual load). The attached patch will
change this to use a relative penalty in case of not-enough memory, so
that low-load low-memory nodes will be used at one point. A half
loaded node has shown to be a good value, as an unbalanced system is
much worse than non-local memory access for guests. Regardless of
that you should restrict the Dom0 on a NUMA system to a reasonable
memory size, so that ballooning is not necessary most of the time. In
this case the guest's memory will be NUMA local.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
The basic work flow to handle the memory hotadd is:
Update node information
Map new pages to xen 1:1 mapping
Setup frametable for new memory range
Setup m2p table for new memory range
Put the new pages to domheap
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
memory hotplug is supported.
Hot-added memory may need a new L4 entry for 1:1 mapping. This patch
setup all L4 entry for 1:1 mapping if memory hotadd is needed, so that
we don't need sync the guest page table in page fault handler.
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
hotplug in page fault handler.
In compact guest situation, the compat m2p table is copied, not
directly mapped in L3, so we have to sync it. Direct mapping range
may changes, and we need sync it with guest's table.
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
We can't use alloc_boot_pages for memory hot-add, so change it to use
the pages range passed in.
One changes need notice is, when memory hotplug needed, we have to
setup initial frametable as pdx index (i.e. the pdx_gorund_valid)
aligned, to make sure mfn_valid() still works after the max_page is
not maximum anymore.
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
The m2p tables should be shared by guest as they will be read-only
mapped by guest. This logical is similar to what happens in
subarch_init_memory(). But we need check the mapping is just setup.
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
As when we destroy the m2p table, it should not be used, so we don't
need consider clean the head/tail mapping that may exits before hot-add.
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
When new memory added to the system, we need to update the m2p table
to cover the new memory range.
When memory add, it is difficult to allocate continous pages, so we
allocate the memory from the new added memory range. This also improve
the locality in numa situation.
We don't support 1G mapping for hot memory, because AFAIK currently
hot-plug memory will not be that large.
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
You can see the following slides to understand the usage.
http://www.xen.org/files/xensummit_intel09/PVUSBStatusUpdate.pdf
Limitations:
"xm usb-hc-create" accepts up to 16 ports, but, current usbfront
can work with up to 15 ports. This may be bug and I'm preparing
to fix it.
This xm/xend support requires linux-2.6.18-xen.hg c/s 939 or above.
I recommend latest tip.
Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
Keir Fraser