tl;dr: Xen PVH is the perfect upgrade path from PV and in combination
with grub2 support, it's the Xen "killer feature" we really should have
in Buster.
Background info about Xen PVH:
https://wiki.xen.org/wiki/Virtualization_Spectrum#Almost_fully_PV:_PVH_mode
PVH mode in Xen, a.k.a. "HVM without having to run qemu" is a Xen guest
type best supported since Xen 4.11 and Linux kernel 4.17. Just like when
using PV mode, the guest does not have an emulated BIOS and the guest
kernel is directly started by the dom0. Buster will ship with Xen 4.11.
Why is PVH interesting?
1. When the whole Meltdown/Spectre story started, it quickly became
apparent that 64-bit PV is the most problematic virtualization mode to
protect and to protect from, since address space from the hypervisor and
other guests (including dom0) is reachable from a 64-bit PV domU. To
mitigate this, XPTI (the Xen variant of PTI) has been implemented in the
hypervisor, but with a performance hit. HVM (so, also PVH) guests are
better isolated from the hypervisor and other guests. Inside the guest a
choice can be made about which mitigations to enable or not. Also see
https://xenbits.xen.org/xsa/advisory-254.html
2. Unlike HVM, it's not needed to have a boot loader/sector, partitions,
and a qemu process in the dom0 (using cpu and memory and having an
attack surface). Also, when running a largeish amount of domUs on a
physical server, not having all the qemu processes is an advantage.
3. Unlike PV, PVH makes use of all hardware features that accelerate
virtualization.
The upgrade path from PV to PVH is super optimal. It's just setting
type='pvh' in the guest file and doing a full restart of the domU!
Unless... (insert Monty Python's Dramatic Chord!)
Unless... grub2 was used to boot the PV guests.
Why is it interesting to be able to use grub?
Without using grub in between, the guest kernel and initrd have to be
copied out of the guest onto the dom0 filesystem, because the guest has
to be booted with them directly. Currently, we already have the
grub-xen packages in Debian, which provide grub images which can be used
as kernel for a PV guest, after which it can load the actual linux
kernel that is symlinked from /vmlinuz on the guest filesystem at that
moment.
The final changes to the Linux kernel for grub+PVH are in Linux 4.20.
This request, to carry a few patches from Linux 4.20, provides one half
of the dots that need to be connected to make the full thing happen for
Buster.
Since we'll have Xen 4.11 in Buster, PVH is supported. The related grub2
patchset was committed to the grub master branch on Dec 12 2018 (yup,
today). So, I'll also start contacting the debian grub team soon to ask
(and help) to get the current grub-xen functionality in Debian to be
extended with PVH capabilities as well.
Test reports:
https://lists.xenproject.org/archives/html/xen-devel/2018-10/msg01913.htmlhttps://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03312.html
Closes: #872263
- kbuild: Add build salt to the kernel and modules
- [arm64,powerpc,x86] Add build salt to the vDSO
- Set BUILD_SALT equal to the release string
- Drop patches included upstream
- Drop "Don't WARN about expected W+X pages on Xen"; the problem appears
to have been fixed by upstream commits 2cc42bac1c ("x86-64/Xen: eliminate
W+X mappings") and 672c0ae09b33 ("x86/mm: Consider effective protection
attributes in W+X check")
- Drop "Kbuild: kconfig: Verbose version of --listnewconfig"; it seems
redundant with upstream commit 17baab68d337 ("kconfig: extend output of
'listnewconfig'")
- Drop lockdown patch to drivers/scsi/eata.c; the driver was removed
upstream
- Refresh various other patches
Drop and refresh patches as appropriate.
In the x86 memtest patch, add #ifdef CONFIG_X86 as memtest is now
cross-architecture and memtest86+ is not.
svn path=/dists/trunk/linux/; revision=22616
System calls from x32 tasks are distinguished by having bit 30 set,
but they share the system call table with x86_64 so where parameter/
return value adjustment is needed there is a difference in the low
bits too. The x32-specific calls are numbered from 512 and of course
are not present in the table if the kernel doesn't support x32.
This means we need to change both the maximum syscall number and the
mask instruction.
svn path=/dists/sid/linux/; revision=21689
- Reject x32 executables if x32 ABI not supported
- Make x32 syscall support conditional on a kernel parameter
- Enable X86_X32_DISABLED so that x32 support must be explicitly enabled
svn path=/dists/sid/linux/; revision=21634
Drop a large number of patches that were merged upstream.
Fix context in features/all/sound-pci-cs46xx-request_firmware.patch.
Remove another firmware image sneaked into staging.
svn path=/dists/trunk/linux-2.6/; revision=18288
piix has been kept around because it has 2 device IDs not listed in
other drivers:
PCI_DEVICE_ID_INTEL_82371FB_0 == 0x122e (PIIX function 0)
This function is the ISA bridge, not a PATA controller!
PCI_DEVICE_ID_INTEL_82801DB_1 == 0x24c1 (ICH4-L function 1)
This should be functionally identical to the ICH4's PATA
controller.
Add the latter device ID to ata_piix and disable piix (except on
alpha, which has not been converted to use libata).
svn path=/dists/trunk/linux-2.6/; revision=16427
Noah Meyerhans
Hans van Kranenburg
Ben Hutchings
Bastian Blank
Ben Hutchings
Maximilian Attems