Binqbu2002:Xen biji

From Xen
Revision as of 10:29, 27 February 2017 by Binqbu2002 (talk | contribs) (Created page with "=Communicate with Sharing Memory= *Because it is possible to implement mechanisms like pipes and message queues solely from shared memory, it is not necessary for Xen—a min...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Communicate with Sharing Memory

  • Because it is possible to implement mechanisms like pipes and message queues solely from shared memory, it is not necessary for Xen—a minimalist hypervisor—to provide anything except shared memory.
  • Xen supports two basic interdomain operations on memory pages: sharing and transferring.
  • Because the hypervisor has all physical memory mapped, this allows data to be copied between domains without modifying any page tables, which ends up being much faster.
  • Xen deals with page tables directly
  • XenStore is not a filesystem,but it is similar to a filesystem.Pages used to transfer data to virtual device drivers will typically be in the /local/domain/0/ backend/ part of the XenStore

Understanding Shared Info page

A kernel booting in a Xen environment, however, does not have access to the real firmware. Instead, there must be another mechanism. Much of the required information is provided by shared memory pages.

Understanding Xen Memory Management

  • For performance reasons, a guest that detects that it is running in a Xen HVM domain may wish to detect this and switch to using paravirtualized memory management.
  • Xen also provides an assist somewhere between full paravirtualized page tables and shadow page tables, known as writable page tables(WPT). In this mode, page tables are not really writable, but the guest is presented with the illusion that they are.

How to trap by the hypervisor

The page tables are marked as read-only by the hypervisor, and an attempt to write to them triggers the following sequence of actions:

1. The page directory entry pointing to the page is invalidated, removing it from the page table.
2. The page is marked as read/write.
3. The guest modifies the page and continues.
4. When an address referenced by the newly invalidated page directory entry is referenced (read or write), a page fault occurs.
5. The hypervisor traps the page fault, validates the contents of the new page table, and reattaches the page.

This means that the guest kernel’s memory management code must deal with machine pages, whereas much of the rest of the kernel will use pseudo-physical addresses.

The page directory itself can’t be modified using this mechanism because of generating page fault.

The ballon driver

  • Currently, Xen does not do swapping(This is a design decision. Supporting swapping would mean that guests would not know whether their memory was in-core or not, and could seriously degrade performance). This means that any memory allocated to a domain is unavailable for other purposes, even if it is not being used. The balloon driver provides a way around this.
  • The hypercall used for these operations is HYPERVISOR_memory_op. This takes two arguments: a command and a pointer to a structure containing an operation. A large variety of commands is currently available. Those most relevant to the balloon driver are XENMEM_increase reservation and XENMEM_decrease reservation. These both use the control structure shown in Listing as the second argument.In xen-version/include/public.c

struct xen_memory_reservation {

    /*
     * XENMEM_increase_reservation:
     *   OUT: MFN (*not* GMFN) bases of extents that were allocated
     * XENMEM_decrease_reservation:
     *   IN:  GMFN bases of extents to free
     * XENMEM_populate_physmap:
     *   IN:  GPFN bases of extents to populate with memory
     *   OUT: GMFN bases of extents that were allocated
     *   (NB. This command also updates the mach_to_phys translation table)
     */
    XEN_GUEST_HANDLE(xen_pfn_t) extent_start;

    /* Number of extents, and size/alignment of each (2^extent_order pages). */
    xen_ulong_t    nr_extents;
    unsigned int   extent_order;

#if __XEN_INTERFACE_VERSION__ >= 0x00030209
    /* XENMEMF flags. */
    unsigned int   mem_flags;
#else
    unsigned int   address_bits;
#endif

    /*
     * Domain whose reservation is being changed.
     * Unprivileged domains can specify only DOMID_SELF.
     */
    domid_t        domid;
};

The first element of this has a variety of different uses. When increasing the reservation, this is filled in by the hypervisor with the machine address of the pages that were allocated to the domain. When decreasing, this is used to pass in the guest machine frame at the base of the range to free.

  • A third command makes use of this structure, XENMEM_populate_physmap,which is used by the domain builder in Domain 0 to create the initial memory allocation for a new domain.