Since XSA-131 qemu-xen has defaulted to non-permissive mode and the
option was extended to cover that case in 015a373351 "tools: libxl:
allow permissive qemu-upstream pci passthrough".
Since I was rewrapping to adjust the text anyway I've split the safety
warning into a separate paragraph to make it more obvious.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Eric <epretorious@yahoo.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
(cherry picked from commit 7f25baba1c)
Some versions of markdown (specifically the one in Debian Wheezy, currently
used to generate
http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html) seem to be
confused by nested lists in the middle of multi-paragraph parent list entries
as seen in the com1,com2 entry.
The effect is that the "Default" section of all following entries are replace
by some sort of hash or checksum (at least, a string of 32 random seeming hex
digits).
Workaround this issue by making the decriptions of the DPS options a nested
list, moving the existing nested list describing the options for S into a third
level list. This seems to avoid the issue, and is arguably better formatting in
its own right (at least its not a regression IMHO)
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
(cherry picked from commit ae325e94d2)
(cherry picked from commit 3e9054c523)
NMI watchdog sets APIC_LVTPC register to generate an NMI when PMU counter
overflow occurs. This may be overwritten by VPMU code later, effectively
turning off the watchdog.
We should disable VPMU when NMI watchdog is running.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: e5e09b5c46
master date: 2015-02-03 11:30:09 +0100
On certain systems some of the memory map entries designated for use by
runtime services cannot be mapped (frequently due to firmware bugs). On
others, some of the memory map entries aren't even marked for runtime
services use, yet are being used by them. For both cases give people a
way to suppress use of runtime services altogether.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 5680244040
master date: 2014-10-27 16:43:52 +0100
Xen cannot safely use any ATS functionality until it gains asynchronous queued
invalidation support, because of the current synchronous wait for completion.
Do not turn ATS on by default.
While editing the default in the command line documentation, correct the
statement regarding PCI Passthrough. ATS is purely a performance
optimisation, and is certainly not required for PCI Passthrough to function.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
master commit: ad6eddb742
master date: 2014-08-28 16:05:10 +0200
List all the sub ops of:
__HYPERVISOR_domctl
__HYPERVISOR_sysctl
__HYPERVISOR_memory_op
__HYPERVISOR_tmem_op
which are subject to the policy given in
http://xenbits.xen.org/xsa/advisory-77.html
It is expected that these lists will be whittled away as each interface is
audited for safety.
New interfaces should be expected to be safe when introduced (IOW the list
should never be expanded).
This is XSA-77.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 5da5288a0a
master date: 2013-12-10 16:09:24 +0100
The qxl drivers for Windows and Linux end up calling instructions
that cannot be used for MMIO at the moment. Just for the 4.3 release,
remove qxl support.
This patch should be reverted as soon as the 4.4 development window opens.
The issue in question:
(XEN) emulate.c:88:d18 bad mmio size 16
(XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 0f 6f
19 41 83 e8 403
The instruction in question is "movdqu (%rcx),%xmm3". Xen knows how
to emulate it, but unfortunately %xmm3 is 16 bytes long, and the interface
between Xen and qemu at the moment would appear to only allow MMIO accesses
of 8 bytes.
It's too late in the release cycle to find a fix or a workaround.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Linux uses sse4_1 and sse4_2, but at the moment libxl uses '.' instead
of '_'. This makes it confusing for people looking in Linux's /proc/cpuinfo
to disable features.
Add the Linux feature names, keeping the old ones for compatability.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Campbell <ian.camppbell@citrix.com>
With the help of the previous patches add a stanza to
xen/arch/arm/Rules.mk to specify the UART configuration of the
Calxeda Midway machine.
The information has been taken from the Linux kernel's .dts file.
This can be enabled by adding "CONFIG_EARLY_PRINTK=midway" to
Config.mk.
Signed-off-by: Andre Przywara <andre.przywara@calxeda.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Though the ARM Fastmodel software emulator mimics a Versatile Express
board, the boot process is different compared to the real hardware,
so the early printk differs slightly. Create a new early-printk
target to model this correctly.
Signed-off-by: Andre Przywara <andre.przywara@calxeda.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The UART memory mapped base address is currently hardcoded in the
early-printk UART driver, which denies the driver to be used by
two machines with a different mapping.
Move this definition out to xen/arch/arm/Rules.mk, allowing easier
user access and later sharing of the driver.
Signed-off-by: Andre Przywara <andre.przywara@calxeda.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
While it seems obvious to initialize the UART before using it, chances
are that some firmware code or the bootloader already did this.
So it may actually be a good idea to skip the initialization, in fact
this fixes early printk on my TC2 Versatile Express.
So provide an option in xen/arch/arm/Rules.mk to only initialize the
UART when needed.
Signed-off-by: Andre Przywara <andre.przywara@calxeda.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
For early-printk the used baud rate was hardcoded in the code, using
precalculated divisor values.
Let the calculation of these values be done by the preprocessor and
use a human readable value in xen/arch/arm/Rules.mk to drive this.
Signed-off-by: Andre Przywara <andre.przywara@calxeda.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Add CONFIG_EARLY_PRINTK options in configs/arm{32,64}.mk to let the user
to choose if he wants to have early output, ie before the console is initialized.
This code is specific for each UART. When CONFIG_EARLY_PRINTK is enabled,
Xen will only be able to run on a board with this UART.
If a developper wants to add support for a new UART, he must implement the
following assembly macro/define:
- EALY_UART_BASE_ADDRESS: variable which contains the physical base address
for the UART
- early_uart_init: initialize the UART
- early_uart_ready: check and wait until the UART can transmit a new
character
- early_uart_transmit: transmit a character
For more details about the parameters of each function,
see arm{32,64}/debug-pl011.inc comments.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
doc: buildsystem fixes
- use correct pathes (make gmake dist-docs from toplevel directory work)
- configure detects perl as tools/configure does
Signed-off-by: Christoph Egger <chegger@amazon.de>
Reviewed-by: Matthew Wilson <msw@amazon.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- reran autogen.sh ]
The representations of boolean type in xl docs are inconsistent. This patch
replaces occurences of "1", "0", "[Tt]rue" and "[Ff]alse" with "[Tt]rue (1)"
and "[Ff]alse (0)".
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This adds a backend_domname field in libxl devices that contain a
backend_domid field, allowing either a domid or a domain name to be
specified in the configuration structures. The domain name is resolved
into a domain ID in the _setdefault function when adding the device.
This change allows the backend of the block devices to be specified
(which previously required passing the libxl_ctx down into the block
device parser), and will simplify specification of backend domains in
other users of libxl.
The check on run_hotplug_scripts in parse_config_data is removed because
it is a duplicate of the one in libxl__device_nic_setdefault, and is
removed here because it no longer has the resolved domain ID to check.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- reran flex ]
cp -d is a GNU extension, and only useful for links, which don't seem
to exist in the directories being copied, so just remove said flag.
Signed-off-by: Patrick Welche <prlw1@cam.ac.uk>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Updating to make it clear that free_memory reported by 'xl info'
is influenced by the outstanding claim value. That is the free
memory that will be available to the host once all outstanding
claims have been completed. This modifies the behavior that the
patch titled "xl: 'xl info' print outstanding claims if enabled
(claim_mode=1 in xl.conf)" had - which reported the
outstanding claims and nothing else.
The free_pages as reported by the hypervisor is the currently
available count of pages on the heap. The outstanding pages is
the total amount of pages reserved for guests (so not taken from
the heap yet). As guests are being populated the memory from the
heap shrinks and the outstanding count of pages decreases.
The total memory used for guests increases.
As the available count of pages on the heap and outstanding
claims are intertwined, report the amount of free memory available
to be a combination of that. That is free heap memory minus the
outstanding pages.
We also make some odd choices in reporting. By default we will
only display 'outstanding_claims' if the claim_mode is enabled
in the global configuration file. However, if there are outstanding
claims, we will ignore the claim_mode and report these values.
Suggested-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
This is similar to "xl: 'xl info' print outstanding claims if enabled
(claim_mode=1 in xl.conf)" which exposes the global claim value.
This patch provides the value of the currently outstanding pages
claimed for each domains. This is per domain value which is added
to the global claim value which influences the hypervisors' MM system.
When a claim call is done, a reservation for a specific amount of pages
is set (and this patch lists said number) and also a global value is
incremented. This global value is then reduced as the domain's memory
is populated and eventually reaches zero.
The toolstack (libxc) also sets the domain's claim to zero when the population
of memory has completed as an extra step. Any call to destroy the domain
will also set the domain's claim to zero.
If the reservation cannot be meet the guest creation fails immediately
instead of taking seconds or minutes (depending on the size of the guest)
while the toolstack populates memory.
See patch: "xl: Implement XENMEM_claim_pages support via 'claim_mode'
global config" for details on how it is implemented.
The value fluctuates quite often so the value is stale once it is provided
to the user-space. However it is useful for diagnostic purposes.
It is printed irregardless of global "claim_mode" option in xl.conf(5).
That is b/c the user might have enabled, launched a guest, and then
disabled the option - and we should still report the correct outstanding
claim value. The 'man xl' shows the details of this argument.
The output is close to what 'xl list' looks like:
Name ID Mem VCPUs State Time(s) Claimed
Domain-0 0 2047 4 r----- 19.7 0
OL5 2 2048 1 --p--- 0.0 847
OL6 3 1024 4 r----- 5.9 0
Windows_XP 4 2047 1 --p--- 0.0 1989
[In which it can be seen that the OL5 guest still has 847MB of claimed
memory (out of the total 2048MB where 1191MB has been allocated to
the guest).]
Please note that the 'Mem' column has the cumulative value of outstanding
claims and the total amount of memory that has been allocated to the guest.
[v1: claims, not claim-list]
[v2: Add outstanding and current memkb in the output list]
[v3: Clairy docs and relax some checks]
[v4: Removed comments about guest config memory being the same as 'Mem']
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
This patch provides the value of the currently outstanding pages
claimed for all domains. This is a total global value that influences
the hypervisors' MM system.
When a claim call is done, a reservation for a specific amount of pages
is set and also a global value is incremented. This global value is then
reduced as the domain's memory is populated and eventually reaches zero.
The toolstack (libxc) also sets the domain's claim to zero when the population
of memory has completed as an extra step. Any call to destroy the domain
will also set the domain's claim to zero.
If the reservation cannot be meet the guest creation fails immediately
instead of taking seconds or minutes (depending on the size of the guest)
while the toolstack populates memory.
See patch: "xl: Implement XENMEM_claim_pages support via 'claim_mode'
global config" for details on how it is implemented.
The value fluctuates quite often so the value is stale once it is provided
to the user-space. However it is useful for diagnostic purposes.
It is only printed when the global "claim_mode" option in xl.conf(5)
is set to enabled (1). The 'man xl' shows the details of this item.
[v1: s/unclaimed/outstanding/]
[v2: Made libxl_get_claiminfo return just MemKB suggested by Ian Campbell]
[v3: Made libxl_get_claininfo return MemMB to conform to the other values printed]
[v4: Improvements suggested by Ian Jackson, also added docs to xl.pod.1]
[v5: Clarify how claims are cancelled, split >72 characters - Ian Jackson]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
The XENMEM_claim_pages hypercall operates per domain and it should be
used system wide. As such this patch introduces a global configuration
option 'claim_mode' that by default is disabled.
If this option is enabled then when a guest is created there will be an
guarantee that there is memory available for the guest. This is an
particularly acute problem on hosts with memory over-provisioned guests
that use tmem and have self-balloon enabled (which is the default option
for them). The self-balloon mechanism can deflate/inflate the balloon
quickly and the amount of free memory (which 'xl info' can show) is stale
the moment it is printed. When claim is enabled a reservation for the
amount of memory ('memory' in guest config) is set, which is then reduced
as the domain's memory is populated and eventually reaches zero.
If the reservation cannot be meet the guest creation fails immediately
instead of taking seconds/minutes (depending on the size of the guest)
while the guest is populated.
Note that to enable tmem type guests, one needs to provide 'tmem' on the
Xen hypervisor argument and as well on the Linux kernel command line.
There are two boolean options:
(0) No claim is made. Memory population during guest creation will be
attempted as normal and may fail due to memory exhaustion.
(1) Normal memory and freeable pool of ephemeral pages (tmem) is used when
calculating whether there is enough memory free to launch a guest.
This guarantees immediate feedback whether the guest can be launched due
to memory exhaustion (which can take a long time to find out if launching
massively huge guests) and in parallel.
[v1: Removed own claim_mode type, using just bool, improved docs, all per
Ian's suggestion]
[v2: Updated the comments]
[v3: Rebase on top 733b9c524d (xl: add vif.default.script)]
[v4: Fixed up comments]
[v5: s/global_claim_mode/claim_mode/]
[v6: Ian Jackson's feedback: use libxl_defbool, better comments, etc]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Now that the hotplug scripts have been fixed to remove hardcoded paths lets
try this again. From 26470:acaf29203cf9:
This is the defacto (or FHS mandated?) standard location for software
built from source, in order to avoid clashing with packaged software
which is installed under /usr/bin etc.
I think there is benefit in having Xen's install behave more like the
majority of other OSS software out there.
The major downside here is in the transition from 4.2 to 4.3 where
people who have built from source will innevitably discover breakage
because 4.3 no longer overwrites stuff in /usr like it used to so they
pickup old stale bits from /usr instead of new stuff from /usr/local.
Packages will use ./configure --prefix=/usr or whatever helper macro
their package manager gives them. I have confirmed that doing this
results in the same list of installed files as before this patch was
applied.
The hypervisor remains in /boot/ and there is no intention to move it.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Allow the "usbdevice" key to accept a list of USB devices, and pass
them in using the new usbdevice_list domain build element.
For backwards compatibility, still accept singleton values.
Also update the xl.cfg manpage, adding information about how to pass
through host devices.
as applied:
- Fix trailing whitespace and wrap some lines in xl_cmdimpl.c -iwj
v2:
- Add some verbiage to make it clear that "usb" is for emulated devices
- Reference qemu manual for more usbdevice options
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
In xl.conf, autoballoon="auto" will do the right thing for most
people. Make it the default (instead of "on").
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
autoballoon=1 is not recommened if dom0_mem was used to reduce the
amount of dom0 memory. Instead of requiring users to change xl.conf
if they do this, extend the autoballoon option with a new choice:
"auto".
With autoballoon="auto", autoballooning will be disabled if dom0_mem
was used on the Xen command line.
For consistency, accept "on" and "off" as valid autoballoon options (1
and 0 are still accepted).
The default remains "on" for now.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
The bootloader should populate /chosen/modules/module@<N>/ for each
module it wishes to pass to the hypervisor. The content of these nodes
is described in docs/misc/arm/device-tree/booting.txt
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
- force use of physical APIC mode if indicated so (as we don't support
xAPIC cluster mode, the respective flag is taken to force physical
mode too)
- don't use MSI if indicated so (implies no IOMMU)
Both can be overridden on the command line, for the MSI case this at
once adds a new command line option allowing to turn off PCI MSI (IOMMU
and HPET are unaffected by this).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
First draft specification document it as a 64bit counter, now are a 128bit
value handled as a couple of 64bit values.
Allow to disable the device is values are all zeroes.
Add documentation for platform/generation-id key.
Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>