aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* x86: fix guest migration after c/s 20892:d311d1efc25eJan Beulich2011-07-161-1/+1
| | | | | | | | | | | | | | Guests would not manage to run successfully after being migrated to a host having sufficiently much more memory than the host they were originally started on. Subsequently the plan is to re-enable the changes behavior under the control of a guest kernel announced feature flag. Signed-off-by: Jan Beulich <jbeulich@novell.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> xen-unstable changeset: 23706:3dd399873c9e xen-unstable date: Sat Jul 16 09:18:21 2011 +0100
* xen/libxc: set CPUID topology leaf as unsupported for PV guestsDavid Vrabel2011-07-162-0/+2
| | | | | | | | | | | | | | | | | The result of a CPUID Extended Topology Enumeration leaf for PV guests is invalid as the level in ECX is ignored. This can cause some guests to loop endlessly when trying to enumerate the topology. Since the physical topology isn't useful to PV guests set the topology leaf as unsupported. Guests affected include Linux kernels prior 2.6.32 where a workaround was applied ("xen: mask extended topology info in cpu", 82d6469916c6fcfa345636a49004c9d1753905d1). Signed-off-by: David Vrabel <david.vrabel@citrix.com> xen-unstable changeset: 23700:867bb675b57b xen-unstable date: Sat Jul 16 09:05:45 2011 +0100
* x86/hvm: Don't expose CPUID time leaf when not using PVRDTSCPPaul Durrant2011-07-081-2/+10
| | | | | | | | | | | | Some versions of Oracle's Solaris PV drivers make a check that the maximal Xen hypervisor CPUID leaf is <= base leaf + 2 and refuse to work if this is not the case. The addition of the time leaf makes the maximal leaf == base leaf + 3 so this patch introduces a workaround that obscures the time leaf unless PVRDTSCP is in operation. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> xen-unstable changeset: 23661:8fe6f4be18aa xen-unstable date: Fri Jul 08 08:31:10 2011 +0100
* x86 cpu: Fix bug: unify cpu_dev attr as __cpuinitdataLiu, Jinsong2011-07-084-5/+5
| | | | | | | | | | | | Currently different x86 cpu define different attr for cpu_dev. Some cpu define as __initdata, this would be risk under cpu hotplug. This patch fix the bug, unify them as __cpuinitdata, as what AMD cpu define now. Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com> Shan, Haitao <haitao.shan@intel.com> xen-unstable changeset: 23659:7fe0331986c5 xen-unstable date: Fri Jul 08 08:30:41 2011 +0100
* x86: fix boot-time watchdog test.Tim Deegan2011-07-081-1/+11
| | | | | | | | | | | | Since the perf counter that the LAPIC NMI watchdog uses only runs while the core isn't halted, and all APs are idle at this point in the boot process, it's possible that remote CPUs won't see any NMIs during the 10-tick waiting period. Force all CPUs to busy-wait so we know the timers are running. Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com> xen-unstable changeset: 23612:6c7a23e08a04 xen-unstable date: Tue Jun 28 09:16:13 2011 +0100
* xen-detect: Fix cpuid asm for 32-bit PIC compilation.Keir Fraser2011-06-231-17/+20
| | | | | | Signed-off-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 23553:eca057e4475c xen-unstable date: Fri Jun 17 08:08:13 2011 +0100
* Protect xen/stdarg.h for multiple inclusion.Keir Fraser2011-06-231-0/+5
| | | | | | Signed-off-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 23549:a574bf2f5059 xen-unstable date: Thu Jun 16 16:14:51 2011 +0100
* x86_emulate: Fix decode of FUCOMIP %stN.Keir Fraser2011-06-151-1/+1
| | | | | | Signed-off-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 23546:d25f2c114ace xen-unstable date: Wed Jun 15 20:33:58 2011 +0100
* x86: Fix argument checking in (privileged) function cpu_add().Keir Fraser2011-06-151-2/+3
| | | | | | | | Thanks to John McDermott <john.mcdermott@nrl.navy.mil> for spotting. Signed-off-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 23505:5a557fda70a9 xen-unstable date: Fri Jun 10 08:08:44 2011 +0100
* Update Xen version to 4.0.3-rc1-preKeir Fraser2011-06-151-1/+1
|
* Added signature for changeset e7ec1f3ebed8Keir Fraser2011-06-141-0/+1
|
* Added tag RELEASE-4.0.2 for changeset e7ec1f3ebed8Keir Fraser2011-06-141-0/+1
|
* Update Xen version to 4.0.2RELEASE-4.0.2Keir Fraser2011-06-142-2/+2
|
* Added signature for changeset 4c39fa80900dKeir Fraser2011-06-031-0/+1
|
* Added tag 4.0.2-rc6 for changeset 4c39fa80900dKeir Fraser2011-06-031-0/+1
|
* Update Xen version to 4.0.2-rc64.0.2-rc6Keir Fraser2011-06-032-2/+2
|
* x86: Hide CPUID leaf 7 from PV guests.Keir Fraser2011-06-032-0/+2
| | | | | | Signed-off-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 23461:5839e797a130 xen-unstable date: Thu Jun 02 14:39:50 2011 +0100
* x86: Fix spurious_page_fault() for 1GB superpages.Keir Fraser2011-06-021-0/+2
| | | | | | | From: Xin Li <xin.li@intel.com> Signed-off-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 23441:4d28306d6e33 xen-unstable date: Tue May 31 13:57:45 2011 +0100
* IOMMU: Fail if intremap is not available and iommu=required/force.Ian Campbell2011-05-282-2/+6
| | | | | | | | | | | Rather than sprinkling panic()s throughout the setup code hoist the check up into common code. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Keir Fraser <keir@xen.org> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> xen-unstable changeset: 23402:f979a1a69fe3 xen-unstable date: Thu May 26 08:18:44 2011 +0100
* libxc: obtain correct length of p2m during core dumpingMarkus Gross2011-05-281-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | while implementing core dumping functionality for the libxl driver of libvirt, I discovered an issue with mapping pages of a pv guest. After dumping the core of a pv guest the domain was not cleared up properly and some pages were not unmapped. This issue is similar to the one reported here: http://lists.xensource.com/archives/html/xen-devel/2011-05/msg01314.html In xc_domain_dumpcore_via_callback in the file xc_core.c the function xc_core_arch_map_p2m is called to map P2M_FL_ENTRIES pages to the variable p2m. But to unmap the pages later, the dinfo->p2m_size has to be set accordingly. This was not done, instead a variable named p2m_size was set. This way P2M_FL_ENTRIES was always zero and the pages were left mapped. Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> xen-unstable changeset: 23374:8bd7b5e98f2a xen-unstable date: Tue May 24 15:00:16 2011 +0100
* libxc: after saving, unmap correct amount for live_m2pJim Fehlig2011-05-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With some help from Olaf, I've finally got to the bottom of an issue I came across while trying to implement save/restore in the libvirt libxenlight driver. After issuing the save operation, the saved domain was not being cleaned up properly and left in this state from xl's perspective xen33:# xl list Name ID Mem VCPUs State Time(s) Domain-0 0 6821 8 r----- 122.5 (null) 2 2 2 --pssd 10.8 Checking the libvirtd /proc/$pid/maps I found this 7f3798984000-7f3798b86000 r--s 00002000 00:03 4026532097 /proc/xen/privcmd So not all all pages belonging to the domain were unmapped from libvirtd. In tools/libxc/xc_domain_save.c we found that P2M_FL_ENTRIES were being mapped but only P2M_FLL_ENTRIES were being unmapped. The attached patch changes the unmapping to use the same P2M_FL_ENTRIES macro. I'm not too familiar with this code though so posting here for review. I suspect this was not noticed before since most (all?) processes doing save terminate after the save and are not long-running like libvirtd. Ian Campbell writes: > Looks like I introduced this in 18558:ccf0205255e1, sorry! > > I guess it is also wrong in the error path out of map_and_save_p2m_table > and so we also need [another hunk]. This change should be backported to relevant earlier trees. -iwj From: Jim Fehlig <jfehlig@novell.com> From: Ian Campbell <Ian.Campbell@citrix.com> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> Cc: Olaf Hering <olaf@aepfle.de> Acked-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> xen-unstable changeset: 23373:171007b4e2c4 xen-unstable date: Tue May 24 14:50:00 2011 +0100
* Added signature for changeset d4cefc444b74Keir Fraser2011-05-241-0/+1
|
* Added tag 4.0.2-rc5 for changeset d4cefc444b74Keir Fraser2011-05-241-0/+1
|
* Update Xen version to 4.0.2-rc54.0.2-rc5Keir Fraser2011-05-241-1/+1
|
* drivers/passthrough: fix error paths in pci_add_device*()Tim Deegan2011-05-241-2/+8
| | | | | | | | | | | | | | | | | | When a device can't be allocated to dom0 by the IOMMU, don't leave dom0 in the "domain" field. It causes pci_remove_device() to crash trying to remove the dev from the domain's list of devices (and was probably the wrong thing to do anyway). Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com> xen-unstable changeset: 23371:4326bcd88b33 xen-unstable date: Mon May 23 18:35:32 2011 +0100 drivers/passthrough: Revert 23352:ea48976517af -- incorrect bugfix. Signed-off-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 23370:2e6719425265 xen-unstable date: Mon May 23 18:35:04 2011 +0100
* Fix Config.mk's cc-option for -Wno-* options.Keir Fraser2011-05-241-2/+12
| | | | | | | | | | | | | | | | | | | | These disable-warning options are handled specially by GCC: (a) they are ignored unless the compiler emits a warning; and (b) even then they produce a warning rather than an error To handle this, modify the test invocation of GCC to compile a fragment of code that will always provoke a warning (integer assigned to pointer). This works around (a) above. Then, we grep the compiler's stdout/stderr for the option-under-test, the presence of which would indicate an "unrecognized command-line option" warning/error. This works around (b) above, letting us distinguish between the "integer assigned to pointer" and "unrecognized command-line option" warnings. Signed-off-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 23369:37c77bacb52a xen-unstable date: Mon May 23 17:38:28 2011 +0100
* Added signature for changeset 82f6fd38f5c2Keir Fraser2011-05-211-0/+1
|
* Added tag 4.0.2-rc4 for changeset 82f6fd38f5c2Keir Fraser2011-05-211-0/+1
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-02 15:00:54 +0000