Re: [HYBRID]: status update...

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Thu, Aug 02, 2012 at 10:53:16AM +0100, George Dunlap wrote:
> On 01/08/12 23:34, Mukesh Rathor wrote:
> >On Wed, 1 Aug 2012 16:25:01 +0100
> >George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> >
> >>I hope this isn't bikeshedding; but I don't like "Hybrid" as a name
> >>for this feature, mainly for "marketing" reasons.  I think it will
> >>probably give people the wrong idea about what the technology does.
> >>PV domains is one of Xen's really distinct advantages -- much simpler
> >>interface, lighter-weight (no qemu, legacy boot), &c &c.  As I
> >>understand it, the mode you've been calling "hybrid" still has all of
> >>these advantages -- it just uses some of the HVM hardware extensions
> >>to make the interface even simpler / faster.  I'm afraid "hybrid" may
> >>be seen as, "Even Xen has had to give up on PV."
> >>
> >>Can I suggest something like "PVH" instead?  That (at least to me)
> >>makes it clear that PV domains are still fully PV, but just use some
> >>HVM extensions.
> >>
> >>Thoughts?
> >Hi George,
> >
> >We gave some thought looking for name. I figured pure PV will be around for
> >a while at least. So there's PV on one side and HVM on the other, hybrid
> >somewhere in between.
> I understand the idea, but I think it's not very accurate.  I would
> call Stefano's "PVHVM" stuff hybrid -- it has the legacy boot and
> emulated devices, but uses the PV interfaces for event delivery
> extensively.  The mode you're working on is too far towards the "PV"
> side to be called "hybrid".  (And as we've seen, the term has
> already confused people, who interpreted it as basically PVHVM.)
> >
> >The issue with PV in HVM is that it limits PV to HVM container only. The
> >vision I had was that hybrid, a PV ops kernel that is somewhere in between
> >PV and HVM, could be configured with options. So, one could run hybrid
> >with say EPT off (altho, won't be supported this anymore). But generic name
> >like hybrid allows it in future to be flexible, instead of confined to a
> >specific. I suppose a PV guest could just be started with various options.
> In general, I think "PV" should mean, "Doesn't use legacy boot,
> doesn't need emulated devices".  So I don't think "PVH" places any
> limitations on what particular subset of HVM hardware you use.  For
> things that specifically depend on knowing whether guest PTs are
> using mfns or gpfns, I think we should have checks for specific
> things -- for instance, "xen_mm_translate()" or something like that.


I like that.. We currently have 'if (feature(AUTOTRANSLATE)' .. blah
blah sprinkled around.

If we altered it to be 'if (xen_mm_translate())' and replaced a bunch
of 'if (xen_pv_domain())' with that it should make it easier. It
might even make the 'xen_hybrid_domain()' not needed at all.

This is good - it would also allow to remove some of the 'xen_hvm_domain()'
with it.

> 
> Also, don't confuse EPT (which is Intel-specific) with HAP (which is
> the generic term for either EPT or RVI); and don't confuse either of
> those with what is called "translate" mode.  Translate mode (where
> Xen translates the guest PTs from gpfns to mfns) can be done either
> with HAP or with shadow; and given the performance issues HAP has
> with certain workloads, we need to make sure that the HVM container
> mode can use both.
> 
> >As for name in code, 'pvh' was confusing, as PVHVM is now routinely used to
> >refer to HVM with PV drivers. 'hpv' for HVM/hybrid PV, well, thats a certain
> >virus ;). So I just used hybrid in the code to refer to PV guest that runs
> >in HVM container. I suppose I could change the flag to pv_in_hvm or
> >something.
> But is "pvhvm" ever actually used in the code?  If not, it's not a problem.
> 
> Actually, perhaps it would be better in any case, rather than having
> checks for "pvh" mode, to have checks for specific things -- e.g.,
> is translation on or off (i.e., are running in classic PV mode, or
> with HAP)?  I'm not sure the other things you're doing with HVM, but
> it should be possible to come up with a descriptive name to use in
> the code for those options, rather than limiting to a specific mode.
> 
> In ancient days, there used to be options, both within Xen and
> within the classic Xen kernel, to run a PV guest in fully-translated
> mode (i.e., the guest PTs contained gpfns, not mfns), and
> "shadow_translate" was a mode used across guest types (both PV and
> HVM) to determine whether this was the case or not.

dom0_shadow=true .. And strangly enought it looks to actually boot
the pvops kernel (dom0) without much issues. Wow. It must be faking it
I think - no bugs??!