It's an interesting project, may be useful to study, though it doesn't support multiple VMs.

booter, don't worry,
I have already started on hypervisor skeleton for AMD64 loaded as driver from running OS. The final driver seems to fit under 4 kB (currenly 3,3 kB), AMD manuals have only about 50 pages concerning virtualization. I can't understand why intel did virtualization in such complicated way (my intel hypervisor driver skeleton for ms windows has 12 kB - but hypervisor has its own paging tables and private virtual memory isolated from running guest, also ability to turn off virtualization and resume OS), Intel manuals have about 200-300 pages about virtualization.

Hi Feryno, how it's going with your AMD skeleton?

Hi booter, the demo skeleton driver for AMD64 hypervisor for win x64 had only 3,3 kB, it launched at 1 CPU and didn't handle vm exits. The sign that everything run well was writing into some diagnostic ports shown by SimNow and another sign that guest started to run well from address in vmcb.rip

Then I decided to run it at more CPUs, and to create separated virtual memory (so hypervisor lives at private CR3 and private paging tables, in the first demo version both hypervisor and the process lauching hypervisor driver had the same CR3 and the same virtual memory translation tables).
So I decided that hypervisor should use GS_base for accessing data unique per every CPU. I decided to create IDT for hypervisor, simple (yet dummy) exception handlers. I also created handler for shuting hypervisor down and resume OS. Hypervisor has also private TSS (because it will need to handle self generated exceptions - I will need debug exception, hypervisor will single step itself...)
Currently the driver has 7 kB and runs well, supports SMP, has private CR3 (nested paging not yet supported, so for accessing guest it needs to extract physical memory page of guest virtual memory page and then map it into hypervisor virtual memory), private GDT, private selectors, private TSS (everything completely separated from guest)

problem to solve:
necessity to disassemble instructions when hypervisor intercepts e.g. writes into CR3 (read the memory of guest at first)
perhaps more elegant solution will be copy opcode into hypervisor memory, set all 16 GPR64 registers of hypervisor to registers of guest, execute the MOV CR3 instruction from hypervisor virtual memory with trap flag set to 1 = single step it, hypervisor handles its debug exception delivered through hypervisor IDT and after that restore hypervisor stack e.g. from gs:[saved_rsp] and vmrun into guest.
Hypervisor paging tables and its whole virtual memory then must be marked global so after loading alien CR3 hypervisor pages must stay in TLB so you can continue

and one thing:
creating vm exit handler is more complicated under AMD64 SVM than at Intel VMX

I suggest you to:

hypervisor_loop:
push rax (physical memory of VMCB for this CPU)
push hypervisor_gs_base ; e.g. push [gs:gs_base]
clear busy bit of hypervisor Task descriptor (easier now than after vm exit, e.g. you may access it quicky if it is at some offset in GS_base, e.g. and [gs:gdt+task_selector+5],not 0010b
vmload rax
vmrun rax
; here we go every vm exit
vmsave rax
mov eax,hypervisor_task_selector
ltr eax ; we already changed busy task to available - before vmload instruction
mov eax,hypervisor_GS_selector
mov gs,eax
pop rax ; restore GS base for this CPU
push rcx rdx
shld rdx,rax,32
mov ecx,MSR_AMD64_GS_base
wrmsr
pop rdx rcx
; now you may handle the vm exit....... it is good to have stored VIRTUAL memory of VMCB where it is mapped and access it again from [gs:hypervisor_VMCB_virtual_memory]
e.g. mov rax,[gs:hypervisor_VMCB_virtual_memory]
cmp [rax+vm_exit_offset],VM_exit_code ; e.g. writing into CR3, execution of VMMCALL, etc.
pop rax ; restore PHYSICAL memory of VMCB for this CPU
jmp hypervisor_loop

ufffff, vm exit handler under Intel was much easier, the designed schema for AMD64 may contain errors, written from my head...
I really suggest you to use GS_base for every CPU so that CPU may quickly load necessary pointer from [gs:offset] - store GDT, TSS somewhere at GS_base to easily access it and also store there VIRTUAL memory where is mapped the PHYSICAL memory containing VMCB for this CPU

I really don't know which platform (AMD64/IntelIA32e) to suggest.
Intel has huge manuals (about 200-300 pages) - AMD smaller (about 50-100 pages). Setting up VMCB is a bit easier at AMD than setting VMCS at Intel. VM exit handler is much more complicated at AMD than at Intel.
The final size of skeleton for AMD64 (7kB) was smaller than for Intel (13 kB) in my implementations (Intel driver contains a lot of data, especially encodings for VMCS fields stored as data, 4 kB of Intel driver is IDT, the IDT is created on the fly for AMD hypervisor). Handling vm exit for e.g. writing into CR3 is easier at Intel, you may directly load from one VMCS field the info which of 16 GPR64 is going to be written into CR3, under AMD it seems to be necessary to read guest memory and manually determine that

You will certainly have a lot of problems and questions, don't hesitate to post them here or PM to me.