aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* libxc: Fix range checking in xc_dom_pfn_to_ptr etc.Ian Jackson2013-06-144-5/+38
| | | | | | | | | | | | | | | | | | | | * Ensure that xc_dom_pfn_to_ptr (when called with count==0) does not return a previously-allocated block which is entirely before the requested pfn (!) * Provide a version of xc_dom_pfn_to_ptr, xc_dom_pfn_to_ptr_retcount, which provides the length of the mapped region via an out parameter. * Change xc_dom_vaddr_to_ptr to always provide the length of the mapped region and change the call site in xc_dom_binloader.c to check it. The call site in xc_dom_load_elf_symtab will be corrected in a forthcoming patch, and for now ignores the returned length. This is part of the fix to a security issue, XSA-55. Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> v5: This patch is new in v5 of the series.
* libxc: introduce xc_dom_seg_to_ptr_pagesIan Jackson2013-06-141-3/+16
| | | | | | | | | | | | Provide a version of xc_dom_seg_to_ptr which returns the number of guest pages it has actually mapped. This is useful for callers who want to do range checking; we will use this later in this series. This is part of the fix to a security issue, XSA-55. Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
* libelf: abolish libelf-relocate.cIan Jackson2013-06-142-373/+1
| | | | | | | | | | | | | | | This file is not actually used. It's not built in Xen's instance of libelf; in libxc's it's built but nothing in it is called. Do not compile it in libxc, and delete it. This reduces the amount of work we need to do in forthcoming patches to libelf (particularly since as libelf-relocate.c is not used it is probably full of bugs). This is part of the fix to a security issue, XSA-55. Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
* Revert "AMD/iommu: SR56x0 Erratum 64 - Reset all head & tail pointers"Jan Beulich2013-06-051-10/+0
| | | | | | | | | | | | | | This reverts commit 22de18bb89e776f77256653901a590aad9fc0a52. The code this patch added is redundant with already present code in set_iommu_{command_buffer,event_log}_control(). Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> master commit: e430510e5cbbfcdc1077739292def633e70fedea master date: 2013-06-05 10:05:49 +0200
* x86/xsave: properly check guest input to XSETBVJan Beulich2013-06-041-0/+5
| | | | | | | | | | | | Other than the HVM emulation path, the PV case so far failed to check that YMM state requires SSE state to be enabled, allowing for a #GP to occur upon passing the inputs to XSETBV inside the hypervisor. This is CVE-2013-2078 / XSA-54. Signed-off-by: Jan Beulich <jbeulich@suse.com> master commit: 365c95f7de789e1dca03f119eab7dc61fe0f77c9 master date: 2013-06-04 09:29:07 +0200
* x86/xsave: recover from faults on XRSTORJan Beulich2013-06-041-5/+20
| | | | | | | | | | | | | | | | Just like FXRSTOR, XRSTOR can raise #GP if bad content is being passed to it in the memory block (i.e. aspects not under the control of the hypervisor, other than e.g. proper alignment of the block). Also correct the comment explaining why FXRSTOR needs exception recovery code to not wrongly state that this can only be a result of the control tools passing a bad image. This is CVE-2013-2077 / XSA-53. Signed-off-by: Jan Beulich <jbeulich@suse.com> master commit: c6ae65db36b98f2866f74a9a7ae6ac5d51fedc67 master date: 2013-06-04 09:27:58 +0200
* x86/xsave: fix information leak on AMD CPUsJan Beulich2013-06-041-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | Just like for FXSAVE/FXRSTOR, XSAVE/XRSTOR also don't save/restore the last instruction and operand pointers as well as the last opcode if there's no pending unmasked exception (see CVE-2006-1056 and commit 9747:4d667a139318). While the FXSR solution sits in the save path, I prefer to have this in the restore path because there the handling is simpler (namely in the context of the pending changes to properly save the selector values for 32-bit guest code). Also this is using FFREE instead of EMMS, as it doesn't seem unlikely that in the future we may see CPUs with x87 and SSE/AVX but no MMX support. The goal here anyway is just to avoid an FPU stack overflow. I would have preferred to use FFREEP instead of FFREE (freeing two stack slots at once), but AMD doesn't document that instruction. This is CVE-2013-2076 / XSA-52. Signed-off-by: Jan Beulich <jbeulich@suse.com> Tested-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> master commit: 8dcf9f0113454f233089e8e5bb3970d891928410 master date: 2013-06-04 09:26:54 +0200
* libxc: limit cpu values when setting vcpu affinityPetr Matousek2013-05-311-0/+12
| | | | | | | | | | | | | | | When support for pinning more than 64 cpus was added, check for cpu out-of-range values was removed. This can lead to subsequent out-of-bounds cpumap array accesses in case the cpu number is higher than the actual count. This patch returns the check. This is CVE-2013-2072 / XSA-56 Signed-off-by: Petr Matousek <pmatouse@redhat.com> master commit: 41abbadef60e5fccdfd688579dd458f7f7887cf5 master date: 2013-05-29 15:49:22 +0100
* x86: fix boot time APIC mode detectionJan Beulich2013-05-311-1/+1
| | | | | | | | | | | | | | | | | current_cpu_data becomes valid only relatively late in the boot process, so looking there for a particular feature early in the game would generally give the appearance of the feature being unavailable. Getting this wrong means that at kexec time the system would get returned to xAPIC mode, causing disconnect_bsp_APIC() to try to access the APIC page, which on systems with x2APIC pre-enabled will never get set up. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> master commit: 234c4dde2fd4f1182fe1a6bea6bced83fe363007 master date: 2013-05-23 13:08:32 +0200
* tools: fix dependency file generationJan Beulich2013-05-231-1/+1
| | | | | | | | | | | | | | | | | There is a small set of places where files in subdirectories get compiled from the parent directory. Dependency file wise this is no problem as long as the files use names distinct without regard to the directories they sit in, and tools/console/ violates this (in having two main.c files). Hence we need to avoid losing the directory name, both to ensure the two compiler instances don't simultaneously write to the same file (happening of which is what triggered me looking into this) and to guarantee dependencies for all files will be seen by make on an incremental rebuild. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> master commit: 4d788e164d6556d931bc3e0a69e36b8cf7280794 master date: 2013-05-21 10:16:30 +0200
* AMD/iommu: SR56x0 Erratum 64 - Reset all head & tail pointersAndrew Cooper2013-05-231-0/+10
| | | | | | | | | | | | | | | | | | Reference at time of patch: http://support.amd.com/us/ChipsetMotherboard_TechDocs/46303.pdf Erratum 64 states that the head and tail pointers for the Command buffer and Event log are only reset on a cold boot, not a warm boot. While the erratum is limited to systems using SR56xx chipsets (such as Family 10h CPUs), resetting the pointers is a sensible action in all cases, including the PPR log for consistency. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Keir Fraser <keir@xen.org> Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> master commit: 6d243308e1d75f866679db226159c797d6c83aad master date: 2013-05-22 15:26:52 +0200
* fix XSA-46 regression with xend/xmJan Beulich2013-05-232-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The hypervisor side changes for XSA-46 require the tool stack to now always map the guest pIRQ before granting access permission to the underlying host IRQ (GSI). This in particular requires that pciif.py no longer can skip this step (assuming qemu would do it) for HVM guests. This in turn exposes, however, an inconsistency between xend and qemu: The former wants to always establish 1:1 mappings between pIRQ and host IRQ (for non-MSI only of course), while the latter always wants to allocate an arbitrary mapping. Since the whole tool stack obviously should always agree on the mapping model, make libxc enforce the 1:1 mapping as the more natural one (as well as being the one that allows for easier debugging, since there no need to find out the extra mapping). Users of libxc that want to establish a particular (rather than an allocated) mapping are still free to do so, as well as tool stacks not based on libxc wanting to implement an allocation based model (which is why it's not the hypervisor that's being changed to enforce either model). Since libxl, like xend, already uses a 1:1 model, it's unaffected by the libxc change (and it being unaffected by the original hypervisor side changes is - afaict - simply due to qemu getting spawned at a later point in time compared to the xend event flow). Signed-off-by: Jan Beulich <jbeulich@suse.com> Tested-by: Andreas Falck <falck.andreas.lists@gmail.com> (on 4.1) Tested-by: Gordan Bobic <gordan@bobich.net> (on 4.2) Acked-by: Ian Campbell <ian.campbell@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> master commit: 934a5253d932b6f67fe40fc48975a2b0117e4cce master date: 2013-05-21 11:32:34 +0200
* x86/shadow: fix off-by-one in MMIO permission checkJan Beulich2013-05-231-3/+3
| | | | | | | | | | | iomem_access_permitted() wants an inclusive range as input. Also use pfn_to_paddr() in nearby code instead of open coding it. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Tim Deegan <tim@xen.org> master commit: afa65ddfd88184a894d9364bec587554c28c20e0 master date: 2013-05-15 14:34:05 +0200
* x86/IO-APIC: fix guest RTE write corner casesJan Beulich2013-05-233-9/+52
| | | | | | | | | | | | | | | | | | | | | | This fixes two regressions from c/s 20143:a7de5bd776ca ("x86: Make the hypercall PHYSDEVOP_alloc_irq_vector hypercall dummy"): For one, IRQs that had their vector set up by Xen internally without a handler ever having got set (e.g. via "com<n>=..." without a matching consumer option like "console=com<n>") would wrongly call add_pin_to_irq() here, triggering the BUG_ON() in that function. Second, when assign_irq_vector() fails this addition to irq_2_pin[] needs to be undone. In the context of this I'm also surprised that the irq_2_pin[] manipulations here occur without any lock, i.e. rely on Dom0 to do some sort of serialization. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> master commit: 30256a0ff17f6f3b1278b85103187341d5b0ac42 master date: 2013-05-15 10:52:02 +0200
* x86: cleanup after making various page table manipulation operations preemptibleJan Beulich2013-05-033-56/+57
| | | | | | | | | | | | | | This drops the "preemptible" parameters from various functions where now they can't (or shouldn't, validated by assertions) be run in non- preemptible mode anymore, to prove that manipulations of at least L3 and L4 page tables and page table entries are now always preemptible, i.e. the earlier patches actually fulfill their purpose of fixing the resulting security issue. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Tim Deegan <tim@xen.org> master commit: b965b31a6bce8c37e67e525fae6da0e2f26d6b2e master date: 2013-05-02 17:04:14 +0200
* VT-d: don't permit SVT_NO_VERIFY entries for known device typesJan Beulich2013-05-021-5/+9
| | | | | | | | | | | | | Only in cases where we don't know what to do we should leave the IRTE blank (suppressing all validation), but we should always log a warning in those cases (as being insecure). This is CVE-2013-1952 / XSA-49. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: "Zhang, Xiantao" <xiantao.zhang@intel.com> master commit: 63cec00679cc65ab5d5a9447a62d5202f155b78c master date: 2013-05-02 17:08:58 +0200
* x86: make page table handling error paths preemptibleJan Beulich2013-05-021-27/+98
| | | | | | | | | | | | | | | | | | | | | ... as they may take significant amounts of time. This requires cloning the tweaked continuation logic from do_mmuext_op() to do_mmu_update(). Note that in mod_l[34]_entry() a negative "preemptible" value gets passed to put_page_from_l[34]e() now, telling the callee to store the respective page in current->arch.old_guest_table (for a hypercall continuation to pick up), rather than carrying out the put right away. This is going to be made a little more explicit by a subsequent cleanup patch. This is part of CVE-2013-1918 / XSA-45. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Tim Deegan <tim@xen.org> master commit: b8efae696c9a2d46e91fa0eda739427efc16c250 master date: 2013-05-02 16:39:37 +0200
* x86: make page table unpinning preemptibleJan Beulich2013-05-022-7/+56
| | | | | | | | | | | | | | | | ... as it may take significant amounts of time. Since we can't re-invoke the operation in a second attempt, the continuation logic must be slightly tweaked so that we make sure do_mmuext_op() gets run one more time even when the preempted unpin operation was the last one in a batch. This is part of CVE-2013-1918 / XSA-45. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Tim Deegan <tim@xen.org> master commit: a3e049f8e86fe18e3b87f18dc0c7be665026fd9f master date: 2013-05-02 16:39:06 +0200
* x86: make arch_set_info_guest() preemptibleJan Beulich2013-05-024-38/+83
| | | | | | | | | | | | .. as the root page table validation (and the dropping of an eventual old one) can require meaningful amounts of time. This is part of CVE-2013-1918 / XSA-45. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Tim Deegan <tim@xen.org> master commit: 99d2b149915010e986f4d8778708c5891e7b4635 master date: 2013-05-02 16:38:30 +0200
* x86: make vcpu_reset() preemptibleJan Beulich2013-05-029-19/+37
| | | | | | | | | | | | ... as dropping the old page tables may take significant amounts of time. This is part of CVE-2013-1918 / XSA-45. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Tim Deegan <tim@xen.org> master commit: 4939f9a6dee4280f38730fd3066e5dce353112f6 master date: 2013-05-02 16:37:24 +0200
* x86: make MMUEXT_NEW_USER_BASEPTR preemptibleJan Beulich2013-05-021-6/+32
| | | | | | | | | | | ... as it may take significant amounts of time. This is part of CVE-2013-1918 / XSA-45. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Tim Deegan <tim@xen.org> master commit: 918a5f17b447072b40780f4d03a3adc99ff0073b master date: 2013-05-02 16:36:44 +0200
* x86: make new_guest_cr3() preemptibleJan Beulich2013-05-022-20/+65
| | | | | | | | | | | ... as it may take significant amounts of time. This is part of CVE-2013-1918 / XSA-45. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Tim Deegan <tim@xen.org> master commit: e2e6b7b627fec0d7a769ab46441f2985ebccbf04 master date: 2013-05-02 16:35:50 +0200
* x86: make vcpu_destroy_pagetables() preemptibleJan Beulich2013-05-025-64/+94
| | | | | | | | | | | | | | | | | ... as it may take significant amounts of time. The function, being moved to mm.c as the better home for it anyway, and to avoid having to make a new helper function there non-static, is given a "preemptible" parameter temporarily (until, in a subsequent patch, its other caller is also being made capable of dealing with preemption). This is part of CVE-2013-1918 / XSA-45. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Tim Deegan <tim@xen.org> master commit: 6cdc9be2a5f2a87b4504404fbf648d16d9503c19 master date: 2013-05-02 16:34:21 +0200
* update Xen version to 4.1.6-preJan Beulich2013-04-291-1/+1
|
* update Xen version to 4.1.5RELEASE-4.1.5Jan Beulich2013-04-232-2/+2
|
* libxl: fix build error after 21c31a81Jan Beulich2013-04-191-1/+1
| | | | | | "libxl: Fix SEGV in network-attach" dropped a necessary &. Signed-off-by: Jan Beulich <jbeulich@suse.com>
* libxl: Fix SEGV in network-attachIan Jackson2013-04-181-1/+2
| | | | | | | | | | | | | | When "device/vif" directory exists but is empty l!=NULL, but nb==0, so l[nb-1] is invalid. Add missing check. Signed-off-by: Marek Marczykowski <marmarek@invisiblethingslab.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> (cherry picked from commit 9f1a6ff38b8e7bb97a016794115de28553a6559f) Conflicts: tools/libxl/libxl.c Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
* Fix rcu domain locking for transitive grantsPaul Durrant2013-04-182-31/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | When acquiring a transitive grant for copy then the owning domain needs to be locked down as well as the granting domain. This was being done, but the unlocking was not. The acquire code now stores the struct domain * of the owning domain (rather than the domid) in the active entry in the granting domain. The release code then does the unlock on the owning domain. Note that I believe I also fixed a bug where, for non-transitive grants the active entry contained a reference to the acquiring domain rather than the granting domain. From my reading of the code this would stop the release code for transitive grants from terminating its recursion correctly. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> master commit: f544bf377ee829e1342abd818ac30478c6f3a134 master date: 2011-03-08 16:30:30 +0000 Also, for non-transitive grants we now avoid incorrectly recursing in __release_grant_for_copy. This is CVE-2013-1964 / XSA-50. Reported-by: Manuel Bouyer <bouyer@antioche.eu.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> Tested-by: Manuel Bouyer <bouyer@antioche.eu.org>
* x86: fix various issues with handling guest IRQsJan Beulich2013-04-188-24/+82
| | | | | | | | | | | | | | | - properly revoke IRQ access in map_domain_pirq() error path - don't permit replacing an in use IRQ - don't accept inputs in the GSI range for MAP_PIRQ_TYPE_MSI - track IRQ access permission in host IRQ terms, not guest IRQ ones (and with that, also disallow Dom0 access to IRQ0) This is CVE-2013-1919 / XSA-46. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> master commit: 545607eb3cfeb2abf5742d1bb869734f317fcfe5 master date: 2013-04-18 16:11:23 +0200
* x86: clear EFLAGS.NT in SYSENTER entry pathJan Beulich2013-04-183-3/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... as it causes problems if we happen to exit back via IRET: In the course of trying to handle the fault, the hypervisor creates a stack frame by hand, and uses PUSHFQ to set the respective EFLAGS field, but expects to be able to IRET through that stack frame to the second portion of the fixup code (which causes a #GP due to the stored EFLAGS having NT set). And even if this worked (e.g if we cleared NT in that path), it would then (through the fail safe callback) cause a #GP in the guest with the SYSENTER handler's first instruction as the source, which in turn would allow guest user mode code to crash the guest kernel. Inject a #GP on the fake (NULL) address of the SYSENTER instruction instead, just like in the case where the guest kernel didn't register a corresponding entry point. On 32-bit we also need to make sure we clear SYSENTER_CS for all CPUs (neither #RESET nor #INIT guarantee this). This is CVE-2013-1917 / XSA-44. Reported-by: Andrew Cooper <andrew.cooper3@citirx.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Tested-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> master commit: fdac9515607b757c044e7ef0d61b1453ef999b08 master date: 2013-04-18 16:00:35 +0200
* iommu/crash: Interrupt remapping is also disabled on crashAndrew Cooper2013-04-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | This fixes a regression side-effect caused by: IOMMU: properly check whether interrupt remapping is enabled git: fae0372140befb88d890a30704a8ec058c902af8 hg: 26742:e1ec14bad0cb On the crash path in nmi_shootdown_cpus(), we shut down the IOMMU, then disable the IOAPIC. On systems which support interrupt remapping, the variable iommu_intremap remains set, meaning that disable_IO_APIC() issues interrupt remapping invalidate requests. IOAPIC interrupt remapping used to be conditional on iommu_enabled, but is now conditional on iommu_intremap, following the above changeset. This behaviour can be fixed by also indicating that interrupt remapping is not enabled after shutting down the IOMMU. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> master commit: 53fd1d8458de01169dfb56feb315f02c2b521a86 master date: 2013-04-16 10:34:32 +0200
* x86: don't pass negative time to gtime_to_gtsc()Jan Beulich2013-04-181-0/+9
| | | | | | | | | | | | | | scale_delta(), which is being called by that function, doesn't cope with that. Also print a warning message, so hopefully we can eventually figure why occasionally a negative value results from the calculation in the first place. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> master commit: eb60be3dd870aecfa47bed1118069680389c15f7 master date: 2013-04-11 12:07:55 +0200
* update Xen version to 4.1.5-rc24.1.5-rc2Jan Beulich2013-04-121-1/+1
|
* VMX: Always disable SMEP when guest is in non-paging modeStefan Bader2013-04-091-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | commit e7dda8ec9fc9020e4f53345cdbb18a2e82e54a65 VMX: disable SMEP feature when guest is in non-paging mode disabled the SMEP bit if a guest VCPU was using HAP and was not in paging mode. However I could observe VCPUs getting stuck in the trampoline after the following patch in the Linux kernel changed the way CR4 gets set up: x86, realmode: read cr4 and EFER from kernel for 64-bit trampoline The change will set CR4 from already set flags which includes the SMEP bit. On bare metal this does not matter as the CPU is in non- paging mode at that time. But Xen seems to use the emulated non- paging mode regardless of HAP (I verified that on the guests I was seeing the issue, HAP was not used). Therefor it seems right to unset the SMEP bit for a VCPU that is not in paging-mode, regardless of its HAP usage. Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Keir Fraser <keir@xen.org> Acked-by: Dongxiao Xu <dongxiao.xu@intel.com> master commit: 0d2e673a763bc7c2ddf97fed074eb691d325ecc5 master date: 2013-04-04 10:37:19 +0200
* VMX: disable SMEP feature when guest is in non-paging modeDongxiao Xu2013-04-091-0/+7
| | | | | | | | | | | | | | | | | | | SMEP is disabled if CPU is in non-paging mode in hardware. However Xen always uses paging mode to emulate guest non-paging mode with HAP. To emulate this behavior, SMEP needs to be manually disabled when guest switches to non-paging mode. We met an issue that, SMP Linux guest with recent kernel (enable SMEP support, for example, 3.5.3) would crash with triple fault if setting unrestricted_guest=0 in grub. This is because Xen uses an identity mapping page table to emulate the non-paging mode, where the page table is set with USER flag. If SMEP is still enabled in this case, guest will meet unhandlable page fault and then crash. Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com> Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com> master commit: e7dda8ec9fc9020e4f53345cdbb18a2e82e54a65 master date: 2013-01-30 09:17:30 -0800
* vmx: Simplify cr0 update handling by deferring cr4 changes to the cr4 handler.Keir Fraser2013-04-091-10/+5
| | | | | | Signed-off-by: Keir Fraser <keir@xen.org> master commit: 1453984eab1297559e016d4e907a27e55997191c master date: 2013-01-30 09:15:39 -0800
* x86/mm/shadow: spurious warning when unmapping xenheap pages.Tim Deegan2013-04-092-3/+6
| | | | | | | | | | | | Xenheap pages will always have an extra typecount, taken in share_xen_page_with_guest(), which doesn't come from a shadow PTE. Adjust the warning in sh_remove_all_mappings() to account for it. Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Tim Deegan <tim@xen.org> Tested-by: Andrew Cooper <andrew.cooper3@citrix.com> master commit: cfc515dabe91e3d6c690c68c6a669d6d77fb7ac4 master date: 2013-04-04 10:14:30 +0100
* x86/S3: Restore broken vcpu affinity on resumeBen Guthro2013-04-093-3/+51
| | | | | | | | | | | | | | | When in SYS_STATE_suspend, and going through the cpu_disable_scheduler path, save a copy of the current cpu affinity, and mark a flag to restore it later. Later, in the resume process, when enabling nonboot cpus restore these affinities. Signed-off-by: Ben Guthro <benjamin.guthro@citrix.com> Acked-by: George Dunlap <george.dunlap@eu.citrix.com> Acked-by: Keir Fraser <keir@xen.org> master commit: 41e71c2607e036f1ac00df898b8f4acb2d4df7ee master date: 2013-04-02 09:52:32 +0200
* x86: irq_move_cleanup_interrupt() must ignore legacy vectorsJan Beulich2013-04-092-1/+8
| | | | | | | | | | | | | | | | | | | | | | | Since the main loop in the function includes legacy vectors, and since vector_irq[] gets set up for legacy vectors regardless of whether those get handled through the IO-APIC, it must not do anything on this vector range. In fact, we should never get past the move_cleanup_count check for IRQs not handled through the IO-APIC. Adding a respective assertion woulkd make those iterations more expensive (due to the lock acquire). For such an assertion to not have false positives we however ought to suppress setting up IRQ2 as an 8259A interrupt (which wasn't correct anyway), which is being done here despite the assertion not actually getting added. Furthermore, there's no point iterating over the vectors past LAST_HIPRIORITY_VECTOR, so terminate the loop accordingly. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Keir Fraser <keir@xen.org> master commit: af699220ad6d111ba76fc3040342184e423cc9a1 master date: 2013-04-02 08:30:03 +0200
* defer event channel bucket pointer store until after XSM checksJan Beulich2013-04-051-1/+2
| | | | | | | | | | | | | | Otherwise a dangling pointer can be left, which would cause subsequent memory corruption as soon as the space got re-allocated for some other purpose. This is CVE-2013-1920 / XSA-47. Reported-by: Wei Liu <wei.liu2@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Tim Deegan <tim@xen.org> master commit: 99b9ab0b3e7f0e7e5786116773cb7b746f3fab87 master date: 2013-04-05 09:59:03 +0200
* ACPI: fix APEI related table size checkingHuang Ying2013-04-021-3/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Huang Ying's machine: erst_tab->header_length == sizeof(struct acpi_table_einj) but Yinghai reported that on his machine, erst_tab->header_length == sizeof(struct acpi_table_einj) - sizeof(struct acpi_table_header) To make erst table size checking code works on all systems, both testing are treated as PASS. Same situation applies to einj_tab->header_length, so corresponding table size checking is changed in similar way too. Originally-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Huang Ying <ying.huang@intel.com> - use switch() for better readability - add comment explaining why a formally invalid size it also being accepted - check erst_tab->header.length before even looking at erst_tab->header_length - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst) Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> master commit: 915ef37d7cc8fcac5b37eb0b40c693754fcd12ab master date: 2012-10-16 17:26:36 +0200
* ACPI, APEI: Add apei_exec_run_optionalHuang Ying2013-04-022-4/+16
| | | | | | | | | | | | | | | | | | | | Some actions in APEI ERST and EINJ tables are optional, for example, ACPI_EINJ_BEGIN_OPERATION action is used to do some preparation for error injection, and firmware may choose to do nothing here. While some other actions are mandatory, for example, firmware must provide ACPI_EINJ_GET_ERROR_TYPE implementation. Original implementation treats all actions as optional (that is, can have no instructions), that may cause issue if firmware does not provide some mandatory actions. To fix this, this patch adds apei_exec_run_optional, which should be used for optional actions. The original apei_exec_run should be used for mandatory actions. Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Tested-by: Andrew Cooper <andrew.cooper3@citrix.com> master commit: 72af01bf6f7489e54ad59270222a29d3e8c501d1 master date: 2013-03-22 12:46:25 +0100
* ACPI/APEI: Unlock apei_iomaps_lock on error pathAndrew Cooper2013-04-021-4/+2
| | | | | | | | | | | | | | | This causes deadlocks during early boot on hardware with broken/buggy APEI implementations, such as a Dell Poweredge 2950 with the latest currently available BIOS. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Don't use goto or another special error path, as handling the error case in normal flow is quite simple. Signed-off-by: Jan Beulich <jbeulich@suse.com> master commit: 0611689d9153227831979c7bafe594214b8505a3 master date: 2013-03-22 09:43:38 +0100
* ACPI/ERST: Name table in otherwise opaque error messagesAndrew Cooper2013-04-021-2/+2
| | | | | | | | | | Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Fix spelling and lower severities. Signed-off-by: Jan Beulich <jbeulich@suse.com> master commit: 759847e44401176401e86e7c55b644cb9f93c781 master date: 2013-03-20 10:02:52 +0100
* ACPI/APEI: fix ERST MOVE_DATA instruction implementationHuang Ying2013-04-021-4/+53
| | | | | | | | | | | | | | | | | | The src_base and dst_base fields in apei_exec_context are physical address, so they should be ioremaped before being used in ERST MOVE_DATA instruction. Reported-by: Javier Martinez Canillas <martinez.javier@gmail.com> Reported-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Huang Ying <ying.huang@intel.com> Replace use of ioremap() by __acpi_map_table()/set_fixmap(). Fix error handling. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> master commit: df2cf6a726b815fafa12e503c9a36707c3962f22 master date: 2012-10-17 14:12:06 +0200
* hvm: Clean up vlapic_reg_write() error propagation.Keir Fraser2013-04-021-12/+10
| | | | | | | | | In particular, correctly propagate errors through vlapic_apicv_write() and hvm_x2apic_msr_write(). Signed-off-by: Keir Fraser <keir@xen.org> master commit: 5082cc19524b6687ef1bc0a717538d75aae7cd00 master date: 2013-03-28 20:16:37 +0000
* x86: reserve pages when SandyBridge integrated graphicsXudong Hao2013-04-025-1/+49
| | | | | | | | | | | | | | | | | | SNB graphics devices have a bug that prevent them from accessing certain memory ranges, namely anything below 1M and in the pages listed in the table. Xen does not initialize below 1MB to heap, i.e. below 1MB pages don't be allocated, so it's unnecessary to reserve memory below the 1 MB mark that has not already been reserved. So reserve those pages listed in the table at xen boot if set detect a SNB gfx device on the CPU to avoid GPU hangs. Signed-off-by: Xudong Hao <xudong.hao@intel.com> Acked-by: Keir Fraser <keir@xen.org> master commit: db537fe3023bf157b85c8246782cb72a6f989b31 master date: 2013-03-26 14:22:07 +0100
* AMD IOMMU: allow disabling only interrupt remapping when certain IVRS ↵Jan Beulich2013-04-022-3/+7
| | | | | | | | | | | | | | | | | | | | | consistency checks fail After some more thought on the XSA-36 and specifically the comments we got regarding disabling the IOMMU in this situation altogether making things worse instead of better, I came to the conclusion that we can actually restrict the action in affected cases to just disabling interrupt remapping. That doesn't make the situation worse than prior to the XSA-36 fixes (where interrupt remapping didn't really protect domains from one another), but allows at least DMA isolation to still be utilized. To do so, disabling of interrupt remapping must be explicitly requested on the command line - respective checks will then be skipped. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Suravee Suthikulanit <suravee.suthikulpanit@amd.com> master changeset: 92b8bc03bd4b582cb524db51494d0dba7607e7ac master date: 2013-03-25 16:55:22 +0100
* VT-d: deal with 5500/5520/X58 errataMalcolm Crossley2013-04-022-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | http://www.intel.com/content/www/us/en/chipsets/5520-and-5500-chipset-ioh-specification-update.html Stepping B-3 has two errata (#47 and #53) related to Interrupt remapping, to which the workaround is for the BIOS to completely disable interrupt remapping. These errata are fixed in stepping C-2. Unfortunately this chipset stepping is very common and many BIOSes are not disabling interrupt remapping on this stepping . We can detect this in Xen and prevent Xen from using the problematic interrupt remapping feature. The Intel 5500/5520/X58 chipset does not support VT-d Extended Interrupt Mode(EIM). This means the iommu_supports_eim() check always fails and so x2apic mode cannot be enabled in Xen before this quirk disables the interrupt remapping feature. Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Gate the function call to check the quirk on interrupt remapping being requested to get enabled, and upon failure disable the IOMMU to be in line with what the changes for XSA-36 (plus follow-ups) did. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: "Zhang, Xiantao" <xiantao.zhang@intel.com> master changeset: 6890cebc6a987d0e896f5d23a8de11a3934101cf master date: 2013-03-25 14:31:27 +0100
* IOMMU: properly check whether interrupt remapping is enabledJan Beulich2013-04-024-4/+12
| | | | | | | | | | | | | | | | | | ... rather than the IOMMU as a whole. That in turn required to make sure iommu_intremap gets properly cleared when the respective initialization fails (or isn't being done at all). Along with making sure interrupt remapping doesn't get inconsistently enabled on some IOMMUs and not on others in the VT-d code, this in turn allowed quite a bit of cleanup on the VT-d side (removed from the backport). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: "Zhang, Xiantao" <xiantao.zhang@intel.com> master changeset: fae0372140befb88d890a30704a8ec058c902af8 master date: 2013-03-25 14:28:31 +0100
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-29 10:44:17 +0000