[PATCH 0/5] x86/xen: untangle PV and PVHVM guest support code

From: Vitaly Kuznetsov
Date: Fri Feb 24 2017 - 11:15:04 EST


Hi,

it's been a while since my 'RFC' submission in November:
https://lists.xen.org/archives/html/xen-devel/2016-11/msg01044.html

I was advised to wait till PVHv2 stuff lands upstream and as this has already
happened I'm sending the first non-RFC version.

Changes since RFC:
- Rebase
- Use enlighten.c, enlighten_pv.c, enlighten_hvm.c, enlighten_pvh.c (and
similar for other files I split) [David Vrabel]
- Split suspend.c too to get rid of #ifdefs in C code.
- I left XEN_DOM0 intact (rename to XEN_PV_DOM0 was suggested by [Boris
Ostrovsky]) as it occured to me that we may want to have all three when
XEN_PVH_DOM0 comes into play. XEN_DOM0 will be used for common code than so
no need to change #ifdefs twice.

Patches are known to produce checkpatch.pl WARNINGS and a couple of ERRORs,
I fixed a few (mostly in _hvm* code I split) and I refrained from fixing the
rest to make it easier to review. I think that we may leave PV code as it is
as sooner or later it will go away.

Original description:

I have a long-standing idea to separate PV and PVHVM code in kernel and
introduce Kconfig options to make it possible to enable the required
parts only breaking the current 'all or nothing' approach.

Motivation:
- Xen related x86 code in kernel is rather big and it is unclear which
parts of it are required for PV, for HVM or for both. With PVH coming
into picture is becomes even more tangled. It makes it hard to
understand/audit the code.

- In some case we may want to avoid bloating kernel by supporting Xen
guests we don't need. In particular, 90% of the code in arch/x86/xen/ is
required to support PV guests and one may require PVHVM support only.

- PV guests are supposed to go away one day and such code separation would
help us to get ready.

This series adds XEN_PV Kconfig option and makes it possible to build PV-only
and PVHVM-only kernels. It also makes it possible to disable Dom0 support.

Patches are rather big but this is mostly just moving code around, no
functional changes intended. I smoke tested it with PV-only and PVHVM-only
builds, booted and did save/restore test. I also tried the newly introduced
PVHv2 guest, it even worked!

Vitaly Kuznetsov (5):
x86/xen: start untangling PV and PVHVM guest support code
x86/xen: split smp.c for PV and PVHVM guests
x86/xen: put setup.c, mmu.c and p2m.c under CONFIG_XEN_PV
x86/xen: put setup.c, pmu.c and apic.c under CONFIG_XEN_PV
x86/xen: split suspend.c for PV and PVHVM guests

arch/x86/include/asm/hypervisor.h | 3 +-
arch/x86/include/asm/xen/page.h | 44 +-
arch/x86/kernel/cpu/hypervisor.c | 7 +-
arch/x86/kernel/process_64.c | 2 +-
arch/x86/xen/Kconfig | 33 +-
arch/x86/xen/Makefile | 18 +-
arch/x86/xen/enlighten.c | 1904 +------------------------
arch/x86/xen/enlighten_hvm.c | 210 +++
arch/x86/xen/enlighten_pv.c | 1561 +++++++++++++++++++++
arch/x86/xen/enlighten_pvh.c | 114 ++
arch/x86/xen/mmu.c | 2776 +------------------------------------
arch/x86/xen/mmu_hvm.c | 77 +
arch/x86/xen/mmu_pv.c | 2636 +++++++++++++++++++++++++++++++++++
arch/x86/xen/pmu.h | 5 +
arch/x86/xen/smp.c | 523 +------
arch/x86/xen/smp.h | 23 +
arch/x86/xen/smp_hvm.c | 58 +
arch/x86/xen/smp_pv.c | 499 +++++++
arch/x86/xen/suspend.c | 54 -
arch/x86/xen/suspend_hvm.c | 22 +
arch/x86/xen/suspend_pv.c | 44 +
arch/x86/xen/xen-head.S | 4 +
arch/x86/xen/xen-ops.h | 16 +
drivers/xen/balloon.c | 30 +-
include/xen/xen-ops.h | 19 +
25 files changed, 5489 insertions(+), 5193 deletions(-)
create mode 100644 arch/x86/xen/enlighten_hvm.c
create mode 100644 arch/x86/xen/enlighten_pv.c
create mode 100644 arch/x86/xen/enlighten_pvh.c
create mode 100644 arch/x86/xen/mmu_hvm.c
create mode 100644 arch/x86/xen/mmu_pv.c
create mode 100644 arch/x86/xen/smp_hvm.c
create mode 100644 arch/x86/xen/smp_pv.c
create mode 100644 arch/x86/xen/suspend_hvm.c
create mode 100644 arch/x86/xen/suspend_pv.c

--
2.9.3