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

[Xen-devel] altp2m: set_mem_access with change_gfn in domU

  • To: xen-devel@xxxxxxxxxxxxxxxxxxxx
  • From: Matt Leinhos <matt@xxxxxxxxxx>
  • Date: Wed, 13 Dec 2017 11:06:09 -0600
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=matt.leinhos@xxxxxxxxxx;
  • Delivery-date: Wed, 13 Dec 2017 17:06:22 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:99


I'm using altp2m from a guest, using Xen 4.9.1 and setting altp2m =
'mixed' in my VM config file.

I'm confused about the expected behavior when combining
HVMOP_altp2m_change_gfn and  HVMOP_altp2m_set_mem_access. In my case, I
am "changing" one GFN to another (I'm thinking of this as GFN
redirection) in a specific view, and setting both to inaccessible in
that same view.

Here's a pictorial summary:
GFN1 ------> GFN2 ( redirected via change_gfn)

GFN1: has XENMEM_access_n
GFN2: has XENMEM_access_n

If I incur a #VE on GFN1 and grant access to it, then access to the
underlying page succeeds. I never incur a #VE on GFN2 -- although I
thought I would get one #VE on GFN1 first, followed by another on GFN2
once GFN1 is accessible.

Is there any document/email/etc on this behavior? I don't know what's
supposed to happen. This might not just an Intel issue -- the behavior
could be influenced by the order of the hypercalls: there are two uses
of set_mem_access and one of change_gfn.


Matt Leinhos
Star Lab, Inc

Xen-devel mailing list



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