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=0.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 061CBC433DB for ; Fri, 19 Feb 2021 16:12:33 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (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 9C93364EC0 for ; Fri, 19 Feb 2021 16:12:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9C93364EC0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.86962.163696 (Exim 4.92) (envelope-from ) id 1lD8OA-00074f-TP; Fri, 19 Feb 2021 16:12:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 86962.163696; Fri, 19 Feb 2021 16:12:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lD8OA-00074Y-Pe; Fri, 19 Feb 2021 16:12:18 +0000 Received: by outflank-mailman (input) for mailman id 86962; Fri, 19 Feb 2021 16:10:38 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lD8MY-00071h-08 for xen-devel@lists.xenproject.org; Fri, 19 Feb 2021 16:10:38 +0000 Received: from mail-ot1-x32f.google.com (unknown [2607:f8b0:4864:20::32f]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 152974fb-6c79-4267-8752-4bcdc551d0b5; Fri, 19 Feb 2021 16:10:37 +0000 (UTC) Received: by mail-ot1-x32f.google.com with SMTP id q4so5521347otm.9 for ; Fri, 19 Feb 2021 08:10:37 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 152974fb-6c79-4267-8752-4bcdc551d0b5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=v7MkuIaxgQ1ml4ate7F2T/nEuIWneFQOQs/Dm6gkCfw=; b=lf9NBKI9DxnzQEiCcAdaAPYWqEt77bmkca/HJc8mT2PIqqY4AvS0zciEhEXubfrpHN nGovZXcOAZeIeP0zD4Y9Ceuoq8jNwX71a+pt+TWmb45G6EQczHmjZvk3cn28MoI/V3sX bTGHCGxA9gA6+4KNta0IRv5nAMJ+xi/MU+H/QFc3Fj4thgO1G3CYG2xcLbdNgk/d1qyL 4HFhFJVH/g4c8ij1tV9rTSgsOP/OI/PFkUWut5vcYF2w9UJd9pKIrZTH5bl/eYRz4QkR eq8FSugWI/nd/Qi02d4m9IrS7iazp8F9pDL6oQuye3jnS1iYBk3U2LQQk1fcO1yVaSKF wkYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=v7MkuIaxgQ1ml4ate7F2T/nEuIWneFQOQs/Dm6gkCfw=; b=DfuiwqIKB9XMgIkNgac9aK3punj+Pjdt/HfESU/a3sAaM9Fcr1PdmJARje2U2Suurz Enurzjgl8GYwUg7OA/iJm1n3mOd/oiQbBwpLCLjT5l+hdFdK3xomGsERNgdJo+XW6Dfb yJJoKe5NJnD5v5HidHl61rueQM0kaC/PS9jy1nYXsTdP/Ni2OphuFf+wl9E42fFOJIX/ e8/7h+Du7dNhwsEg4xo+ePYp/arZkmGH1F4aA1XhbS/LvxoSB3a9GnYX+3DoeWwROfdN KD/vwvCZ8UOV6gm1FIuahhFT25SIJYwNUeQVpuC50w339hfl3v6r6Qb8NJNh5r/u6Rn1 QKiQ== X-Gm-Message-State: AOAM530g98D5+NkavZvQCP3DAL73G30yqVhtqnqW1nBha5jiUB31aeW4 HQDzkudln8REjNTmX3KWstcKBEJ1Luzp6nTDz206OAPQwQ== X-Google-Smtp-Source: ABdhPJwOoeGr8acsF+dBNLbmaVXbY2yvyZys9FcN7wdThmiDFwKSF3BX35N2v72curU1KzeZIGdoKAXdzPp97aB5Ovw= X-Received: by 2002:a9d:d87:: with SMTP id 7mr7559451ots.256.1613751036403; Fri, 19 Feb 2021 08:10:36 -0800 (PST) MIME-Version: 1.0 From: Kevin Negy Date: Fri, 19 Feb 2021 11:10:00 -0500 Message-ID: Subject: How does shadow page table work during migration? To: xen-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="00000000000047e49b05bbb2b138" --00000000000047e49b05bbb2b138 Content-Type: text/plain; charset="UTF-8" Hello, I'm trying to understand how the shadow page table works in Xen, specifically during live migration. My understanding is that after shadow paging is enabled (sh_enable_log_dirty() in xen/arch/x86/mm/shadow/common.c), a shadow page table is created, which is a complete copy of the current guest page table. Then the CR3 register is switched to use this shadow page table as the active table while the guest page table is stored elsewhere. The guest page table itself (and not the individual entries in the page table) is marked as read only so that any guest memory access that requires the page table will result in a page fault. These page faults happen and are trapped to the Xen hypervisor. Xen will then update the shadow page table to match what the guest sees on its page tables. Is this understanding correct? If so, here is where I get confused. During the migration pre-copy phase, each pre-copy iteration reads the dirty bitmap (paging_log_dirty_op() in xen/arch/x86/mm/paging.c) and cleans it. This process seems to destroy all the shadow page tables of the domain with the call to shadow_blow_tables() in sh_clean_dirty_bitmap(). How is the dirty bitmap related to shadow page tables? Why destroy the entire shadow page table if it is the only legitimate page table in CR3 for the domain? Thank you, Kevin --00000000000047e49b05bbb2b138 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I'm trying to understand how= the shadow page table works in Xen, specifically during live migration. My= understanding is that after shadow paging is enabled (sh_enable_log_dirty(= ) in xen/arch/x86/mm/shadow/common.c), a shadow page table is created, whic= h is a complete copy of the current guest page table. Then the CR3 register= is switched to use this shadow page table as the active table while the gu= est page table is stored elsewhere. The guest page table itself (and not th= e individual entries in the page table) is marked as read only so that any = guest memory access that requires the page table will result in a page faul= t. These page faults happen and are trapped to the Xen hypervisor. Xen will= then update the shadow page table to match what the guest sees on its page= tables.

Is this understanding correct?

If so, here is wher= e I get confused. During the migration pre-copy phase, each pre-copy iterat= ion reads the dirty bitmap (paging_log_dirty_op() in xen/arch/x86/mm/paging= .c) and cleans it. This process seems to destroy all the shadow page tables= of the domain with the call to shadow_blow_tables() in sh_clean_dirty_bitm= ap().

How is the dirty bitmap related to shadow page tables? Why de= stroy the entire shadow page table if it is the only legitimate page table = in CR3 for the domain?=C2=A0

Thank you,
<= div>Kevin
--00000000000047e49b05bbb2b138--