Qualcomm Trusted Virtual Machine (QTVM) are VMs that are authenticated by
Qualcomm firmware before the VM starts. The firmware also defines the
VM's image layout. Additionally, each QTVM comes with a reserved VM ID.
Introduce an IOCTL to allow VMMs to configure a QTVM and this driver will
handle the setup for QTVMs.
Bug: 399219478
Change-Id: Ia3fe74a46c0e53134b9b4b10fa59bcaa8f376c87
Signed-off-by: Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>
This is a CMA allocator for VMs which need their memory to be backed by
contiguous memory. The driver creates /dev/<qtvm_name_cma> to represent
the qtvm's DMA pool. Once opened, VMM can make an IOCTL CREATE_CMA_MEM to
obtain an fd to the file created which represents the VM's memory backed
by the specific DMA pool.
Bug: 399219478
Change-Id: I63f092ed15ef209a8723de8c2b51df19115d1ecb
Signed-off-by: Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>
In preparation for Gunyah-aware protected guests, make the core gunyah
driver which probes the info_area page compile separately.
Bug: 395833312
Change-Id: Ibea70a89dfa66fbc08491acb1a78fa6e57d6943a
Signed-off-by: Elliot Berman <elliot.berman@oss.qualcomm.com>
Allow userspace to attach an ioeventfd to an mmio address within the
guest. Userspace provides a description of the type of write to
"subscribe" to and eventfd to trigger when that type of write is
performed by the guest. This mechanism allows userspace to respond
asynchronously to a guest manipulating a virtualized device and is
similar to KVM's ioeventfd.
Bug: 338347082
Link: https://lore.kernel.org/all/20240222-gunyah-v17-34-1e9da6763d38@quicinc.com/
Change-Id: Ic01e6a05f268b278a972fc28fb70168c14894537
Reviewed-by: Alex Elder <elder@linaro.org>
Co-developed-by: Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>
Signed-off-by: Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Signed-off-by: Sreenad Menon <quic_sreemeno@quicinc.com>
[Elliot: s/eventfd_signal(..., 1)/event_fd_signal(...)/]
Signed-off-by: Elliot Berman <elliot.berman@oss.qualcomm.com>
Enable support for creating irqfds which can raise an interrupt on a
Gunyah virtual machine. irqfds are exposed to userspace as a Gunyah VM
function with the name "irqfd". If the VM devicetree is not configured
to create a doorbell with the corresponding label, userspace will still
be able to assert the eventfd but no interrupt will be raised on the
guest.
Bug: 338347082
Link: https://lore.kernel.org/all/20240222-gunyah-v17-32-1e9da6763d38@quicinc.com/
Change-Id: I642ff862db1268cc5195346f79ed96573a9ba492
Acked-by: Alex Elder <elder@linaro.org>
Co-developed-by: Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>
Signed-off-by: Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
[Elliot: s/fd.file/fd_file(fd)/]
Signed-off-by: Elliot Berman <elliot.berman@oss.qualcomm.com>
Memory provided to Gunyah virtual machines are provided by a
Gunyah guestmemfd. Because memory provided to virtual machines may be
unmapped at stage-2 from the host (i.e. in the hypervisor's page tables
for the host), special care needs to be taken to ensure that the kernel
doesn't have a page mapped when it is lent to the guest. Without this
tracking, a kernel panic could be induced by userspace tricking the
kernel into accessing guest-private memory.
Introduce the basic guestmemfd ops and ioctl. Userspace should be able
to access the memory unless it is provided to the guest virtual machine:
this is necessary to allow userspace to preload binaries such as the
kernel Image prior to running the VM. Subsequent commits will wire up
providing the memory to the guest.
Bug: 338347082
Link: https://lore.kernel.org/all/20240222-gunyah-v17-23-1e9da6763d38@quicinc.com/
Change-Id: Ifa869957b3b0c1e83ac94c44f9cf5acfee8aa4bc
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Signed-off-by: Elliot Berman <elliot.berman@oss.qualcomm.com>
Qualcomm platforms have a firmware entity which performs access control
to physical pages. Dynamically started Gunyah virtual machines use the
QCOM_SCM_RM_MANAGED_VMID for access. Linux thus needs to assign access
to the memory used by guest VMs. Gunyah doesn't do this operation for us
since it is the current VM (typically VMID_HLOS) delegating the access
and not Gunyah itself. Use the Gunyah platform ops to achieve this so
that only Qualcomm platforms attempt to make the needed SCM calls.
Bug: 338347082
Link: https://lore.kernel.org/all/20240222-gunyah-v17-22-1e9da6763d38@quicinc.com/
Change-Id: I2bd98d5e4ba5680fe938a0513d5028ebda86598d
Reviewed-by: Alex Elder <elder@linaro.org>
Co-developed-by: Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>
Signed-off-by: Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Signed-off-by: Elliot Berman <elliot.berman@oss.qualcomm.com>
Gunyah virtual machines are created with either all memory provided at
VM creation using the Resource Manager memory parcel construct, or
Incrementally by enabling VM demand paging.
The Gunyah demand paging support is provided directly by the hypervisor
and does not require the creation of resource manager memory parcels.
Demand paging allows the host to map/unmap contiguous pages (folios) to
a Gunyah memory extent object with the correct rights allowing its
contained pages to be mapped into the Guest VM's address space. Memory
extents are Gunyah's mechanism for handling system memory abstracting
from the direct use of physical page numbers. Memory extents are
hypervisor objects and are therefore referenced and access controlled
with capabilities.
When a virtual machine is configured for demand paging, 3 memory
extent and 1 address space capabilities are provided to the host. The
resource manager defined policy is such that memory in the "host-only"
extent (the default) is private to the host. Memory in the "guest-only"
extent can be used for guest private mappings, and are unmapped from the
host. Memory in the "host-and-guest-shared" extent can be mapped
concurrently and shared between the host and guest VMs.
Implement two functions which Linux can use to move memory between the
virtual machines: gunyah_provide_folio and gunyah_reclaim_folio. Memory
that has been provided to the guest is tracked in a maple tree to be
reclaimed later. Folios provided to the virtual machine are assumed to
be owned Gunyah stack: the folio's ->private field is used for
bookkeeping about whether page is mapped into virtual machine.
Bug: 338347082
Link: https://lore.kernel.org/all/20240222-gunyah-v17-20-1e9da6763d38@quicinc.com/
Change-Id: I303fced6f7baef3c69540ef9fa9a7a04db957365
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Signed-off-by: Elliot Berman <elliot.berman@oss.qualcomm.com>
Gunyah allows vCPUs that are configured as proxy-scheduled to be scheduled by
another virtual machine (host) that holds capabilities to those vCPUs with
suitable rights.
Gunyah also supports configuring regions of a proxy-scheduled VM's address
space to be virtualized by the host VM. This permits a host VMM to emulate MMIO
devices in the proxy-scheduled VM.
vCPUs are presented to the host as a Gunyah resource and represented to
userspace as a Gunyah VM function.
Creating the vcpu function on the VM will create a file descriptor that:
- can handle an ioctl to run the vCPU. When called, Gunyah will directly
context-switch to the selected vCPU and run it until one of the following
events occurs:
* the host vcpu's time slice ends
* the host vcpu receives an interrupt or would have been pre-empted
by the hypervisor
* a fault occurs in the proxy-scheduled vcpu
* a power management event, such as idle or cpu-off call in the vcpu
- can be mmap'd to share the gunyah_vcpu_run structure with userspace. This
allows the vcpu_run result codes to be accessed, and for arguments to
vcpu_run to be passed, e.g. for resuming the vcpu when handling certain fault
and exit cases.
Bug: 338347082
Link: https://lore.kernel.org/all/20240222-gunyah-v17-15-1e9da6763d38@quicinc.com/
Change-Id: Ia20ffc27cd57c1c205aba909f43f654e2a4c0891
Co-developed-by: Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>
Signed-off-by: Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Signed-off-by: Elliot Berman <elliot.berman@oss.qualcomm.com>
The resource manager is a special virtual machine which is always
running on a Gunyah system. It provides APIs for creating and destroying
VMs, secure memory management, sharing/lending of memory between VMs,
and setup of inter-VM communication. Calls to the resource manager are
made via message queues.
This patch implements the basic probing and RPC mechanism to make those
API calls. Request/response calls can be made with gh_rm_call.
Drivers can also register to notifications pushed by RM via
gh_rm_register_notifier
Specific API calls that resource manager supports will be implemented in
subsequent patches.
Bug: 338347082
Link: https://lore.kernel.org/all/20240222-gunyah-v17-7-1e9da6763d38@quicinc.com/
Change-Id: I014020b676a4db46bd7d64cc62df4eda5259a1f3
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Signed-off-by: Elliot Berman <elliot.berman@oss.qualcomm.com>
Prakruthi Deepak Heragu
Elliot Berman
Sreenad Menon
Elliot Berman