I don't think protocol specific data really belongs in this header
but since it is already there and we seem to be stuck with it let's at
least make the users explicit lest people get caught out by future new
fields moving the pad field around.
This is the Xen portion of this change. The kernel portion will be
sent separately. There is no dependency between the two.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Daniel Stodden <daniel.stodden@citrix.com>
Cc: Dongxiao Xu <dongxiao.xu@intel.com>
xen-unstable changeset: feee0abed6aa
xen-unstable date: Fri Jul 02 18:58:02 2010 +0100
In ioapic_suspend, it reads and saves ioapic RTEs. But when interrupt
remapping is enabled, io_apic_read will call io_apic_read_remap_rte to
convert remapped format interrupt to compatible format, this results
in 'dest' field may be changed in remap_entry_to_ioapic_rte. When in
ioapic_resume, it will write the saved RTEs with incorrect 'dest' to
interrupt remapping table.
Actually it needn't to convert RTEs regardless interrupt remapping is
enabled or not. It just needs to save and restore RTE values
directly. This patch just uses __io_apic_read and __io_apic_write,
which won't call Interrupt remapping functions to convert, to save and
restore RTEs in ioapic_suspend and ioapic_resume. Thus fix this issue.
Signed-off-by: Weidong Han <weidong.han@intel.com>
xen-unstable changeset: 01d185dab39e
xen-unstable date: Fri Aug 13 14:57:35 2010 +0100
allocation Rather than trying to count the number of PoD entries we're
putting in, we simply pass the target # of pages - the vga hole, and
let the hypervisor do the calculation.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
xen-unstable changeset: 6f059a340cdf
xen-unstable date: Wed Aug 11 15:56:21 2010 +0100
The current version of the powernow driver uses the APERF/MPEF
and the HWCR MSRs. Add cases in traps.c to let dom0 access
those MSRs.
Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com>
xen-unstable changeset: 6471b8b71401
xen-unstable date: Fri Aug 13 08:38:35 2010 +0100
When __pci_enable_msix() returns early, output parameter (struct
msi_desc **desc) will not be initialized. On my machine, a Broadcom
BCM5709 nic has both MSI and MSIX capability blocks and when guest
tries to enable msix interrupts but __pci_enable_msix() returns early
for encountering a msi block, the whole system will crash for fatal
page fault immediately.
Signed-off-by: Wei Wang <wei.wang2@amd.com>
xen-unstable changeset: 786b163da49b
xen-unstable date: Wed Aug 11 17:01:02 2010 +0100
If libelf calls elf_err() or elf_msg() before elf_set_log() has been
called then it could potentially read an uninitialised log handling
callback function pointer from struct elf_binary. Fix this in libxc by
zeroing the structure before calling elf_init().
Signed-off-by: Gianni Tedesco <gianni.tedesco@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
xen-unstable changeset: 1d67dd785ef4
xen-unstable date: Mon Aug 09 17:43:18 2010 +0100
This is needed to pull a non-default branch, and to allow the test
infrastructure's bisection machinery to work.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
When ioapic_rte_to_remap_entry fails, currently it just writes value
to ioapic. But the 'mask' bit may be changed if it writes to the upper
half of RTE. This patch ensures to recover the original value of
'mask' bit in this case.
Signed-off-by: Weidong Han <weidong.han@intel.com>
xen-unstable changeset: 21934:befd1814c0a2
xen-unstable date: Mon Aug 09 16:33:45 2010 +0100
At the end of io_apic_write_remap_rte, it writes new entry (remapped
interrupt) to ioapic. But it writes low 32 bits before high 32 bits,
it unmasks interrupt before writing high 32 bits if 'mask' bit in low
32 bits is cleared. Thus it may result in issues. This patch fixes
this issue by writing high 32 bits before low 32 bits.
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Weidong Han <weidong.han@intel.com>
xen-unstable changeset: 21933:add40eb47868
xen-unstable date: Mon Aug 09 16:32:45 2010 +0100
There isn't seem to be a way to directly check for EPT, so instead
check for HAP and an Intel processor. If EPT isn't enabled, then
return an error to the tool.
Signed-off-by: Patrick Colp <pjcolp@cs.ubc.ca>
xen-unstable changeset: 21882:af52102e4dcf
xen-unstable date: Wed Jul 28 07:54:40 2010 +0100
There are a few places in Xen where we walk a domain's page lists
without holding the page_alloc lock. They race with updates to the
page lists, which are normally rare but can be quite common under PoD
when the domain is close to its memory limit and the PoD reclaimer is
busy. This patch protects those places by taking the page_alloc lock.
I think this is OK for the two debug-key printouts - they don't run
from irq context and look deadlock-free. The tboot change seems safe
too unless tboot shutdown functions are called from irq context or
with the page_alloc lock held. The p2m one is the scariest but there
are already code paths in PoD that take the page_alloc lock with the
p2m lock held so it's no worse than existing code.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
xen-unstable changeset: 21881:57de3a3118bb
xen-unstable date: Wed Jul 28 07:54:12 2010 +0100
out of file descriptors meaning new the console of new domains are not
logged.
Seems to have been accidentally removed in 16638:28921e83000b.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 21818:9ccd024065c5
xen-unstable date: Mon Jul 19 12:21:24 2010 +0100
LOG_WARNING (or precisely LOG_DEBUG if -v) would be logged.
xenconsoled only actually logs using LOG_ERR and LOG_DEBUG so for the
most part we would have been logging absolutely nothing up until now.
Linux provides a LOG_UPTO macro but I'm not sure how portable that is
so I have opencoded the list of levels.
Do I get some sort of prize for fixing a bug introduced in 2005?
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 21814:91ce0b0953ca
xen-unstable date: Fri Jul 16 12:10:56 2010 +0100
This can just mean we have raced with the bootloader exiting and if we
continue we will likely see the real domain console show up.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 21797:c18f43ed379e
xen-unstable date: Wed Jul 14 16:36:47 2010 +0100
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>
xen-unstable changeset: 21837:3c00cb0d9bc4
xen-unstable date: Wed Jul 21 08:43:35 2010 +0100
There are cases of identical repeated calls to
iommu_map_page(). Flushing is slow, so it's worth detecting these and
bailing early.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
xen-unstable changeset: 21813:07b718833c74
xen-unstable date: Fri Jul 16 17:41:53 2010 +0100
The former strips dom0 of its usual 1:1 mapping of all memory, and
only provides it with mappings of its own memory, like any other
domain. The latter is a new consistent name for iommu=passthrough.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
xen-unstable changeset: 21771:42ccccfe1a6a
xen-unstable date: Fri Jul 09 16:45:42 2010 +0100
iommu: Map dom0 initial allocation in 'dom0-strict' iommu mode.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
xen-unstable changeset: 21812:e382656e4dcc
xen-unstable date: Fri Jul 16 16:19:51 2010 +0100
Send the debug VIRQ to guests after the rest of the domain dump is
done. This stops all the 'q' debug-key output getting interleaved with
the debug-virq output from a pv-ops dom0 kernel.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
xen-unstable changeset: 21809:1f7c2418e58c
xen-unstable date: Fri Jul 16 13:51:27 2010 +0100
When create DomU, if bootloader is specified, 'kernel/ramdisk' will be
used by bootloader when boots DomU. So it is needless to check the
path is existent or not.
Signed-off-by: Yu Zhiguo <yuzg@cn.fujitsu.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 21807:6fdb00dc93a5
xen-unstable date: Thu Jul 15 16:32:50 2010 +0100