aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* x86/mm: Don't lose track of the log dirty bitmapTim Deegan2012-03-071-1/+5
| | | | | | | | | | | | | hap_log_dirty_init unconditionally sets the top of the log dirty bitmap to INVALID_MFN. If there had been a bitmap allocated, it is then leaked, and the host crashes on an ASSERT when the domain is cleaned up. Signed-off-by: Tim Deegan <tim@xen.org> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org> Committed-by: Tim Deegan <tim@xen.org> xen-unstable changeset: 24282:a06cda9fb25f xen-unstable date: Thu Dec 01 14:17:16 2011 +0000
* x86: small fixes to pcpu platform op handlingJan Beulich2012-03-071-4/+15
| | | | | | | | | | | | | | | | | | | | XENPF_get_cpuinfo should init the flags output field rather than only modify it. XENPF_cpu_online must check for the input CPU number to be in range. XENPF_cpu_offline must also do that, and should also reject attempts to offline CPU 0 (this fails in cpu_down() too, but preventing this here appears more correct given that the code here calls continue_hypercall_on_cpu(0, ...), which would be flawed if cpu_down() would ever allow bringing down CPU 0 (and a distinct error code is easier to deal with when debugging issues). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 24201:9c6bea25f712 xen-unstable date: Thu Nov 24 17:56:26 2011 +0100
* Trivial fix for rc val in hap track dirty vramAndres Lagar-Cavilla2012-03-071-1/+1
| | | | | | | Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org> Committed-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 24193:67d2ac426def xen-unstable date: Thu Nov 24 15:44:51 2011 +0000
* x86/mm: change return code for log-dirty disablingAndres Lagar-Cavilla2012-03-071-0/+2
| | | | | | | | | | | Disabling log dirty mode in HAP always returns -EINVAL. Make it return the correct rc on success. Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org> Signed-off-by: Tim Deegan <tim@xen.org> Committed-by: Tim Deegan <tim@xen.org> xen-unstable changeset: 24190:6b3d8250ee2c xen-unstable date: Thu Nov 24 15:20:57 2011 +0000
* x86/vioapic: clear remote IRR when switching RTE to edge triggeredJan Beulich2012-03-071-2/+3
| | | | | | | | | | | | | | mode Xen itself (as much as Linux) relies on this behavior, so it should also emulate it properly. Not doing so reportedly gets in the way of kexec inside a HVM guest. Signed-off-by: Jan Beulich <jbeulich@suse.com> Tested-by: Olaf Hering <olaf@aepfle.de> xen-unstable changeset: 24168:9c350ab8d3ea xen-unstable date: Mon Nov 21 09:29:31 2011 +0100 Committed-by: Keir Fraser <keir@xen.org>
* x86/IO-APIC: refine EOI-ing of migrating level interruptsJan Beulich2012-03-071-63/+5
| | | | | | | | | | | | | | Rather than going through all IO-APICs and calling io_apic_eoi_vector() for the vector in question, just use eoi_IO_APIC_irq(). This in turn allows to eliminate quite a bit of other code. Signed-off-by: Jan Beulich <jbeulich@suse.com> Tested-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> xen-unstable changeset: 24155:0d50e704834f xen-unstable date: Fri Nov 18 09:18:41 2011 +0100
* xen: add missing unlock from gnttab_get_versionIan Campbell2012-02-231-0/+2
| | | | | | | | Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Reported-by: Francisco Rocha <f.e.liberal-rocha@newcastle.ac.uk> Committed-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 24871:66cc5b67e749 xen-unstable date: Thu Feb 23 09:59:35 2012 +0000
* gnttab: miscellaneous fixesJan Beulich2012-02-233-8/+25
| | | | | | | | | | | | | - _GTF_* constants name bit positions, so binary arithmetic on them is wrong - gnttab_clear_flag() cannot (on x86 and ia64 at least) simply use clear_bit(), as that may access more than the two bytes that are intended to be accessed Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 24742:9fc810bb8145 xen-unstable date: Thu Feb 09 16:39:16 2012 +0100
* Update QEMU_TAG, for CVE-2012-0029Ian Jackson2012-02-021-4/+3
|
* vesa: flush lfb after zeroingAndrew Cooper2012-01-311-18/+19
| | | | | | | | | | | | | | | | | | | If Xen is going to relinquish the VGA console, flush the linear frame buffer after zeroing it in vesa_endboot(). Failing to do so in some circumstances leads to the actual linear framebuffer on the graphics card still containing the output of the Xen boot console can lead to ugly graphics output when dom0 is setting up the graphics card for its own use. While the patch is quite large, it is mostly just code motion to prevent having to forward declare lfb_flush(). The only functional change to vesa_endboot() is to insert a call to lbf_flush(). Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Committed-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 24615:ac9f32525376 xen-unstable date: Sat Jan 28 13:42:25 2012 +0000
* Console: introduce console=none command line parameterAndrew Cooper2012-01-311-0/+2
| | | | | | | | | | | | | | | | | | | | Currenty, not specifying 'console=<foo>' on the command line causes Xen to default to 'vga'. Alternativly, the user can explicitly specifiy 'console=vga|com1|com2'. However, there is no way to specify that neither vga nor serial should be used. Specifying 'console=' does have the effect that neither vga nor serial is set up, but at the cost of an "Bad console= option ''" warning. Therefore, expliticly support a 'console=none' option which does not set up vga and does not set up serial, but does not trigger the bad console warning. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Committed-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 24614:f8c2cf24a26c xen-unstable date: Sat Jan 28 13:41:42 2012 +0000
* VMX: print Pause Loop Exiting disabled message just onceJan Beulich2012-01-171-1/+2
| | | | | | | | | ... rather than per booting CPU. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 24465:5b2676ac1321 xen-unstable date: Mon Jan 09 16:01:44 2012 +0100
* x86: emulate lea with two register operands correctlyDavid Vrabel2012-01-171-0/+1
| | | | | | | | | | | | | | An lea instruction with two register operands should raise an undefined instruction exception. Skype does such a instruction and will crash when starting if it does not get the exception. Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: Keir Fraser <keir@xen.org> Committed-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 24456:03781de56c31 xen-unstable date: Thu Jan 05 15:47:16 2012 +0000
* x86/vIRQ: IRR and TMR race condition bug fixYongan Liu2012-01-171-4/+1
| | | | | | | | | | | | | | | | | In vlapic_set_irq, we set the IRR register before the TMR. And the IRR might be serviced before setting TMR, and even worse EOI might occur before TMR setting, in which case the vioapic_update_EOI won't be called, and further prevent all the subsequent interrupt injecting. Reorder setting the TMR and IRR will solve the problem. Besides, KVM has fixed a similar bug in: http://markmail.org/search/?q=APIC_TMR#query:APIC_TMR+page:1+mid:rphs4f7lkxjlldne+state:results Signed-off-by: Yongan Liu<Liuyongan@huawei.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Committed-by: Jan Beulich <jbeulich@suse.com> xen-unstable changeset: 24453:02b92d035f64 xen-unstable date: Thu Jan 05 09:29:59 2012 +0100
* x86/ucode: fix for AMD Fam15 CPUsChristoph Egger2012-01-152-46/+62
| | | | | | | | | | | Remove hardcoded maximum size a microcode patch can have. This is dynamic now. The microcode patch for family15h can be larger than 2048 bytes and gets silently truncated. Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> Backport from xen-unstable changeset 24411:ca5f588bd203 to Xen 4.0
* Allow VMs to query their own grant table version.Paul Durrant2011-12-182-8/+7
| | | | | | | Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Committed-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 24427:931bf1105730 xen-unstable date: Sun Dec 18 14:38:32 2011 +0000
* x86/AMD: use correct shift count when merging model and steppingJan Beulich2011-12-181-1/+1
| | | | | | | | | | ... for legacy errata matching. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 24412:99caac2e35df xen-unstable date: Thu Dec 15 14:28:45 2011 +0100 Committed-by: Keir Fraser <keir@xen.org>
* tools/libxc: Fix x86_32 build breakage in previous changeset.Keir Fraser2011-12-062-15/+18
| | | | | | | | | | | | | | | | | | | Signed-off-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 24345:491c3ebf1d37 xen-unstable date: Fri Dec 02 08:40:02 2011 -0800 tools/x86_64: Fix cpuid() inline asm to not clobber stack's red zone Pushing stuff onto the stack on x86-64 when we do not specify -mno-red-zone is unsafe. Since the complicated asm is due to register pressure on i386, we simply implement an all-new simpler alternative for x86-64. Signed-off-by: Keir Fraser <keir@xen.org> Acked-by: Jan Beulich <jbeulich@novell.com> xen-unstable changeset: 24344:72f4e4cb7440 xen-unstable date: Fri Dec 02 06:31:14 2011 -0800
* [shadow] Disable higher level pagetables early unshadow only when the ↵Gianluca Guida2011-11-161-2/+3
| | | | | | | | | | | | "process dying" hypercall is used. This patch fixes a performance problem in fully virtualized guests. Signed-off-by: Gianluca Guida <gianluca.guida@citrix.com> Tested-by: Jan Beulich <jbeulich@suse.com> Committed-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 24148:3ecc8fef4281 xen-unstable date: Wed Nov 16 15:19:33 2011 +0000
* x86/amd: Eliminate cache flushing when entering C3 on select AMD processorsMark Langsdorf2011-11-121-1/+2
| | | | | | | | | | | | AMD Fam15h processors have a shared cache. It does not need= to be be flushed when entering C3 and doing so causes reduces performance. Modify acpi_processor_power_init_bm_check to prevent these processors from flushing when entering C3. Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com> xen-unstable changeset: 23511:450f1d198e1e xen-unstable date: Tue Jun 14 12:46:29 2011 +0100 Committed-by: Keir Fraser <keir@xen.org>
* amd xsave: Move xsave initialization code to a common placeWei Huang2011-10-252-9/+10
| | | | | | | | | | | | This patch moves xsave/xrstor code to CPU common file. First of all, it prepares xsave/xrstor support for AMD CPUs. Secondly, Xen would crash on __context_switch() without this patch on xsave-capable AMD CPUs. The crash was due to cpu_has_xsave reports true in domain.c while xsave space wasn't initialized. Signed-off-by: Wei Huang <wei.huang2@amd.com> xen-unstable changeset: 22462:98eb4a334b77 xen-unstable date: Tue Dec 07 18:26:38 2010 +0000
* Revert xen-unstable:23871:503ee256fecfKeir Fraser2011-10-241-1/+5
| | | | Signed-off-by: Keir Fraser <keir@xen.org>
* Update Xen version to 4.0.4-rc1-preKeir Fraser2011-10-241-1/+1
|
* Added signature for changeset 00b5807c08f2Keir Fraser2011-10-201-0/+1
|
* Added tag RELEASE-4.0.3 for changeset 00b5807c08f2Keir Fraser2011-10-201-0/+1
|
* Update Xen version to 4.0.3RELEASE-4.0.3Keir Fraser2011-10-202-2/+2
|
* Added signature for changeset fd7c4d4e52d9Keir Fraser2011-10-071-0/+1
|
* Added tag 4.0.3-rc3 for changeset fd7c4d4e52d9Keir Fraser2011-10-071-0/+1
|
* Update Xen version to 4.0.3-rc34.0.3-rc3Keir Fraser2011-10-072-2/+2
|
* build: fix grep invocation in cc-optionsIan Campbell2011-10-031-1/+1
| | | | | | | | | | | | | | | | Currently the build produces lots of Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. This is due to the "grep -- $(2)" in cc-options. It seems that the default of reading stdin is disabled when using "--". I don't know if this is a bug in grep or how it is supposed to be but we can work around it by explicitly passing in "-" Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Committed-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 23898:3d1664cc9e45 xen-unstable date: Fri Sep 30 21:17:47 2011 +0100
* x86: ucode-amd: Don't warn when no ucode is available for a CPUJan Beulich2011-10-031-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | revision This patch originally comes from the Linus mainline kernel (2.6.33), find below the patch details: From: Andreas Herrmann <herrmann.der.user@googlemail.com> There is no point in warning when there is no ucode available for a specific CPU revision. Currently the container-file, which provides the AMD ucode patches for OS load, contains only a few ucode patches. It's already clearly indicated by the printed patch_level whenever new ucode was available and an update happened. So the warning message is of no help but rather annoying on systems with many CPUs. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Jan Beulich <jbeulich@suse.com> xen-unstable changeset: 23871:503ee256fecf xen-unstable date: Thu Sep 22 18:35:30 2011 +0100
* VT-d: fix off-by-one error in RMRR validationJan Beulich2011-10-031-1/+1
| | | | | | | | | | | | (base_addr,end_addr) is an inclusive range, and hence there shouldn't be a subtraction of 1 in the second invocation of page_is_ram_type(). For RMRRs covering a single page that actually resulted in the immediately preceding page to get checked (which could have resulted in a false warning). Signed-off-by: Jan Beulich <jbeulich@suse.com> xen-unstable changeset: 23868:28147fd781af xen-unstable date: Thu Sep 22 18:32:34 2011 +0100
* Clear IRQ_GUEST in irq_desc->status when setting action to NULL.Igor Mammedov2011-10-031-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Looking more closely at usage of action field with relation to IRQ_GUEST flag. It appears that set IRQ_GUEST implies that action is not NULL. As result it is not safe to set action to NULL and leave IRQ_GUEST set. Hence IRQ_GUEST should be cleared in dynamic_irq_cleanup where action is set to NULL. An addition remove BUGON at __pirq_guest_unbind that appears to be bogus and not needed anymore. Thanks Paolo Bonzini for NACKing previous patch, and pointing at the correct solution. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reinstate the BUG_ON, but after the action==NULL check. Since we then go and start interpreting action as an irq_guest_action_t, the BUG_ON is relevant here. More generally, the brute-force nature of dynamic_irq_cleanup() looks a bit worrying. Possibly there should be more integratioin with pirq_guest_unbind() logic, for cleaning up un-acked EOIs and the like. Signed-off-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 23852:c944e82bb092 xen-unstable date: Sun Sep 18 00:00:26 2011 +0100
* x86/vmx: don't call __vmxoff() blindlyJan Beulich2011-10-031-0/+6
| | | | | | | | | | | | | If vmx_vcpu_up() failed, __vmxon() would generally not have got (successfully) executed, and in that case __vmxoff() will #UD. Additionally, any panic() during early resume (namely the tboot related one) would cause vmx_cpu_down() to get executed without vmx_cpu_up() having run before. Signed-off-by: Jan Beulich <jbeulich@suse.com> xen-unstable changeset: 23848:cf37d2eec2ef xen-unstable date: Sat Sep 17 16:26:37 2011 +0100
* bitmap_scnlistprintf() should always zero-terminate its output bufferJan Beulich2011-09-131-3/+4
| | | | | | | | | | | | ... as long as it has non-zero size. So far this would not happen if the passed in CPU mask was empty. Also fix the comment describing the return value to actually match reality. Signed-off-by: Jan Beulich <jbeulich@suse.com> xen-unstable changeset: 23820:ba75234a6f56 xen-unstable date: Wed Sep 07 10:36:55 2011 +0100
* IRQ: IO-APIC support End Of Interrupt for older IO-APICsAndrew Cooper2011-09-132-7/+109
| | | | | | | | | | | | | | | | | The old io_apic_eoi() function using the EOI register only works for IO-APICs with a version of 0x20. Older IO-APICs do not have an EOI register so line level interrupts have to be EOI'd by flipping the mode to edge and back, which clears the IRR and Delivery Status bits. This patch replaces the current io_apic_eoi() function with one which takes into account the version of the IO-APIC and EOI's appropriately. v2: make recursive call to __io_apic_eoi() to reduce code size. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> xen-unstable changeset: 23833:ffe8e65f6687 xen-unstable date: Tue Sep 13 10:33:10 2011 +0100
* Passthrough: disable bus-mastering on any card that causes an IOMMU fault.Tim Deegan2011-09-082-2/+22
| | | | | | | | | | | This stops the card from raising back-to-back faults and live-locking the CPU that handles them. Signed-off-by: Tim Deegan <tim@xen.org> Acked-by: Wei Wang2 <wei.wang2@amd.com> Acked-by: Allen M Kay <allen.m.kay@intel.com> xen-unstable changeset: 23762:537ed3b74b3f xen-unstable date: Fri Aug 12 11:29:24 2011 +0100
* Update Xen version to 4.0.3-rc3-preKeir Fraser2011-09-081-1/+1
|
* Added signature for changeset 8d012bc20d30Keir Fraser2011-09-071-0/+1
|
* Added tag 4.0.3-rc2 for changeset 8d012bc20d30Keir Fraser2011-09-071-0/+1
|
* Update Xen version to 4.0.3-rc24.0.3-rc2Keir Fraser2011-09-071-1/+1
|
* IRQ: manually EOI migrating line interruptsAndrew Cooper2011-08-318-19/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When migrating IO-APIC line level interrupts between PCPUs, the migration code rewrites the IO-APIC entry to point to the new CPU/Vector before EOI'ing it. The EOI process says that EOI'ing the Local APIC will cause a broadcast with the vector number, which the IO-APIC must listen to to clear the IRR and Status bits. In the case of migrating, the IO-APIC has already been reprogrammed so the EOI broadcast with the old vector fails to match the new vector, leaving the IO-APIC with an outstanding vector, preventing any more use of that line interrupt. This causes a lockup especially when your root device is using PCI INTA (megaraid_sas driver *ehem*) However, the problem is mostly hidden because send_cleanup_vector() causes a cleanup of all moving vectors on the current PCPU in such a way which does not cause the problem, and if the problem has occured, the writes it makes to the IO-APIC clears the IRR and Status bits which unlocks the problem. This fix is distinctly a temporary hack, waiting on a cleanup of the irq code. It checks for the edge case where we have moved the irq, and manually EOI's the old vector with the IO-APIC which correctly clears the IRR and Status bits. Also, it protects the code which updates irq_cfg by disabling interrupts. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> xen-unstable changeset: 23805:7048810180de xen-unstable date: Wed Aug 31 15:19:24 2011 +0100
* Update Xen version to 4.0.3-rc2-preKeir Fraser2011-08-251-1/+1
|
* Added signature for changeset 47f9c9648fe7Keir Fraser2011-08-251-0/+1
|
* Added tag 4.0.3-rc1 for changeset 47f9c9648fe7Keir Fraser2011-08-251-0/+1
|
* Update Xen version to 4.0.3-rc14.0.3-rc1Keir Fraser2011-08-252-2/+2
|
* VT-d: always clean up dpci timers.Tim Deegan2011-08-161-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If a VM has all its PCI devices deassigned, need_iommu(d) becomes false but it might still have DPCI EOI timers that were init_timer()d but not yet kill_timer()d. That causes xen to crash later because the linked list of inactive timers gets corrupted, e.g.: (XEN) Xen call trace: (XEN) [<ffff82c480126256>] set_timer+0x1c2/0x24f (XEN) [<ffff82c48011fbf8>] schedule+0x129/0x5dd (XEN) [<ffff82c480122c1e>] __do_softirq+0x7e/0x89 (XEN) [<ffff82c480122c9d>] do_softirq+0x26/0x28 (XEN) [<ffff82c480153c85>] idle_loop+0x5a/0x5c (XEN) (XEN) (XEN) **************************************** (XEN) Panic on CPU 0: (XEN) Assertion 'entry->next->prev == entry' failed at /local/scratch/tdeegan/xen-unstable.hg/xen/include:172 (XEN) **************************************** The following patch makes sure that the domain destruction path always clears up the DPCI state even if !needs_iommu(d). Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com> xen-unstable changeset: 23746:aa54b8175954 xen-unstable date: Mon Jul 25 16:41:33 2011 +0100
* x86: Replace missing return stmt accidentally removed by 21513:649372e3d46aKeir Fraser2011-07-271-0/+1
| | | | Signed-off-by: Keir Fraser <keir@xen.org>
* hvmloader: Switch to absolute addressing for calling hypercall stubs.Keir Fraser2011-07-204-266/+268
| | | | | | | | | | | | | | | | | | This is clearer and less fragile than trying to make relative calls work. In particular, the old approach failed if _start was not == HVMLOADER_PHYSICAL_ADDRESS. This was the case for some modern toolchains which reorder functions. Signed-off-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 23730:dd5eecf739d1 xen-unstable date: Wed Jul 20 15:02:16 2011 +0100 hvmloader: Remove hard tabs from source files. Signed-off-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 23729:4f1109af9c63 xen-unstable date: Wed Jul 20 14:52:16 2011 +0100
* tools/hotplug/Linux: start all xen daemons in runlevel 2Fabio Fantoni2011-07-183-6/+6
| | | | | | | | Backported from xen-4.1-testing.hg 23086:9b5fbd8ff152 -iwj. Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-01 15:02:14 +0000