Re: [Xen-devel] [HYBRID]: status update...

[Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>]

On Thu, 2 Aug 2012 10:53:16 +0100
George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:

> On 01/08/12 23:34, Mukesh Rathor wrote:
> > On Wed, 1 Aug 2012 16:25:01 +0100
> > George Dunlap <George.Dunlap@xxxxxxxxxxxxx> 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.
> 
> 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.
> 
>   -George



Ok, I changed all code references from xen_hybrid_domain to xen_pvh_domain
in linux. Changing xen code too. So it's PVH now.

thanks,
Mukesh


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