History log of /src/sys/arch/xen/include/xenmem.h
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: perseant-exfatfs-base-20250801 netbsd-11-base netbsd-10-1-RELEASE perseant-exfatfs-base-20240630 perseant-exfatfs-base netbsd-10-0-RELEASE netbsd-10-0-RC6 netbsd-10-0-RC5 netbsd-10-0-RC4 netbsd-10-0-RC3 netbsd-10-0-RC2 thorpej-ifq-base thorpej-altq-separation-base netbsd-10-0-RC1 netbsd-10-base bouyer-sunxi-drm-base
# 1.2 31-Aug-2022 bouyer

Remove XENPV support from xenmem; it's only used for !XENPV at this time.


# 1.1 31-Aug-2022 bouyer

Work in progress on dom0 PVH support: ioctl support for tools.
Basically, in PVH mode (where XENFEAT_auto_translated_physmap is enabled),
the hypervisor will not map foreing ressources in our virtual address
space for us. Instead, we have to pass it an address in our physical
address space (but not mapped to some RAM) where the ressource will show up
and then enter this PA in pour page table.

For this, introduce xenmem_* which manage the PA space. In PVH mode this
is just allocated from the iomem_ex extent.

With this, I can start a PV domU, and the guest's kernel boots (and
the console works). It hangs because the backend driver can't map the
frontend ressources (yet).

Note that, per https://xenbits.xen.org/docs/unstable/support-matrix.html,
dom0 PVH support is still considered experimental by Xen.