It appears that the changeset
qemu-xen: build adjustments to support out-of-tree builds
broke the build.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
QEMU by itself can be built outside of its source directory. With the
qemu repository being separate from the hypervisor/tools one it seems
to make sense to make use of this feature, but doing so requires a
couple of adjustments to the Xen changes to it. Basically, if
CONFIG_QEMU is found to indicate an existing directory, this directory
will be used rather than cloning the git repo into the build tree.
[ This changeset is the xen-unstable part of the patch but also
includes the QEMU_TAG update to pull in the qemu part. -iwj ]
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Fix an issue on Nehalem cpus where performance counter overflows may
lead to endless interrupt loops on this cpu.
Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
the attached patch makes Xen tracing work again, after the introduction
of the hypercall buffers broke it. Just a missing line.
Thanks to Uwe Dannowski for reporting this.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Introduce a new physdev_op called PHYSDEVOP_get_free_pirq to allow a
guest to get a free pirq number from Xen; the hypervisor would keep
that pirq free for the guest to use in a mapping.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
This patch allows HVM guests to remap interrupts and MSIs into pirqs;
once the mapping is in place the guest will receive the interrupt (or
the MSI) as an event. The interrupt to be remapped can either be an
interrupt of an emulated device or an interrupt of a passthrough
device and we keep track of that.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
The BASE_VALID() macro needs adjustment to match the other changes
done to the original Linux code (which are all queued to be merged
into Linus' tree), plus per Hypertransport specification the range
0xff00000000-0xffffffffff also needs to be excluded.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Move the p2m alloc and free functions back into the per-domain paging
assistance structure and allow them to be called from the log-dirty
code. This makes it less likely that log-dirty code will run out of
memory populating the log-dirty bitmap.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
Soon we will properly handle paged out memory in this function by
sleeping in hypervisor context. This will require that all callers can
sleep.
If this check is too strong, we can reduce it to only applying to
guests with paging enabled (which also currently implies only guests
using Intel EPT). However my brief testing seems to indicate it works
okay.
Signed-off-by: Keir Fraser <keir@xen.org>
If the guest sleeps in hypervisor context, it should not be destroyed
until execution reaches a safe point (i.e., guest context). This is
not implemented yet. :-) But the next patch will rely on it, to allow
an HVM guest to execute hypercalls that indirectly invoke __hvm_copy()
within an rcu_lock_current_domain() region.
Signed-off-by: Keir Fraser <keir@xen.org>
Mitigate the heavy contention on handle_pmt_io when running a HVM
configured with many cores (e.g., 32 cores). As the virtual time of a
domain must be fresh, there should be someone updating it,
periodically. But it is not necessary to let a VCPU update the virtual
time when another one has been updating it. Thus the update can be
skipped when the VCPU finds someone else is updating the virtual time.
So every time a VCPU invoke handle_pmt_io to update the current
domain's virtual time, it will first try to acquire the pmtimer lock.
If it succeeds, it will update the virtual time. Otherwise, it can
skip the update, waits for the pmtimer lock holder to finish updating
the virtual time and returns the updated time.
Signed-off-by: Xiang Song <xiangsong@fudan.edu.cn>
Signed-off-by: Keir Fraser <keir@xen.org>
Currently Xen triggers a panic if user disables VT-d by command line
while not disable x2APIC. This requires users to specify both
"iommu=0" and "x2apic=0" to disable VT-d if the platform supports
x2APIC. It's not user friendly. This patch removes the panic
condition. That's to say, don't require user to specify "x2apic=0"
when specify "iommu=0". As long as VT-d is not enabled (disabled in
BIOS or in command line), x2APIC won't be enabled naturally (x2APIC
depends on VT-d Interrupt remapping).
Signed-off-by: Weidong Han <weidong.han@intel.com>
The size should be in bytes not 32-bit words. Fixes graphics
corruption issues for HVM guests due to bouncing too little data.
Also the dirty_bitmap buffer is output only and therefore only needs
bouncing in one direction.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
With newer (pvops) kernels logs get flooded with this iptables
warning: physdev match: using --physdev-out in the OUTPUT, FORWARD and
POSTROUTING chains for non-bridged traffic is not supported anymore
Using the --physdev-is-bridged option prevents this.
See also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571634#10
Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
hvmloader is responsible for - amoungst other things - initialising
the PCI device BARs prior to loading the guest BIOS. The previous
code only probed for devfn up to 128. The lower 3 bits are function
IDs so this meant that only devices in slots 0-15 were actually being
initialized.
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Acked-by: Gianni Tedesco <gianni.tedesco@citrix.com>
This change some fadt values -- the address of the acpi ioports -- and
the pm1a_evt_address value wrote for the pci bus.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
This patch adds an explicit update mechanism:
make tools/ioemu-dir-force-update
This isn't brilliant but is better than doing "cd tools/ioemu-remote
&& git reset --hard <sha1...>" by hand.
Note that invoking this target will destroy all working tree changes
made to qemu-xen.
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
As part of the QEMU/Xen merge, this patch comes to change the value of
sleep states and add some information in the PCI registers to match the
implementation of the BIOS of QEMU.
It also does a hypercall (HVM_PARAM_ACPI_IOPORTS_LOCATION) that tell the
Xen to use the new Port I/O instead of the old one.
[ Also, in this patch, update QEMU_TAG to the qemu-xen revision
with the corresponding qemu change. -iwj ]
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
The (Dom0 only for now) kernel can indicate that it doesn't need its
initrd mapped through a newly added ELF note - it gets passed the PFN
of the initrd in this case instead of the virtual address.
Even for kernels not making use of the new feature, the initrd will
no longer get copied into the initial mapping, but the memory it lives
in will get assigned to and mapped for the guest instead.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
By doing so, we're no longer restricted to be able to place all boot
loader modules into the low 1Gb/4Gb (32-/64-bit) of memory, nor is
there a dependency anymore on where the boot loader places the
modules.
We're also no longer restricted to copy the modules into a place below
4Gb, nor to put them all together into a single piece of memory.
Further it allows even the 32-bit Dom0 kernel to be loaded anywhere in
physical memory (except if it doesn't support PAE-above-4G).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
The implementation of xl was lacking a lot of consts on its char*s.
In this patch we improve matters. It doesn't fix everything. In
particular:
* I only changed char*s and not other structs that ought to be const.
* libxl_send_debug_keys should take a const char* but the pointer
ends up getting sent to DECLARE_HYPERCALL_BOUNCE from xc_private.h
and that won't take a const char*. I wasn't sure what to do so
I have left it.
* There is a great deal of in-place string tokenisation (both
ad-hoc, and using strtok_r). I haven't changed any of that.
* I haven't changed any of the occurrences of char **argv because of
the castless assignment incompatibility between const char** and
char **.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson