aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* fix compat memory exchange op splittingJan Beulich2013-03-121-1/+1
| | | | | | | | | | | A shift with a negative count was erroneously used here, yielding undefined behavior. Reported-by: Xi Wang <xi@mit.edu> Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> master changeset: 53decd322157e922cac2988e07da6d39538c8033 master date: 2013-03-01 16:59:49 +0100
* Avoid stale pointer when moving domain to another cpupoolJuergen Gross2013-03-121-9/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a domain is moved to another cpupool the scheduler private data pointers in vcpu and domain structures must never point to an already freed memory area. While at it, simplify sched_init_vcpu() by using DOM2OP instead VCPU2OP. Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com> This also required commit dbfa7bba0f213b1802e1900b71bc34837c30ee52: xen, cpupools: Fix cpupool-move to make more consistent The full order for creating new private data structures when moving from one pool to another is now: * Allocate all new structures - Allocate a new private domain structure (but don't point there yet) - Allocate per-vcpu data structures (but don't point there yet) * Remove old structures - Remove each vcpu, freeing the associated data structure - Free the domain data structure * Switch to the new structures - Set the domain to the new cpupool, with the new private domain structure - Set each vcpu to the respective new structure, and insert This is in line with a (fairly reasonable) assumption in credit2 that the private structure of the domain will be the private structure pointed to by the per-vcpu private structure. Also fix a bug, in which insert_vcpu was called with the *old* vcpu ops rather than the new ones. Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com> master changeset: 482300def7d08e773ccd2a0d978bcb9469fdd810 master date: 2013-02-28 14:56:45 +0000
* vmx: fix handling of NMI VMEXIT.Tim Deegan2013-03-124-2/+35
| | | | | | | | | | | | | | | | | | Call do_nmi() directly and explicitly re-enable NMIs rather than raising an NMI through the APIC. Since NMIs are disabled after the VMEXIT, the raised NMI would be blocked until the next IRET instruction (i.e. the next real interrupt, or after scheduling a PV guest) and in the meantime the guest will spin taking NMI VMEXITS. Also, handle NMIs before re-enabling interrupts, since if we handle an interrupt (and therefore IRET) before calling do_nmi(), we may end up running the NMI handler with NMIs enabled. Signed-off-by: Tim Deegan <tim@xen.org> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> master changeset: 7dd3b06ff031c9a8c727df16c5def2afb382101c master date: 2013-02-28 14:00:18 +0000
* x86: fix CMCI injectionJan Beulich2013-03-084-10/+12
| | | | | | | | | | | | | | | | | | This fixes the wrong use of literal vector 0xF7 with an "int" instruction (invalidated by 25113:14609be41f36) and the fact that doing the injection via a software interrupt was never valid anyway (because cmci_interrupt() acks the LAPIC, which does the wrong thing if the interrupt didn't get delivered though it). In order to do latter, the patch introduces send_IPI_self(), at once removing two opend coded uses of "genapic" in the IRQ handling code. Reported-by: Yongjie Ren <yongjie.ren@intel.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Tested-by: Yongjie Ren <yongjie.ren@intel.com> Acked-by: Keir Fraser <keir@xen.org> master changeset: 2f8c55ccefe49bb526df0eaf5fa9b7b788422208 master date: 2013-02-26 10:15:56 +0100
* IOMMU, AMD Family15h Model10-1Fh erratum 746 WorkaroundSuravee Suthikulpanit2013-03-081-0/+38
| | | | | | | | | | | | | | | | | The IOMMU may stop processing page translations due to a perceived lack of credits for writing upstream peripheral page service request (PPR) or event logs. If the L2B miscellaneous clock gating feature is enabled the IOMMU does not properly register credits after the log request has completed, leading to a potential system hang. BIOSes are supposed to disable L2B micellaneous clock gating by setting L2_L2B_CK_GATE_CONTROL[CKGateL2BMiscDisable](D0F2xF4_x90[2]) = 1b. This patch corrects that for those which do not enable this workaround. Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> master changeset: 0f8adcb2a7183bea5063f6fffba7d7e1aa14fc84 master date: 2013-02-26 10:14:53 +0100
* x86: fix null pointer dereference in intel_get_extended_msrs()Xi Wang2013-03-081-1/+1
| | | | | | | | | `memset(&mc_ext, 0, ...)' leads to a buffer overflow and a subsequent null pointer dereference. Replace `&mc_ext' with `mc_ext'. Signed-off-by: Xi Wang <xi@mit.edu> master changeset: c40e24a8ef74f9d0ee59dd9b8ca890be08b0b874 master date: 2013-02-25 12:44:25 +0100
* x86/setup: don't relocate the VGA hole.Tim Deegan2013-03-081-5/+3
| | | | | | | | | | | | | | Copying the contents of the VGA hole is at best pointless and at worst dangerous. Booting Xen on Xen, it causes a very long delay as each byte is referred to qemu. Since we were already discarding the first 1MB of the relocated area, just avoid copying it in the first place. Reported-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com> Signed-off-by: Tim Deegan <tim@xen.org> master changeset: 0b76ce20de85ad7c23c47ee3275020859b91d46b master date: 2013-02-14 12:20:58 +0000
* Add .gitignoreIan Jackson2013-02-281-0/+394
| | | | | | | Copy .gitignore from staging-4.2 current tip (ie from 3f5e3cd97398468d624cf907979c2bb12ff7ee7e). Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
* tools: Fix memset(&p,0,sizeof(p)) idiom in several places.Michael Young2013-02-285-5/+5
| | | | | | | | | | gcc 4.8 identifies several places where code of the form memset(x, 0, sizeof(x)); is used incorrectly, meaning that less memory is set to zero than required. Signed-off-by: Michael Young <m.a.young@durham.ac.uk> Committed-by: Keir Fraser <keir@xen.org> (cherry picked from commit d119301b5816b39b5ba722a2f8b301b37e8e34bd)
* libxl: Fix uninitialized variable in libxl_create_stubdomMarek Marczykowski2013-02-261-1/+1
| | | | | | | | | | | | It is used for result domid from libxl__domain_make, but actually this function have assert on an initial value. This patch is intended for xen-4.1 only - 4.2 and later have reworked this part of code already containing the fix. Signed-off-by: Marek Marczykowski <marmarek@invisiblethingslab.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
* AMD IOMMU: don't BUG() when we don't have toJan Beulich2013-02-221-2/+1
| | | | | | | | | find_iommu_for_device() can easily return NULL instead, as all of its callers are prepared for that. Signed-off-by: Jan Beulich <jbeulich@suse.com> master changeset: f547d42ec0306cdceffb8f7603c7e6f8977cf398 master date: 2013-02-18 09:37:35 +0100
* xenoprof: avoid division by 0Tim Deegan2013-02-221-4/+7
| | | | | | | | Signed-off-by: Tim Deegan <tim@xen.org> Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> master changeset: 085f1f2d3aee1a35dfc7ca2f4423e51fa654010c master date: 2013-02-15 09:42:02 +0100
* gcc4.8 build fix: Add -Wno-unused-local-typedefs to CFLAGS.Keir Fraser2013-02-221-0/+1
| | | | | | | | Based on a patch by M A Young <m.a.young@durham.ac.uk> Signed-off-by: Keir Fraser <keir@xen.org> master changeset: 511278b4e239df00de7b33f7b42d8d5d7e52221b master date: 2013-02-13 17:03:31 +0000
* xen: sched_credit: improve picking up the idle CPU for a VCPUDario Faggioli2013-02-151-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In _csched_cpu_pick() we try to select the best possible CPU for running a VCPU, considering the characteristics of the underlying hardware (i.e., how many threads, core, sockets, and how busy they are). What we want is "the idle execution vehicle with the most idling neighbours in its grouping". In order to achieve it, we select a CPU from the VCPU's affinity, giving preference to its current processor if possible, as the basis for the comparison with all the other CPUs. Problem is, to discount the VCPU itself when computing this "idleness" (in an attempt to be fair wrt its current processor), we arbitrarily and unconditionally consider that selected CPU as idle, even when it is not the case, for instance: 1. If the CPU is not the one where the VCPU is running (perhaps due to the affinity being changed); 2. The CPU is where the VCPU is running, but it has other VCPUs in its runq, so it won't go idle even if the VCPU in question goes. This is exemplified in the trace below: ] 3.466115364 x|------|------| d10v1 22005(2:2:5) 3 [ a 1 8 ] ... ... ... 3.466122856 x|------|------| d10v1 runstate_change d10v1 running->offline 3.466123046 x|------|------| d?v? runstate_change d32767v0 runnable->running ... ... ... ] 3.466126887 x|------|------| d32767v0 28004(2:8:4) 3 [ a 1 8 ] 22005(...) line (the first line) means _csched_cpu_pick() was called on VCPU 1 of domain 10, while it is running on CPU 0, and it choose CPU 8, which is busy ('|'), even if there are plenty of idle CPUs. That is because, as a consequence of changing the VCPU affinity, CPU 8 was chosen as the basis for the comparison, and therefore considered idle (its bit gets unconditionally set in the bitmask representing the idle CPUs). 28004(...) line means the VCPU is woken up and queued on CPU 8's runq, where it waits for a context switch or a migration, in order to be able to execute. This change fixes things by only considering the "guessed" CPU idle if the VCPU in question is both running there and is its only runnable VCPU. Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Acked-by: George Dunlap <george.dunlap@citrix.com> xen-unstable changeset: 26287:127c2c47d440 xen-unstable date: Tue Dec 18 18:10:18 UTC 2012
* AMD IOMMU: also spot missing IO-APIC entries in IVRS tableJan Beulich2013-02-151-14/+37
| | | | | | | | | | | | | | | | | | | | Apart from dealing duplicate conflicting entries, we also have to handle firmware omitting IO-APIC entries in IVRS altogether. Not doing so has resulted in c/s 26517:601139e2b0db to crash such systems during boot (whereas with the change here the IOMMU gets disabled just as is being done in the other cases, i.e. unless global tables are being used). Debugging this issue has also pointed out that the debug log output is pretty ugly to look at - consolidate the output, and add one extra item for the IVHD special entries, so that future issues are easier to analyze. Signed-off-by: Jan Beulich <jbeulich@suse.com> Tested-by: Sander Eikelenboom <linux@eikelenboom.it> Acked-by: Ian Campbell <ian.campbell@citrix.com> xen-unstable changeset: 26531:e68f14b9e739 xen-unstable date: Thu Feb 14 08:40:52 UTC 2013
* tools/ocaml: oxenstored: correctly handle a full ring.Ian Campbell2013-02-151-2/+2
| | | | | | | | | | | | | | | Change 26521:2c0fd406f02c (part of XSA-38 / CVE-2013-0215) incorrectly caused us to ignore rather than process a completely full ring. Check if producer and consumer are equal before masking to avoid this, since prod == cons + PAGE_SIZE after masking becomes prod == cons. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Keir Fraser <keir@xen.org> Committed-by: Ian Campbell <ian.campbell@citrix.com> xen-unstable changeset: 26539:759574df84a6 Backport-requested-by: security@xen.org Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
* unmodified_drivers: __devinit was removed in linux-3.8Olaf Hering2013-02-141-1/+10
| | | | | | | | | | Signed-off-by: Olaf Hering <olaf@aepfle.de> Merge with __init handling. Signed-off-by: Jan Beulich <jbeulich@suse.com> xen-unstable changeset: 26526:a37aa55c3cbc xen-unstable date: Tue Feb 12 10:29:51 UTC 2013
* x86: restore (optional) forwarding of PCI SERR induced NMI to Dom0Jan Beulich2013-02-122-3/+20
| | | | | | | | | | | | | | | | | | c/s 22949:54fe1011f86b removed the forwarding of NMIs to Dom0 when they were caused by PCI SERR. NMI buttons as well as BMCs (like HP's iLO) may however want such events to be seen in Dom0 (e.g. to trigger a dump). Therefore restore most of the functionality which named c/s removed (adjusted for subsequent changes, and adjusting the public interface to use the modern term, retaining the old one for backwards compatibility). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 26440:5af4f2ab06f3 xen-unstable date: Tue Jan 22 08:33:10 UTC 2013
* x86/AMD: Enable WC+ memory type on family 10 processorsBoris Ostrovsky2013-02-122-2/+16
| | | | | | | | | | | In some cases BIOS may not enable WC+ memory type on family 10 processors, instead converting what would be WC+ memory to CD type. On guests using nested pages this could result in performance degradation. This patch enables WC+. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com> xen-unstable changeset: 26427:8f6dd5dc5d6c xen-unstable date: Fri Jan 18 11:20:58 UTC 2013
* oxenstored: Enforce a maximum message size of 4096 bytesIan Jackson2013-02-071-0/+8
| | | | | | | | | | | | | | | | | | | | | | The maximum size of a message is part of the protocol spec in xen/include/public/io/xs_wire.h Before this patch a client which sends an overly large message can cause a buffer read overrun. Note if a badly-behaved client sends a very large message then it will be difficult for them to make their connection work again-- they will probably need to reboot. This is a security issue, part of XSA-38 / CVE-2013-0215. Signed-off-by: David Scott <dave.scott@eu.citrix.com> Acked-by: Ian Campbell <Ian.Campbell@citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> xen-unstable changeset: 26522:ffd30e7388ad Backport-requested-by: security@xen.org Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
* tools/ocaml: oxenstored: Be more paranoid about ring readingIan Jackson2013-02-071-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | oxenstored makes use of the OCaml Xenbus bindings, in which the function xs_ring_read in tools/ocaml/libs/xb/xs_ring_stubs.c is used to read from the shared memory Xenstore ring. This function does not correctly handle all possible (prod, cons) states when MASK_XENSTORE_IDX(prod) > MASK_XENSTORE_IDX(cons). The root cause is the use of the unmasked values of prod and cons to calculate to_read. If prod is set to an out-of-range value, the ring peer can cause to_read to be too large or even negative. This allows the ring peer to force oxenstored to read and write out of range for the buffers leading to a crash or possibly to privilege escalation. Correct this by masking the values of cons and prod at the start, so we only deal with masked values. This makes the logic simpler, as semantically inappropriate values of the upper bits of the ring pointers are simply ignored. The same vulnerability does not exist in the ring writer because the only use made of the unmasked value is the check which prevents the prod pointer overtaking the cons pointer. A ring peer which defeats this check will suffer only lost data. However, additionally, precautions need to be taken to ensure that req_cons and req_prod are only read once in each function. Without the use of volatile or some asm construct, the compiler can "prove" that req_cons and req_prod do not change unexpectedly and is permitted to "amplify" the read of (say) req_cons into two reads at different times, giving two different values for use as cons, and then use the two sources of cons interchangeably. (The use of xen_mb() does not forbid this.) Therefore do the reads of req_cons and req_prod through a volatile pointer in both xs_ring_read and xs_ring_write. This is currently believed to be a theoretical vulnerability as we are not aware of any compilers which amplify reads in this way. This is a security issue, part of XSA-38 / CVE-2013-0215. Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> Tested-by: Matthew Daley <mattjd@gmail.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> xen-unstable changeset: 26521:2c0fd406f02c Backport-requested-by: security@xen.org Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
* AMD,IOMMU: Make per-device interrupt remapping table defaultBoris Ostrovsky2013-02-053-4/+5
| | | | | | | | | | | | | | | Using global interrupt remapping table may be insecure, as described by XSA-36. This patch makes per-device mode default. This is XSA-36 / CVE-2013-0153. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com> Moved warning in amd_iov_detect() to location covering all cases. Signed-off-by: Jan Beulich <jbeulich@suse.com> xen-unstable changeset: 26519:1af531e7bc2f xen-unstable date: Tue Feb 5 14:22:11 UTC 2013
* AMD,IOMMU: Disable IOMMU if SATA Combined mode is onBoris Ostrovsky2013-02-051-0/+33
| | | | | | | | | | | | | | | | | | | | | | | AMD's SP5100 chipset can be placed into SATA Combined mode that may cause prevent dom0 from booting when IOMMU is enabled and per-device interrupt remapping table is used. While SP5100 erratum 28 requires BIOSes to disable this mode, some may still use it. This patch checks whether this mode is on and, if per-device table is in use, disables IOMMU. This is XSA-36 / CVE-2013-0153. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com> Flipped operands of && in amd_iommu_init() to make the message issued by amd_sp5100_erratum28() match reality (when amd_iommu_perdev_intremap is zero, there's really no point in calling the function). Signed-off-by: Jan Beulich <jbeulich@suse.com> xen-unstable changeset: 26518:e379a23b0465 xen-unstable date: Tue Feb 5 14:21:25 UTC 2013
* AMD,IOMMU: Clean up old entries in remapping tables when creating new oneJan Beulich2013-02-053-10/+93
| | | | | | | | | | | | | | | | | | | When changing the affinity of an IRQ associated with a passed through PCI device, clear previous mapping. This is XSA-36 / CVE-2013-0153. Signed-off-by: Jan Beulich <jbeulich@suse.com> In addition, because some BIOSes may incorrectly program IVRS entries for IOAPIC try to check for entry's consistency. Specifically, if conflicting entries are found disable IOMMU if per-device remapping table is used. If entries refer to bogus IOAPIC IDs disable IOMMU unconditionally Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com> xen-unstable changeset: 26517:601139e2b0db xen-unstable date: Tue Feb 5 14:20:47 UTC 2013
* ACPI: acpi_table_parse() should return handler's error codeBoris Ostrovsky2013-02-051-3/+2
| | | | | | | | | | | Currently, the error code returned by acpi_table_parse()'s handler is ignored. This patch will propagate handler's return value to acpi_table_parse()'s caller. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com> Committed-by: Jan Beulich <jbeulich@suse.com> xen-unstable changeset: 26516:32d4516a97f0 xen-unstable date: Tue Feb 5 14:18:18 UTC 2013
* QEMU_TAG updateIan Jackson2013-01-171-3/+3
|
* x86: compat_show_guest_stack() should not truncate MFNJan Beulich2013-01-171-2/+3
| | | | | | | | | | Re-using "addr" here was a mistake, as it is a 32-bit quantity. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 26332:8e942f2f3b45 xen-unstable date: Mon Jan 7 12:28:29 UTC 2013
* x86/mm: Fix loop increment in paging_log_dirty_range()Tim Deegan2013-01-171-1/+2
| | | | | | | | | | | | | In 23417:53ef1f35a0f8 (the fix for XSA-27 / CVE-2012-5511), the loop variable gets incremented twice, so the loop only clears every second page of the bitmap. This might cause the tools to think that pages are dirty when they are not. Reported-by: Steven Noonan <snoonan@amazon.com> Reported-by: Matt Wilson <msw@amazon.com> Signed-off-by: Tim Deegan <tim@xen.org> Acked-by: Ian Campbell <ian.campbell@citrix.com> Committed-by: Jan Beulich <jbeulich@suse.com>
* Config.mk: delete accidentally introduced drivelIan Jackson2013-01-171-3/+0
|
* QEMU_TAG updateIan Jackson2013-01-171-3/+6
|
* QEMU_TAG updateIan Jackson2013-01-161-3/+3
|
* VT-d: fix interrupt remapping source validation for devices behind legacy ↵Jan Beulich2013-01-091-1/+1
| | | | | | | | | | | | | bridges Using SVT_VERIFY_BUS here doesn't make sense; native Linux also uses SVT_VERIFY_SID_SQ here instead. This is XSA-33 / CVE-2012-5634. Signed-off-by: Jan Beulich <jbeulich@suse.com> xen-unstable changeset: 26340:19fd1237ff0d xen-unstable date: Wed Jan 9 16:13:26 UTC 2013
* x86, amd: Disable way access filter on Piledriver CPUsAndre Przywara2013-01-082-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Way Access Filter in recent AMD CPUs may hurt the performance of some workloads, caused by aliasing issues in the L1 cache. This patch disables it on the affected CPUs. The issue is similar to that one of last year: http://lkml.indiana.edu/hypermail/linux/kernel/1107.3/00041.html This new patch does not replace the old one, we just need another quirk for newer CPUs. The performance penalty without the patch depends on the circumstances, but is a bit less than the last year's 3%. The workloads affected would be those that access code from the same physical page under different virtual addresses, so different processes using the same libraries with ASLR or multiple instances of PIE-binaries. The code needs to be accessed simultaneously from both cores of the same compute unit. More details can be found here: http://developer.amd.com/Assets/SharedL1InstructionCacheonAMD15hCPU.pdf CPUs affected are anything with the core known as Piledriver. That includes the new parts of the AMD A-Series (aka Trinity) and the just released new CPUs of the FX-Series (aka Vishera). The model numbering is a bit odd here: FX CPUs have model 2, A-Series has model 10h, with possible extensions to 1Fh. Hence the range of model ids. Signed-off-by: Andre Przywara <osp@andrep.de> Add and use MSR_AMD64_IC_CFG. Update the value whenever it is found to not have all bits set, rather than just when it's zero. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 26294:5fb0b8b838da xen-unstable date: Wed Dec 19 10:42:09 UTC 2012
* IOMMU/ATS: fix maximum queue depth calculationJan Beulich2013-01-081-2/+3
| | | | | | | | | | | | | | | The capabilities register field is a 5-bit value, and the 5 bits all being zero actually means 32 entries. Under the assumption that amd_iommu_flush_iotlb() really just tried to correct for the miscalculation above when adding 32 to the value, that adjustment is also being removed. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by Xiantao Zhang <xiantao.zhang@intel.com> Acked-by: Wei Huang <wei.huang2@amd.com> xen-unstable changeset: 26235:670b07e8d738 xen-unstable date: Wed Dec 5 08:52:14 UTC 2012
* x86/HPET: fix FSB interrupt maskingJan Beulich2013-01-082-9/+10
| | | | | | | | | | | | | | | | | | | | | HPET_TN_FSB is not really suitable for masking interrupts - it merely switches between the two delivery methods. The right way of masking is through the HPET_TN_ENABLE bit (which really is an interrupt enable, not a counter enable or some such). This is even more so with certain chip sets not even allowing HPET_TN_FSB to be cleared on some of the channels. Further, all the setup of the channel should happen before actually enabling the interrupt, which requires splitting legacy and FSB logic. Finally this also fixes an S3 resume problem (HPET_TN_FSB did not get set in hpet_broadcast_resume(), and hpet_msi_unmask() doesn't get called from the general resume code either afaict). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> xen-unstable changeset: 26183:c139ca92edca xen-unstable date: Thu Nov 22 09:03:23 UTC 2012
* passthrough/PCI: replace improper uses of pci_find_next_cap()Jan Beulich2013-01-081-13/+3
| | | | | | | | | | | | | | | | | | Using pci_find_next_cap() without prior pci_find_cap_offset() is bogus (and possibly wrong, given that the latter doesn't check the PCI_STATUS_CAP_LIST flag, which so far was checked in an open-coded way only for the non-bridge case). Once at it, fold the two calls into one, as we need its result in any case. Question is whether, without any caller left, pci_find_next_cap() should be purged as well. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Xiantao Zhang <xiantao.zhang@intel.com> xen-unstable changeset: 26179:ae6fb202b233 xen-unstable date: Tue Nov 20 07:58:31 UTC 2012
* XZ: Fix incorrect XZ_BUF_ERRORLasse Collin2012-12-191-7/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From: Lasse Collin <lasse.collin@tukaani.org> xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the following was true: - The caller knows how many bytes of output to expect and only provides that much output space. - When the last output bytes are decoded, the caller-provided input buffer ends right before the LZMA2 end of payload marker. So LZMA2 won't provide more output anymore, but it won't know it yet and thus won't return XZ_STREAM_END yet. - A BCJ filter is in use and it hasn't left any unfiltered bytes in the temp buffer. This can happen with any BCJ filter, but in practice it's more likely with filters other than the x86 BCJ. This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408> where Squashfs thinks that a valid file system is corrupt. This also fixes a similar bug in single-call mode where the uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller provided no output space. Many empty .xz files don't contain any blocks and thus don't trigger this bug. This also tweaks a closely related detail: xz_dec_bcj_run() could call xz_dec_lzma2_run() to decode into temp buffer when it was known to be useless. This was harmless although it wasted a minuscule number of CPU cycles. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> xen-unstable changeset: 23870:5c97b02f48fc xen-unstable date: Thu Sep 22 17:34:27 UTC 2011
* XZ decompressor: Fix decoding of empty LZMA2 streamsLasse Collin2012-12-191-3/+3
| | | | | | | | | | | | | | From: Lasse Collin <lasse.collin@tukaani.org> The old code considered valid empty LZMA2 streams to be corrupt. Note that a typical empty .xz file has no LZMA2 data at all, and thus most .xz files having no uncompressed data are handled correctly even without this fix. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> xen-unstable changeset: 23869:db1ea4b127cd xen-unstable date: Thu Sep 22 17:33:48 UTC 2011
* Add Dom0 xz kernel decompressionJan Beulich2012-12-1912-2/+3447
| | | | | | | | Largely taken from Linux 2.6.38 and made build/work for Xen. Signed-off-by: Jan Beulich <jbeulich@novell.com> xen-unstable changeset: 23001:9eb9948904cd xen-unstable date: Wed Mar 9 16:18:58 UTC 2011
* update Xen version to 4.1.5-preJan Beulich2012-12-191-1/+1
|
* Added signature for changeset 12c4c4c0a715Ian Jackson2012-12-181-0/+1
|
* Added tag RELEASE-4.1.4 for changeset 12c4c4c0a715Jan Beulich2012-12-181-0/+1
|
* update Xen version to 4.1.4RELEASE-4.1.4Jan Beulich2012-12-182-2/+2
|
* libxl: revert 23428:93e17b0cd035 "avoid blktap2 deadlock"Ian Jackson2012-12-172-7/+1
| | | | | | | This results in additional leakage in xenstore according to the automated tests. Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
* libxl: avoid blktap2 deadlock on cleanupGreg Wettstein2012-12-132-1/+7
| | | | | | | | | | | | | | | | | Establishes correct cleanup behavior for blktap devices. This patch implements the release of the backend device before calling for the destruction of the userspace component of the blktap device. Without this patch the kernel xen-blkback driver deadlocks with the blktap2 user control plane until the IPC channel is terminated by the timeout on the select() call. This results in a noticeable delay in the termination of the guest and causes the blktap minor number which had been allocated to be orphaned. Signed-off-by: Greg Wettstein <greg@enjellic.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
* From: Ian Campbell <ian.campbell@citrix.com>Ian Jackson2012-12-126-11/+51
| | | | | | | | | | | | | | | | libxl: attempt to cleanup tapdisk processes on disk backend destroy. This patch properly terminates the tapdisk2 process(es) started to service a virtual block device. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> xen-unstable changeset: 23883:7998217630e2 xen-unstable date: Wed Sep 28 16:42:11 2011 +0100 Signed-off-by: Greg Wettstein <greg@enjellic.com> Backport-requested-by: Greg Wettstein <greg@enjellic.com> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
* Added signature for changeset 0125069bc1b2Keir Fraser2012-12-121-0/+1
|
* Added tag 4.1.4-rc2 for changeset 0125069bc1b2Jan Beulich2012-12-121-0/+1
|
* update Xen version to 4.1.4-rc24.1.4-rc2Jan Beulich2012-12-121-1/+1
|
* x86/hap: Fix memory leak of domain->arch.hvm_domain.dirty_vramKouya Shimura2012-12-061-0/+3
| | | | | | | Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com> Signed-off-by: Tim Deegan <tim@xen.org> xen-unstable changeset: 26203:b5cb6cccc32c xen-unstable date: Thu Nov 29 11:01:00 UTC 2012
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-27 08:01:35 +0000