Pkg xen devel - Jul 2018 - Report on the Xen BOF at Debconf 18

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.

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 ?

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.

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.

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.

Ian.

Thank you for the report! Booting newer Windows versions with UEFI works fine
(if you use OVMF), were there any specific versions or problems mentioned?
I’ll see if I can find the videos when they are uploaded, that probably is much
faster to answer any questions I might have ;-)

John
> On 30 Jul 2018, at 05:11, Ian Jackson <ijackson at
chiark.greenend.org.uk> 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.
> 
> 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 ?
> 
> 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.
> 
> 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.
> 
> 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.
> 
> Ian.
> 
> _______________________________________________
> Pkg-xen-devel mailing list
> Pkg-xen-devel at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-xen-devel

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