The assertion only allows values of 1 (no_delay_for_missed_ticks)
up to 3 (one_missed_tick_pending). It should be possible to
use the value of 0 (delay_for_missed_ticks) for the timer configuration
option.
Acked-by: Ian Campbell <ian.cambell@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Upstream the "xen/acpi-processor: C and P-state driver that
uploads said data to hypervisor." takes care of uploading power information
information that normally a cpu frequency scaling driver would using
in the initial domain. We want the hypervisor to take that data and
make good usage of it.
Fortunatly for us we do not have to worry about the native cpu frequency
scaling drivers being loaded first, as the upstream commit:
"xen/cpufreq: Disable the cpu frequency scaling drivers from loading."
takes care of that. Meaning we can load the xen-acpi-processor at any time.
By default that driver is built as a module - and since we are
the only user of it - we should load it.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
The val is used as the pagetable entry with the machine
frame number and some page table bits. This explains
what those page table bits are.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
There are some implicit requirements when using the hypercall
which are not mentioned.
Mainly the requirement that the pagetable be RO.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Bugzilla 1680: Xend fails to start if /var/lib/xend/state/*.xml are empty
which I get often when replacing the Xen hypervisor with a newer version.
This can be easily be reproduced under Fedora Core 16 by installing
xen RPMs and then replacing the xen.gz with a newer version.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Anthony Low <shinji@pikopiko.org>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Alter the 'reserved' uint8_t to be used a 'flag'. We use only for one
flag: BLKIF_DISCARD_SECURE.
That flag can only be set if the backend has set 'discard-secure' to
one. If backend has not set 'discard-secure' to one, that flag will
have no effect.
Acked-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Committed-by: Keir Fraser <keir@xen.org>
We flesh out details on what is expected of 'feature-flush' and
what are some of the extra parameters that the frontend can read
from the backend. Those extra parameters are: : discard-aligment,
and discard-granularity.
Acked-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Committed-by: Keir Fraser <keir@xen.org>
Just a simple sed s/trim/discard/. We are ignoring the comments
which are incorrect.
The reason for the name change is that TRIM is specific to ATA
while the operation can be done on top of SCSI interfaces too.
Hence the rename to something more generic.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Committed-by: Keir Fraser <keir@xen.org>
The "xen: Automatically find serial port on PCI/PCIe and AMT devices."
provides the functionality to probe for the I/O base using the
"pci" and "amt" option. Update the documentation with this fact.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Jan Beulich pointed out that the pci_uart_config can be called for
com2 and we should probe the second BAR instead of the first one.
This patch will probe the BAR0 if it is com1, and BAR1 if its com2.
It also cleans up some of the whitespace problems and changes the
name of the parameter and function from 'magic' to 'pci'.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Certain PCI serial cards just don't want to remember
what they are when they come out of resume. Save
the BAR and the PCI command values before we suspend and
write them back in when we resume.
Signed-off-by: Roger Cruz <roger.cruz@virtualcomputer.com>
Signed-off-by: Tom Goetz <tom.goetz@virtualcomputer.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
For PCI type cards, you need to disable the timer code during
suspend. Otherwise during resume, the timer can be put on the
heap as its being resumed and corrupt it resulting in a crash.
Signed-off-by: Roger Cruz <roger.cruz@virtualcomputer.com>
Signed-off-by: Tom Goetz <tom.goetz@virtualcomputer.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
.. as there is no need to keep that internal header file anymore.
We export two functions xc_domain_[set|get]_memory_map which
depend on the 'struct e820entry' defined in 'xc_e820.h'.
We move the contents of the 'xc_e820.h' to the 'xenctrl.h' fixing
compiler errors when applications outside the Xen tree are trying
to compile against the libraries.
Tested-by: Daniel Castro <evil.dani@gmail.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
.. which will be removed once the auto-ballooning of guests
with PCI devices works. During testing of the patches which provide
a host E820 in a PV guest, certain inconsistencies were found with
guests. When launching a RHEL5 or SLES11 PV guest with 4GB and a PCI device,
the kernel would report 4GB, but have 1.5G "used". What happend was that
the P2M that fall within the E820 I/O holes would never be used and was just
wasted. The mechanism to go around this is to shrink the size of the guest
before launch (say memory=2048, maxmem=4096) and then balloon back to 4096M
after start. For PVOPS type kernels it would detect the E820 I/O holes and
deflate by the correct amount but would not inflate back to 4GB.
Manually inflating makes it work.
The fix in the future for guests where the memory amount flows over the
PCI hole, is to launch the guest with decreased amount right up to the cusp
of where the E820 PCI hole starts. Also increase the 'maxmem' by the delta
and then when the guest has launched, balloon up to the delta number.
This will require some careful surgery so for right now this parameter
will guard against unsuspecting users seeing their PV guests memory "vanish."
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Most machines after the RAM regions in the e802 have a couple of
E820_RESERVED, with E820_ACPI and E820_NVS. On some Intel machines, the
E820 looks like swiss cheese:
(XEN) Initial Xen-e820 RAM map:
(XEN) 0000000000000000 - 000000000009d000 (usable)
(XEN) 000000000009d000 - 00000000000a0000 (reserved)
(XEN) 00000000000e0000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 000000009cf66000 (usable)
(XEN) 000000009cf66000 - 000000009d102000 (ACPI NVS)
(XEN) 000000009d102000 - 000000009f6bd000 (usable) <--
(XEN) 000000009f6bd000 - 000000009f6bf000 (reserved)
(XEN) 000000009f6bf000 - 000000009f714000 (usable) <--
(XEN) 000000009f714000 - 000000009f7bf000 (ACPI NVS)
(XEN) 000000009f7bf000 - 000000009f7e0000 (usable) <--
(XEN) 000000009f7e0000 - 000000009f7ff000 (ACPI data)
(XEN) 000000009f7ff000 - 000000009f800000 (usable) <--
(XEN) 000000009f800000 - 00000000a0000000 (reserved)
(XEN) 00000000a0000000 - 00000000b0000000 (reserved)
(XEN) 00000000fc000000 - 00000000fd000000 (reserved)
(XEN) 00000000ffe00000 - 0000000100000000 (reserved)
(XEN) 0000000100000000 - 0000000160000000 (usable)
Which means we have to pay attention to the E820_RAM that are
between the E820_[ACPI,NVS,RESERVED]. If we remove those
E820_RAM (b/c the amount of memory passed to the guest
is less that where those E820 regions reside) from the E820, the
Linux kernel interprets those "gaps" as PCI I/O space.
This is what we are currently doing.
This can be disastrous if we pass in an Intel IGD card which tries
to use the first available PCI I/O space - and ends up
using the MFNs which are actually RAM instead of being the
PCI I/O space.
To make this work, we convert all E820_RAM that are above
the 'target_kb' (those that overlap the 'target_kb'
are truncated appropriately) to be E820_UNUSABLE. We also limit this
alternation up to 4GB. This means that an E820 for a guest
>from this (target_kb=1024, maxmem=2048):
[ 0.000000] Set 405658 page(s) to 1-1 mapping.
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] Xen: 0000000000000000 - 00000000000a0000 (usable)
[ 0.000000] Xen: 00000000000a0000 - 0000000000100000 (reserved)
[ 0.000000] Xen: 0000000000100000 - 0000000040000000 (usable)
[ 0.000000] Xen: 0000000040000000 - 000000009cf66000 (unusable)
[ 0.000000] Xen: 000000009cf66000 - 000000009d102000 (ACPI NVS)
[ 0.000000] Xen: 000000009f6bd000 - 000000009f6bf000 (reserved)
[ 0.000000] Xen: 000000009f714000 - 000000009f7bf000 (ACPI NVS)
[ 0.000000] Xen: 000000009f7e0000 - 000000009f7ff000 (ACPI data)
[ 0.000000] Xen: 000000009f800000 - 00000000b0000000 (reserved)
[ 0.000000] Xen: 00000000fc000000 - 00000000fd000000 (reserved)
[ 0.000000] Xen: 00000000fec00000 - 00000000fec01000 (reserved)
[ 0.000000] Xen: 00000000fee00000 - 00000000fee01000 (reserved)
[ 0.000000] Xen: 00000000ffe00000 - 0000000100000000 (reserved)
[ 0.000000] Xen: 0000000100000000 - 0000000140800000 (usable)
Will look as so:
[ 0.000000] Set 395880 page(s) to 1-1 mapping.
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] Xen: 0000000000000000 - 00000000000a0000 (usable)
[ 0.000000] Xen: 00000000000a0000 - 0000000000100000 (reserved)
[ 0.000000] Xen: 0000000000100000 - 0000000040000000 (usable)
[ 0.000000] Xen: 0000000040000000 - 000000009cf66000 (unusable)
[ 0.000000] Xen: 000000009cf66000 - 000000009d102000 (ACPI NVS)
[ 0.000000] Xen: 000000009d102000 - 000000009f6bd000 (unusable)
[ 0.000000] Xen: 000000009f6bd000 - 000000009f6bf000 (reserved)
[ 0.000000] Xen: 000000009f6bf000 - 000000009f714000 (unusable)
[ 0.000000] Xen: 000000009f714000 - 000000009f7bf000 (ACPI NVS)
[ 0.000000] Xen: 000000009f7bf000 - 000000009f7e0000 (unusable)
[ 0.000000] Xen: 000000009f7e0000 - 000000009f7ff000 (ACPI data)
[ 0.000000] Xen: 000000009f7ff000 - 000000009f800000 (unusable)
[ 0.000000] Xen: 000000009f800000 - 00000000b0000000 (reserved)
[ 0.000000] Xen: 00000000fc000000 - 00000000fd000000 (reserved)
[ 0.000000] Xen: 00000000fec00000 - 00000000fec01000 (reserved)
[ 0.000000] Xen: 00000000fee00000 - 00000000fee01000 (reserved)
[ 0.000000] Xen: 00000000ffe00000 - 0000000100000000 (reserved)
[ 0.000000] Xen: 0000000100000000 - 0000000140800000 (usable)
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
The code that populates E820 is unconditionally triggered by the guest
configuration having "pci=['<BDF>,..']", being a PV guest, and if
b_info->u.pv.e820_host is set.
The code do_domain_create calls the libxl__e820_alloc when
it notices that the guest is PV, has at least one PCI devices, and has
the e820_host flag set.
libxl__e820_alloc calls the xc_get_machine_memory_map to retrieve the systems
E820. Then the E820 is sanitized to weed out E820 entries below 16MB, and as
well remove any E820_RAM or E820_UNUSED regions as the guest does not need to
know about them. The guest only needs the E820_ACPI, E820_NVS, E820_RESERVED to
get an idea of where the PCI I/O space is. Mostly.. The Linux kernel assumes that any
gap in the E820 is considered PCI I/O space which means that if we pass
in the guest 2GB, and the E820_ACPI, and its friend start at 3GB, the
gap between 2GB and 3GB will be considered as PCI I/O space. To guard against
that we also create an E820_UNUSABLE between the region of 'target_kb'
(called ram_end in the code) up to the first E820_[ACPI,NVS,RESERVED] region.
Lastly, the xc_domain_set_memory_map is called to install the new E820.
When tested with another PV guest (NetBSD 5.1) the modified E820 gave
it no trouble. The code has also been tested with older "classic" Xen Linux
and with the newer "pvops" with success (SLES11, RHEL5, Ubuntu Lucid,
Debian Squeeze, 2.6.37, 2.6.38, 2.6.39).
Memory that is slack or for balloon (so 'maxmem' in guest configuration)
is put behind the machine E820. Which in most cases is after the 4GB.
The reason for doing the fetching of the E820 using the hypercall in
the toolstack (instead of the guest doing it) is that when a guest
would do a hypercall to 'XENMEM_machine_memory_map' it would
retrieve an E820 with I/O range caps added in. Meaning that the
region after 4GB up to end of possible memory would be marked as unusable
and the kernel would not have any space to allocate a balloon
region.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Add these two functions.
The later retrieves the E820 as seen by the hypervisor (completely
unchanged) and the second call sets the E820 for the specified guest.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
