New key handler 'o' to dump the IOMMU p2m table for each domain.
Skips dumping table for domain 0.
Intel and AMD specific iommu_ops handler for dumping p2m table.
Incorporated feedback from Jan Beulich and Wei Wang.
Fixed indent printing with %*s.
Removed superflous superpage and other attribute prints.
Make next_level use consistent for AMD IOMMU dumps. Warn if found
inconsistent.
AMD IOMMU does not skip levels. Handle 2mb and 1gb IOMMU page size for
AMD.
Signed-off-by: Santosh Jodh <santosh.jodh@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
The unwind path was not clearing the shared entry status bits. This
was BSOD-ing guests on network activity under certain configurations.
Also:
* sed the fixup method name to signal it's related to grant copy.
* use atomic clear flag ops during fixup.
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Committed-by: Keir Fraser <keir@xen.org>
Microsoft have now published their VM generation ID specification at
https://www.microsoft.com/en-us/download/details.aspx?id=30707.
It differs from the original specification upon which I based my
implementation in several key areas. Particularly, it is no longer
an incrementing 64-bit counter and so this patch is to remove
the incr_generationid field from the build_info and also disable the
ACPI device before 4.2 is released.
I will follow up with further patches to implement the VM generation
ID to the new specification.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
Doing a reverse lookup from MFN to its owning domain is redundant with
the internal checks Xen does on pages. Change the checks to operate
directly on the domain owning the pages for normal memory; MMIO areas
are still checked with security_iomem_sid.
This fixes a hypervisor crash when a domU attempts to map an MFN that
is free in Xen's heap: the XSM hook is called before the validity
check, and page_get_owner returns garbage when called on these
pages. While explicitly checking for such pages using
page_get_owner_and_reference is a possible solution, this ends up
duplicating parts of get_page_from_l1e.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Committed-by: Keir Fraser <keir@xen.org>
A few XSM hooks have been defined without implementation in dummy.c;
these will cause a null function pointer deference if called. Also
implement the efi_call hook, which was incorrectly added without any
implementations.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Committed-by: Keir Fraser <keir@xen.org>
Our product management wasn't happy with the "solution" for XSA-9, and
demanded that customer systems must continue to boot. Rather than
having our and perhaps other distros carry non-trivial patches, allow
for more fine grained control (panic on boot, deny guest creation, or
merely warn) by means of a single line change.
Also, as this was found to be a problem with remotely managed systems,
don't default to boot denial (just deny guest creation).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
So far we only ever set up the respective MSRs on Intel CPUs, yet we
hide the feature only on a 32-bit hypervisor. That prevents booting of
PV guests on top of a 64-bit hypervisor making use of the instruction
on unknown CPUs (VIA in this case).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Cleaning the python directory should completely remove the build/
directory, otherwise subsequent builds may be short-circuited and a
stale build installed.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
This avoids the hypercall buffer becoming CoW on fork.
In multi-threads and multi-processes environment, e.g. the process has two
threads, thread A may call hypercall, thread B may call fork() to create child
process. After forking, all pages of the process including hypercall buffers
are cow. It will cause a write protection and return EFAULT error if hypervisor
calls copy_to_user in hypercall in thread A context,
Fix:
1. Before hypercall: use MADV_DONTFORK of madvise syscall to make the hypercall
buffer not to be copied to child process after fork.
2. After hypercall: undo the effect of MADV_DONTFORK for the hypercall buffer
by using MADV_DOFORK of madvise syscall.
3. Use mmap/nunmap for memory alloc/free instead of malloc/free to bypass libc.
Note:
Child processes must not use the opened xc_{interface,evtchn,gnttab,gntshr}
handle that inherits from parents. They should reopen the handle if they want
to interact with xc. Otherwise, it may cause segment fault to access hypercall
buffer caches of the handle.
Signed-off-by: Zhenguo Wang <wangzhenguo@huawei.com>
Signed-off-by: Xiaowei Yang <xiaowei.yang@huawei.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- s/ptr/p/ to fix build & tweaked the wording of the comments
slightly. ]
Committed-by: Ian Campbell <ian.campbell@citrix.com>
When PoD got enabled to support 1Gb pages, ept_get_entry() didn't get
updated to match - the assertion in there triggered, indicating that
the call to p2m_pod_demand_populate() needed adjustment.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>
max_mapped_pfn should reflect the highest mapping we've ever seen of
any type, or the tests in the lookup functions will be wrong. As it
happens, the highest mapping has always been a RAM one, but this is no
longer the case when we allow 64-bit BARs.
Reported-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>
GMFN values must undoubtedly be "unsigned long". "count" and
"entry_count", since they are signed types, should also be "long" as
otherwise they can't fit all values that can fit into "d->tot_pages"
(which currently is "uint32_t").
Beyond that, the patch doesn't convert everything to "long" as in many
places it is clear that "int" suffices. In places where "long" is being
used partially already, the change is however being done.
Furthermore, page order values have no use of being "long".
Finally, in the course of updating a few printk messages anyway, some
also get slightly shortened (to focus on the relevant information).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
When an external agent (e.g. a monitoring daemon) happens to access the
memory of a PoD guest prior to setting the PoD target, that access must
fail for there not being any page in the PoD cache, and only the space
above the low 2Mb gets scanned for victim pages (while only the low 2Mb
got real pages populated so far).
To accomodate for this
- set the PoD target first
- do all physmap population in PoD mode (i.e. not just large [2Mb or
1Gb] pages)
- slightly lift the restrictions enforced by p2m_pod_set_mem_target()
to accomodate for the changed tools behavior
Tested-by: Jürgen Groß <juergen.gross@ts.fujitsu.com>
(in a 4.0.x based incarnation)
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Passing invalid CPU value to do_pm_op() will cause assertion
in cpu_online().
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Such checks would, at a first glance, then also be missing at the top
of various helper functions, but these check really were already
redundant with the check in do_pm_op(). Remove the redundant checks
for clarity and brevity.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
Without this, the compilation of check.c could fail due to compiler
features such as -fstack-protector being enabled, which causes a
missing __stack_chk_fail symbol error.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Rather than using plain CFLAGS here, remove CFLAGS-y from them to
particularly get rid of the -MF argument referencing (the undefined
here) $(@F).
The use of CFLAGS at once allows dropping the explicit use of -Werror.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
RPM based packaging systems expect binaries to have debug symbols which get
placed in a separate debuginfo RPM.
Split the concept of a debug build up so that binaries can be built with
debugging symbols without having the other gubbins which $(debug) implies, most
notibly frame pointers.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
So far all we (explicitly) require is gcc 3.4 or better, so we
shouldn't be unconditionally using features supported only by much
newer versions.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Load all known backend drivers fron xenlinux and pvops based dom0
kernels. There is currently no code in xend or libxl to load these
drivers on demand. Currently libxl has also no helpful error message if
a backend driver is missing.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
First of all, when no ACPI Cx data was reported, make sure the usage
count passed back to user mode is not random.
Besides that, fold a lot of redundant code.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
for common and x86 ones at least, to address the problem of storing
zero-extended values into the multicall result field otherwise.
Reported-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
This reverts one of the intentional changes from 25733:353bc0801b11.
That change exposed an issue with the xl migration protocol, which
although safe triggers the hotplug scripts device sharing logic.
For 4.2 we disable this logic by writing the physical-device xenstore
node ourselves if a user did not supply a script. If the user did
supply a script then we continue to rely on it to write the
physical-device node (not least because the script may create the
device and therefore it is not available before we run the script).
This means that to support localhost migration a block hotplug script
needs to be robust against adding a device twice and should not
deactivate the device until it has been removed twice.
This should be revisited for 4.3.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
This pointer is never used for anything, and needlessly increases the
memory footprint of various pieces of data.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Application Note" (http://www.intel.com/Assets/PDF/manual/323850.pdf)
does not document support for extended model 2H model DH (Intel Xeon
Processor E5 Family), empirical evidence shows that the same MSR
addresses can be used for cpuid masking as exdended model 2H model AH
(Intel Xen Processor E3-1200 Family).
Signed-off-by: Matt Wilson <msw@amazon.com>
Acked-by: Nakajima, Jun <jun.nakajima@intel.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
This is a middle-work patch, preparing for the future new vMCE model.
It removes mcg_ctl, disables MCG_CTL_P, and sets bank count to 2.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
These are provided using the "script=" syntax described in
docs/misc/xl-disk-configuration.txt.
The existing hotplug scripts currently conflate two different
concepts, namely that of making a datapath available in the backend
domain (logging into iSCSI LUNs and the like) and that of actually
connecting that datapath to a Xen backend path (e.g. writing
"physical-device" node in xenstore to bring up blkback).
For this reason the script support implemented here is only supported
in conjunction with backendtype=phy.
Eventually we hope to rework the hotplug scripts to separate the to
concepts, but that is not 4.2 material.
In addition there are some other subtleties:
- Previously in the blktap case we would add "script = .../blktap" to
the backend flex array, but then jumped to the PHY case which added
"script = .../block" too. The block one takes precendence since it
comes second.
This was, accidentally, correct. The blktap script is for blktap1
devices and not blktap2 devices. libxl completely manages the
blktap2 side of things without resorting to hotplug scripts and
creates a blkback device directly. Therefore the "block" script is
always the correct one to call. Custom script are not supported in
this context.
- libxl should not write the "physical-device" node. This is the
responsibility of the block script. Writing the "physical-device"
node in libxl basically completely short-cuts the standard block
hotplug script which uses "physical-device" to know if it has run
already or not.
In the case of more complex scripts libxl cannot know the right
value to write here anyway, in particular the device may not exist
until after the script is called.
This change has the side effect of re-enabling the checks for
device sharing aspect of the default block script, which I have tested
and which now cause libxl to properly abort now that libxl properly
checks for hotplug script errors.
There is no sharing check for blktap2 since even if you reuse the
same vhd the resulting tap device is different. I would have preferred
to simply write the "physical-device" node for the blktap2 case but
the hotplug script infrastructure is not currently setup to handle
LIBXL__DEVICE_KIND_VBD
devices without a hotplug script (backendtype phy and tap both end
up as KIND_VBD). Changing this was more surgery than I was happy doing
for 4.2 and therefore I have simply hardcoded to the block script for
the LIBXL_DISK_BACKEND_TAP case.
- libxl__device_disk_set_backend running against a phy device with a
script cannot stat the device to check its properties since it may
not exist until the script is run. Therefore I have special cased
this in disk_try_backend to simply assume that backend == phy is
always ok if a script was
configured. Similarly the other backend types are always rejected
if a script was configured.
Note that the reason for implementing the default script behaviour
in device_disk_add instead of libxl__device_disk_setdefault is
because we need to be able to tell when the script was
user-supplied rather than defaulted by libxl in order to correctly
implement the above. The setdefault function must be idempotent so
we cannot simply update disk->script.
I suspect that for 4.3 a script member should be added to
libxl__device, this would also help in the case above of handling
devices with no script in a consistent manner. This is not 4.2
material.
- When the block script falls through and shells out to a block-$type
script it used to pass "$node" however the only place this was
assigned was in the remove+phy case (in which case it contains the
file:// derived /dev/loopN device), and in that case the script
exits without falling through to the block-$type case.
Since libxl never creates a type other than phy this never happens
in practice anyway and we now call the correct block-$type script
directly. But fix it up anyway since it is confusing.
- The block-nbd and block-enbd scripts which we supply appear to be
broken WRT the hotplug calling convention, in that they seem to
expect a command line parameter (perhaps the $node described above)
rather than reading the appropriate node from xenstore.
I rather suspect this was broken by 7774:e2e7f47e6f79 in November
2005. I think it is safe to say no one is using these scripts! I
haven't fixed this here. It would be good to track down some working
scripts and either incorproate them or defer to them in their existing
home (e.g. if they live somewhere useful like the nbd tools
package).
- Added a few block script related entries to check-xl-disk-parse
from http://backdrift.org/xen-block-iscsi-script-with-multipath-support
and http://lists.linbit.com/pipermail/drbd-user/2008-September/010221.html /
http://www.drbd.org/users-guide-emb/s-xen-configure-domu.html (and
snuck in another interesting empty CDROM case)
This highlighted two bugs in the libxlu disk parser handling of the
deprecated "<script>:" prefix:
- It was failing to prefix with "block-" to construct the actual
script name
- The regex for matching iscsi or drdb or e?nbd was incorrect
- Use libxl__abs_path for the nic script too. Just because the
existing code nearly tricked me into repeating the mistake
I have tested with a custom block script which uses "lvchange -a" to
dynamically add remove the referenced device (simulates iSCSI
login/logout without requiring me to faff around setting up an iSCSI
target). I also tested on a blktap2 system.
I haven't directly tested anything more complex like iscsi: or nbd:
other than what check-xl-disk-parse exercises.
[ Recommit of correct version of 25727:a8d708fcb347, which was mangled
during commit. Sorry. -iwj ]
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>
This fixes theoretical issues with those constraints - operands that
get clobbered before consuming all input operands must be marked so
according the the gcc documentation. Beyond that, the change is merely
code improvement, not a bug fix.
In __prepare_to_wait(), properly mark early clobbered registers. By
doing so, we at once eliminate the need to save/restore rCX and rDI.
In check_wakeup_from_wait(), make the current constraints match by
removing the code that actuall alters registers. By adjusting the
resume address in __prepare_to_wait(), we can simply re-use the copying
operation there (rather than doing a second pointless copy in the
opposite direction after branching to the resume point), which at once
eliminates the need for re-loading rCX and rDI inside the asm().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
We pass be_path to tapdisk_destroy but we've already deleted it so it
fails to read tapdisk-params. However it appears that we need to
destroy the tap device after tearing down xenstore, to avoid the leak
reported by Greg Wettstein in
<201207312141.q6VLfJje012656@wind.enjellic.com>.
So read the tapdisk-params in the cleanup transaction, before the
remove, and pass that down to destroy_tapdisk instead. tapdisk-params
may of course be NULL if the device isn't a tap device.
There is no need to tear down the tap device from
libxl__initiate_device_remove since this ultimately calls
libxl__device_destroy.
Propagate and log errors from libxl__device_destroy_tapdisk.
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>
These are provided using the "script=" syntax described in
docs/misc/xl-disk-configuration.txt.
The existing hotplug scripts currently conflate two different
concepts, namely that of making a datapath available in the backend
domain (logging into iSCSI LUNs and the like) and that of actually
connecting that datapath to a Xen backend path (e.g. writing
"physical-device" node in xenstore to bring up blkback).
For this reason the script support implemented here is only supported
in conjunction with backendtype=phy.
Eventually we hope to rework the hotplug scripts to separate the to
concepts, but that is not 4.2 material.
In addition there are some other subtleties:
- Previously in the blktap case we would add "script = .../blktap" to
the backend flex array, but then jumped to the PHY case which added
"script = .../block" too. The block one takes precendence since it
comes second.
This was, accidentally, correct. The blktap script is for blktap1
devices and not blktap2 devices. libxl completely manages the
blktap2 side of things without resorting to hotplug scripts and
creates a blkback device directly. Therefore the "block" script is
always the correct one to call. Custom script are not supported in
this context.
- libxl should not write the "physical-device" node. This is the
responsibility of the block script. Writing the "physical-device"
node in libxl basically completely short-cuts the standard block
hotplug script which uses "physical-device" to know if it has run
already or not.
In the case of more complex scripts libxl cannot know the right
value to write here anyway, in particular the device may not exist
until after the script is called.
This change has the side effect of re-enabling the checks for
device sharing aspect of the default block script, which I have tested
and which now cause libxl to properly abort now that libxl properly
checks for hotplug script errors.
There is no sharing check for blktap2 since even if you reuse the
same vhd the resulting tap device is different. I would have preferred
to simply write the "physical-device" node for the blktap2 case but
the hotplug script infrastructure is not currently setup to handle
LIBXL__DEVICE_KIND_VBD
devices without a hotplug script (backendtype phy and tap both end
up as KIND_VBD). Changing this was more surgery than I was happy doing
for 4.2 and therefore I have simply hardcoded to the block script for
the LIBXL_DISK_BACKEND_TAP case.
- libxl__device_disk_set_backend running against a phy device with a
script cannot stat the device to check its properties since it may
not exist until the script is run. Therefore I have special cased
this in disk_try_backend to simply assume that backend == phy is
always ok if a script was
configured. Similarly the other backend types are always rejected
if a script was configured.
Note that the reason for implementing the default script behaviour
in device_disk_add instead of libxl__device_disk_setdefault is
because we need to be able to tell when the script was
user-supplied rather than defaulted by libxl in order to correctly
implement the above. The setdefault function must be idempotent so
we cannot simply update disk->script.
I suspect that for 4.3 a script member should be added to
libxl__device, this would also help in the case above of handling
devices with no script in a consistent manner. This is not 4.2
material.
- When the block script falls through and shells out to a block-$type
script it used to pass "$node" however the only place this was
assigned was in the remove+phy case (in which case it contains the
file:// derived /dev/loopN device), and in that case the script
exits without falling through to the block-$type case.
Since libxl never creates a type other than phy this never happens
in practice anyway and we now call the correct block-$type script
directly. But fix it up anyway since it is confusing.
- The block-nbd and block-enbd scripts which we supply appear to be
broken WRT the hotplug calling convention, in that they seem to
expect a command line parameter (perhaps the $node described above)
rather than reading the appropriate node from xenstore.
I rather suspect this was broken by 7774:e2e7f47e6f79 in November
2005. I think it is safe to say no one is using these scripts! I
haven't fixed this here. It would be good to track down some working
scripts and either incorproate them or defer to them in their existing
home (e.g. if they live somewhere useful like the nbd tools
package).
- Added a few block script related entries to check-xl-disk-parse
from http://backdrift.org/xen-block-iscsi-script-with-multipath-support
and http://lists.linbit.com/pipermail/drbd-user/2008-September/010221.html /
http://www.drbd.org/users-guide-emb/s-xen-configure-domu.html (and
snuck in another interesting empty CDROM case)
This highlighted two bugs in the libxlu disk parser handling of the
deprecated "<script>:" prefix:
- It was failing to prefix with "block-" to construct the actual
script name
- The regex for matching iscsi or drdb or e?nbd was incorrect
- Use libxl__abs_path for the nic script too. Just because the
existing code nearly tricked me into repeating the mistake
I have tested with a custom block script which uses "lvchange -a" to
dynamically add remove the referenced device (simulates iSCSI
login/logout without requiring me to faff around setting up an iSCSI
target). I also tested on a blktap2 system.
I haven't directly tested anything more complex like iscsi: or nbd:
other than what check-xl-disk-parse exercises.
[ reran flex/bison -iwj ]
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
* libxl may indeed register more than one callback for the same fd,
with some restrictions. The allowable range of responses to this by
the application means that this should pose no problems for users.
But the documentation comment should be fixed.
* Document the relaxed synchronicity semantics of the fd_modify
registration callback.
* A couple of comments referred to old names for functions.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Keir Fraser
Santosh Jodh
Andres Lagar-Cavilla
Paul Durrant
Daniel De Graaf
Jan Beulich
Ian Campbell
Andrew Cooper
Wangzhenguo
M A Young
Yongjie Ren
Tim Deegan
Boris Ostrovsky
Ian Jackson
Olaf Hering
Matt Wilson
Liu, Jinsong
Fabio Fantoni