similar to: Xen support for native EFI boot

During debugging of another problem I found that in x2APIC mode, the destination field of the low address value wasn''t passed back correctly. While this is benign in most cases (as the value isn''t being used anywhere), it can be confusing (and misguiding) when printing the value read or when comparing it to the one previously passed into the inverse function. Signed-off-by: Jan

Finally I got around to breaking up the similarly named monolithic patch that caused a regression shortly before the 4.2 release and got therefore reverted. This series consists of the broken up pieces that - according to my testing - don''t expose the reported lockup; the 7th will need debugging to understand what''s wrong there. 1: use RTC_* names instead of literal numbers 2:

Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2008-09-19/xen/arch/x86/platform_hypercall.c =================================================================== --- 2008-09-19.orig/xen/arch/x86/platform_hypercall.c 2008-09-19 14:12:02.000000000 +0200 +++ 2008-09-19/xen/arch/x86/platform_hypercall.c 2008-09-19 14:12:56.000000000 +0200 @@ -21,7 +21,7 @@ #include <xen/acpi.h>

The DMI checks that force the use of the bigsmp APIC driver are for systems that are no longer supported by Xen (32-bit x86). Signed-off-by: Matt Wilson <msw@amazon.com> Cc: Keir Fraser <keir@xen.org> Cc: Jan Beulich <jbeulich@suse.com> Cc: Andrew Cooper <andrew.cooper3@citrix.com> --- xen/arch/x86/genapic/bigsmp.c | 30 +----------------------------- 1 files changed, 1

All, in the light of erratum #573 I''m wondering if we need to tweak or conditionally suppress fsincos emulation. The question is whether there is any possibility for getting the emulator to hit this instruction on AMD (as no real mode emulation ought to be taking place there), i.e. whether there are places where emulation gets continued eagerly in anticipation of the need for emulation

This applies to both SVM and VMX. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -310,7 +310,7 @@ static struct keyhandler vmcb_dump_keyha .desc = "dump AMD-V VMCBs" }; -void setup_vmcb_dump(void) +void __init setup_vmcb_dump(void) { register_keyhandler(''v'',

Coverity IDs 1054956, 1054957 Coverity pointed out that we applying array operations based on an expression which yielded singleton pointers. The problem is actually that the externs were typed incorrectly. Correct the extern declaration to prevent straying into undefined behaviour, and relying on the lenience of GCC to work. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> CC:

The first patch really isn''t as much of a follow-up than what triggered the security issues to be noticed in the first place. 1: x86: preserve FPU selectors for 32-bit guest code 2: x86: fix XCR0 handling 3: x86/xsave: adjust state management 4: x86/fxsave: bring in line with recent xsave adjustments The first two I would see as candidates for 4.3 (as well as subsequent backporting,

With pretty trivial user mode programs being able to crash the kernel due to the ref counter widths in Xen being more narrow than in Linux, I started an attempt to put together a kernel side fix. While addressing the plain hypercalls is pretty strait forward, dealing with multicalls (both when using them for lazy mmu mode batching and when explicitly using them in e.g. netback - the backends are

Call update_domain_wallclock_time on hvm_latch_shinfo_size even if the bitness of the guest has already been set, this fixes the problem with the wallclock not being set for PVHVM guests on resume from migration. Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Cc: Jan Beulich <JBeulich@suse.com> Cc: Keir Fraser <keir@xen.org> Cc: George Dunlap

.. is out of sync on i386 and x86-64 - should it be allowed on i386, or should it be suppressed on x86-64? Since Xen fails ill accesses, I would assume enabling it on i386 is fine. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

When using sedf scheduler in a cpupool the system might panic when setting sedf scheduling parameters for a domain. Signed-off-by: juergen.gross@ts.fujitsu.com 1 file changed, 4 insertions(+) xen/common/sched_sedf.c | 4 ++++ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

This set of patches converts the way frames gets created from using PUSHes/POPs to using MOVes, thus allowing (in certain cases) to avoid saving/restoring part of the register set. While the place where the (small) win from this comes from varies between CPUs, the net effect is a 1 to 2% reduction on a combined interruption entry and exit when the full state save can be avoided. 1: use MOV

Hi! I catched two pieces with debug and crash_debug enabled. One of them fixes a build error even without the -Wcast-qual flag. Patch attached. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

The series "HVM firmware passthrough" series in Jan 2013 from Ross Philipson cause two regressions for HVM guests which sadly found their way into the Xen 4.3 release. The first regression causes an incorrect count of tables to be placed in the main header, and can be seen by running dmidecode in any applicable HVM domain. The second regression found its way into the public ABI, making

This series consists of improvements to Xen''s ability to print traces of its own stack, and specifically for the stack overflow case to be able to use frame pointers in a debug build. I have dev tested the series in debug and non-debug cases, with and without memory guards, and I believe that all the stack traces look correct. However, I would greatly appreciate a second opinion on the

Under the assumption that in these cases recurring faults aren''t a security issue and it can be expected that the drivers there are going to try to take care of the problem. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/drivers/passthrough/amd/iommu_init.c +++ b/xen/drivers/passthrough/amd/iommu_init.c @@ -625,6 +625,18 @@ static void parse_event_log_entry(struct

These two fixes are the final two outstanding issues in tools/firmware. They are both quite minor. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> -- 1.7.10.4

There are BIOSes that want to map the IO-APIC MMIO region from some ACPI method(s), and there is at least one BIOS flavor that wants to use this mapping to clear an RTE''s mask bit. While we can''t allow the latter, we can permit reads and simply drop write attempts, leveraging the already existing infrastructure introduced for dealing with AMD IOMMUs'' representation as

Hi, Keir, This patch is a bugfix for saving and restoring MSI/MSI-X across S3. Currently, Dom0''s PCI layer unmaps MSI when S3 and maps them back when resuming. However, this triggers unexpected behaviors. For example, if the drivers still holds that irq at the point of unmapping MSI, Xen will force unbind that pirq. But after resume, we have no mechanism to rebind that pirq. The device