From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5D4BC432BE for ; Fri, 20 Aug 2021 18:22:58 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 152B961268 for ; Fri, 20 Aug 2021 18:22:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 152B961268 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 6B5404B104; Fri, 20 Aug 2021 14:22:57 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zATDKuVJkeJN; Fri, 20 Aug 2021 14:22:53 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 7B6024B10B; Fri, 20 Aug 2021 14:22:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 123664B0FC for ; Fri, 20 Aug 2021 14:22:52 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zc5EJ2gVQBzM for ; Fri, 20 Aug 2021 14:22:51 -0400 (EDT) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id D8D4F409DD for ; Fri, 20 Aug 2021 14:22:50 -0400 (EDT) Received: by mail-lf1-f46.google.com with SMTP id g13so22296265lfj.12 for ; Fri, 20 Aug 2021 11:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zDMz36x4yKQMykOmV38uNAmEx7fWvh5K0Ht5jE7INgk=; b=Y9OO0b8f19YmabyG92B9Kuy1+feyypMWz7BFCyCyfsyYJj+hx3l6T09vZ+qUzq4V5K 2SlCFAhM4pTllTgtEzfCfFLmrUw/4hU17q70A6oqFWfiZEzOzLr6VHlYrHUlBIkiplJK H6pYwQvTQZZeGaGfuBXSErpKKnKEV0Q/U8pU3LnW29oU+SBnMuvJ3ucmaanMUsfWi6mF 2Btm+e9FpjNvLxzYQZdJid2UhYdOCXlBrDFNbrtYzO3RImslr6lZWxq7FAJ0wrUgF9rn sBEa3hNIVj7+hTW2eR9TBuwb/rSH/bBPbKsehu91kbdDr6lEsZBbt/DmRuZI7yMQ9VRH iZzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zDMz36x4yKQMykOmV38uNAmEx7fWvh5K0Ht5jE7INgk=; b=uFJWtoEDfmknggDqBbHyjR14i2PeRzQn9ciigL8J7dyxpvb7Es31JLh7XP692X/wPy sT+9dxiZG+vMNnsf9eAXIec3NwCa9d29SDSmuQ4Q0LAqOnrEwWJgXxv8AHz6zCyvHZCz PkPc8L1V3gopeFLtJdyUBqjncqM+M7WCdx5pO/zbEDOK8HF8u7iif801YQSK3AnXXwz0 ghhwq1MMbhb9+U3HSqzO3BxwkwZ3cN0PzgqJ31YhYiHD5fi6avsvc4QLNWbxXxkk4Q5X CwK/qthNuAgDZvvbiUr6zF3jNE1pfYELMNY5ELl9903sipG5NlRgQth6ia0aDe5ozxoa N72w== X-Gm-Message-State: AOAM533/5/9j63YYxMhq8qk2OF0crffvJYKjMA4ZVI7tkpLzKL0M3rmS jZIEjHyr8gAaLBimmQwL6YveFFC1Jph7u4/CG8hO9A== X-Google-Smtp-Source: ABdhPJzTvCiSF40hWim53AIx0O9SVmdquq5dpPkCWKWdqy+7H6yPirLretuTQkPUsSrtEbmbLIg+wMxDI3XaHyvGxDk= X-Received: by 2002:ac2:5fc7:: with SMTP id q7mr15153411lfg.524.1629483769092; Fri, 20 Aug 2021 11:22:49 -0700 (PDT) MIME-Version: 1.0 References: <20210816001130.3059564-1-oupton@google.com> <20210816001130.3059564-2-oupton@google.com> <20210819182422.GA25923@fuller.cnet> In-Reply-To: <20210819182422.GA25923@fuller.cnet> From: Oliver Upton Date: Fri, 20 Aug 2021 11:22:38 -0700 Message-ID: Subject: Re: [PATCH v7 1/6] KVM: x86: Fix potential race in KVM_GET_CLOCK To: Marcelo Tosatti Cc: Catalin Marinas , kvm@vger.kernel.org, Will Deacon , Marc Zyngier , Peter Shier , Sean Christopherson , David Matlack , Paolo Bonzini , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, Jim Mattson X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Thu, Aug 19, 2021 at 11:43 AM Marcelo Tosatti wrote: > > On Mon, Aug 16, 2021 at 12:11:25AM +0000, Oliver Upton wrote: > > Sean noticed that KVM_GET_CLOCK was checking kvm_arch.use_master_clock > > outside of the pvclock sync lock. This is problematic, as the clock > > value written to the user may or may not actually correspond to a stable > > TSC. > > > > Fix the race by populating the entire kvm_clock_data structure behind > > the pvclock_gtod_sync_lock. > > Oliver, > > Can you please describe the race in more detail? > > Is it about host TSC going unstable VS parallel KVM_GET_CLOCK ? > Yeah, pretty much any event that causes us to set use_master_clock = false could interleave with the KVM_GET_CLOCK ioctl. A guest could kick its TSCs out of sync, for example, to cause this too. AFAICT, KVM serializes the write side (pvclock_update_vm_gtod_copy()) with pvclock_gtod_sync_lock, as it should. -- Thanks, Oliver _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 45147C4338F for ; Fri, 20 Aug 2021 18:24:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2F81C61351 for ; Fri, 20 Aug 2021 18:24:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238426AbhHTSZQ (ORCPT ); Fri, 20 Aug 2021 14:25:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32816 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239615AbhHTSY5 (ORCPT ); Fri, 20 Aug 2021 14:24:57 -0400 Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1C44BC061154 for ; Fri, 20 Aug 2021 11:22:51 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id f10so7554792lfv.6 for ; Fri, 20 Aug 2021 11:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zDMz36x4yKQMykOmV38uNAmEx7fWvh5K0Ht5jE7INgk=; b=Y9OO0b8f19YmabyG92B9Kuy1+feyypMWz7BFCyCyfsyYJj+hx3l6T09vZ+qUzq4V5K 2SlCFAhM4pTllTgtEzfCfFLmrUw/4hU17q70A6oqFWfiZEzOzLr6VHlYrHUlBIkiplJK H6pYwQvTQZZeGaGfuBXSErpKKnKEV0Q/U8pU3LnW29oU+SBnMuvJ3ucmaanMUsfWi6mF 2Btm+e9FpjNvLxzYQZdJid2UhYdOCXlBrDFNbrtYzO3RImslr6lZWxq7FAJ0wrUgF9rn sBEa3hNIVj7+hTW2eR9TBuwb/rSH/bBPbKsehu91kbdDr6lEsZBbt/DmRuZI7yMQ9VRH iZzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zDMz36x4yKQMykOmV38uNAmEx7fWvh5K0Ht5jE7INgk=; b=F+7cJEWzymWf4i6cqUq8F383X5axQfurHYe+jwwOKc1aqce2JqA/7fI4dGTVNOvuTr KNKrU/xW9ixhNNhJULOQFyjdpvIjmUEV2nGu8cpNcapCxX/3LAtyXrxZ0sOeGoyb/a1I GLUgawx4VCkI97MRdVQTyfrLuG76Fo91wFc6STS1K46rPa6v9w9Zl0buo9EdkbOF1SBV mKU77dFSuLhyFXMa+2urwB+ouYpxkjQrxLvuRx+9G3uQcf/pJ1J3JEsBieTG7tixxd6L 3EcvxgMzdUGM5FJQsDoyycFKzyK/r78PqUQwwOs6WZF6NemX+iLctWseYmmswoyib2a/ o7hw== X-Gm-Message-State: AOAM530NUIanw+6xmjfNnG8Fs0mj1QWUzNUnR2ulD6UKSg9jTciU+DmI 8W94es9Eb/FnUAc8qtfHBmcw9pZ52dPvmbW3iYLDqaNjZRQ= X-Google-Smtp-Source: ABdhPJzTvCiSF40hWim53AIx0O9SVmdquq5dpPkCWKWdqy+7H6yPirLretuTQkPUsSrtEbmbLIg+wMxDI3XaHyvGxDk= X-Received: by 2002:ac2:5fc7:: with SMTP id q7mr15153411lfg.524.1629483769092; Fri, 20 Aug 2021 11:22:49 -0700 (PDT) MIME-Version: 1.0 References: <20210816001130.3059564-1-oupton@google.com> <20210816001130.3059564-2-oupton@google.com> <20210819182422.GA25923@fuller.cnet> In-Reply-To: <20210819182422.GA25923@fuller.cnet> From: Oliver Upton Date: Fri, 20 Aug 2021 11:22:38 -0700 Message-ID: Subject: Re: [PATCH v7 1/6] KVM: x86: Fix potential race in KVM_GET_CLOCK To: Marcelo Tosatti Cc: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, Paolo Bonzini , Sean Christopherson , Marc Zyngier , Peter Shier , Jim Mattson , David Matlack , Ricardo Koller , Jing Zhang , Raghavendra Rao Anata , James Morse , Alexandru Elisei , Suzuki K Poulose , linux-arm-kernel@lists.infradead.org, Andrew Jones , Will Deacon , Catalin Marinas Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Thu, Aug 19, 2021 at 11:43 AM Marcelo Tosatti wrote: > > On Mon, Aug 16, 2021 at 12:11:25AM +0000, Oliver Upton wrote: > > Sean noticed that KVM_GET_CLOCK was checking kvm_arch.use_master_clock > > outside of the pvclock sync lock. This is problematic, as the clock > > value written to the user may or may not actually correspond to a stable > > TSC. > > > > Fix the race by populating the entire kvm_clock_data structure behind > > the pvclock_gtod_sync_lock. > > Oliver, > > Can you please describe the race in more detail? > > Is it about host TSC going unstable VS parallel KVM_GET_CLOCK ? > Yeah, pretty much any event that causes us to set use_master_clock = false could interleave with the KVM_GET_CLOCK ioctl. A guest could kick its TSCs out of sync, for example, to cause this too. AFAICT, KVM serializes the write side (pvclock_update_vm_gtod_copy()) with pvclock_gtod_sync_lock, as it should. -- Thanks, Oliver From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C907AC432BE for ; Fri, 20 Aug 2021 18:26:01 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9AFB26120C for ; Fri, 20 Aug 2021 18:26:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 9AFB26120C Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=efV6IwkRM/K1bxzo04O91XyimsFHVCg+fKmldYxP6rE=; b=Gsh/unrgyYsGlW B1P+RbNJxnLUbazcm74VslmYQxsL31Nv3IZy4QLFjO012iC+b0JCMBp4fyH3ZSao8MCxEdjBWT9+a scwjz1tkv6S1R0L7HWWBJkvt3ZQA7mSV2V51d/kqvO2AvJbMaJg3uaOllnqIg/tyzvpu93pHW0aaf geGtanhUcQqmGabc3e6tH6eFhg0CG3Oq5tEuiDnMIMO71LzCgs2ZXv0zFcJe0csG4/1214BH3xT16 /q4nMDD/QayEmK3M9yxXFs/DxDmm+JEEGuvjvhA1LGXxD78gTbfKyDb9NQeba23/s2IHChHEkDj/j uBfruSgPVhwJRseFc6Hw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mH9AP-00Bpgd-Rc; Fri, 20 Aug 2021 18:22:58 +0000 Received: from mail-lf1-x12c.google.com ([2a00:1450:4864:20::12c]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mH9AM-00Bpfj-Og for linux-arm-kernel@lists.infradead.org; Fri, 20 Aug 2021 18:22:55 +0000 Received: by mail-lf1-x12c.google.com with SMTP id k5so22370476lfu.4 for ; Fri, 20 Aug 2021 11:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zDMz36x4yKQMykOmV38uNAmEx7fWvh5K0Ht5jE7INgk=; b=Y9OO0b8f19YmabyG92B9Kuy1+feyypMWz7BFCyCyfsyYJj+hx3l6T09vZ+qUzq4V5K 2SlCFAhM4pTllTgtEzfCfFLmrUw/4hU17q70A6oqFWfiZEzOzLr6VHlYrHUlBIkiplJK H6pYwQvTQZZeGaGfuBXSErpKKnKEV0Q/U8pU3LnW29oU+SBnMuvJ3ucmaanMUsfWi6mF 2Btm+e9FpjNvLxzYQZdJid2UhYdOCXlBrDFNbrtYzO3RImslr6lZWxq7FAJ0wrUgF9rn sBEa3hNIVj7+hTW2eR9TBuwb/rSH/bBPbKsehu91kbdDr6lEsZBbt/DmRuZI7yMQ9VRH iZzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zDMz36x4yKQMykOmV38uNAmEx7fWvh5K0Ht5jE7INgk=; b=AboHSnl6QLjCWMKBlb36lq1PQE59iHzMzUOfpOTFXZY6QbKCYQKI04tRoGfpLD7W/t acMj0oVdPkbdK9Jv7dcNilizv6YKvI3jrvDTw3O/YImnTNU9gXz0z4nUw7rAxtu2Y8dF 3dV2dWclAgVhkv4CsP6mD6Ic3TFDutW8RIqGRdbMkd8LtAw44vk0uT7eV2W3id7VITWA 777uAunNvfN9QClTXakQ+Gb8uBFffpLRwN2hh7VTOryv7laZARQ/c5df94v0I/9MqHqx BeI5s3IFD+u8TaHBdADbq2hwY9/SC+AZJ/2oVPZVA6Oa06nnVrz9mqXZXL3YzNLtQdpT Vn1Q== X-Gm-Message-State: AOAM533IjEU4egZ1mC56xlIdwbSZV2uFtx7BRn00iBAV1dFsNLxeE9mr Yzb/7g40s4tWzX1BqiTD/GRqabsDG47EPQqu+zD8hQ== X-Google-Smtp-Source: ABdhPJzTvCiSF40hWim53AIx0O9SVmdquq5dpPkCWKWdqy+7H6yPirLretuTQkPUsSrtEbmbLIg+wMxDI3XaHyvGxDk= X-Received: by 2002:ac2:5fc7:: with SMTP id q7mr15153411lfg.524.1629483769092; Fri, 20 Aug 2021 11:22:49 -0700 (PDT) MIME-Version: 1.0 References: <20210816001130.3059564-1-oupton@google.com> <20210816001130.3059564-2-oupton@google.com> <20210819182422.GA25923@fuller.cnet> In-Reply-To: <20210819182422.GA25923@fuller.cnet> From: Oliver Upton Date: Fri, 20 Aug 2021 11:22:38 -0700 Message-ID: Subject: Re: [PATCH v7 1/6] KVM: x86: Fix potential race in KVM_GET_CLOCK To: Marcelo Tosatti Cc: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, Paolo Bonzini , Sean Christopherson , Marc Zyngier , Peter Shier , Jim Mattson , David Matlack , Ricardo Koller , Jing Zhang , Raghavendra Rao Anata , James Morse , Alexandru Elisei , Suzuki K Poulose , linux-arm-kernel@lists.infradead.org, Andrew Jones , Will Deacon , Catalin Marinas X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210820_112254_844497_1B1DA097 X-CRM114-Status: GOOD ( 15.41 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Aug 19, 2021 at 11:43 AM Marcelo Tosatti wrote: > > On Mon, Aug 16, 2021 at 12:11:25AM +0000, Oliver Upton wrote: > > Sean noticed that KVM_GET_CLOCK was checking kvm_arch.use_master_clock > > outside of the pvclock sync lock. This is problematic, as the clock > > value written to the user may or may not actually correspond to a stable > > TSC. > > > > Fix the race by populating the entire kvm_clock_data structure behind > > the pvclock_gtod_sync_lock. > > Oliver, > > Can you please describe the race in more detail? > > Is it about host TSC going unstable VS parallel KVM_GET_CLOCK ? > Yeah, pretty much any event that causes us to set use_master_clock = false could interleave with the KVM_GET_CLOCK ioctl. A guest could kick its TSCs out of sync, for example, to cause this too. AFAICT, KVM serializes the write side (pvclock_update_vm_gtod_copy()) with pvclock_gtod_sync_lock, as it should. -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel