<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/arch/arm/kvm/interrupts_head.S, branch dev</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2015-06-17T08:59:55+00:00</updated>
<entry>
<title>arm/arm64: KVM: vgic: Do not save GICH_HCR / ICH_HCR_EL2</title>
<updated>2015-06-17T08:59:55+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>marc.zyngier@arm.com</email>
</author>
<published>2015-06-11T17:50:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=4642019dc4457486223e1fb75a6a4cba6e0e903a'/>
<id>urn:sha1:4642019dc4457486223e1fb75a6a4cba6e0e903a</id>
<content type='text'>
The GIC Hypervisor Configuration Register is used to enable
the delivery of virtual interupts to a guest, as well as to
define in which conditions maintenance interrupts are delivered
to the host.

This register doesn't contain any information that we need to
read back (the EOIcount is utterly useless for us).

So let's save ourselves some cycles, and not save it before
writing zero to it.

Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
</content>
</entry>
<entry>
<title>arm: KVM: force execution of HCPTR access on VM exit</title>
<updated>2015-06-17T08:40:14+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>marc.zyngier@arm.com</email>
</author>
<published>2015-03-16T10:59:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=85e84ba31039595995dae80b277378213602891b'/>
<id>urn:sha1:85e84ba31039595995dae80b277378213602891b</id>
<content type='text'>
On VM entry, we disable access to the VFP registers in order to
perform a lazy save/restore of these registers.

On VM exit, we restore access, test if we did enable them before,
and save/restore the guest/host registers if necessary. In this
sequence, the FPEXC register is always accessed, irrespective
of the trapping configuration.

If the guest didn't touch the VFP registers, then the HCPTR access
has now enabled such access, but we're missing a barrier to ensure
architectural execution of the new HCPTR configuration. If the HCPTR
access has been delayed/reordered, the subsequent access to FPEXC
will cause a trap, which we aren't prepared to handle at all.

The same condition exists when trapping to enable VFP for the guest.

The fix is to introduce a barrier after enabling VFP access. In the
vmexit case, it can be relaxed to only takes place if the guest hasn't
accessed its view of the VFP registers, making the access to FPEXC safe.

The set_hcptr macro is modified to deal with both vmenter/vmexit and
vmtrap operations, and now takes an optional label that is branched to
when the guest hasn't touched the VFP registers.

Reported-by: Vikram Sethi &lt;vikrams@codeaurora.org&gt;
Cc: stable@kernel.org	# v3.9+
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
</content>
</entry>
<entry>
<title>arm/arm64: KVM: Kill CONFIG_KVM_ARM_{VGIC,TIMER}</title>
<updated>2015-03-12T14:15:27+00:00</updated>
<author>
<name>Christoffer Dall</name>
<email>christoffer.dall@linaro.org</email>
</author>
<published>2015-03-11T13:21:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=662d9715840aef44dcb573b0f9fab9e8319c868a'/>
<id>urn:sha1:662d9715840aef44dcb573b0f9fab9e8319c868a</id>
<content type='text'>
We can definitely decide at run-time whether to use the GIC and timers
or not, and the extra code and data structures that we allocate space
for is really negligable with this config option, so I don't think it's
worth the extra complexity of always having to define stub static
inlines.  The !CONFIG_KVM_ARM_VGIC/TIMER case is pretty much an untested
code path anyway, so we're better off just getting rid of it.

Signed-off-by: Christoffer Dall &lt;christoffer.dall@linaro.org&gt;
Acked-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
</content>
</entry>
<entry>
<title>arm/arm64: KVM: Fix BE accesses to GICv2 EISR and ELRSR regs</title>
<updated>2014-10-16T08:57:41+00:00</updated>
<author>
<name>Christoffer Dall</name>
<email>christoffer.dall@linaro.org</email>
</author>
<published>2014-09-28T14:04:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=2df36a5dd6792870bef48f63bfca42055ea5b79c'/>
<id>urn:sha1:2df36a5dd6792870bef48f63bfca42055ea5b79c</id>
<content type='text'>
The EIRSR and ELRSR registers are 32-bit registers on GICv2, and we
store these as an array of two such registers on the vgic vcpu struct.
However, we access them as a single 64-bit value or as a bitmap pointer
in the generic vgic code, which breaks BE support.

Instead, store them as u64 values on the vgic structure and do the
word-swapping in the assembly code, which already handles the byte order
for BE systems.

Tested-by: Victor Kamensky &lt;victor.kamensky@linaro.org&gt;
Acked-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Christoffer Dall &lt;christoffer.dall@linaro.org&gt;
</content>
</entry>
<entry>
<title>ARM: KVM: handle 64bit values passed to mrcc or from mcrr instructions in BE case</title>
<updated>2014-07-11T11:57:38+00:00</updated>
<author>
<name>Victor Kamensky</name>
<email>victor.kamensky@linaro.org</email>
</author>
<published>2014-06-12T16:30:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=19b0e60a63f758a28329aa40f4270a6c98c2dcb7'/>
<id>urn:sha1:19b0e60a63f758a28329aa40f4270a6c98c2dcb7</id>
<content type='text'>
In some cases the mcrr and mrrc instructions in combination with the ldrd
and strd instructions need to deal with 64bit value in memory. The ldrd
and strd instructions already handle endianness within word (register)
boundaries but to get effect of the whole 64bit value represented correctly,
rr_lo_hi macro is introduced and is used to swap registers positions when
the mcrr and mrrc instructions are used. That has the effect of swapping
two words.

