[Pkg-xen-devel] Report on the Xen BOF at Debconf 18

[Hans van Kranenburg]

Hi,

On 07/30/2018 05:11 AM, Ian Jackson wrote:
> We had a smallish attendance but of quite keen and engaged people.
> 
> I reported Hans van Kranenburg's work on Xen 4.11 to the BOF, although
> as it was very recent I hadn't been able to examine it myself.  Hans,
> thank you.
> 
> Much of the discussion was about speculative execution problems.  It's
> clear that the user community din't really appreciate the situation,
> and in particular, that new exploit techniques and updates are likely
> to continue to appear indefinitely.  I think it will be worth writing
> some kind of statement or briefing or polemic or something.  I'll
> think about what what that ought to look like, and/or search for an
> existing thing to refer to.
> 
> The distribution of microcode updates for spectre/meltdown mitigations
> came up.  It appears that projects like Debian are getting the new
> microcode quite late, and in this respect the fairness of particularly
> Intel's handling of the free software community was questioned.  I
> will ask my colleagues upstream if we have any leverage or influence.

Yes, this is a thing. Intel seems to mostly care about the latest type
of hardware they shipped (this is my personal impression based on what
kind of updates I see for HP server with Intel CPU).

Xen has fixes for things which only work if you have some kind of
microcode, but it's a bit unclear how all these combinations work together.

If I am a stupid user which just wants to dist-upgrade and reboot and
then expect I'm doing the right thing, then where is the source of
information that tells me what I'm missing?

> We also had questions from Xen contributors and downstreams/users
> about qemu, PVH, UEFI, and support for booting newer versions of
> Windows.  Mostly I tried to answer these, as a representative of
> upstream.  I think an action point for upstream here is to consider
> how we can best present this kind of feature support information.
> 
> Some of it is in SUPPORT.md in xen.git, which is shown here
>   http://xenbits.xen.org/docs/unstable/support-matrix.html
> but perhaps the situation with Windows guest support should be written
> down somewhere on the wiki ?

My personal opinion is that ideally the goal should be (for Xen) to not
need to have that many wiki pages at a Debian wiki, but mostly refer
upstream documentation (which hopefully has a technical writer, someone
to manage it), and have us actively help upstream things instead of
choosing the easy way to edit a Debian wiki. There's a bunch of pages
now, and there's probably still also outdated info in there that I added
10 years ago.

For me, after seeing all of the spectre/meltdown stuff that happened
since dec 2017, it makes much more sense to try actively work with
upstream, transforming documentation from developer to user level
instead of trying to duplicate anything in a debian wiki.

> I asked about the versioning of the tools, as a quick check to see
> whether that is considered valuable.  (One main use case is to allow
> reboots of a host with running guests.)  Feedback was that this is
> still an important feature.

Good.

> There were a couple of questions about maintainership, including of
> the Xen packages and of the xen-tools package.  I'm currently the
> maintainer of Xen at least in stretch, although Hans has been working
> on buster and at this rate that he may well be a/the maintainer in
> buster.  The xen-tools package may be orphaned upstream, but is heavily
> used in the upstream CI, and it seems to work and be unlikely to
> break, so feeling at the BOF was that we don't think this is a serious
> difficulty.

I definitely see my role as an "a" instead of "the", trying to gather
people together, which can make things happen. Don't expect me myself to
fix your random problem. I have experience getting a bunch of rebellious
hackers together to organize an event, but at the same time,
technically, I'm a python programmer, I am comfortable implementing
linux kernel IOCTL APIs throwing bits around, but also still a big n00b
regarding C code compiling things, shared libraries and all those
things. I'm eager to learn, though, because I want to get better at that.

> Since no-one at the event objected, the event was video streamed,
> despite to the original programme note to the contrary.  So the video
> stream will be available from the Debconf conference video site in due
> course.

FYI, nope, there is no video in the archive.

Knorrie