[Xen-devel] PVH cleanups after 4.5

[Tim Deegan <tim@xxxxxxx>]

Hi all,

At the Hackathon in Rackspace we discussed a plan to tidy up the
hypervisor side of PVH code so that 'PVH' stops being a separate guest
type, becoming instead a HVM guest with various features disabled (and
one or two other tweaks). 

Although I had hoped to work on that in the meantime, various other
things have got in the way.  But I'd like to at least document the
plan in the hope of getting back on track in the 4.6 development
cycle.

The plan goes something like this:

1. Merge the PVH and HVM hypercall tables.  Patches were already
   posted for this but will need rebasing, and probably more scrutiny.

2. Make PVH-ness a flag on a HVM guest, retaining all the current
   has_hvm_container/is_pvh_domain tests as-is but dropping the
   three-way guest type.

3. Add feature flags to HVM guests that disable various features. 
   These flags should be set once, at domain creation/build, and
   for sanity of testing we should only allow two combinations
   of settings, corresponding to the current HVM and PVH types.
   Make sure that all PVH guests have the PVH feature set.

4. Replace tests for pvh-ness with feature-flag tests wherever
   possible.

5. Fix any outstanding is_pvh tests -- expect this mostly to be 
   feature compatibility with other HVM features (e.g. paging).
   Hopefully we can remove those constraints, or make them constraints
   on a feature set (e.g. can't have PCI passthrough w/out an
   emulated PCI controller).  This also needs an audit of is_hvm tests,
   which are implicitly !is_pvh at the moment.

6. Remove 'PVH' from the hypercall interface, and remove the PVH flag
   from the HVM domain struct.  At this point Xen no longer treats PVH
   and HVM as different (though the tools and the guests themselves
   can maintain the distinction).

Potential feature flags, based on whiteboard notes at the session.
Things that are 'Yes' in both columns might not need actual flags :)

                     'HVM'       'PVH'
64bit hypercalls      Yes         Yes
32bit hypercalls      Yes         No
Paging assistance     Yes         Yes
ioreq-servers         Yes         No
HVM-style CPUID       Yes         Yes
Interrupt controllers Yes         No     ([x2]apic, ioapic, pic &c)
Timers                Yes         No     (rtc, hpet, pit, pmtimer)
Machine Check regs    Yes         Yes
Emulated PCI          Yes         No     (PVH to use pcifront?)

This plan doesn't explicitly add things that we might like to happen
for PVH in 4.6 (e.g. PCI passthrough, compat hypercalls) but it ought
to make some of them easier, and we might get some (e.g. shadow
pagetables) for free as the differences between PVH and HVM go away.

I would like to work on this stuff, but I can't really guarantee to
get anything done for 4.6 in the time I have available.  Any
volunteers to help out would be welcomed!  Likewise, any feedback on
the overall plan is welcome before any more work gets done. :)

Cheers,

Tim.

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