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

[Xen-devel] PVHv2/HVM memory layout and interface specification


  • To: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: "Johnson, Ethan" <ejohns48@xxxxxxxxxxxxxxxx>
  • Date: Mon, 22 Jul 2019 23:50:00 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cs.rochester.edu;dmarc=pass action=none header.from=cs.rochester.edu;dkim=pass header.d=cs.rochester.edu;arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AIcV1Gp1fMIpQuZGJAIBSVClSlkKuXfFDyJfVeyWI4I=; b=M/1myADaSFAMDZmEagdXioRvwnpjPZnjJOzicR046fjC358F9wK4hByH1H3B0pyI78RGCvnrb9gjg/V+s60eA05FWJS/zt3eXUXQZ2VhF977abafBFbrU011F6cPEQDCOqSEDK7pAzReBtl6xhpnsVu1JPepmz/boiqIuKRSIvKzxxN7j2aJoeTR1vJJt14Y+XTHfb6rDBqcIiKPXADXXSu1vcPd4sIV43PWhMmRlkW7nJirJvgV8qNIFOoKbOc1hJaYcybnoLmKam2vPnF5Vwbt19e4o9iKqQVHJJZzh0swBZwB3jZklSmaeNs4yLNjmua7TsOLZGf7KT3pXb9Ewg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WC+r4WKY2IkanpERt6b+O7CX7hGu3oYq4hhvXk4/MDdzZG5H8OCSLBTgtmV0O7vo2BFgYt7mn+FVwoc25KW+j9zuM/dl5QD1sdQIPOXi/jCoqOdBkBJHet8DtjIzSz2Uhg26IpK73TOyMDYFTfrGAVnuD2Q9TmUHnE6eP7GAR+37Ix5yEB1ahizYVjCW3fNqT+73uhf1MSZ4d/zEbZPPj14spwwHtoiEyySzPweayiwnNuw52VuTpE7kJi6YEDqKbv4hOmH5vWoofbyt1hynguzkKpFKNPvbHOdtRU2al8KydP4wIWo0CLupyCGMATny/3NNdK+wmv+oKYj2tVe++Q==
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=ejohns48@xxxxxxxxxxxxxxxx;
  • Delivery-date: Mon, 22 Jul 2019 23:50:09 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AdVA3wyWSHObj/sRQ/qradWRmZafIQ==
  • Thread-topic: PVHv2/HVM memory layout and interface specification

Hi all,

I'm interested in using Xen as a research platform for enforcing novel memory 
protection schemes on hypervisors and guests. Specifically, I'm looking to do 
this in an environment containing PVH(v2) and potentially HVM guests.

To know what my options are for this, I need to know where the Xen hypervisor 
"lives" in the system's memory layouts (both virtual and physical, and within 
guests' spaces as virtualized by extended paging). I found a Google Project 
Zero article from 2017 
(https://googleprojectzero.blogspot.com/2017/04/pandavirtualization-exploiting-xen.html)
 that explains the memory layout for classic PV mode, but I couldn't find 
anything for PVH or HVM, either in the Xen documentation, the wiki, or general 
web searches.

So, I thought I'd ask here...what's the general lay of the land in terms of how 
Xen lays out memory for itself and guests in PVH and HVM modes? Is this 
documented anywhere, e.g. in some sort of specification for the PVHv2 
paravirtualization interface? I looked for such a specification document but 
couldn't find anything particularly complete; the closest I found was 
http://xenbits.xen.org/docs/4.12-testing/misc/pvh.html, which didn't have a lot 
of detail. (The Xen 4.7 version of the documentation had a little bit more 
detail at https://xenbits.xen.org/docs/4.7-testing/misc/pvh.html, but it still 
doesn't have quite what I'm looking for, and I'm not sure if that's for PVHv2 
or the older PVHv1.)

Specifically, I'm wondering:

1. Where does the Xen hypervisor itself live in the host's (VMX root) virtual 
and physical address spaces under PVH and HVM? In classic PV it seems it lived 
just below the guest kernel, but that was without extended paging separating 
the host and guest's views of memory.

2. Does Xen also live somewhere within the guest's (VMX non-root) view of 
physical memory as provided by extended paging, in PVH mode? (I'm guessing it 
wouldn't for HVM, but I'm wondering about PVH because it did for classic PV.)

3. How are hypercalls handled in PVH/HVM mode? Do they use the VMCALL 
instruction (or something comparable) to initiate a VM exit, or are they 
sometimes handled within VMX non-root mode without a VM exit, similar to 
classic PV?

4. How does Xen access the guest's memory when it needs to examine or modify 
it? Does it just access the physical frames through a direct map in VMX root 
mode, or are guests' views of physical memory somehow represented somewhere in 
the host's (hypervisor's) virtual address space?

5. How do PVH guests learn what their physical memory layout looks like? Which 
regions of memory do they use to communicate with Xen? How is this process 
different for HVM (non-PVH) guests?

6. How does dom0 factor into all this? Does it have any direct access to domUs' 
physical memory pages, or does it have to ask Xen to do that on its behalf with 
a hypercall? 

Thanks in advance for any help anyone can offer. If there are any good 
resources out there (books? blog posts?) for understanding the big-picture 
structure of the Xen architecture and codebase as it exists in its modern form 
(i.e., in the PVH/HVM era), those would be especially appreciated.

Sincerely,
Ethan Johnson

-- 
Ethan J. Johnson
Computer Science PhD student, Systems group, University of Rochester
ejohns48@xxxxxxxxxxxxxxxx
ethanjohnson@xxxxxxx
PGP public key available from public directory or on request

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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