X-Git-Url: http://v3vee.org/palacios/gitweb/gitweb.cgi?p=palacios.git;a=blobdiff_plain;f=palacios%2Finclude%2Fpalacios%2Fvmm_hvm.h;h=7f822206ac4081cc99781c4914c3387c85340a97;hp=7a1dceb7c1c626459fcdc00dd56fa84868447541;hb=142b59ca44b3d00f0479910c986f6791216651e7;hpb=366a20deaf086107d75a2004fec076db4705e7c2 diff --git a/palacios/include/palacios/vmm_hvm.h b/palacios/include/palacios/vmm_hvm.h index 7a1dceb..7f82220 100644 --- a/palacios/include/palacios/vmm_hvm.h +++ b/palacios/include/palacios/vmm_hvm.h @@ -24,6 +24,7 @@ #ifdef __V3VEE__ #include +#include struct v3_vm_hvm { uint8_t is_hvm; @@ -32,6 +33,23 @@ struct v3_vm_hvm { struct v3_cfg_file *hrt_file; uint64_t hrt_entry_addr; enum { HRT_BLOB, HRT_ELF64, HRT_MBOOT2, HRT_MBOOT64 } hrt_type; + + // The following parallel the content of mb_info_hrt_t in + // the extended multiboot header. They reflect how the + // HRT has actually been mapped, as opposed to the requested + // mapping/flags from the mb_mb64_hrt_t + uint64_t hrt_flags; + uint64_t max_mem_mapped; + uint64_t gva_offset; + uint64_t gva_entry; + uint64_t comm_page_gpa; + uint8_t hrt_int_vector; + + void *comm_page_hpa; + void *comm_page_hva; + + enum {HRT_IDLE=0, HRT_CALL, HRT_PARCALL, HRT_MERGE} trans_state; + uint64_t trans_count; }; struct v3_core_hvm { @@ -39,6 +57,8 @@ struct v3_core_hvm { uint64_t last_boot_start; }; + + struct v3_xml; int v3_init_hvm(); @@ -68,11 +88,110 @@ void v3_hvm_find_apics_seen_by_core(struct guest_info *core, struct v3_vm_in uint32_t *start_apic, uint32_t *num_apics); +int v3_build_hrt_multiboot_tag(struct guest_info *core, mb_info_hrt_t *hrt); + int v3_setup_hvm_vm_for_boot(struct v3_vm_info *vm); int v3_setup_hvm_hrt_core_for_boot(struct guest_info *core); int v3_handle_hvm_reset(struct guest_info *core); +/* + HVM/HRT interaction is as follows: + + 1. MB_TAG_MB64_HRT tag in the HRT multiboot kernel signifies it + is handled by the HVM. + 2. The flags and other info in the the tag indicate the properties of the HRT + to the HVM. (see vmm_multiboot.h), in particular: + - position independence + - ability to be initially mapped with an offset + between virtual and physical addresses, for example + to hoist it into the same position that the ROS kernel + will occupy in the virtual address space of a ROS + process + - how much physical address space we will intiially map + and what kind of page tables are used to map it + - what physical page (4KB) should we reserve for use + in HVM/HRT communication (particularly upcalls) + - the interrupt vector used to upcall from the HVM to the HRT + 3. The MB_INFO_HRT_TAG within the multiboot info structures the + HRT sees on boot indicates that HRT functionality is established and + gives details of operation to the HRT, including the following. + See vmm_multiboot.c for more info + - apics and ioapic ids, and indications of which apics + and which entries on ioapics are exclusively for HRT use + - physical address range that is exclusively for HRT use + - where the the physical address range exclusively for HRT use + is mapped into the virtual address space (offset). The + ROS part of the physical address space is always identity mapped + initially. + - the amount of physical memory that has been mapped + - the physical address of the page the HVM will use to + communicate with the HRT + - the interrupt vector the HVM will use to upcall the HRT + - flags copied from the HRT's HRT tag (position independence, + page table model, offset, etc) + 4. Downcalls: + hypercall 0xf00df00d with arguments depending on operation + with examples described below. + 5. Upcalls + interrupt injected by VMM or a magic #PF + communication via a shared memory page, contents below + + Upcalls + + Type of upcall is determined by the first 64 bits in the commm page + + 0x0 => Null (test) + 0x20 => Invoke function in HRT + Next 64 bits contains address of structure + describing function call. This is typically the ROS + trying to get the HRT to run a function for it. + ROS is resposible for assuring that this address + (and other addresses) are correct with respect to + mappings. That is, for a non-merged address space, + the ROS needs to supply physical addresses so that + they can be used (with the identity-mapped ROS physical + memory.) If it wants to use virtual addresses, it + needs to first merge the address spaces. + 0x21 => Invoke function in HRT in parallel + Exactly like previos, but the upcall is happening + simultaneously on all HRT cores. + 0x30 => Merge address space + Next 64 bits contains the ROS CR3 that we will use + to map the user portion of ROS address space into + the HRT address space + 0x31 => Unmerge address space + return the ROS memory mapping to normal (physical/virtual identity) + + Downcalls + + HVM_HCALL is the general hypercall number used to talk to the HVM + The first argument is the request number (below). The other arguments + depend on the first. + + 0x0 => Null, just for timing + 0x1 => Reboot ROS + 0x2 => Reboot HRT + 0x3 => Reboot Both + 0xf => Get HRT transaction state + + 0x20 => Invoke function (ROS->HRT) + first argument is pointer to structure describing call + 0x21 => Invoke function in parallel (ROS->HRT) + same as above, but simultaneously on all HRT cores + 0x2f => Function execution complete (HRT->ROS, once per core) + 0x30 => Merge address space (ROS->HRT) + no arguments (CR3 implicit). Merge the current + address space in the ROS with the address space on + the HRT + 0x31 => Unmerge address apce (ROS->HRT) + release any address space merger and restore identity mapping + 0x3f => Merge request complete (HRT->ROS) + +*/ + + + #endif /* ! __V3VEE__ */