The specifier only needs to be added to the function's definition.
At the same time, fix init_cpu_to_node() to be __init rather than
__devinit (it is only called at boot time).
Signed-off-by: Keir Fraser <keir@xen.org>
* platform_supports_{intremap,x2apic} should not be marked __init as
they are used during S3 resume.
* DMAR flags should be taken from the table passed to
acpi_parse_dmar() -- this is the trusted copy of the DMAR, when
running in TXT mode.
Signed-off-by: Allen Kay <allen.m.kay@intel.com>
AMD64 defines two special bits (bit 3 and 4) RdMem and WrMem in fixed
MTRR type. Their values are supposed to be 0 after BIOS hands the
control to OS according to AMD BKDG. Unless OS specificially turn them
on, they are kept 0 all the time. As a result, k8_enable_fixed_iorrs()
is unnecessary and removed from upstream kernel (see
https://patchwork.kernel.org/patch/11425/). This patch does the same
thing.
Signed-off-by: Wei Huang <wei.huang2@amd.com>
Some buggy BIOS might set SYS_CFG DramModEn bit to 1, which can cause
unexpected behavior on AMD platforms. This patch clears DramModEn bit
if it is 1.
Signed-off-by: Wei Huang <wei.huang2@amd.com>
The -hdX syntax is only retained for compatibility reasons and the
-sdX syntax doesn't even exist.
Additionally convert the first four non-SCSI disks to hd[a-d] and
ignore any further non-SCSI disks (since qemu only supports 4 IDE
devices).
SCSI disks are passed through as is. qemu-xen was limited to 7 SCSI
devices but upstream qemu supports 256, therefore do not limit the
number of disks on the libxl side.
qemu-xen did all this itself internally.
Fixes "qemu: -xvda: invalid option" and allows PVHVM to work with
upstream qemu.
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>
Given that we have the information available this is preferable to
picking it out of xenstore instead. We already do this for VIFs.
Only the qemu upstream version makes use of it since old qemu-xen
actually parses xenstore itself.
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>
Ideally we should be able to infer the format from something stashed
in xenstore but this is better than letting users see garbage values.
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>
Since d->nr_pirqs is guaranteed to be not larger than nr_irqs,
indexing arrays by the former ought to be preferred. In the case
given, the indices so far had to be computed specially in a number of
cases, whereas the indexes use now are all readily available.
This opens the possibility to fold the ->mirq[] and ->hvm_timer[]
members of struct hvm_irq_dpci into a single array, possibly with some
members overlayed in a union to reduce size (see
http://lists.xensource.com/archives/html/xen-devel/2011-03/msg02006.html).
Such space saving wouldn't, however, suffice to generally get the
respective allocation sizes here to below PAGE_SIZE, not even when
converting the array of structures into an array of pointers to
structures. Whether a multi-level lookup mechanism would make sense
here is questionable, as it can be expected that for other than Dom0
(which isn't hvm, and hence shouldn't use these data structures - see
http://lists.xensource.com/archives/html/xen-devel/2011-03/msg02004.html)
only very few entries would commonly be used here. An obvious
alternative would be to use rb or radix trees (both currently only
used in tmem).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
This is necessary because on x86-64 struct vcpu_guest_context is
larger than PAGE_SIZE, and hence not suitable for a general purpose
runtime allocation. On x86-32, FIX_PAE_HIGHMEM_* fixmap entries are
being re-used, whiule on x86-64 new per-CPU fixmap entries get
introduced. The implication of using per-CPU fixmaps is that these
allocations have to happen from non-preemptable hypercall context
(which they all do).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
This is accomplished by converting a couple of embedded arrays (in one
case a structure containing an array) into separately allocated
pointers, and (just as for struct arch_vcpu in a prior patch)
overlaying some PV-only fields with HVM-only ones.
One particularly noteworthy change in the opposite direction is that
of PITState - this field so far lived in the HVM-only portion, but is
being used by PV guests too, and hence needed to be moved out of
struct hvm_domain.
The change to XENMEM_set_memory_map (and hence libxl__build_pre() and
the movement of the E820 related pieces to struct pv_domain) are
subject to a positive response to a query sent to xen-devel regarding
the need for this to happen for HVM guests (see
http://lists.xensource.com/archives/html/xen-devel/2011-03/msg01848.html).
The protection of arch.hvm_domain.irq.dpci accesses by is_hvm_domain()
is subject to confirmation that the field is used for HVM guests only
(see
http://lists.xensource.com/archives/html/xen-devel/2011-03/msg02004.html).
In the absence of any reply to these queries, and given the early
state of 4.2 development, I think it should be acceptable to take the
risk of having to later undo/redo some of this.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
... thus further shrinking overall size of struct arch_vcpu.
This has a minor effect on XEN_DOMCTL_{get,set}_ext_vcpucontext - for
HVM guests, some meaningless fields will no longer get stored or
retrieved: reads will now return zero, and writes are required to be
(mostly) zero (the same as was already done on x86-32).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
This is accomplished by splitting the guest_context member, which by
itself is larger than a page on x86-64. Quite a number of fields of
this structure is completely meaningless for HVM guests, and thus a
new struct pv_vcpu gets introduced, which is being overlaid with
struct hvm_vcpu in struct arch_vcpu. The one member that is mostly
responsible for the large size is trap_ctxt, which now gets allocated
separately (unless fitting on the same page as struct arch_vcpu, as is
currently the case for x86-32), and only for non-hvm, non-idle
domains.
This change pointed out a latent problem in arch_set_info_guest(),
which is permitted to be called on already initialized vCPU-s, but
so far copied the new state into struct arch_vcpu without (in this
case) actually going through all the necessary accounting/validation
steps. The logic gets changed so that the pieces that bypass
accounting
will at least be verified to be no different from the currently active
bits, and the whole change will fail in case they are. The logic does
*not* get adjusted here to do full error recovery, that is, partially
modified state continues to not get unrolled in case of failure.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
The CPU masks embedded in these structures prevent NR_CPUS-independent
sizing of these structures.
Basic concept (in xen/include/cpumask.h) taken from recent Linux.
For scalability purposes, many other uses of cpumask_t should be
replaced by cpumask_var_t, particularly local variables of functions.
This implies that no functions should have by-value cpumask_t
parameters, and that the whole old cpumask interface (cpus_...())
should go away in favor of the new (cpumask_...()) one.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
libxenlight and xl grew enough to need a CODING_STYLE, that I blatantly
copied from qemu and linux, just adding few specific modifications.
The result should be as less controversial as possible, mostly
documenting what we are already doing.
[ Message and document originally posted to xen-devel on 2010-09-01 ]
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
The PSE handling doesn't check bits 1...8 (or 1...9 for non-PAE guests)
being zero, thus allowing bad (not 2Mb/4Mb aligned) large pages to be
handled.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Acked-by: Tim Deegan <Tim.Deegan@citrix.com>
We're building for one case (CONFIG_ACPI_PCI defined) only, yet still
had the other case's code in there. Additionally there was quite a bit
of pseudo-duplication between disabled(!) DMI scan and ACPI boot code.
acpi_pci_disabled had only a single reader, which is off by default
(i.e. must be enable on the command line), so it seems pointless to
keep it.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
xen/arch/x86/acpi/boot.c consists of almost only code/data in .init.*,
so move the few bits that aren't into a new file and then use the
recently introduced .init.o mechanism to move all the literal strings
into .init.rodata.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Besides marking a few more items __init/__initdata, use the recently
introduced .init.o mechanism to move all the literal strings into
.init.rodata in those files that consist of only contributions to
.init.*.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
With no modular drivers, all CPU notifier setup is supposed to happen
during boot. There also is a respective comment in the function.=20
Signed-off-by: Jan Beulich <jbeulich@novell.com>
The pointer value in case of an allocation failure is rather
uninteresting.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
The current formula to calculate t_info_pages, based on the initial
code, is slightly incorrect. It may allocate more than needed.
Each cpu has some pages/mfns stored as uint32_t.
That list is stored with an offset at tinfo.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Check flags field in ACPI DMAR structure before enabling interrupt
remapping or x2apic. This allows platform vendors to disable
interrupt remapping or x2apic features if on board BIOS does not
support them.
Signed-off-by: Allen Kay <allen.m.kay@intel.com>
This is the libxl convention. By using the "typedef enum foo { } foo;"
syntax we can retain backwards compatibility with existing users.
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>
The libxl_device_nic struct has strings which are initially strdup()ed
and then free()ed in libxl_device_nic_destroy(). In the
"network-attach" parser we need to free() the existing string and
strdup((*argv) + N), rather than just copying the pointer.
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
lib<foo>_stubs.a was linking against $(LIBS_<foo>) which only includes
dynamic linkage information which is not useful for a static library.
$(LIBS_<foo>) is still used when linking <foo>.cmxa
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>
cegger
Keir Fraser
Allen Kay
Wei Huang
Ian Campbell
Jan Beulich
Machon Gregory
Ian Jackson
Tim Deegan
Christoph Egger
Olaf Hering
Juergen Gross
David Scott