[Xen-devel] [MINUTES] Monthly Xen.org Technical Call (2015-07-22)

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

This was the rescheduled 8 July call, on the topic of PVH and related work

= Attendees =

 * Ian Campbell
 * David Vrabel
 * Stefano Stabellini
 * Boris Ostrovsky
 * Elena Ufimtseva
 * Wei Liu
 * George Dunlap
 * Konrad Rzeszutek Wilk
 * Jan Beulich
 * Daniel Kiper
 * Andrew Cooper 
 * Roger Pau Monne

Apologies:

 * Ian Jackson

= Current Status =

Note on naming: Eventually we will end up with a thing called PVH. At
the moment there are two options for who we get there. For the
purposes of this discussion we need to distinguish the two
approaches. So we call them "PVH classic" (the approach following the
path start by Mukesh) and "no-dm" (the approach which Roger has
proposed patches for).

== PVH (classic) ==

Boris: Most important lack is 32-bit, AMD and migration support. To
get the code to support the first two features doesn't require major
additional code but doesn't get us where we wanted to go.

George: Does it work with shadow? Answer: No.

Andy: Also doesn't work with AMD.

Andy: What is wrong with migration?
Boris: It may be a trivial fix but it doesn't work in practice
Andy: Thought Roger had fixed
Roger: Fixed migration using PVH dom0, but not of a PVH guest.

Stefano: Also missing PCI passthrough

Jan: MMIO handling for dom0 is a problem with the current code,
e.g. MSI related issues.

Boris: 32-bit patches only support domU
Roger: Not sure of the point of 32-bit dom0 PVH

Someone/several: Should be no restriction on the mode of a PVH guest.

== PVH (no-dm/HVMlite) ==

Roger:

Picked up libxc and noticed that the PV vs HVM builders are very
different and the HVM one is not very good. Currently patches move the
builder for HVM to use the same code as the PV builder code. Not too
complicated, lots of hooks in place already. Adds another type of
guest with e.g. different hooks for populating memory, special pages.

Has been able to unify the way we build the two guest types, to the
point of one function in libxl being the decision point.

Can now choose a container type and then load whatever kernel,
hvmload, PV kernel, pv grub etc etc.

Remaining work is to disable emulated devices in Xen.

Start a no-dm guest as an HVM guest, 32-bit flat, same as with HVM
today with the entry point.

= Ongoing work =

(we sort of drifted into this)

Needs a kernel with a suitable 32-bit flat entry point, which may be
Xen specific or may be possible to share with native (depends on the
guest). Other than entry point doesn't need much other than PVH.

Konrad: Another entry point without page tables might be an issue in
terms of upstreaming to Linux. Going from the Xen entry point to the
Linux generic entry point is similar to the x86/PV.

Roger: The physical entry point should use a different ELF note, could
also check for 32 vs 64 but would prefer not to, i.e. would prefer to
have the guest take care of the mode starting from a common mode.

Konrad: The issue is that it expects a bootloader stub (internal to
Linux).

David: Can we use EFI firmware (replacing hvmloader) which provides a
known entry protocol etc and boots using the UEFI interfaces.

George: Need to think about microkernels too

David: EFI just for Linux, but microkernels do not have to use it.

Roger: dom0 is a problem for UEFI

David: Just use it as another multiboot module

Jan: Using OVMF/EFI as the basis, is: Is OVMF Xen aware.

Andy: it is aware of PV drivers

Jan: But not using all of the PV infra is the bigger part.

David: PV entry point is a non-starter. If the entry point for no-dm
is not the native entry point then it is not viable and won't be
accepted. Maybe not the full UEFI firmware, but some sort of firmware.

Ian: Do we mean the 32- or 16-bit real entry point?

David: Needs to see a more concrete proposal. It is fine to have a
stub to build a set of 64-bit page tables and enter at the 64-bit
entry point.

Konrad: Would need per OS stubs.

David: Doesn't see a problem with that.

Konrad: This path wouldn't enable the pvops hooks

David: Those hooks already exists.

Roger: But where can you set those hooks?

Konrad: Much later. What happens between early boot up stage and when
we can set those hooks.

David: Something which needs to get looked at.

Andy: Could move the native entry points per-hypervisor checks
earlier.

Konrad: This means working with the x86 maintainers.

David: Doesn't see any issue with that.

Andy: Also benefits other hypervisors not just us.

Summary:

  - Want boot up path to be as no-dm (flat 32-bit, no paging), with
    different per-OS stubs depending on the OS, which setup whatever
    is needed for the given OS.

Roger: Where does the stub live, in Xen or in guest OS?

David: Stub could live in the guest OS. Self contained, independent of
other x86 code. Just needs to go from Xen entry point to the native
entry point.

Roger: Needs to be bundled with Linux

Stefano: Similar model to the EFI stub.

Ian: Need some way to find the Xen entry point.

Konrad: Who is going to write that code.

Boris: Was planning to do for Linux as Roger did for BSD.

Roger: Was ~200 lines of code for BSD.

Konrad: Need to setup Linux bootparams code.

David: Bigger concern is the early stuff which assumes ACPI tables and
so on in the native path. A certain amount of chasing these cases down
and removing assumptions.

Konrad: Bring up of secondary processors, how do to.

Roger: It has to use the PV interface

Andy: Should just expose that to HVM guests.

Roger: Baremetal way requires a local APIC, so PV is the only way.

Andy: Eventually want to expose a local APIC to PVH guests when
Post-Interrupts are available. To start with lets disable, but
eventually may want to allow emulated local APIC.

Ian: As we do on ARM. But lets leave this for a future discussion.

= Next steps =

General agreement to go to the no-dm approach to PVH.

Boris: What about the short term?

David: Lets not worry short term and stop working on PVH classic. Lets
focus on doing it right.

Konrad: PVH classic useful for e.g. testing

George: No point testing PVH classic on AMD and then doing it again on
no-dm. Just do it once.

Konrad: So should stop work on AMD support, but keep going with
secondary processor setup (which is the same in both approaches).

David: The initial list of features are things which (hopefully) just
work if you use no-dm.

Konrad: PCI passthrough is the exception

Andy: PCI passthrough (and dom0) can be exluded from the initial set.

Summary: Will go with the no-dm approach, stopping work on anything in
classic which cannot be reused for no-dm.

Boris: Would prefer to see 32-bit stuff go in as it is a very small
amount of code, bit of not would continue with no-dm.

Jan: It could in principal subject to the freeze. Post freeze does it
make sense to commit something which we are committed to replacing?
Worst case need to remove a little bit extra, not a big deal.

David: Similarly for the Linux side.

Andy: Roger, do you think it is reasonable to plan for ~January to
have: plain domU no-dm style work, no frills, no passthrough, no
dom0. With a stable interface.

Roger: The series seems in good shape, but hasn't had lots of comments
due to the freeze. Is a good cleanup in any case, the rest shouldn't
be that intrusive and is mostly cleanup of things we already
have. Very likely to make 4.7. Was hoping to even do dom0.

David: To declare the ABI stable need 2 guests to use it. i.e. add
Linux to the existing BSD.

Roger: ABI is as HVM today plus some hypercalls one for memory map and
three to do secondary CPU setup, all that is needed for simple no-dm
approach. More needed for passthrough.

Boris and Roger will do most of this, Boris is planning to do the
Linux entry point.

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