From patchwork Fri Jan 29 09:32:37 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: alvise rigo X-Patchwork-Id: 8161081 Return-Path: X-Original-To: patchwork-qemu-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 16741BEEE5 for ; Fri, 29 Jan 2016 09:39:55 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 24674200C1 for ; Fri, 29 Jan 2016 09:39:54 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BEBCF20375 for ; Fri, 29 Jan 2016 09:39:52 +0000 (UTC) Received: from localhost ([::1]:60762 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aP5Wy-0002hi-7F for patchwork-qemu-devel@patchwork.kernel.org; Fri, 29 Jan 2016 04:39:52 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33670) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aP5QV-0007Wf-Kg for qemu-devel@nongnu.org; Fri, 29 Jan 2016 04:33:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aP5QU-0000Tl-7m for qemu-devel@nongnu.org; Fri, 29 Jan 2016 04:33:11 -0500 Received: from mail-wm0-x234.google.com ([2a00:1450:400c:c09::234]:34054) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aP5QT-0000TS-TE for qemu-devel@nongnu.org; Fri, 29 Jan 2016 04:33:10 -0500 Received: by mail-wm0-x234.google.com with SMTP id 128so44747066wmz.1 for ; Fri, 29 Jan 2016 01:33:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtualopensystems-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=RzAySDfYoMmjDZGVmB+0Q/I1jRM/Unxq3ypDBB0TuDQ=; b=h/yA6xY/wt7aKqU4Xf73bpuio/JyCx+nLq8bdfYwZzt3pOtanTCiBi/e7SftD/+3Te b3eP/7kpjZlfKqRuKNI80wYaxefJ2xV936dzolgXiFZxHp0op76mUCcKQgAXzRuPuKJn 1/PSgPnIQ0cLa/D7eUlR0r1164uQgBZCPhNLhxs3PmG0PtyYQ4MabgORjTbJ4j0ZaPdo VBiOR+ZqiO4icdOl6nmJmHO1wDV+FfknJ6gO0dULKWN4lL1p5rIyyIVMYR0/3wfZMJXw gDULsXB6gj5bodwdyow7Cbf1S+f6Ba3GgGyOucyspK3aS+Q+H694ssb2vmm76K6nDmpH XDYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=RzAySDfYoMmjDZGVmB+0Q/I1jRM/Unxq3ypDBB0TuDQ=; b=cKHKk1QDOdUjY0gLJo7ZGi3GWdzneuB05zQXn9B/k4Vnc9+YU9Xxgl7sdrJyu5074I qiF+xad5n9mZfaS+UOm6jjJXAbQ0FY5uVGMZnt3YG8LU76XpPjif4EKfpBUtiHtnbkWn UOxowmOxLp525kTa7fimk9SmnoZZUgM5ShSrx3gsNAoTytMrZS5Rs2AMmsVVlyxkHOz8 FIcduZSwLySOUuxV+BNizwDyAzQewTT5Vz5FL4ClzQ+gKC6Fl2B/BHJi/RfDWMQr6YXb NmTDsxHwDmR0Ddudc3lLZqoVvASbqvw1+WvkOl4rSse1rr6u+3SVnrcHQF9umWB8PhVj ucCQ== X-Gm-Message-State: AG10YOSCIf8KI7xSUlNhNCfjdwUY5+TwIwS24c53TXchW/zNIOo8uouUcmb5bvXTd4dEnw== X-Received: by 10.194.20.5 with SMTP id j5mr7567295wje.71.1454059989337; Fri, 29 Jan 2016 01:33:09 -0800 (PST) Received: from localhost.localdomain (LPuteaux-656-1-278-113.w80-15.abo.wanadoo.fr. [80.15.154.113]) by smtp.googlemail.com with ESMTPSA id o7sm14765451wjf.45.2016.01.29.01.33.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 29 Jan 2016 01:33:08 -0800 (PST) From: Alvise Rigo To: qemu-devel@nongnu.org, mttcg@listserver.greensocs.com Date: Fri, 29 Jan 2016 10:32:37 +0100 Message-Id: <1454059965-23402-9-git-send-email-a.rigo@virtualopensystems.com> X-Mailer: git-send-email 2.7.0 In-Reply-To: <1454059965-23402-1-git-send-email-a.rigo@virtualopensystems.com> References: <1454059965-23402-1-git-send-email-a.rigo@virtualopensystems.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::234 Cc: claudio.fontana@huawei.com, pbonzini@redhat.com, jani.kokkonen@huawei.com, tech@virtualopensystems.com, alex.bennee@linaro.org, rth@twiddle.net Subject: [Qemu-devel] [RFC v7 08/16] softmmu: Honor the new exclusive bitmap X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The pages set as exclusive (clean) in the DIRTY_MEMORY_EXCLUSIVE bitmap have to have their TLB entries flagged with TLB_EXCL. The accesses to pages with TLB_EXCL flag set have to be properly handled in that they can potentially invalidate an open LL/SC transaction. Modify the TLB entries generation to honor the new bitmap and extend the softmmu_template to handle the accesses made to guest pages marked as exclusive. In the case we remove a TLB entry marked as EXCL, we unset the corresponding exclusive bit in the bitmap. Suggested-by: Jani Kokkonen Suggested-by: Claudio Fontana Signed-off-by: Alvise Rigo --- cputlb.c | 44 ++++++++++++++++++++++++++++-- softmmu_template.h | 80 ++++++++++++++++++++++++++++++++++++++++++++++++------ 2 files changed, 113 insertions(+), 11 deletions(-) diff --git a/cputlb.c b/cputlb.c index ce6d720..aa9cc17 100644 --- a/cputlb.c +++ b/cputlb.c @@ -395,6 +395,16 @@ void tlb_set_page_with_attrs(CPUState *cpu, target_ulong vaddr, env->tlb_v_table[mmu_idx][vidx] = *te; env->iotlb_v[mmu_idx][vidx] = env->iotlb[mmu_idx][index]; + if (unlikely(!(te->addr_write & TLB_MMIO) && (te->addr_write & TLB_EXCL))) { + /* We are removing an exclusive entry, set the page to dirty. This + * is not be necessary if the vCPU has performed both SC and LL. */ + hwaddr hw_addr = (env->iotlb[mmu_idx][index].addr & TARGET_PAGE_MASK) + + (te->addr_write & TARGET_PAGE_MASK); + if (!cpu->ll_sc_context) { + cpu_physical_memory_unset_excl(hw_addr); + } + } + /* refill the tlb */ env->iotlb[mmu_idx][index].addr = iotlb - vaddr; env->iotlb[mmu_idx][index].attrs = attrs; @@ -418,9 +428,19 @@ void tlb_set_page_with_attrs(CPUState *cpu, target_ulong vaddr, } else if (memory_region_is_ram(section->mr) && cpu_physical_memory_is_clean(section->mr->ram_addr + xlat)) { - te->addr_write = address | TLB_NOTDIRTY; - } else { - te->addr_write = address; + address |= TLB_NOTDIRTY; + } + + /* Since the MMIO accesses follow always the slow path, we do not need + * to set any flag to trap the access */ + if (!(address & TLB_MMIO)) { + if (cpu_physical_memory_is_excl(section->mr->ram_addr + xlat)) { + /* There is at least one vCPU that has flagged the address as + * exclusive. */ + te->addr_write = address | TLB_EXCL; + } else { + te->addr_write = address; + } } } else { te->addr_write = -1; @@ -474,6 +494,24 @@ tb_page_addr_t get_page_addr_code(CPUArchState *env1, target_ulong addr) return qemu_ram_addr_from_host_nofail(p); } +/* For every vCPU compare the exclusive address and reset it in case of a + * match. Since only one vCPU is running at once, no lock has to be held to + * guard this operation. */ +static inline void lookup_and_reset_cpus_ll_addr(hwaddr addr, hwaddr size) +{ + CPUState *cpu; + + CPU_FOREACH(cpu) { + if (cpu->excl_protected_range.begin != EXCLUSIVE_RESET_ADDR && + ranges_overlap(cpu->excl_protected_range.begin, + cpu->excl_protected_range.end - + cpu->excl_protected_range.begin, + addr, size)) { + cpu->excl_protected_range.begin = EXCLUSIVE_RESET_ADDR; + } + } +} + #define MMUSUFFIX _mmu /* Generates LoadLink/StoreConditional helpers in softmmu_template.h */ diff --git a/softmmu_template.h b/softmmu_template.h index 4332db2..267c52a 100644 --- a/softmmu_template.h +++ b/softmmu_template.h @@ -474,11 +474,43 @@ void helper_le_st_name(CPUArchState *env, target_ulong addr, DATA_TYPE val, tlb_addr = env->tlb_table[mmu_idx][index].addr_write; } - /* Handle an IO access. */ + /* Handle an IO access or exclusive access. */ if (unlikely(tlb_addr & ~TARGET_PAGE_MASK)) { - glue(helper_le_st_name, _do_mmio_access)(env, val, addr, oi, - mmu_idx, index, retaddr); - return; + if ((tlb_addr & ~TARGET_PAGE_MASK) == TLB_EXCL) { + CPUIOTLBEntry *iotlbentry = &env->iotlb[mmu_idx][index]; + CPUState *cpu = ENV_GET_CPU(env); + CPUClass *cc = CPU_GET_CLASS(cpu); + /* The slow-path has been forced since we are writing to + * exclusive-protected memory. */ + hwaddr hw_addr = (iotlbentry->addr & TARGET_PAGE_MASK) + addr; + + /* The function lookup_and_reset_cpus_ll_addr could have reset the + * exclusive address. Fail the SC in this case. + * N.B.: here excl_succeed == true means that the caller is + * helper_stcond_name in softmmu_llsc_template. + * On the contrary, excl_succeeded == false occurs when a VCPU is + * writing through normal store to a page with TLB_EXCL bit set. */ + if (cpu->excl_succeeded) { + if (!cc->cpu_valid_excl_access(cpu, hw_addr, DATA_SIZE)) { + /* The vCPU is SC-ing to an unprotected address. */ + cpu->excl_protected_range.begin = EXCLUSIVE_RESET_ADDR; + cpu->excl_succeeded = false; + + return; + } + } + + glue(helper_le_st_name, _do_ram_access)(env, val, addr, oi, + mmu_idx, index, retaddr); + + lookup_and_reset_cpus_ll_addr(hw_addr, DATA_SIZE); + + return; + } else { + glue(helper_le_st_name, _do_mmio_access)(env, val, addr, oi, + mmu_idx, index, retaddr); + return; + } } glue(helper_le_st_name, _do_ram_access)(env, val, addr, oi, mmu_idx, index, @@ -586,11 +618,43 @@ void helper_be_st_name(CPUArchState *env, target_ulong addr, DATA_TYPE val, tlb_addr = env->tlb_table[mmu_idx][index].addr_write; } - /* Handle an IO access. */ + /* Handle an IO access or exclusive access. */ if (unlikely(tlb_addr & ~TARGET_PAGE_MASK)) { - glue(helper_be_st_name, _do_mmio_access)(env, val, addr, oi, - mmu_idx, index, retaddr); - return; + if ((tlb_addr & ~TARGET_PAGE_MASK) == TLB_EXCL) { + CPUIOTLBEntry *iotlbentry = &env->iotlb[mmu_idx][index]; + CPUState *cpu = ENV_GET_CPU(env); + CPUClass *cc = CPU_GET_CLASS(cpu); + /* The slow-path has been forced since we are writing to + * exclusive-protected memory. */ + hwaddr hw_addr = (iotlbentry->addr & TARGET_PAGE_MASK) + addr; + + /* The function lookup_and_reset_cpus_ll_addr could have reset the + * exclusive address. Fail the SC in this case. + * N.B.: here excl_succeed == true means that the caller is + * helper_stcond_name in softmmu_llsc_template. + * On the contrary, excl_succeeded == false occurs when a VCPU is + * writing through normal store to a page with TLB_EXCL bit set. */ + if (cpu->excl_succeeded) { + if (!cc->cpu_valid_excl_access(cpu, hw_addr, DATA_SIZE)) { + /* The vCPU is SC-ing to an unprotected address. */ + cpu->excl_protected_range.begin = EXCLUSIVE_RESET_ADDR; + cpu->excl_succeeded = false; + + return; + } + } + + glue(helper_be_st_name, _do_ram_access)(env, val, addr, oi, + mmu_idx, index, retaddr); + + lookup_and_reset_cpus_ll_addr(hw_addr, DATA_SIZE); + + return; + } else { + glue(helper_be_st_name, _do_mmio_access)(env, val, addr, oi, + mmu_idx, index, retaddr); + return; + } } glue(helper_be_st_name, _do_ram_access)(env, val, addr, oi, mmu_idx, index,