{"push_id":2596234773,"size":13,"distinct_size":13,"ref":"refs/heads/master","head":"ec30dcf7f425dc811ac365b5c4b0f097f98e569f","before":"bc2dbc5420e82560e650f8531ceca597441ca171","commits":[{"sha":"57b8daa70a179bc23cc4240420ab6fbcdd7faf77","author":{"name":"Paul Mackerras","email":"19a0ba370c443ba08d20b5061586430ab449ee8c@ozlabs.org"},"message":"KVM: PPC: Book3S HV: Snapshot timebase offset on guest entry\n\nCurrently, the HV KVM guest entry/exit code adds the timebase offset\nfrom the vcore struct to the timebase on guest entry, and subtracts\nit on guest exit.  Which is fine, except that it is possible for\nuserspace to change the offset using the SET_ONE_REG interface while\nthe vcore is running, as there is only one timebase offset per vcore\nbut potentially multiple VCPUs in the vcore.  If that were to happen,\nKVM would subtract a different offset on guest exit from that which\nit had added on guest entry, leading to the timebase being out of sync\nbetween cores in the host, which then leads to bad things happening\nsuch as hangs and spurious watchdog timeouts.\n\nTo fix this, we add a new field 'tb_offset_applied' to the vcore struct\nwhich stores the offset that is currently applied to the timebase.\nThis value is set from the vcore tb_offset field on guest entry, and\nis what is subtracted from the timebase on guest exit.  Since it is\nzero when the timebase offset is not applied, we can simplify the\nlogic in kvmhv_start_timing and kvmhv_accumulate_time.\n\nIn addition, we had secondary threads reading the timebase while\nrunning concurrently with code on the primary thread which would\neventually add or subtract the timebase offset from the timebase.\nThis occurred while saving or restoring the DEC register value on\nthe secondary threads.  Although no specific incorrect behaviour has\nbeen observed, this is a race which should be fixed.  To fix it, we\nmove the DEC saving code to just before we call kvmhv_commence_exit,\nand the DEC restoring code to after the point where we have waited\nfor the primary thread to switch the MMU context and add the timebase\noffset.  That way we are sure that the timebase contains the guest\ntimebase value in both cases.\n\nSigned-off-by: Paul Mackerras <paulus@ozlabs.org>","distinct":true,"url":"https://api.github.com/repos/kraj/linux/commits/57b8daa70a179bc23cc4240420ab6fbcdd7faf77"},{"sha":"e2560b108fb1375b5fab196c1ec0d910bbe8a38b","author":{"name":"Nicholas Piggin","email":"24829078df5003d9dd1dd871ca2aeb0b1cf95ef4@gmail.com"},"message":"KVM: PPC: Book3S HV: Make radix use correct tlbie sequence in kvmppc_radix_tlbie_page\n\nThe standard eieio ; tlbsync ; ptesync must follow tlbie to ensure it\nis ordered with respect to subsequent operations.\n\nSigned-off-by: Nicholas Piggin <npiggin@gmail.com>\nSigned-off-by: Paul Mackerras <paulus@ozlabs.org>","distinct":true,"url":"https://api.github.com/repos/kraj/linux/commits/e2560b108fb1375b5fab196c1ec0d910bbe8a38b"},{"sha":"7e3d9a1d0f2c681456a2e04b8ba9a2fb448fe515","author":{"name":"Nicholas Piggin","email":"24829078df5003d9dd1dd871ca2aeb0b1cf95ef4@gmail.com"},"message":"KVM: PPC: Book3S HV: Make radix clear pte when unmapping\n\nThe current partition table unmap code clears the _PAGE_PRESENT bit\nout of the pte, which leaves pud_huge/pmd_huge true and does not\nclear pud_present/pmd_present.  This can confuse subsequent page\nfaults and possibly lead to the guest looping doing continual\nhypervisor page faults.\n\nSigned-off-by: Nicholas Piggin <npiggin@gmail.com>\nSigned-off-by: Paul Mackerras <paulus@ozlabs.org>","distinct":true,"url":"https://api.github.com/repos/kraj/linux/commits/7e3d9a1d0f2c681456a2e04b8ba9a2fb448fe515"},{"sha":"9dc81d6b0f1e3c40bdf97671dd26a24f128e1182","author":{"name":"Benjamin Herrenschmidt","email":"a7089bb6e7e92505d88aaff006cbdd60cc9120b6@kernel.crashing.org"},"message":"KVM: PPC: Book3S HV: XIVE: Resend re-routed interrupts on CPU priority change\n\nWhen a vcpu priority (CPPR) is set to a lower value (masking more\ninterrupts), we stop processing interrupts already in the queue\nfor the priorities that have now been masked.\n\nIf those interrupts were previously re-routed to a different\nCPU, they might still be stuck until the older one that has\nthem in its queue processes them. In the case of guest CPU\nunplug, that can be never.\n\nTo address that without creating additional overhead for\nthe normal interrupt processing path, this changes H_CPPR\nhandling so that when such a priority change occurs, we\nscan the interrupt queue for that vCPU, and for any\ninterrupt in there that has been re-routed, we replace it\nwith a dummy and force a re-trigger.\n\nSigned-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>\nTested-by: Alexey Kardashevskiy <aik@ozlabs.ru>\nSigned-off-by: Paul Mackerras <paulus@ozlabs.org>","distinct":true,"url":"https://api.github.com/repos/kraj/linux/commits/9dc81d6b0f1e3c40bdf97671dd26a24f128e1182"},{"sha":"df158189dbcc2e0ee29dc4b917d45ee5bf25a35e","author":{"name":"Paul Mackerras","email":"19a0ba370c443ba08d20b5061586430ab449ee8c@ozlabs.org"},"message":"KVM: PPC: Book 3S HV: Do ptesync in radix guest exit path\n\nA radix guest can execute tlbie instructions to invalidate TLB entries.\nAfter a tlbie or a group of tlbies, it must then do the architected\nsequence eieio; tlbsync; ptesync to ensure that the TLB invalidation\nhas been processed by all CPUs in the system before it can rely on\nno CPU using any translation that it just invalidated.\n\nIn fact it is the ptesync which does the actual synchronization in\nthis sequence, and hardware has a requirement that the ptesync must\nbe executed on the same CPU thread as the tlbies which it is expected\nto order.  Thus, if a vCPU gets moved from one physical CPU to\nanother after it has done some tlbies but before it can get to do the\nptesync, the ptesync will not have the desired effect when it is\nexecuted on the second physical CPU.\n\nTo fix this, we do a ptesync in the exit path for radix guests.  If\nthere are any pending tlbies, this will wait for them to complete.\nIf there aren't, then ptesync will just do the same as sync.\n\nSigned-off-by: Paul Mackerras <paulus@ozlabs.org>","distinct":true,"url":"https://api.github.com/repos/kraj/linux/commits/df158189dbcc2e0ee29dc4b917d45ee5bf25a35e"},{"sha":"f4a551b72358facbbe5714248dff78404272feee","author":{"name":"David Hildenbrand","email":"aa743a0aaec8f7d7a1f01442503957f4d7a2d634@redhat.com"},"message":"KVM: s390: vsie: fix < 8k check for the itdba\n\nBy missing an \"L\", we might detect some addresses to be <8k,\nalthough they are not.\n\ne.g. for itdba = 100001fff\n!(gpa & ~0x1fffU) -> 1\n!(gpa & ~0x1fffUL) -> 0\n\nSo we would report a SIE validity intercept although everything is fine.\n\nFixes: 166ecb3 (\"KVM: s390: vsie: support transactional execution\")\nReported-by: Dan Carpenter <dan.carpenter@oracle.com>\nReviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>\nReviewed-by: Janosch Frank <frankja@linux.ibm.com>\nReviewed-by: Cornelia Huck <cohuck@redhat.com>\nSigned-off-by: David Hildenbrand <david@redhat.com>\nSigned-off-by: Janosch Frank <frankja@linux.ibm.com>\nCc: stable@vger.kernel.org # v4.8+\nSigned-off-by: Christian Borntraeger <borntraeger@de.ibm.com>","distinct":true,"url":"https://api.github.com/repos/kraj/linux/commits/f4a551b72358facbbe5714248dff78404272feee"},{"sha":"e20ac8b11b0f06ebae63c56062123b62b0c64c2b","author":{"name":"Paolo Bonzini","email":"69d3ebcf5ee4e7f05a50dc23cd96655b730804b4@redhat.com"},"message":"Merge tag 'kvm-s390-master-4.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into kvm-master\n\nKVM: s390: Fix vsie handling for transactional diagnostic block\n\nvsie (nested KVM) might reject a valid input. Fix it.","distinct":true,"url":"https://api.github.com/repos/kraj/linux/commits/e20ac8b11b0f06ebae63c56062123b62b0c64c2b"},{"sha":"b09efdc250f0df1bea73f83ef8fb9e9a16229fc5","author":{"name":"Radim Krčmář","email":"e4aea3f2c531804c57884e1d444a6744efb5af4d@redhat.com"},"message":"Merge tag 'kvm-ppc-fixes-4.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc\n\nFixes for PPC KVM:\n\n- Close a hole which could possibly lead to the host timebase getting\n  out of sync.\n\n- Three fixes relating to PTEs and TLB entries for radix guests.\n\n- Fix a bug which could lead to an interrupt never getting delivered\n  to the guest, if it is pending for a guest vCPU when the vCPU gets\n  offlined.","distinct":true,"url":"https://api.github.com/repos/kraj/linux/commits/b09efdc250f0df1bea73f83ef8fb9e9a16229fc5"},{"sha":"d8f2f498d9ed0c5010bc1bbc1146f94c8bf9f8cc","author":{"name":"David Vrabel","email":"b9d45bd1f671e508cd8daa63dfc3cabb597562df@nutanix.com"},"message":"x86/kvm: fix LAPIC timer drift when guest uses periodic mode\n\nSince 4.10, commit 8003c9ae204e (KVM: LAPIC: add APIC Timer\nperiodic/oneshot mode VMX preemption timer support), guests using\nperiodic LAPIC timers (such as FreeBSD 8.4) would see their timers\ndrift significantly over time.\n\nDifferences in the underlying clocks and numerical errors means the\nperiods of the two timers (hv and sw) are not the same. This\ndifference will accumulate with every expiry resulting in a large\nerror between the hv and sw timer.\n\nThis means the sw timer may be running slow when compared to the hv\ntimer. When the timer is switched from hv to sw, the now active sw\ntimer will expire late. The guest VCPU is reentered and it switches to\nusing the hv timer. This timer catches up, injecting multiple IRQs\ninto the guest (of which the guest only sees one as it does not get to\nrun until the hv timer has caught up) and thus the guest's timer rate\nis low (and becomes increasing slower over time as the sw timer lags\nfurther and further behind).\n\nI believe a similar problem would occur if the hv timer is the slower\none, but I have not observed this.\n\nFix this by synchronizing the deadlines for both timers to the same\ntime source on every tick. This prevents the errors from accumulating.\n\nFixes: 8003c9ae204e21204e49816c5ea629357e283b06\nCc: Wanpeng Li <wanpeng.li@hotmail.com>\nSigned-off-by: David Vrabel <david.vrabel@nutanix.com>\nCc: stable@vger.kernel.org\nReviewed-by: Paolo Bonzini <pbonzini@redhat.com>\nReviewed-by: Wanpeng Li <wanpengli@tencent.com>\nSigned-off-by: Radim Krčmář <rkrcmar@redhat.com>","distinct":true,"url":"https://api.github.com/repos/kraj/linux/commits/d8f2f498d9ed0c5010bc1bbc1146f94c8bf9f8cc"},{"sha":"c4d2188206bafa177ea58e9a25b952baa0bf7712","author":{"name":"Wei Huang","email":"8fa8838ab83387ae867845f542b9fe9ca04873f0@redhat.com"},"message":"KVM: x86: Update cpuid properly when CR4.OSXAVE or CR4.PKE is changed\n\nThe CPUID bits of OSXSAVE (function=0x1) and OSPKE (func=0x7, leaf=0x0)\nallows user apps to detect if OS has set CR4.OSXSAVE or CR4.PKE. KVM is\nsupposed to update these CPUID bits when CR4 is updated. Current KVM\ncode doesn't handle some special cases when updates come from emulator.\nHere is one example:\n\n  Step 1: guest boots\n  Step 2: guest OS enables XSAVE ==> CR4.OSXSAVE=1 and CPUID.OSXSAVE=1\n  Step 3: guest hot reboot ==> QEMU reset CR4 to 0, but CPUID.OSXAVE==1\n  Step 4: guest os checks CPUID.OSXAVE, detects 1, then executes xgetbv\n\nStep 4 above will cause an #UD and guest crash because guest OS hasn't\nturned on OSXAVE yet. This patch solves the problem by comparing the the\nold_cr4 with cr4. If the related bits have been changed,\nkvm_update_cpuid() needs to be called.\n\nSigned-off-by: Wei Huang <wei@redhat.com>\nReviewed-by: Bandan Das <bsd@redhat.com>\nCc: stable@vger.kernel.org\nSigned-off-by: Radim Krčmář <rkrcmar@redhat.com>","distinct":true,"url":"https://api.github.com/repos/kraj/linux/commits/c4d2188206bafa177ea58e9a25b952baa0bf7712"},{"sha":"1eaafe91a0df4157521b6417b3dd8430bf5f52f0","author":{"name":"Jim Mattson","email":"69e6c825ffb81c81b96935a61b79166dbc1f7a9d@google.com"},"message":"kvm: x86: IA32_ARCH_CAPABILITIES is always supported\n\nIf there is a possibility that a VM may migrate to a Skylake host,\nthen the hypervisor should report IA32_ARCH_CAPABILITIES.RSBA[bit 2]\nas being set (future work, of course). This implies that\nCPUID.(EAX=7,ECX=0):EDX.ARCH_CAPABILITIES[bit 29] should be\nset. Therefore, kvm should report this CPUID bit as being supported\nwhether or not the host supports it.  Userspace is still free to clear\nthe bit if it chooses.\n\nFor more information on RSBA, see Intel's white paper, \"Retpoline: A\nBranch Target Injection Mitigation\" (Document Number 337131-001),\ncurrently available at https://bugzilla.kernel.org/show_bug.cgi?id=199511.\n\nSince the IA32_ARCH_CAPABILITIES MSR is emulated in kvm, there is no\ndependency on hardware support for this feature.\n\nSigned-off-by: Jim Mattson <jmattson@google.com>\nReviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>\nFixes: 28c1c9fabf48 (\"KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES\")\nCc: stable@vger.kernel.org\nSigned-off-by: Radim Krčmář <rkrcmar@redhat.com>","distinct":true,"url":"https://api.github.com/repos/kraj/linux/commits/1eaafe91a0df4157521b6417b3dd8430bf5f52f0"},{"sha":"696ca779a928d0e93d61c38ffc3a4d8914a9b9a0","author":{"name":"Radim Krčmář","email":"e4aea3f2c531804c57884e1d444a6744efb5af4d@redhat.com"},"message":"KVM: x86: fix #UD address of failed Hyper-V hypercalls\n\nIf the hypercall was called from userspace or real mode, KVM injects #UD\nand then advances RIP, so it looks like #UD was caused by the following\ninstruction.  This probably won't cause more than confusion, but could\ngive an unexpected access to guest OS' instruction emulator.\n\nAlso, refactor the code to count hv hypercalls that were handled by the\nvirt userspace.\n\nFixes: 6356ee0c9602 (\"x86: Delay skip of emulated hypercall instruction\")\nReviewed-by: Paolo Bonzini <pbonzini@redhat.com>\nSigned-off-by: Radim Krčmář <rkrcmar@redhat.com>","distinct":true,"url":"https://api.github.com/repos/kraj/linux/commits/696ca779a928d0e93d61c38ffc3a4d8914a9b9a0"},{"sha":"ec30dcf7f425dc811ac365b5c4b0f097f98e569f","author":{"name":"Linus Torvalds","email":"69652caca27c8b940640ad396ab71f93cacec34f@linux-foundation.org"},"message":"Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm\n\nPull KVM fixes from Radim Krčmář:\n \"PPC:\n\n   - Close a hole which could possibly lead to the host timebase getting\n     out of sync.\n\n   - Three fixes relating to PTEs and TLB entries for radix guests.\n\n   - Fix a bug which could lead to an interrupt never getting delivered\n     to the guest, if it is pending for a guest vCPU when the vCPU gets\n     offlined.\n\n  s390:\n\n   - Fix false negatives in VSIE validity check (Cc stable)\n\n  x86:\n\n   - Fix time drift of VMX preemption timer when a guest uses LAPIC\n     timer in periodic mode (Cc stable)\n\n   - Unconditionally expose CPUID.IA32_ARCH_CAPABILITIES to allow\n     migration from hosts that don't need retpoline mitigation (Cc\n     stable)\n\n   - Fix guest crashes on reboot by properly coupling CR4.OSXSAVE and\n     CPUID.OSXSAVE (Cc stable)\n\n   - Report correct RIP after Hyper-V hypercall #UD (introduced in\n     -rc6)\"\n\n* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:\n  KVM: x86: fix #UD address of failed Hyper-V hypercalls\n  kvm: x86: IA32_ARCH_CAPABILITIES is always supported\n  KVM: x86: Update cpuid properly when CR4.OSXAVE or CR4.PKE is changed\n  x86/kvm: fix LAPIC timer drift when guest uses periodic mode\n  KVM: s390: vsie: fix < 8k check for the itdba\n  KVM: PPC: Book 3S HV: Do ptesync in radix guest exit path\n  KVM: PPC: Book3S HV: XIVE: Resend re-routed interrupts on CPU priority change\n  KVM: PPC: Book3S HV: Make radix clear pte when unmapping\n  KVM: PPC: Book3S HV: Make radix use correct tlbie sequence in kvmppc_radix_tlbie_page\n  KVM: PPC: Book3S HV: Snapshot timebase offset on guest entry","distinct":true,"url":"https://api.github.com/repos/kraj/linux/commits/ec30dcf7f425dc811ac365b5c4b0f097f98e569f"}]}
{"actor":{"display_login":"kraj"}}