Hello,
Now that 4.13 is on its way out of the door, it is time to look to
ongoing work.
We have a large backlog of speculation-related work. For one, we still
don't virtualise MSR_ARCH_CAPS for guests, or use eIBRS ourselves in
Xen. Therefore, while Xen does function on Cascade Lake, support is
distinctly suboptimal.
Similarly, AMD systems frequently fill /var/log with:
(XEN) emul-priv-op.c:1113:d0v13 Domain attempted WRMSR c0011020 from
0x0006404000000000 to 0x0006404000000400
which is an interaction Linux's prctl() to disable memory disambiguation
on a per-process basis, Xen's write/discard behaviour for MSRs, and the
long-overdue series to properly virtualise SSBD support on AMD
hardware. AMD Rome hardware, like Cascade Lake, has certain hardware
speculative mitigation features which need virtualising for guests to
make use of.
Similarly, there is plenty more work to do with core-aware scheduling,
and from my side of things, sane guest topology. This will eventually
unblock one of the factors on the hard 128 vcpu limit for HVM guests.
Another big area is the stability of toolstack hypercalls. This is a
crippling pain point for distros and upgradeability of systems, and
there is frankly no justifiable reason for the way we currently do
things The real reason is inertia from back in the days when Xen.git
(bitkeeper as it was back then) contained a fork of every relevant
pieces of software, but this a long-since obsolete model, but still
causing us pain. I will follow up with a proposal in due course, but as
a oneliner, it will build on the dm_op() API model.
Likely included within this is making the domain/vcpu destroy paths
idempotent so we can fix a load of NULL pointer dereferences in Xen
caused by XEN_DOMCTL_max_vcpus not being part of XEN_DOMCTL_createdomain.
Other work in this area involves adding X86_EMUL_{VIRIDIAN,NESTED_VIRT}
to replace their existing problematic enablement interfaces.
A start needs to be made on a total rethink of the HVM ABI. This has
come up repeatedly at previous dev summits, and is in desperate need of
having some work started on it.
Other areas in need of work is the boot time directmap at 0 (which hides
NULL pointer deferences during boot), and the correct handling of %dr6
for all kinds of guests.
Anyway, that's probably a good enough summary for now.
Thoughts/comments welcome, especially if something on this list happens
to be a priority elsewhere and engineering effort can be put towards it.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
