From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Zyngier Subject: Re: [PATCH v5 13/14] KVM: ARM: Handle I/O aborts Date: Tue, 15 Jan 2013 13:29:40 +0000 Message-ID: <50F559C4.8080900@arm.com> References: <20130108183811.46302.58543.stgit@ubuntu> <20130108184005.46302.38495.stgit@ubuntu> <20130115131855.GL11529@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: 8BIT Cc: Christoffer Dall , "kvm@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "kvmarm@lists.cs.columbia.edu" , Marcelo Tosatti , Rusty Russell To: Gleb Natapov Return-path: Received: from service87.mimecast.com ([91.220.42.44]:44067 "EHLO service87.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751916Ab3AON3o convert rfc822-to-8bit (ORCPT ); Tue, 15 Jan 2013 08:29:44 -0500 In-Reply-To: <20130115131855.GL11529@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 15/01/13 13:18, Gleb Natapov wrote: > On Tue, Jan 08, 2013 at 01:40:05PM -0500, Christoffer Dall wrote: >> When the guest accesses I/O memory this will create data abort >> exceptions and they are handled by decoding the HSR information >> (physical address, read/write, length, register) and forwarding reads >> and writes to QEMU which performs the device emulation. >> >> Certain classes of load/store operations do not support the syndrome >> information provided in the HSR and we therefore must be able to fetch >> the offending instruction from guest memory and decode it manually. >> >> We only support instruction decoding for valid reasonable MMIO operations >> where trapping them do not provide sufficient information in the HSR (no >> 16-bit Thumb instructions provide register writeback that we care about). >> >> The following instruction types are NOT supported for MMIO operations >> despite the HSR not containing decode info: >> - any Load/Store multiple >> - any load/store exclusive >> - any load/store dual >> - anything with the PC as the dest register >> >> This requires changing the general flow somewhat since new calls to run >> the VCPU must check if there's a pending MMIO load and perform the write >> after userspace has made the data available. >> >> Rusty Russell fixed a horrible race pointed out by Ben Herrenschmidt: >> (1) Guest complicated mmio instruction traps. >> (2) The hardware doesn't tell us enough, so we need to read the actual >> instruction which was being exectuted. >> (3) KVM maps the instruction virtual address to a physical address. >> (4) The guest (SMP) swaps out that page, and fills it with something else. >> (5) We read the physical address, but now that's the wrong thing. > How can this happen?! The guest cannot reuse physical page before it > flushes it from all vcpus tlb cache. For that it needs to send > synchronous IPI to all vcpus and IPI will not be processed by a vcpu > while it does emulation. I don't know how this works on x86, but a KVM/ARM guest can definitely handle an IPI. Furthermore, TLB invalidation doesn't require an IPI on ARMv7 (unless we're doing some set/way operation which is handled separately). M. -- Jazz is not dead. It just smells funny...