| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Forcibly enabling the MMCFG space on AMD Fam10 CPUs cannot be expected
to work since with the firmware not being aware of the address range
used it cannot possibly reserve the space in E820 or ACPI resources.
Hence we need to manually insert the range into the E820 table, and
enable the range only when the insertion actually works without
conflict.
Further, the actual enabling of the space is done from identify_cpu(),
which means that acpi_mmcfg_init() muts be called after that function
(and hance should not be called from acpi_boot_init()). Otherwise,
Dom0 would be able to use MMCFG, but Xen wouldn't.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
| |
|
|
| |
Signed-off-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
... decreasing cache footprint. As a prerequisite this requires making
cmdline_parse() a little more flexible.
Also remove a few variables altogether, and adjust sections
annotations for several others.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
|
| |
Unlike mem=, this specifies the limit on usable RAM, rather than a
limit on maximum physical address of RAM.
Original patch by Sarina Canelake <sarina.canelake@Oracle.Com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are issues in updating the e820 map in the middle of a loop that
iterates over it. For example, after memmove(&e820.map[i],
&e820.map[i+1], ...), the original e820.map[i+1] become current
e820.map[i] but the next loop count is i+1, so the original
e820.map[i+1] will be skipped.
Fix and clarify the code by making a double loop.
Original bug discovery and fix by Xiao Guangrong <ericxiao.gr@gmail.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
|
| |
|
|
|
|
|
|
| |
In below case, e820_change_range_type() will return success:
[s, e] is in the middle of [rs, re] and e820->nr_map+1 >=
ARRAY_SIZE(e820->map) actually, it's failed, so this patch fix it
Signed-off-by: Xiao Guangrong <ericxiao.gr@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since Dom0 derives machine address ranges usable for assigning PCI
device resources from the output of this sub-hypercall, Xen should
make
sure it properly reports all ranges not suitable for this (as either
reserved or unusable):
- RAM regions excluded via command line option
- memory regions used by Xen itself (LAPIC, IOAPICs)
While the latter should generally already be excluded by the BIOS
provided E820 table, this apparently isn't always the case at least
for IOAPICs, and with Linux having got changed to account for this it
seems to make sense to also do so in Xen.
Generally the HPET range should also be excluded here, but since it
isn't being reflected in Dom0's iomem_caps (and can't be, as it's a
sub-page range) I wasn't sure whether adding explicit code for doing
so would be reasonable.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduces a virtual space conserving transformation on the MFN thus
far used to index 1:1 mapping and frame table, removing the largest
range of contiguous bits (below the most significant one) which are
zero for all valid MFNs from the MFN representation, to be used to
index into those arrays, thereby cutting the virtual range these
tables must cover approximately by half with each bit removed.
Since this should account for hotpluggable memory (in order to not
requiring a re-write when that gets supported), the determination of
which bits are candidates for removal must not be based on the E820
information, but instead has to use the SRAT. That in turn requires a
change to the ordering of steps done during early boot.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
| |
|
|
|
|
|
|
| |
Extend the virtual range reserved for the 1:1 mapping to cover 5Tb,
and make the virtual size of the frame table gets match whatever the
1:1 table can cover.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
With there being several instances of custom_param() where the handler
is just invoking parse_size_and_unit(), it seems to make sense to
introduce a simplifying abstraction.
Also fix serial_txbufsz not having been guaranteed to be a power of
two.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
| |
|
|
|
|
| |
This patch enables PCI MMCONFIG in xen and turns on hooks for ATS.
Signed-off-by: Allen Kay <allen.m.kay@intel.com>
|
| |
|
|
| |
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
|
| |
|
|
|
|
|
|
|
|
| |
[no-]e820-mtrr-clip: Clip e820 RAM areas to top-of-memory according
to MTRRs. Prefix no- to disable the clip.
e820-verbose: Extra e820 info printed during boot.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
|
| |
|
|
|
|
|
|
| |
cacheable (WB) by MTRRs. Fix up by truncating the memory map.
This fixes performance issues on certain systems.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Unless more than 16Tb are going to ever be supported in Xen, this will
allow reducing the linked list entries in struct page_info from 16 to
8 bytes.
This doesn't modify struct shadow_page_info, yet, so in order to meet
the constraints of that 'mirror' structure the list entry gets
artificially forced to be 16 bytes in size. That workaround will be
removed in a subsequent patch.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
| |
|
|
|
|
|
| |
explicitly disallow them itself.
Signed-off-by: Shane Wang <shane.wang@intel.com>
Signed-off-by: Joseph Cihula <joseph.cihula@intel.com>
|
| |
|
|
|
|
|
|
|
|
| |
... which currently means:
- The 1:1 map cannot deal with more than 1Tb.
- The m2p table can handle at most 8Tb.
- The page_info array can cover up to e.g. 1.6Gb (<=3D 64 CPUs) or
1Tb (193-256 CPUs).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
| |
|
|
|
|
| |
copy-on-grant-transfer, and eliminate 166GB memory limit for x86/64
Xen.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
|
| |
|
|
| |
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
|
|
|
|
|
|
| |
In order for Dom0 to be able to map the DMI table, it must not be in
E820 RAM; since some BIOS versions apparently fail to set the type
correctly for the page(s) containing this table, adjust it before
starting to consume memory.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
|
| |
Signed-off-by: Joseph Cihula <joseph.cihula@intel.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
|
| |
guests (to 166GB).
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
| |
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
| |
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
|
|
| |
parsing. Get rid of unneeded e820_raw variable -- map straight onto
boot-trampoline e820 array.
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
|
|
| |
meaningful to compatibility mode guests.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dom0_mem=[min:<min_amt>,][max:<max_amt>,][<amt>]
<min_amt>: The minimum amount of memory which should be allocated for dom0.
<max_amt>: The maximum amount of memory which should be allocated for dom0.
<amt>: The precise amount of memory to allocate for dom0.
Notes:
1. <amt> is clamped from below by <min_amt> and from above by available
memory and <max_amt>
2. <min_amt> is clamped from above by available memory and <max_amt>
3. <min_amt> is ignored if it is greater than <max_amt>
4. If <amt> is not specified, it is calculated as follows:
"All of memory is allocated to domain 0, minus 1/16th which is reserved
for uses such as DMA buffers (the reservation is clamped to 128MB)."
Each value can be specified as positive or negative:
If +ve: The specified amount is an absolute value.
If -ve: The specified amount is subtracted from total available memory.
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
| |
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
|
|
|
|
| |
of memory.
Signed-off-by: Gerd Knorr <kraxel@suse.de>
|
| |
|
|
|
|
|
| |
Rename memparse() to parse_size_and_unit(). A more general-purpose
name, and avoids unecessary clash with Linux function name.
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
|
|
|
|
| |
Initialise 1:1 mapping of physical memory map early during x86/64 boot.
This mapping should include all ACPI tables, so simplify the mapping
check in the ACPI code.
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change the Xen command-line parameter syntax. 'noacpi' and
'ignorebiostables' are gone. 'dom0_mem' can optionally take a k/m/g
suffix to specify units (default units are still kilobytes).
Also added:
1. 'mem=xxx' to specify maximum physical RAM address (supports
k/m/g suffix)
2. acpi=xxx/acpi_skip_timer_override/noapic: These all have same
semantics as in Linux. They are *automatically* propagated to
the domain0 command line, as dom0 shares resposibility for
platform initialisation.
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
|
|
|
| |
No longer disable format checking for printf/printk statements. This
required a whole bunch of cleanups to get the build working again.
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
|
|
|
| |
If debugging is enabled, printout the e820 map for vmx guests.
Signed-off-by: michael.fetterman@cl.cam.ac.uk
|
| |
|
|
|
|
| |
Build and x86/64 fixes.
Signed-off-by: keir.fraser@cl.cam.ac.uk
|
| |
|
|
|
|
| |
Truncate the e820 RAM map to 4GB maximum on 32-bit x86.
We don't support PAE36 mode.
|
| |
|
|
|
| |
Improved memory bootstrapping takes into account e820 RAM holes.
|
| |
|
|
|
| |
remove unused fn
|
|
|
Add e820 parsing to Xen. Currently not hooked into heap initialisation:
this is the next step.
|
