• P
    KVM: PPC: Allocate RMAs (Real Mode Areas) at boot for use by guests · aa04b4cc
    Paul Mackerras 提交于
    This adds infrastructure which will be needed to allow book3s_hv KVM to
    run on older POWER processors, including PPC970, which don't support
    the Virtual Real Mode Area (VRMA) facility, but only the Real Mode
    Offset (RMO) facility.  These processors require a physically
    contiguous, aligned area of memory for each guest.  When the guest does
    an access in real mode (MMU off), the address is compared against a
    limit value, and if it is lower, the address is ORed with an offset
    value (from the Real Mode Offset Register (RMOR)) and the result becomes
    the real address for the access.  The size of the RMA has to be one of
    a set of supported values, which usually includes 64MB, 128MB, 256MB
    and some larger powers of 2.
    
    Since we are unlikely to be able to allocate 64MB or more of physically
    contiguous memory after the kernel has been running for a while, we
    allocate a pool of RMAs at boot time using the bootmem allocator.  The
    size and number of the RMAs can be set using the kvm_rma_size=xx and
    kvm_rma_count=xx kernel command line options.
    
    KVM exports a new capability, KVM_CAP_PPC_RMA, to signal the availability
    of the pool of preallocated RMAs.  The capability value is 1 if the
    processor can use an RMA but doesn't require one (because it supports
    the VRMA facility), or 2 if the processor requires an RMA for each guest.
    
    This adds a new ioctl, KVM_ALLOCATE_RMA, which allocates an RMA from the
    pool and returns a file descriptor which can be used to map the RMA.  It
    also returns the size of the RMA in the argument structure.
    
    Having an RMA means we will get multiple KMV_SET_USER_MEMORY_REGION
    ioctl calls from userspace.  To cope with this, we now preallocate the
    kvm->arch.ram_pginfo array when the VM is created with a size sufficient
    for up to 64GB of guest memory.  Subsequently we will get rid of this
    array and use memory associated with each memslot instead.
    
    This moves most of the code that translates the user addresses into
    host pfns (page frame numbers) out of kvmppc_prepare_vrma up one level
    to kvmppc_core_prepare_memory_region.  Also, instead of having to look
    up the VMA for each page in order to check the page size, we now check
    that the pages we get are compound pages of 16MB.  However, if we are
    adding memory that is mapped to an RMA, we don't bother with calling
    get_user_pages_fast and instead just offset from the base pfn for the
    RMA.
    
    Typically the RMA gets added after vcpus are created, which makes it
    inconvenient to have the LPCR (logical partition control register) value
    in the vcpu->arch struct, since the LPCR controls whether the processor
    uses RMA or VRMA for the guest.  This moves the LPCR value into the
    kvm->arch struct and arranges for the MER (mediated external request)
    bit, which is the only bit that varies between vcpus, to be set in
    assembly code when going into the guest if there is a pending external
    interrupt request.
    Signed-off-by: NPaul Mackerras <paulus@samba.org>
    Signed-off-by: NAlexander Graf <agraf@suse.de>
    aa04b4cc
asm-offsets.c 27.5 KB