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=-6.6 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 B6E0DC433E4 for ; Fri, 21 Aug 2020 03:54:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 95BA320714 for ; Fri, 21 Aug 2020 03:54:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727827AbgHUDye (ORCPT ); Thu, 20 Aug 2020 23:54:34 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:10296 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727066AbgHUDyc (ORCPT ); Thu, 20 Aug 2020 23:54:32 -0400 Received: from DGGEMS404-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 4D20C79887F5437BBDF7; Fri, 21 Aug 2020 11:54:29 +0800 (CST) Received: from [10.174.187.22] (10.174.187.22) by DGGEMS404-HUB.china.huawei.com (10.3.19.204) with Microsoft SMTP Server id 14.3.487.0; Fri, 21 Aug 2020 11:54:23 +0800 Subject: Re: [RFC PATCH 0/5] KVM: arm64: Add pvtime LPT support To: Steven Price , Marc Zyngier References: <20200817084110.2672-1-zhukeqian1@huawei.com> <8308f52e4c906cad710575724f9e3855@kernel.org> CC: , , , , Catalin Marinas , Will Deacon , James Morse , Suzuki K Poulose , , , From: zhukeqian Message-ID: <177a273d-3312-ec33-de0c-fd38b49f153b@huawei.com> Date: Fri, 21 Aug 2020 11:54:22 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.187.22] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/8/19 16:54, Steven Price wrote: > On 18/08/2020 15:41, Marc Zyngier wrote: >> On 2020-08-17 09:41, Keqian Zhu wrote: >>> Hi all, >>> >>> This patch series picks up the LPT pvtime feature originally developed >>> by Steven Price: https://patchwork.kernel.org/cover/10726499/ >>> >>> Backgroud: >>> >>> There is demand for cross-platform migration, which means we have to >>> solve different CPU features and arch counter frequency between hosts. >>> This patch series can solve the latter problem. >>> >>> About LPT: >>> >>> This implements support for Live Physical Time (LPT) which provides the >>> guest with a method to derive a stable counter of time during which the >>> guest is executing even when the guest is being migrated between hosts >>> with different physical counter frequencies. >>> >>> Changes on Steven Price's work: >>> 1. LPT structure: use symmatical semantics of scale multiplier, and use >>> fraction bits instead of "shift" to make everything clear. >>> 2. Structure allocation: host kernel does not allocates the LPT structure, >>> instead it is allocated by userspace through VM attributes. The save/restore >>> functionality can be removed. >>> 3. Since LPT structure just need update once for each guest run, add a flag to >>> indicate the update status. This has two benifits: 1) avoid multiple update >>> by each vCPUs. 2) If the update flag is not set, then return NOT SUPPORT for >>> coressponding guest HVC call. >>> 4. Add VM device attributes interface for userspace configuration. >>> 5. Add a base LPT read/write layer to reduce code. >>> 6. Support ptimer scaling. >>> 7. Support timer event stream translation. >>> >>> Things need concern: >>> 1. https://developer.arm.com/docs/den0057/a needs update. >> >> LPT was explicitly removed from the spec because it doesn't really >> solve the problem, specially for the firmware: EFI knows >> nothing about this, for example. How is it going to work? >> Also, nobody was ever able to explain how this would work for >> nested virt. >> >> ARMv8.4 and ARMv8.6 have the feature set that is required to solve >> this problem without adding more PV to the kernel. > > Hi Marc, > > These are good points, however we do still have the situation that CPUs that don't have ARMv8.4/8.6 clearly cannot implement this. I presume the use-case Keqian is looking at predates the necessary support in the CPU - Keqian if you can provide more details on the architecture(s) involved that would be helpful. > > Nested virt is indeed more of an issue - we did have some ideas around using SDEI that never made it to the spec. However I would argue that the most pragmatic approach would be to not support the combination of nested virt and LPT. Hopefully that can wait until the counter scaling support is available and not require PV. > > We are discussing (re-)releasing the spec with the LPT parts added. If you have fundamental objections then please me know. > > Thanks, > > Steve > . > Hi Marc and Steven, In fact, I have realize a demo which utilize v8.6-ECV to present a constant timer freq to guest. It seems work well, but this approach has some shortcoming: 1. Guest access to cntvct cntv_ctl cntv_tval cntv_cval must trap to EL2. Every trap will take about hundreds of nano-seconds. For every timer interrupt, there is about 5~6 traps, so it will spend several us (this seems not a serious problem :-) ). But trap will cause big deviation for nano-sleep. 2. We have to make cntfrq be a context of guest. However, only the highest exception level has right to modify cntfrq. It means we have to add a new SMC call. 3. cntkctl controls event stream freq, so KVM should also translate the guest access of cntkctl. However we cannot trap guest access of that. Any solution for this problem? I think LPT as a software solution can solve these problems. However, as Marc said, UEFI knows nothing about LPT, and it will access vtimer/counter directly. The key point is how serious the impact is on UEFI. I can see that some UEFI runtime services and drivers/applications will access timer/counter. For runtime services, it is OK. Because we can translate the result which return from UEFI for Linux. For drivers/applications, they will feel time goes faster or slower after migration. This is a problem indeed :-) Thanks, Keqian 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=-6.6 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 E95C9C433E1 for ; Fri, 21 Aug 2020 03:54:38 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 6DACD20714 for ; Fri, 21 Aug 2020 03:54:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6DACD20714 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 9D4BD4C2C9; Thu, 20 Aug 2020 23:54:37 -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 15XZy7A+LTLi; Thu, 20 Aug 2020 23:54:36 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 66A7B4C2D4; Thu, 20 Aug 2020 23:54:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id A8D944C2D3 for ; Thu, 20 Aug 2020 23:54:35 -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 TDhJDFLHbow8 for ; Thu, 20 Aug 2020 23:54:33 -0400 (EDT) Received: from huawei.com (szxga04-in.huawei.com [45.249.212.190]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 9ACE34C248 for ; Thu, 20 Aug 2020 23:54:33 -0400 (EDT) Received: from DGGEMS404-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 4D20C79887F5437BBDF7; Fri, 21 Aug 2020 11:54:29 +0800 (CST) Received: from [10.174.187.22] (10.174.187.22) by DGGEMS404-HUB.china.huawei.com (10.3.19.204) with Microsoft SMTP Server id 14.3.487.0; Fri, 21 Aug 2020 11:54:23 +0800 Subject: Re: [RFC PATCH 0/5] KVM: arm64: Add pvtime LPT support To: Steven Price , Marc Zyngier References: <20200817084110.2672-1-zhukeqian1@huawei.com> <8308f52e4c906cad710575724f9e3855@kernel.org> From: zhukeqian Message-ID: <177a273d-3312-ec33-de0c-fd38b49f153b@huawei.com> Date: Fri, 21 Aug 2020 11:54:22 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [10.174.187.22] X-CFilter-Loop: Reflected Cc: kvm@vger.kernel.org, Catalin Marinas , linux-kernel@vger.kernel.org, yebiaoxiang@huawei.com, Will Deacon , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org 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 2020/8/19 16:54, Steven Price wrote: > On 18/08/2020 15:41, Marc Zyngier wrote: >> On 2020-08-17 09:41, Keqian Zhu wrote: >>> Hi all, >>> >>> This patch series picks up the LPT pvtime feature originally developed >>> by Steven Price: https://patchwork.kernel.org/cover/10726499/ >>> >>> Backgroud: >>> >>> There is demand for cross-platform migration, which means we have to >>> solve different CPU features and arch counter frequency between hosts. >>> This patch series can solve the latter problem. >>> >>> About LPT: >>> >>> This implements support for Live Physical Time (LPT) which provides the >>> guest with a method to derive a stable counter of time during which the >>> guest is executing even when the guest is being migrated between hosts >>> with different physical counter frequencies. >>> >>> Changes on Steven Price's work: >>> 1. LPT structure: use symmatical semantics of scale multiplier, and use >>> fraction bits instead of "shift" to make everything clear. >>> 2. Structure allocation: host kernel does not allocates the LPT structure, >>> instead it is allocated by userspace through VM attributes. The save/restore >>> functionality can be removed. >>> 3. Since LPT structure just need update once for each guest run, add a flag to >>> indicate the update status. This has two benifits: 1) avoid multiple update >>> by each vCPUs. 2) If the update flag is not set, then return NOT SUPPORT for >>> coressponding guest HVC call. >>> 4. Add VM device attributes interface for userspace configuration. >>> 5. Add a base LPT read/write layer to reduce code. >>> 6. Support ptimer scaling. >>> 7. Support timer event stream translation. >>> >>> Things need concern: >>> 1. https://developer.arm.com/docs/den0057/a needs update. >> >> LPT was explicitly removed from the spec because it doesn't really >> solve the problem, specially for the firmware: EFI knows >> nothing about this, for example. How is it going to work? >> Also, nobody was ever able to explain how this would work for >> nested virt. >> >> ARMv8.4 and ARMv8.6 have the feature set that is required to solve >> this problem without adding more PV to the kernel. > > Hi Marc, > > These are good points, however we do still have the situation that CPUs that don't have ARMv8.4/8.6 clearly cannot implement this. I presume the use-case Keqian is looking at predates the necessary support in the CPU - Keqian if you can provide more details on the architecture(s) involved that would be helpful. > > Nested virt is indeed more of an issue - we did have some ideas around using SDEI that never made it to the spec. However I would argue that the most pragmatic approach would be to not support the combination of nested virt and LPT. Hopefully that can wait until the counter scaling support is available and not require PV. > > We are discussing (re-)releasing the spec with the LPT parts added. If you have fundamental objections then please me know. > > Thanks, > > Steve > . > Hi Marc and Steven, In fact, I have realize a demo which utilize v8.6-ECV to present a constant timer freq to guest. It seems work well, but this approach has some shortcoming: 1. Guest access to cntvct cntv_ctl cntv_tval cntv_cval must trap to EL2. Every trap will take about hundreds of nano-seconds. For every timer interrupt, there is about 5~6 traps, so it will spend several us (this seems not a serious problem :-) ). But trap will cause big deviation for nano-sleep. 2. We have to make cntfrq be a context of guest. However, only the highest exception level has right to modify cntfrq. It means we have to add a new SMC call. 3. cntkctl controls event stream freq, so KVM should also translate the guest access of cntkctl. However we cannot trap guest access of that. Any solution for this problem? I think LPT as a software solution can solve these problems. However, as Marc said, UEFI knows nothing about LPT, and it will access vtimer/counter directly. The key point is how serious the impact is on UEFI. I can see that some UEFI runtime services and drivers/applications will access timer/counter. For runtime services, it is OK. Because we can translate the result which return from UEFI for Linux. For drivers/applications, they will feel time goes faster or slower after migration. This is a problem indeed :-) Thanks, Keqian _______________________________________________ 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=-6.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 0E834C433DF for ; Fri, 21 Aug 2020 03:59:53 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 CABB320714 for ; Fri, 21 Aug 2020 03:59:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="bjvJOJ7G" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CABB320714 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=uWNwvCAwSyYb553b607H8852/iQqR37f24tw6ZzHPM0=; b=bjvJOJ7G8AnDm3PAID1SSYvVD 2EChJoKyGkvr1Wz7BV0FaLswYs9nVHuaNOmokQbkSR/SKo7leu+3V403RzGOkkS4gH3ngsB84ZWH0 xCvsy/IfJu63e8Oz3xj3yHFxjBUI5fF11ZOTNJiNLgkizZbnLEcEKVDk0OgKRCMgBZJ+dAfvo/KBA XR+K9PtjmHO7Tz7Ve0mHdjunbbdk9ZiGs8kltzYcR4c8gKPBgzkrnVp0m/f7StDU6JUkgyGjcVrB1 kLj5ZfLxDDSKNtSG4/3NP/iefH4ZFfpkJ1Jpnpe9hcJ5cohnZte8gJdTHfW4rJQp3jIizO0LiLzKB x4L0nqiFA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8yBi-0005YZ-IV; Fri, 21 Aug 2020 03:57:58 +0000 Received: from szxga04-in.huawei.com ([45.249.212.190] helo=huawei.com) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8y8U-0004Dv-1v for linux-arm-kernel@lists.infradead.org; Fri, 21 Aug 2020 03:54:54 +0000 Received: from DGGEMS404-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 4D20C79887F5437BBDF7; Fri, 21 Aug 2020 11:54:29 +0800 (CST) Received: from [10.174.187.22] (10.174.187.22) by DGGEMS404-HUB.china.huawei.com (10.3.19.204) with Microsoft SMTP Server id 14.3.487.0; Fri, 21 Aug 2020 11:54:23 +0800 Subject: Re: [RFC PATCH 0/5] KVM: arm64: Add pvtime LPT support To: Steven Price , Marc Zyngier References: <20200817084110.2672-1-zhukeqian1@huawei.com> <8308f52e4c906cad710575724f9e3855@kernel.org> From: zhukeqian Message-ID: <177a273d-3312-ec33-de0c-fd38b49f153b@huawei.com> Date: Fri, 21 Aug 2020 11:54:22 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [10.174.187.22] X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200820_235439_965207_4F566623 X-CRM114-Status: GOOD ( 22.35 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kvm@vger.kernel.org, Suzuki K Poulose , Catalin Marinas , linux-kernel@vger.kernel.org, xiexiangyou@huawei.com, yebiaoxiang@huawei.com, James Morse , wanghaibin.wang@huawei.com, Will Deacon , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org 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 2020/8/19 16:54, Steven Price wrote: > On 18/08/2020 15:41, Marc Zyngier wrote: >> On 2020-08-17 09:41, Keqian Zhu wrote: >>> Hi all, >>> >>> This patch series picks up the LPT pvtime feature originally developed >>> by Steven Price: https://patchwork.kernel.org/cover/10726499/ >>> >>> Backgroud: >>> >>> There is demand for cross-platform migration, which means we have to >>> solve different CPU features and arch counter frequency between hosts. >>> This patch series can solve the latter problem. >>> >>> About LPT: >>> >>> This implements support for Live Physical Time (LPT) which provides the >>> guest with a method to derive a stable counter of time during which the >>> guest is executing even when the guest is being migrated between hosts >>> with different physical counter frequencies. >>> >>> Changes on Steven Price's work: >>> 1. LPT structure: use symmatical semantics of scale multiplier, and use >>> fraction bits instead of "shift" to make everything clear. >>> 2. Structure allocation: host kernel does not allocates the LPT structure, >>> instead it is allocated by userspace through VM attributes. The save/restore >>> functionality can be removed. >>> 3. Since LPT structure just need update once for each guest run, add a flag to >>> indicate the update status. This has two benifits: 1) avoid multiple update >>> by each vCPUs. 2) If the update flag is not set, then return NOT SUPPORT for >>> coressponding guest HVC call. >>> 4. Add VM device attributes interface for userspace configuration. >>> 5. Add a base LPT read/write layer to reduce code. >>> 6. Support ptimer scaling. >>> 7. Support timer event stream translation. >>> >>> Things need concern: >>> 1. https://developer.arm.com/docs/den0057/a needs update. >> >> LPT was explicitly removed from the spec because it doesn't really >> solve the problem, specially for the firmware: EFI knows >> nothing about this, for example. How is it going to work? >> Also, nobody was ever able to explain how this would work for >> nested virt. >> >> ARMv8.4 and ARMv8.6 have the feature set that is required to solve >> this problem without adding more PV to the kernel. > > Hi Marc, > > These are good points, however we do still have the situation that CPUs that don't have ARMv8.4/8.6 clearly cannot implement this. I presume the use-case Keqian is looking at predates the necessary support in the CPU - Keqian if you can provide more details on the architecture(s) involved that would be helpful. > > Nested virt is indeed more of an issue - we did have some ideas around using SDEI that never made it to the spec. However I would argue that the most pragmatic approach would be to not support the combination of nested virt and LPT. Hopefully that can wait until the counter scaling support is available and not require PV. > > We are discussing (re-)releasing the spec with the LPT parts added. If you have fundamental objections then please me know. > > Thanks, > > Steve > . > Hi Marc and Steven, In fact, I have realize a demo which utilize v8.6-ECV to present a constant timer freq to guest. It seems work well, but this approach has some shortcoming: 1. Guest access to cntvct cntv_ctl cntv_tval cntv_cval must trap to EL2. Every trap will take about hundreds of nano-seconds. For every timer interrupt, there is about 5~6 traps, so it will spend several us (this seems not a serious problem :-) ). But trap will cause big deviation for nano-sleep. 2. We have to make cntfrq be a context of guest. However, only the highest exception level has right to modify cntfrq. It means we have to add a new SMC call. 3. cntkctl controls event stream freq, so KVM should also translate the guest access of cntkctl. However we cannot trap guest access of that. Any solution for this problem? I think LPT as a software solution can solve these problems. However, as Marc said, UEFI knows nothing about LPT, and it will access vtimer/counter directly. The key point is how serious the impact is on UEFI. I can see that some UEFI runtime services and drivers/applications will access timer/counter. For runtime services, it is OK. Because we can translate the result which return from UEFI for Linux. For drivers/applications, they will feel time goes faster or slower after migration. This is a problem indeed :-) Thanks, Keqian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel