OVMF BoF @ KVM Forum 2015

OVMF BoF @ KVM Forum 2015

[Laszlo Ersek]

Hi.

Let's do an OVMF BoF at this year's KVM Forum too.

Paolo will present

  Securing secure boot: system management mode in KVM and Tiano Core

on Thursday, August 20, in the 5:00pm - 5:30pm time slot.

Right after that, the BoF section starts at 5:30pm:

  http://events.linuxfoundation.org/events/kvm-forum/program/schedule

We should convene and discuss stuff. I don't have an agenda, so people
should bring their ideas and questions (famous last words).

As food for thought, I tried to collect the feature-looking patches from
the git history that have been committed since last year's KVM Forum,
and to match them against patch sets on the mailing list:

  git log --reverse --oneline --since=2014-10-14 -- \
      OvmfPkg/ \
      ArmVirtPkg/ \
      ArmPlatformPkg/ArmVirtualizationPkg/

I attempted to sort them into categories. You can see the list below.
The ordering is totally random, it's just what I ended up with.
Corrections / additions welcome.

Personally, one (missing) feature I'd like to see discussed is
"SataControllerDxe in OVMF". SMM will require Q35, and the only "IDE"
that Q35 speaks is SATA / AHCI. (And you can't disable that controller
on Q35.)

Anyway, here goes.

Features completed
------------------

(... unless marked [pending])

- Xen guest:

  - PV block driver:
    [PATCH v4 00/19] Introducing Xen PV block driver to OVMF

  - Xen for ARM:
    [PATCH v5 00/29] Xen/ARM guest support

- PCI / hw related:

  - PCI on ARM; detect VGA and USB keyboard:
    [PATCH v3 00/28] ArmVirtualizationPkg/ArmVirtualizationQemu: enable PCI
    [PATCH 0/4] ArmVirtualizationPkg: PlatformIntelBdsLib: dynamic console setup

  - support for Q35:
    [PATCH v6 0/9] OVMF: Add support for Qemu Q35 machine type
    [PATCH 1/1] OvmfPkg: QemuBootOrderLib: parse OFW device path nodes of PCI bridges

  - USB3 (ARM and x86):
    [PATCH v2 2/4] ArmVirtualizationPkg/ArmVirtualizationQemu: include XHCI driver
    [PATCH v2 4/4] OvmfPkg: include XHCI driver

  - support TCO watchdog emulation features:
    [PATCH v5 2/2] OvmfPkg/PlatformPei: Initialise RCBA (B0:D31:F0 0xf0) register

  - virtio-vga:
    [PATCH] Add virtio-vga support

  - support extra PCI root buses for NUMA-locality with assigned
    devices:
    [PATCH v3 00/23] OvmfPkg: support extra PCI root buses

- QEMU config integration:

  - fw_cfg, boot order, and -kernel booting on ARM:
    [PATCH v4 00/13] ArmVirtualizationQemu: support fw_cfg, bootorder, '-kernel'
    [PATCH 0/3] ArmVirtPkg: drop support for the ARM BDS

  - support for "-boot menu=on[,splash-time=N]":
    [PATCH v2 0/3] OVMF, ArmVirt: consume QEMU's "-boot menu=on[,splash-time=N]"

  - ACPI tables for ARM:
    [PATCH v2 0/3] ACPI over fw_cfg for ARM/AARCH64 qemu guests

  - SMBIOS features: Type 0 default, and SMBIOS 3.0 support on ARM and
    x86:
    [PATCH] OvmfPkg/SMBIOS: Provide default Type 0 (BIOS Information) structure
    [PATCH v2 0/6] ArmVirtPkg/ArmVirtQemu: support SMBIOS
    [PATCH 0/9] OvmfPkg, ArmVirtPkg: SMBIOS 3.0, round 2

- ARM specific:

  - "fun" with the caches:
    [PATCH v4 0/5] ArmVirtualizationPkg: explicit cache maintenance

  - secure boot:
    [PATCH v3 0/3] ArmVirtualizationQemu: enable support for UEFI Secure Boot

  - performance optimization:
    [PATCH v2 0/6] ArmPkg/ArmVirtPkg: GIC revision detection

  - better handling for the typical Linux terminal (generic driver code,
    hooked up to ArmVirt):
    [PATCH V4 0/5] Add TtyTerm terminal type

- SMM for OVMF (in progress):
    [PATCH 00/11] Bits and pieces
    [PATCH 00/58] OvmfPkg: support SMM for better security (single VCPU, IA32) [pending]

- Build system:

  - moving to NASM:
    [PATCH 0/7] Convert OVMF assembly to NASM
    [PATCH v2 0/6] OvmfPkg/XenBusDxe: Convert *.asm to NASM.

  - accept UTF-8 in .uni files:
    [PATCH v4 00/10] Support UTF-8 in .uni string files

  - LLVM/clang support for AARCH64 (in progress):
    [PATCH v4 00/13] BaseTools: unify all GCC linker scripts
    [PATCH v4 0/7] small model and clang support for AARCH64 [pending]

- UEFI compliance:

  - support for OsIndications:
    [PATCH v2 0/9] OvmfPkg: PlatformBdsLib cleanups and improvements

  - signal ReadyToBoot:
    [PATCH 1/8] OvmfPkg/PlatformBdsLib: Signal ReadyToBoot before booting QEMU kernel

  - signal EndOfDxe:
    [PATCH v2] ArmVirtPkg: signal EndOxDxe event in PlatformBsdInit
    [PATCH v2 0/6] OvmfPkg: save S3 state at EndOfDxe

  - fix Serial IO Protocol issues flagged by SCT
    [PATCH V4 0/5] Some improvements on serial terminal

- other

  - big OVMF guests:
    [PATCH v2 0/4] OvmfPkg: enable >= 64 GB guests

  - IPv6 (conditionally enabled):
    [PATCH v2] OvmfPkg: enable the IPv6 support

  - many fixes for toolchain warnings and C language misuse

Thanks
Laszlo

Re: OVMF BoF @ KVM Forum 2015

[Laszlo Ersek]

On 09/09/15 18:34, Ian Campbell wrote:
> On Wed, 2015-09-09 at 10:57 +0200, Laszlo Ersek wrote:
>> On 08/10/15 18:24, Laszlo Ersek wrote:
>>> Hi.
>>>
>>> Let's do an OVMF BoF at this year's KVM Forum too.
>>
>> Here's a preliminary task list
> 
> Thanks for including xen-devel in this. Was anyone from the Xen community
> present at the BoF (so far as you know)? Are there any minutes or anything
> like that for those interested in the discussion and reasoning rather than
> just the resulting action items?

Okay, second attempt at an answer. I *have* forgotten a great deal of
the sentences that were uttered at the BoF, but I mostly remember why we
wanted these things. :)

So let me see if I can elaborate on these (after all you are interested
in the reasoning in general, not just the discussions that I fail to
recall in detail):

>> , after some off-list discussion (I tried
>> to incorporate comments):
>>
>> - create GPL'd fork called "ovmf" for expediting virt development
>>   (OvmfPkg, ArmVirtPkg)
>>   - maybe leverage the feature under
>>     <http://permalink.gmane.org/gmane.comp.bios.edk2.devel/941> for
>>     setting up a separate "tianocore/edk2-gpl" repo, for GPL'd
>>     contributions [Jordan]
>>     - repo separation by license could make things harder for packagers
>>       and QEMU bundling [Laszlo]

So in this item (which, in the above form, is already obsolete) I
managed to mix up three separate things. (But Jordan then went on and
clarified those today.)

(1) One thing is a virt-oriented fork of edk2, without explicit
licensing-oriented goals. The main purpose of this fork would be to
expedite virt development (OvmfPkg, ArmVirtPkg, and central packages on
which the former two depend).