Signed-off-by: Victor Kamensky &lt;victor.kamensky@linaro.org&gt;
Reviewed-by: Christoffer Dall &lt;christoffer.dall@linaro.org&gt;
Acked-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
</content>
</entry>
<entry>
<title>ARM: KVM: fix vgic V7 assembler code to work in BE image</title>
<updated>2014-07-11T11:57:38+00:00</updated>
<author>
<name>Victor Kamensky</name>
<email>victor.kamensky@linaro.org</email>
</author>
<published>2014-06-12T16:30:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=64054c25cf7e060cd6780744fefe7ed3990e4f21'/>
<id>urn:sha1:64054c25cf7e060cd6780744fefe7ed3990e4f21</id>
<content type='text'>
The vgic h/w registers are little endian; when BE asm code
reads/writes from/to them, it needs to do byteswap after/before.
Byteswap code uses ARM_BE8 wrapper to add swap only if
CONFIG_CPU_BIG_ENDIAN is configured.

Signed-off-by: Victor Kamensky &lt;victor.kamensky@linaro.org&gt;
Reviewed-by: Christoffer Dall &lt;christoffer.dall@linaro.org&gt;
Acked-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
</content>
</entry>
<entry>
<title>KVM: arm/arm64: vgic: move GICv2 registers to their own structure</title>
<updated>2014-07-11T11:57:31+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>marc.zyngier@arm.com</email>
</author>
<published>2013-05-30T09:20:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=eede821dbfd58df89edb072da64e006321eaef58'/>
<id>urn:sha1:eede821dbfd58df89edb072da64e006321eaef58</id>
<content type='text'>
In order to make way for the GICv3 registers, move the v2-specific
registers to their own structure.

Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Reviewed-by: Christoffer Dall &lt;christoffer.dall@linaro.org&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
</content>
</entry>
<entry>
<title>ARM: KVM: add world-switch for AMAIR{0,1}</title>
<updated>2014-03-03T01:15:24+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>marc.zyngier@arm.com</email>
</author>
<published>2014-01-22T10:20:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=af20814ee927ed888288d98917a766b4179c4fe0'/>
<id>urn:sha1:af20814ee927ed888288d98917a766b4179c4fe0</id>
<content type='text'>
HCR.TVM traps (among other things) accesses to AMAIR0 and AMAIR1.
In order to minimise the amount of surprise a guest could generate by
trying to access these registers with caches off, add them to the
list of registers we switch/handle.

Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Reviewed-by: Christoffer Dall &lt;christoffer.dall@linaro.org&gt;
Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
</content>
</entry>
<entry>
<title>ARM: KVM: introduce per-vcpu HYP Configuration Register</title>
<updated>2014-03-03T01:15:23+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>marc.zyngier@arm.com</email>
</author>
<published>2014-01-22T09:43:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=ac30a11e8e92a03dbe236b285c5cbae0bf563141'/>
<id>urn:sha1:ac30a11e8e92a03dbe236b285c5cbae0bf563141</id>
<content type='text'>
So far, KVM/ARM used a fixed HCR configuration per guest, except for
the VI/VF/VA bits to control the interrupt in absence of VGIC.

With the upcoming need to dynamically reconfigure trapping, it becomes
necessary to allow the HCR to be changed on a per-vcpu basis.

The fix here is to mimic what KVM/arm64 already does: a per vcpu HCR
field, initialized at setup time.

Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Reviewed-by: Christoffer Dall &lt;christoffer.dall@linaro.org&gt;
Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm</title>
<updated>2013-07-03T20:21:40+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2013-07-03T20:21:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=fe489bf4505ae26d3c6d6a1f1d3064c2a9c5cd85'/>
<id>urn:sha1:fe489bf4505ae26d3c6d6a1f1d3064c2a9c5cd85</id>
<content type='text'>
Pull KVM fixes from Paolo Bonzini:
 "On the x86 side, there are some optimizations and documentation
  updates.  The big ARM/KVM change for 3.11, support for AArch64, will
  come through Catalin Marinas's tree.  s390 and PPC have misc cleanups
  and bugfixes"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (87 commits)
  KVM: PPC: Ignore PIR writes
  KVM: PPC: Book3S PR: Invalidate SLB entries properly
  KVM: PPC: Book3S PR: Allow guest to use 1TB segments
  KVM: PPC: Book3S PR: Don't keep scanning HPTEG after we find a match
  KVM: PPC: Book3S PR: Fix invalidation of SLB entry 0 on guest entry
  KVM: PPC: Book3S PR: Fix proto-VSID calculations
  KVM: PPC: Guard doorbell exception with CONFIG_PPC_DOORBELL
  KVM: Fix RTC interrupt coalescing tracking
  kvm: Add a tracepoint write_tsc_offset
  KVM: MMU: Inform users of mmio generation wraparound
  KVM: MMU: document fast invalidate all mmio sptes
  KVM: MMU: document fast invalidate all pages
  KVM: MMU: document fast page fault
  KVM: MMU: document mmio page fault
  KVM: MMU: document write_flooding_count
  KVM: MMU: document clear_spte_count
  KVM: MMU: drop kvm_mmu_zap_mmio_sptes
  KVM: MMU: init kvm generation close to mmio wrap-around value
  KVM: MMU: add tracepoint for check_mmio_spte
  KVM: MMU: fast invalidate all mmio sptes
  ...
</content>
</entry>
</feed>
