Changeset 104796 in vbox for trunk/src/VBox

Timestamp:

May 27, 2024 11:22:11 PM (6 months ago)

Author:

vboxsync

Message:

VMM/GIMHv: @todo about incorrect HvExtCallGetBootZeroedMemory implementation. bugref:10687

File:

• trunk/src/VBox/VMM/VMMR3/GIMHv.cpp (modified) (1 diff)

trunk/src/VBox/VMM/VMMR3/GIMHv.cpp

@@ -2233 +2233 @@
      * Perform the hypercall.
      */
+/** @todo r=bird: This is *nothing* like the microsoft description (2024-05-28).
+ * https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/hypercalls/hvextcallgetbootzeroedmemory
+ *
+ * It describes this as returning pages known to be all zeros at the time this
+ * hypercall is made.  What we return instead is a is a single entry:
+ *      GIMHVEXTGETBOOTZEROMEM::GCPhysStart = 0;
+ *      GIMHVEXTGETBOOTZEROMEM::cPages      = SUM(PGMRAMRANGE.cb) >> GIM_HV_PAGE_SHIFT;
+ *
+ * This isn't right for any VM configuration, given that VGA & MMIO & ROM memory
+ * starts at 0xa0000 and contains pages that aren't zero.  For VM configurations
+ * with more than 3GB (or 2) of memory, it doesn't take into account the RAM hole
+ * below 4G.
+ *
+ * A much better approach for VMs with large configs, but still not really correct,
+ * would be to find the highest RAM address (non-MMIO, non-MMIO2, non-ROM) and
+ * convert it to a page count and assign that to cPages.
+ *
+ * A slight improvement would be to report two or three ranges:
+ *      [0] = 0x00000-0xa0000,
+ *      [1] = 1MB - RamHole,
+ *      [2] = 4GB - EndOfRam;
+ *
+ * The best would be to implement this directly PGM, as the number of mapped RAM
+ * ranges doesn't need to be constant during the call if other VCPUs are
+ * enabling/disabling devices and such.
+ */
     uint32_t const cRanges = PGMR3PhysGetRamRangeCount(pVM);
     pOut->cPages = 0;