It has sometimes occurred that an OVMF feature got tied up in
inter-maintainer disagreement, or other non-technical reasons (lack of
review capacity etc). This holds back virt development, plus it has the
potential to force downstreams (let's be concrete: Red Hat at minimum)
to carry some patches in downstream only.

The fork would accelerate things here. We'd have a set of rules for
committing to the fork (and the divergence would have to be rebased
periodically, or alternatively edk2 patches would have to be merged into
the fork, periodically).

Considering this purpose (ie. expediting virt development) in isolation,
the fork should stick with the original edk2 licenses.

(2) The *ability* to provide the end user with free software (in the
FSF's definition) or open source software (in the OSI's definition),
which the current FAT driver is regrettably none of, is extremely important.

Currently the only alternative that appears feasible is Peter Batard's
UEFI port of GRUB's read-only FAT driver. That driver comes under the
GPL, and therefore it ties into topic (3) below.

However, note that if the in-tree FAT driver were liberated (= made Free
or Open Source Software, for example by dropping the "Additional Terms"
from its license, thereby rendering it 3-BSDL), then goal (2) would be
immediately achieved, and it wouldn't tie into goal (3) below.

(3) Accommodating drivers that contributors can (or are willing to)
submit only under the GPL would be nice. For example there has been such
a contribution from Ludovic Rousseau, a smart card reader protocol
implementation (a port from Linux).

Jordan's most recent suggestion was to actually keep GPL'd drivers
within edk2, under "GplDriverPkg". This is being discussed on
edk2-devel, so I'll move on.

>> - document the rules / justification for "ovmf" (licensing
>>   conflicts, non-technical blockage on edk2 etc).
>> - No new mailing list needed

Okay, so the rules. They would go like (obviously they are up for
discussion):

- submit your stuff to edk2-devel as always

- work with the reviewers / maintainers

- if you get demonstrably stuck, due to inter-maintainer deadlock (ie.
  you'd be fine implementing either maintainer's request, but their
  requirements *together* are unsatisfiable, because they conflict),
  the patches can be committed to the fork, subject to review *for* the
  fork

- same if there's just no feedback for a patchset

- same if the patches are blocked due to non-technical criticism

- maybe the same if the technical feedback would require
  *disproportionate* effort (ie. cross-package refactorings), esp.
  involving client (=platform) packages that are not related to virt.
  We have to be careful with this one (it's not a blanket excuse, and
  arguments are bound to be somewhat subjective here), but such
  unjustified / overarching / disproportionate requirements can block
  the upstreaming of a feature (developed under a deadline) for good.

  Example: consider a refactoring that straddles DuetPkg or EmulatorPkg
  *and* MdeModulePkg, so that you can use a feature in OvmfPkg. You
  just turned a two week development effort into 6-8 weeks.

  No. You might not even have the environment to test DuetPkg. Etc.

- Initial set of committers to this fork would be the current virt
  package maintainers (ArmVirtPkg, OvmfPkg).

- Reviews should be done for the fork too, of course. But, the chance
  for inter-maintainer deadlock is much smaller. (Eg. if a virt-pkg
  maintainer "deadlocks" with a non-virt-pkg maintainer while reviewing
  a virt-related (or virt-serving!) patch, then as far as the "ovmf"
  repo is concerned, the virt-pkg maintainer's requirements
  automatically "win", and the patch submitter becomes capable of
  implementing the requirements, even if the implementation affects the
  non-virt-pkg maintainer's package.)

>> - push RH's downstream-only patches to "ovmf", wherever that makes
>>   sense

Some of those are downstream only due to problems listed above. Some
other patches are admittedly not suitable for upstream. (They are not
"secret"; anyone can see them in the SRPM.)

>> - remove encumbered FAT driver

See (2)

>> - import Peter Batard's GPL r/o FAT driver port of GRUB's

This is *one* alternative for solving (2), and it happens to tie into
(3). (The optimal alternative would be relicensing the in-tree FAT
driver, but that's not something that can be contributed.)

>> - secure OpenSSL linking exception for the former from the copyright
>>   holders (Peter Batard, GRUB project)

Further complication for (3). "Linking" GPL code together with OpenSSL
licensed code is not trivial, I'm told. (The concept of "linking" might
also be interesting for a firmware image.) I'm not a lawyer (obviously),
so this item is here to keep the question on the radar.

I'll note that if (2) was solved by relicensing the current FAT driver
(and therefore (2) didn't tie into (3)), then (2) would become
independent of this question as well, and this question would lose a lot
of significance (similarly to (3)).

>> - "ovmf" should be periodically rebased / should fetch+merge edk2 as
>>   master (arguments both for and against merging); distros should
>>   then track "ovmf" as their upstream, not edk2

Distros packaging OVMF and/or ArmVirtPkg should follow the fork, because
some ("trapped") features would exist only there.

>> - get OVMF into Fedora (as pkg) and QEMU (as bundled binary)

(2) is both necessary and sufficient for this!

>> - do OVMF releases, maybe in sync with QEMU's releases
>>   - we can probably build from known good revisions from git [Alex]

Helps with error reporting and narrowing down regressions, before
starting an actual bisection.

>> - revive Q35 SATA driver work / poke Reza
>>   - Hannes and Gabriel have refreshed patches, but their versions differ

A SATA driver for Q35 would be really nice, although both Linux and
Windows guests can be installed without such a firmware driver
(requiring virtio-containing initrd's / driver disks, respectively).
AFAIR this work got bogged down in cross-module requirements too.

... I hope this helps. I'm sorry if the above ended up chaotic; I'm
tired but I didn't want to leave it at "I don't remember". I do remember
the reasons, if not the specific discussion.

Corrections welcome, of course...

Thanks
Laszlo


>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel

Re: OVMF BoF @ KVM Forum 2015

[Laszlo Ersek]

On 09/09/15 18:34, Ian Campbell wrote:
> On Wed, 2015-09-09 at 10:57 +0200, Laszlo Ersek wrote:
>> On 08/10/15 18:24, Laszlo Ersek wrote:
>>> Hi.
>>>
>>> Let's do an OVMF BoF at this year's KVM Forum too.
>>
>> Here's a preliminary task list
> 
> Thanks for including xen-devel in this. Was anyone from the Xen community
> present at the BoF (so far as you know)?

Noone was. And I know it for a fact, because all of the handful of BoF
participants were sitting around one table. :)

(If someone speaks up now, "hey I was there, and I'm a Xen guy", then
I'll just dig myself a pit.)

> Are there any minutes or anything
> like that for those interested in the discussion and reasoning rather than
> just the resulting action items?

Not really; I think this todo list is pretty comprehensive. I remember
talking a lot and having trouble breathing (I had gotten sick just a few
days earlier -- yay crowded conferences and parties), but I tend to
speak in many details about few things, and not concisely about many things.

Should you care about those details, I've now forgotten them all. They
probably weren't important anyway. I recall trying to convince Jordan
politely to review my SMM patches. We probably discussed some SMM details.

... Please ask Jordan or the other participants, they weren't sick, and
they don't have a chronic verbosity problem.

... Man, it must be great to work with me! ;)

Thanks for your interest!
Laszlo

> 
> Thanks,
> Ian.
> 
>> , after some off-list discussion (I tried
>> to incorporate comments):
>>
>> - create GPL'd fork called "ovmf" for expediting virt development
>>   (OvmfPkg, ArmVirtPkg)
>>   - maybe leverage the feature under
>>     <http://permalink.gmane.org/gmane.comp.bios.edk2.devel/941> for
>>     setting up a separate "tianocore/edk2-gpl" repo, for GPL'd
>>     contributions [Jordan]
>>     - repo separation by license could make things harder for packagers
>>       and QEMU bundling [Laszlo]
>> - document the rules / justification for "ovmf" (licensing
>>   conflicts, non-technical blockage on edk2 etc).
>> - No new mailing list needed
>> - push RH's downstream-only patches to "ovmf", wherever that makes
>>   sense
>> - remove encumbered FAT driver
>> - import Peter Batard's GPL r/o FAT driver port of GRUB's
>> - secure OpenSSL linking exception for the former from the copyright
>>   holders (Peter Batard, GRUB project)
>> - "ovmf" should be periodically rebased / should fetch+merge edk2 as
>>   master (arguments both for and against merging); distros should
>>   then track "ovmf" as their upstream, not edk2
>> - get OVMF into Fedora (as pkg) and QEMU (as bundled binary)
>> - do OVMF releases, maybe in sync with QEMU's releases
>>   - we can probably build from known good revisions from git [Alex]
>> - revive Q35 SATA driver work / poke Reza
>>   - Hannes and Gabriel have refreshed patches, but their versions differ
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel

Re: OVMF BoF @ KVM Forum 2015

[Ian Campbell]

On Wed, 2015-09-09 at 10:57 +0200, Laszlo Ersek wrote:
> On 08/10/15 18:24, Laszlo Ersek wrote:
> > Hi.
> > 
> > Let's do an OVMF BoF at this year's KVM Forum too.
> 
> Here's a preliminary task list

Thanks for including xen-devel in this. Was anyone from the Xen community
present at the BoF (so far as you know)? Are there any minutes or anything
like that for those interested in the discussion and reasoning rather than
just the resulting action items?

Thanks,
Ian.

> , after some off-list discussion (I tried
> to incorporate comments):
> 
> - create GPL'd fork called "ovmf" for expediting virt development
>   (OvmfPkg, ArmVirtPkg)
>   - maybe leverage the feature under
>     <http://permalink.gmane.org/gmane.comp.bios.edk2.devel/941> for
>     setting up a separate "tianocore/edk2-gpl" repo, for GPL'd
>     contributions [Jordan]
>     - repo separation by license could make things harder for packagers
>       and QEMU bundling [Laszlo]
> - document the rules / justification for "ovmf" (licensing
>   conflicts, non-technical blockage on edk2 etc).
> - No new mailing list needed
> - push RH's downstream-only patches to "ovmf", wherever that makes
>   sense
> - remove encumbered FAT driver
> - import Peter Batard's GPL r/o FAT driver port of GRUB's
> - secure OpenSSL linking exception for the former from the copyright
>   holders (Peter Batard, GRUB project)
> - "ovmf" should be periodically rebased / should fetch+merge edk2 as
>   master (arguments both for and against merging); distros should
>   then track "ovmf" as their upstream, not edk2
> - get OVMF into Fedora (as pkg) and QEMU (as bundled binary)
> - do OVMF releases, maybe in sync with QEMU's releases
>   - we can probably build from known good revisions from git [Alex]
> - revive Q35 SATA driver work / poke Reza
>   - Hannes and Gabriel have refreshed patches, but their versions differ
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: OVMF BoF @ KVM Forum 2015

[Laszlo Ersek]

On 08/10/15 18:24, Laszlo Ersek wrote:
> Hi.
> 
> Let's do an OVMF BoF at this year's KVM Forum too.

Here's a preliminary task list, after some off-list discussion (I tried
to incorporate comments):

- create GPL'd fork called "ovmf" for expediting virt development
  (OvmfPkg, ArmVirtPkg)
  - maybe leverage the feature under
    <http://permalink.gmane.org/gmane.comp.bios.edk2.devel/941> for
    setting up a separate "tianocore/edk2-gpl" repo, for GPL'd
    contributions [Jordan]
    - repo separation by license could make things harder for packagers
      and QEMU bundling [Laszlo]
- document the rules / justification for "ovmf" (licensing
  conflicts, non-technical blockage on edk2 etc).
- No new mailing list needed
- push RH's downstream-only patches to "ovmf", wherever that makes
  sense
- remove encumbered FAT driver
- import Peter Batard's GPL r/o FAT driver port of GRUB's
- secure OpenSSL linking exception for the former from the copyright
  holders (Peter Batard, GRUB project)
- "ovmf" should be periodically rebased / should fetch+merge edk2 as
  master (arguments both for and against merging); distros should
  then track "ovmf" as their upstream, not edk2
- get OVMF into Fedora (as pkg) and QEMU (as bundled binary)
- do OVMF releases, maybe in sync with QEMU's releases
  - we can probably build from known good revisions from git [Alex]
- revive Q35 SATA driver work / poke Reza
  - Hannes and Gabriel have refreshed patches, but their versions differ