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=-5.3 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 A0267C4361B for ; Tue, 15 Dec 2020 07:28:02 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (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 080BB20791 for ; Tue, 15 Dec 2020 07:28:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 080BB20791 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:46378 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kp4ka-0007bl-TY for qemu-devel@archiver.kernel.org; Tue, 15 Dec 2020 02:28:00 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:57812) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kp4gW-0004Rf-5z for qemu-devel@nongnu.org; Tue, 15 Dec 2020 02:23:48 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:2995) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kp4gU-0001HN-Ac for qemu-devel@nongnu.org; Tue, 15 Dec 2020 02:23:47 -0500 Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4Cw8qY15f8zhscW; Tue, 15 Dec 2020 15:23:05 +0800 (CST) Received: from [10.174.187.37] (10.174.187.37) by DGGEMS406-HUB.china.huawei.com (10.3.19.206) with Microsoft SMTP Server id 14.3.498.0; Tue, 15 Dec 2020 15:23:33 +0800 Subject: Re: [PATCH] kvm: Take into account the unaligned section size when preparing bitmap To: Peter Xu References: <20201208114013.875-1-yuzenghui@huawei.com> <20201208151654.GA6432@xz-x1> <6dc82702-9246-4684-4f28-e104abc0c11d@huawei.com> <20201210020843.GB3211@xz-x1> <7d46e5ca-24ab-7c44-201c-77e8fc6a2ace@huawei.com> <20201210145006.GD3211@xz-x1> <2607b4cd-524c-2360-6261-224736861fc4@huawei.com> <20201211152518.GD6520@xz-x1> <41d9ac96-83af-e8c3-6e54-c702f5527f5e@huawei.com> <20201214153625.GF6520@xz-x1> From: zhukeqian Message-ID: Date: Tue, 15 Dec 2020 15:23:34 +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: <20201214153625.GF6520@xz-x1> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.187.37] X-CFilter-Loop: Reflected Received-SPF: pass client-ip=45.249.212.191; envelope-from=zhukeqian1@huawei.com; helo=szxga05-in.huawei.com X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Zenghui Yu , pbonzini@redhat.com, qemu-devel@nongnu.org, wanghaibin.wang@huawei.com Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 2020/12/14 23:36, Peter Xu wrote: > On Mon, Dec 14, 2020 at 10:14:11AM +0800, zhukeqian wrote: > > [...] > >>>>> Though indeed I must confess I don't know how it worked in general when host >>>>> page size != target page size, at least for migration. For example, I believe >>>>> kvm dirty logging is host page size based, though migration should be migrating >>>>> pages in guest page size granule when it spots a dirty bit set. > > [1] > >> Hi Peter, > > Keqian, > >>> OTOH I'm more worried on the other question on how we handle guest psize != >>> host psize case for migration now... >> I think it does not matter when guest_psize != host_psize, as we only need to interact with >> stage2 page tables during migration. Stage2 is enough to tracking guest dirty memory, and even >> if guest close stage1, we also can do a successful migration. > > I don't know why 2-stage matters here, since I believe KVM can track dirty > pages either using two dimentional paging or shadowing, however it's always > done in host small page size. The question I'm confused is there seems to have > a size mismatch between qemu migration and what kvm does [1]. For example, how > migration works on ARM64 where host has psize==4K while guest has psize=64K. > Hi Peter, OK, I got it ;-) Do you mean qemu_real_host_page_size != TARGET_PAGE_SIZE? After my analysis, I see that when qemu_real_host_page_size != TARGET_PAGE_SIZE, there are some problems indeed. I have send out some patches, please check whether they solve this problem, thanks! Keqian. > Thanks, >