[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Sources of page dirtying for HVM domains in Xen 3.2.x

  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: "Mike Sun" <msun@xxxxxxxxxx>
  • Date: Thu, 2 Oct 2008 15:19:25 -0400
  • Delivery-date: Thu, 02 Oct 2008 12:19:46 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=A6GXttuwdk4g4uD1J83jMCGr31Oayvrtw/grmC/FLKfpg4I5WNiUzoFOe7k+e1jixm 4j+YSjcfTKIiRuGsEGQcfWXSpqHGqt6DZ3xWDj2i0RDJry8Q5IDPHiYC0jwacDy477wA G1/OuixXT4f0yZT49d4Sr+hLnmExSdF3CEF2Y=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Hi all,

I recently moved my research implementation to Xen 3.2.x from 3.1.x
and am trying to get a grasp on the shadow page table code changes.

I need to trap all writes/modifications to memory pages mapped in a
HVM domain's pseudo-physical address space.  I have been using the
log-dirty mode as a means to do this.  It seems like for an HVM domain
in log-dirty mode, all writes to guest memory will trigger a page
fault, which can be then handled in sh_page_fault().  The log-dirty
handling code is buried inside _sh_propagate() which is eventually
called from sh_page_fault().

But I've noticed that the paging_mark_dirty() is also called from
other places that do not originate from the page fault handler.  This
makes sense to me for PV translated domains as other Xen functions may
modify guest pages.  But for HVM domains, are there other sources of
guest memory modification that will not originate from page faults?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.