Accesses to MSR_IA32_TSC_DEADLINE are trapped, with value stored in a
new field vlapic->hw.tdt_msr. vlapic->pt is reused in one shot mode
for vtdt to trigger expire events.
For details, please refer to the Intel Architectures Software
Developer's Manual 3A, 10.5.4.1 TSC-Deadline Mode.
Signed-off-by: Wei Gang <gang.wei@intel.com>
This mirrors the RVI/shadow situation, where p2m read access is
lockless because it's done in the hardware (linear map of the p2m
table).
This fixes the original bug (call it bug A) without introducing bug B
(a deadlock).
Bug A was caused by a race when updating p2m entries: between testing
if it's valid, and testing if it's populate-on-demand, it may have
been changed from populate-on-demand to valid.
My original patch simply introduced a lock into ept_get_entry, but
that caused bug B, caused by circular locking order: p2m_change_type
[grabs p2m lock] -> set_p2m_entry -> ept_set_entry ->
ept_set_middle_level -> p2m_alloc [grabs hap lock] write cr4 ->
hap_update_paging_modes [grabes hap lock] -> hap_update_cr3 ->
gfn_to_mfn -> ept_get_entry -> [grabs p2m lock]
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
These two bugs apparently complement each other enough that
they escaped problems in my testing, but eventually gum
up the works and are obviously horribly wrong.
Found while developing tmem for native Linux.
Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
In certain cases this will allow us to load old HVM save images where
an HVM saved chunk has subsequently been extended with new
fields. Rather than fail to load the chunk, we can pad the extended
structure with zeroes, if the caller knows how to handle that.
Signed-off-by: Keir Fraser <keir@xen.org>
Acked-by: Tim Deegan <Tim.Deegan@citrix.com>
Introduce libxl_need_xenpv_qemu to detect if the caller needs to create
a pv qemu instance (using libxl_create_xenpv_qemu).
A positive reply depends on the number of pv console and vfbs, and the
type of disk backends.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Write up some sparse documentation about xenpaging usage.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Instead of passing xch around, use the handle from xenpaging_t.
In the updated functions, use a local xch variable.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Fix DPRINTF/ERROR usage. Both macros reference a xch variable in local scope.
If xc_interface_open fails and after xc_interface_close, both can not be used
anymore. Use standard fprintf for this case.
Remove the code to print the exit value, its not really useful.
Its a left-over for debugging from an earlier patch.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Fix double-free in xc_interface_close() because xenpaging_teardown()
releases the *xch already. Remove second xc_interface_close() call.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
No DPRINTF output is logged because the default loglevel is to low in
libxc. Recognize the XENPAGING_DEBUG environment variable to change the
default loglevel at runtime.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Use the libxc error macro to report errors if initialising xenpaging
fails. Also report the actual errno string.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Just for correctness, close the xch handle in the error path.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Most versions of netback do not support setting the MAC address. This
means that c/s 937488219719 causes the hotplug script to break for
vifs, even as it fixes the bridge-wrong-MAC-address problem for tap
devices (used for emulated nics).
The mac-setting operation is not necessary for vifs since they are
hardcoded to fe:ff* anyway.
As a band-aid, add "|| true" to the call to ip link, so that this
error does not cause the hotplug operation to fail. There will still
be an error message printed until we can fix this better.
Suggested-by: Ian Campbell <Ian.Campbell@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
When a script using locking.sh is stopped by ctrl-C, the lock file remains.
We have to wait 100 seconds for releasing the lock at the next time.
Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
The "-s" option to xenstore-ls is used by the xencommons startup
script to check whether xenstored is already running, before starting
it.
Since 22498:a40455ae9ad3, "-s" has been a no-op, and libxenstore will
always fall back to using xenbus. The combined effect is that the
xencommons script deadlocks: xenstore-ls hangs waiting for xenstored,
which isn't started by xencommons because xencommons is waiting for
xenstore-ls.
In this patch, we:
* Introduce a new XS_OPEN_SOCKETONLY flag which disables the
fallback behaviour;
* Make the xenstore command line tools use the new xs_open call
rather than the old, deprecated xs_open_* calls (which are
now identical).
* Plumb the xenstore command line tools "-s" option to set the
XS_OPEN_SOCKETONLY flag.
* Change the type of the XS_OPEN_* flags so that they naturally have
type unsigned long.
The "-s" option to xenstore-ls et al, and the XS_OPEN_SOCKETONLY flag,
are intended for use by toolstack infrastructure and should not
normally be used by higher-level code.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
As of c/s 21812:e382656e4dcc, IOMMU related allocations for Dom0
happen only after it got all of its memory allocated, and hence the
reserve (mainly for setting up its swiotlb) may get exhausted without
accounting for the necessary allocations up front.
While not precise, the estimate has been found to be within a couple
of pages for the systems it got tested on.
For the calculation to be reasonably correct, this depends on the
patch titled "x86/iommu: don't map RAM holes above 4G" sent out
yesterday.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Instead, use scan_pci_devices() just like VT-d does. This at once
allows making {alloc,free}_pdev() static.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Matching the comment in iommu_set_dom0_mapping(), map only actual RAM
from the address range starting at 4G. It's not clear though whether
that comment is actually correct (which is why I'm sending this as
RFC), but it is certain that on systems with sparse physical memory
map we're currently wasting a potentially significant amount of memory
for setting up IOMMU page tables that will never be used.
The main question is what happens for MMIO ranges living above 4G. Of
course, the same issue would currently exist for any such ranges
sitting beyon the end of RAM.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
In libxl_build_device_model_args_new:
- Adds -xen-attach options to the list of arguments to Qemu.
- Adds -vga xenfb options when vnc and sdl are not set.
- Remove disk list from the command line for XenPV as they will be
read from xenstore by Qemu.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
committer: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
tools/libxl/libxl.c | 30 +++++++++++++++++++++---------
1 files changed, 21 insertions(+), 9 deletions(-)
In libxl_build_device_model_args_new, the path to the disk image are
freeed before there was actually use to make the arguments list of Qemu.
The patch strdups it.
This patch also changes argv[0] of the device model.
Now, it is the conventional argv[0], so is value come from
info->device_model.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
committer: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
tools/libxl/libxl.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
In libxl_build_device_model_args_new, vifs[i].ifname can be free two
times, by the gc, and by freeing the vifs structures. This patch avoids
this.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
committer: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
tools/libxl/libxl.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
While doing block-detach blktap2 disk, tap2 device info is not cleared from
xenstore /vm/uuid/xxx. The reason is in xen-hotplug-cleanup script: when $vm_dev
does not exist, $(xenstore-read "$vm_dev" 2>/dev/null) is also "", won't enter
the block. So, change to use cmd return value to check existence.
Signed-off-by Chunyan Liu <cyliu@novell.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
committer: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Doesn't actually appear to be used anywhere but is defined for other
OSes.
The NetBSD evtchn.h contains comments "Return allocated port" for
several ioctls which currently return the allocated port as a member
of the argument structure and not as the ioctl return value (I think
this is a cut and paste error).
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Christoph Egger <Christoph.Egger@amd.com>
committer: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Allows us to build even if the ipxe git server is down. We still fall
back to the git server if we cannot download a suitably named tarball
from our own URL.
Signed-off-by: Keir Fraser <keir@xen.org>
If a tap device is not given an explicit MAC address it will generate
one randomly.
The behaviour of the Linux bridge is to pickup the lowest MAC address
of any port for use in for ARP, STP etc. If the tap device's randomly
generated MAC address happens to be the lowest then this can cause all
manner of strange networking glitches in both domain 0 and guests when
the bridge suddenly takes over from the previously used MAC address.
We choose FE:FF:FF:FF:FF:FF as it the numerically largest
non-broadcast address. This ensures that the physical NIC device's
port will have the lowest MAC address and therefore be the one picked
up by the bridge.
vif devices already have a MAC address of FE:FF:FF:FF:FF:FF set by
netback already but there is no harm in forcing it a second time in
the hotplug script.
tap devices are added by the "add" event and therefore we should call
setup_bridge_port then as well as for "online" which is caused by vif
devices.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Adds depends information for building python extensions.
The extensions depend on the library binaries they are using.
Signed-off-by: juergen.gross@ts.fujitsu.com
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Simply taking stat()'s st_rdev doesn't work here, as the minor is
split into two parts, the major is present, and the "extended" bit
isn't set.
Rather than fixing this in a way that would likely be OS-dependent,
simply remove the access to the device file, and instead just parse
the provided string (as is done e.g. for block-attach).
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>
This follows some changes proposed for upstream Linux:
1. Do not check the FADT reset register size/offset
2. Try ACPI poking twice during our reset attempt sequence
Hopefully this will help us reset reliably on a wider range of
platforms.
Signed-off-by: Keir Fraser <keir@xen.org>
Keir Fraser
Stefano Stabellini
Ian Campbell
Ian Jackson
Olaf Hering
Kouya Shimura
Juergen Gross
Anthony PERARD
Chunyan Liu
Stefano Stabellini
Jan Beulich
Wei Gang