On Fri, Mar 21, 2014 at 08:20:02PM -0700, Christoffer Dall wrote:
> Does anyone have anything they would like to discuss on a KVM/ARM Call
> on Tuesday?
Minutes from the call on Tuesday March 25th:
Present
-------
- Christoffer Dall
- Peter Maydell
- Andre Przywara
- Marc Zyngier
- Kim Phillips
- Alvise Rigo
- Rob Herring
- Anup Patel
- Some others who didn't announce
Agenda
------
- PSCI conduit (hvc/smc)
* We discussed the problem of using SMC as the PSCI conduit for QEMU
and HVC for KVM, and how that would break migration between the two
platforms.
* It was previously felt that it was something of a hack to use HVC
for QEMU, but the it seems that since we don't emulate either EL2
or EL3 in QEMU, either is an equally sized hack.
* Therefore, we can safely proceed to use HVC for the QEMU TCG case
as well.
- PSCI state migration
* We need to look at using the GET_ONE_REG for the CPU and come up
with a set of PSCI registers that exports the vcpu->pause state.
* This interface can be extended with additional registers if we
properly support power down states for PSCI_SUSPEND, in which case
we need to be able to export the context_id and the reentry
address.
- PSCI suspend implementation, which wake-up events do we support?
* During the review of Anup's PSCI 0.2 patches the question came up
if PSCI_SUSPEND allows spurious wake-ups along the lines WFI?
* Everyone agreed that this was indeed architecture compliant and we
should therefore implement all PSCI suspend calls as suspend
actions, even if a power down state is requested (this is within
the spec). This, however, must be clearly documented in the code
and preferebly also in Documentation/... somehwere.
* The wake-up events for KVM should pretty much be interrupts, and we
need to document this somewhere as well.
- PCI support in QEMU/KVM, state of kernel patches
* Patches for generic PCI support on aarch64
* Will posted generic PCI host controller patches
* Marc added MSI support, connected to GICv3
* Pushing for generic PCI support patches for 3.16
* Peter thinks it is reasonable to implement similar support in QEMU,
but not before the kernel patches are upstream, because we need
some fixed point of reference.
* Once patches go into QEMU, we need to maintain it.
* So we should think about whether it makes sense to directly support
PCIe from the beginning, if that's the only thing we care about.
* MSI-X is an attractive feature, because it gives you a performance
boost in allowing us to use eventfds. (can someone give more
background on this, is this because MSI-X interrupts can be
masked?)
* MSI-X support would be included in the 3.16 kernel patch set
* Another possibility is to model a GICv2m in KVM
* Linaro will look at doing this work
- ABI clarification patch on mmio.data endianness
* should be included in next kvm/arm pull request
- Workflow changes
* changing to a single repo on kernel.org
* should improve the LAVA usefulness
- Virtual IRQs
* We discussed virtual IRQs briefly and the problem of requiring MMIO
traps to know when to unmask IRQs at the host distributor level.
* Marc suggested we look at priorities to handle the situation.
* (Another problem that we did not have time to dicsuss during the
call is that we still don't know when to lower the virtual IRQ line
using this method, and therefore may have to rely on trapping on
the EOI event or the MMIO accesses).
>
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
