diff --git a/docs/meeting-minutes/.pages.yml b/docs/meeting-minutes/.pages.yml
new file mode 100644
index 0000000..ae4bb0e
--- /dev/null
+++ b/docs/meeting-minutes/.pages.yml
@@ -0,0 +1,3 @@
+title: TrenchBoot Meeting Minutes
+nav:
+  - ...
\ No newline at end of file
diff --git a/docs/meeting-minutes/TrenchBoot-AEM-January24-2023.md b/docs/meeting-minutes/TrenchBoot-AEM-January24-2023.md
new file mode 100644
index 0000000..11d9de2
--- /dev/null
+++ b/docs/meeting-minutes/TrenchBoot-AEM-January24-2023.md
@@ -0,0 +1,64 @@
+## Attendees
+
+- Daniel P. Smith (Apertus Solutions)
+- Andrew Cooper (Citrix)
+- Krystian Hebel (3mdeb)
+- Michał Żygowski (3mdeb)
+
+## Agenda
+
+- Review the current state of TrenchBoot boot protocol being upstreamed to GRUB
+  and Linux kernel
+- Discuss the scope of the work needed to align Qubes OS Anti Evil Maid
+  solution based on TrenchBoot with the most recent boot protocol version
+- Discuss possibilities to implement DRTM launch on S3 resume in Xen
+
+## Meeting Minutes
+
+Current approach of booting Linux with TrenchBoot:
+
+- meet Linux demand so that anything can do EBS and DRTM can still work
+- Linux doing EBS to gather necessary info from firmware
+- bootloader to put slaunch code to memory
+- the code being put to memory is going to be standardized and does everything
+  what DRTM technology needs
+- standardize an input table to be used for generic stub not specific to any
+  bootloader/kernel
+
+Current Xen status:
+
+- Xen efi needs fixing in order to work without Xen's efi-stub, so it would be
+  better to follow Linux's approach of jumping into Xen and Xen calling out to
+  slstub
+- AP wakeup developed during the Qubes OS AEM PoC in Xen hypervisor kernel is
+  still valid and will be needed in the most recent approach as well
+- for legacy boot module will have to be placed in memory by GRUB but GRUB will
+  also construct the input table and call SENTER/SKINIT
+
+DRTM S3 resume support for Xen:
+
+- Idea: for legacy S3 resume mark pages with slaunch module so that Xen won't
+  use them and later do DRTM relaunch using the module (needs a plan how to
+  implement it in Xen for legacy BIOS boot)
+- tboot relaunches itself and then resumes kernel, seals its state to DRTM
+  PCRs, does DRTM on itself and tries to unseal the state, if it is ok, the
+  state is unsealed and tboot may proceed with kernel resume (not exactly what
+  we want)
+- Xen patches alternatives, not runtime, S3 resume measurement would not be the
+  same even when only text section would be measured
+- ideal solution is for Xen to reinstantiate itself with DRTM and reload the VM
+  configuration
+
+Possible solution for S3:
+
+- boot into Xen
+- search for SRT table and look for SL module
+- take measurement of Xen at the end of boot and by delaying the dynamic launch
+  until after we're done making boot-time modifications to Xen's .text/etc. so
+  that the measurement will be stable. This doesn't cope with livepatching yet,
+  but livepatching support can be omitted in v1 implementation.
+- Currently it is not possible to take a meaningful measurement of Dom0 after
+  coming back from S3. It is still valid to measure Dom0 on initial boot to
+  ensure that the correct dom0 kernel is used to start the system. Also dom0
+  measurement will be largely meaningless, so it can be excluded from v1
+  implementation
diff --git a/docs/meeting-minutes/index.md b/docs/meeting-minutes/index.md
new file mode 100644
index 0000000..8897087
--- /dev/null
+++ b/docs/meeting-minutes/index.md
@@ -0,0 +1,5 @@
+# TrenchBoot Meetings Minutes
+
+Here you will find the meeting minutes from various TrenchBoot meetings.
+
+{nav}
diff --git a/mkdocs.yml b/mkdocs.yml
index e5b7905..ad24cb7 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -20,6 +20,7 @@ nav:
     - Documentation:
       - ... | documentation/*.md
       - ... | blueprints/*.md
+      - ... | meeting-minutes/*.md
     - Steering Committee:
       - ... | steering-committee/*.md
     - FAQ: