Home > Hyper-V, Windows Server 2008 > Memory Management in Hyper-V (Part-2)

Memory Management in Hyper-V (Part-2)

Guest Physical Address Spaces

The size of the GPA space for a partition is the range from 0 to some maximum address that depends on architectural attributes of the virtual machine exposed by the partition.

Each page within a GPA space is in one of three states:

Mapped: A mapped GPA page is associated with a RAM SPA page.

Inaccessible: An inaccessible GPA page may not be read, written, or executed by the partition.

Unmapped: An unmapped GPA page is not associated with a RAM SPA page.

The way in which the GPA space is defined and the behaviour associated with unmapped page accesses differs between the root partition and non-root partitions.

For the root partition:

Its GPA space is identity-mapped—that is, all mapped GPA pages map directly to the SPA page with the same address.

The GPA mappings are defined by the hypervisor at boot time or when SPA RAM ranges are added or removed. All valid SPA RAM pages are therefore always mapped within the root partition’s GPA space. The root partition is not allowed to unmap these. The root partition may, however, modify its access rights to its mapped pages.

Unmapped GPA pages within the root partition’s GPA space (that is, SPA pages that are not part of known SPA RAM ranges) can be accessed by the root partition. This allows the partition to access memory-mapped registers, video memory buffers and so on. Some unmapped pages are off limits even to the root partition. These include SPA pages that correspond to hardware resources that must be managed by the hypervisor for correct operation. For example, the hypervisor does not allow the root partition to directly access the local APIC’s memory-mapped registers.

For non-root partitions:

Its GPA mappings are not necessarily identity-mapped. That is, a GPA does not necessarily refer to the same SPA.

The GPA mappings are defined by the partition’s parent. At the time they are mapped (through a call to HvMapGpaPages), they are specified in terms of the parent’s GPA space. Therefore, these pages must be mapped into the parent’s GPA space; however, the parent is not required to have read, write or execute access to these mapped pages.

When a virtual processor accesses an unmapped GPA page, the hypervisor suspends the virtual processor and sends a message to the partition’s parent. Code within the parent will typically respond by creating a mapping or by emulating the instruction that generated the memory access. In either case, it is up to the software in the parent partition to “unsuspend” the child’s virtual processor.

Page Access Rights

Mapped GPA pages have the following attributes which define the access rights of the partition:

Readable: Data on the page can be read.

Writeable: Data to the page can be written.

Executable: Code on the page can be executed.

These access rights are enforced for explicit accesses performed by the child’s virtual processors. They are also enforced for implicit reads or writes performed by the hypervisor (for example, due to guest page table flag updates).

Access right combinations are limited by the underlying hardware. The following table shows the valid combinations for an x64 system.

Access Type

Description

Read

Write

Exec

·

·

·

Instruction fetches, reads, and writes are allowed

 

·

·

Illegal combination

·

 

·

Instruction fetches and reads are allowed

 

 

·

Illegal combination

·

·

 

Reads and writes are allowed

 

·

 

Illegal combination

·

 

 

Reads are allowed

 

 

 

No access is allowed

If an attempted memory access is not permitted according to the access rights, the virtual processor that performed the access is suspended (on an instruction boundary) and a message is sent to the parent partition. Code within the parent will typically respond by adjusting the access rights to allow the access or emulating the instruction that performed the memory access. In either case, it is up to the software in the parent partition to “unsuspend” the child’s virtual processor.

Memory accesses that cross page boundaries are handled in a manner that is consistent with the underlying processor architecture. For x64, this means the entire access is validated before any data exchange occurs. For example, if a four-byte write is split across two pages and the first page is writable but the second is not, the first two bytes are not written.

 

GPA Overlay Pages

The hypervisor defines several special pages that “overlay” the guest’s GPA space. The hypercall code page is an example of an overlay page. Overlays are addressed by guest physical addresses but are not included in the normal GPA map maintained internally by the hypervisor. Conceptually, they exist in a separate map that overlays the GPA map.

If a page within the GPA space is overlaid, any SPA page mapped to the GPA page is effectively “obscured” and generally unreachable by the virtual processor through processor memory accesses. Furthermore, access rights installed on the underlying GPA page are not honored when accessing an overlay page.

If an overlay page is disabled or is moved to a new location in the GPA space, the underlying GPA page is “uncovered”, and an existing mapping becomes accessible to the guest.

If multiple overlay pages are programmed to appear on top of each other (for example, the guest programs the APIC to appear on top of the hypercall page), the hypervisor will choose an ordering (which is undefined) and only one of these overlays will be visible to code running within the partition. In such cases, if the “top-most” overlay is disabled or moved, another overlay page will become visible.

Parent partitions that include instruction completion logic should use the hypercalls HvTranslateVirtualAddress, HvReadGpa, and HvWriteGpa to emulate virtual processor memory accesses correctly in the presence of overlays.

HvTranslateVirtualAddress returns a flag indicating whether the specified virtual address maps to an overlay page. HvReadGpa and HvWriteGpa perform the GPA access in the same way the specified virtual processor would have. If an overlay page is present at the specified address, the access is directed to that overlay page. Otherwise, the access is directed to the underlying GPA page.

When the hypervisor performs a guest page table walk either in response to a virtual processor memory access or a call to HvTranslateVirtualAddress, it might find that a page table is located on a GPA location associated with an overlay page. In this case, the hypervisor may choose to do any one of the following: generate a guest page fault, reference the contents of the overlay page, or reference the contents of the underlying GPA mapping. Because this behavior can vary from one hypervisor implementation to the next, it is strongly recommended that guests avoid this situation.

Source Hypervisor Functional Specification 1.0        

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: