xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Negy <kevinnegy@gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel@lists.xenproject.org
Subject: Re: How does shadow page table work during migration?
Date: Mon, 22 Feb 2021 13:52:31 -0500	[thread overview]
Message-ID: <CACZWC-r7fS2AztaAgGdVPv5NcJiAxZ5mvC4FQTkorPDGwOfn9g@mail.gmail.com> (raw)
In-Reply-To: <38cf0d39-da1d-5375-89dc-1668e26323a2@citrix.com>

[-- Attachment #1: Type: text/plain, Size: 2565 bytes --]

Hello again,

Thank you for the helpful responses. I have several follow up questions.

1)

> With Shadow, Xen has to do the combination of address spaces itself -
> the shadow pagetables map guest virtual to host physical address.


The shadow_blow_tables() call is "please recycle everything" which is used
> to throw away all shadow pagetables, which in turn will cause the
> shadows to be recreated from scratch as the guest continues to run.


With shadowing enabled, given a guest virtual address, how does the
hypervisor recreate the mapping to the host physical address (mfn) from the
virtual address if the shadow page tables are empty (after a call to
shadow_blow_tables, for instance)? I had been thinking of shadow page
tables as the definitive mapping between guest pages and machine pages, but
should I think of them as more of a TLB, which implies there's another way
to get/recreate the mappings if there's no entry in the shadow table?


2) I'm trying to grasp the general steps of enabling shadowing and handling
page faults. Is this correct?
    a) Normal PV - default shadowing is disabled, guest has its page tables
in r/w mode or whatever mode is considered normal for guest page tables
    b) Shadowing is enabled - shadow memory pool allocated, all memory
accesses must now go through shadow pages in CR3. Since no entries are in
shadow tables, initial read and writes from the guest will result in page
faults.
    c) As soon as the first guest memory access occurs, a mandatory page
fault occurs because there is no mapping in the shadows. Xen does a guest
page table walk for the address that caused the fault (va) and then marks
all the guest page table pages along the walk as read only.
    d) Xen finds out the mfn of the guest va somehow (my first question)
and adds the mapping of the va to the shadow page table.
    e) If the page fault was a write, the va is now marked as read/write
but logged as dirty in the logdirty map.
    e) Now the next page fault to any of the page tables marked read-only
in c) must have been caused by the guest writing to its tables, which can
be reflected in the shadow page tables.


3) How do Xen/shadow page tables distinguish between two equivalent guest
virtual addresses from different guest processes? I suppose when a guest OS
tries to change page tables from one process to another, this will cause a
page fault that Xen will trap and be able to infer that the current shadow
page table should be swapped to a different one corresponding to the new
guest process?

Thank you so much,
Kevin

[-- Attachment #2: Type: text/html, Size: 3059 bytes --]

  reply	other threads:[~2021-02-22 18:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-19 16:10 How does shadow page table work during migration? Kevin Negy
2021-02-19 16:36 ` Jan Beulich
2021-02-19 20:17 ` Andrew Cooper
2021-02-22 18:52   ` Kevin Negy [this message]
2021-02-23  0:23     ` Andrew Cooper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACZWC-r7fS2AztaAgGdVPv5NcJiAxZ5mvC4FQTkorPDGwOfn9g@mail.gmail.com \
    --to=kevinnegy@gmail.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).