[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Rudolph: merging Vixen and Comet



On Fri, Jan 12, 2018 at 06:57:09AM -0700, Jan Beulich wrote:
> >>> On 12.01.18 at 14:24, <wei.liu2@xxxxxxxxxx> wrote:
> > Here I list the differences between the two implementations.
> 
> Thanks for the summary.
> 
> >                       Vixen                          Comet
> > Boot mode             HVM                            PVH + HVM
> > Kconfig options       XEN_GUEST                      XEN_GUEST + PVH_GUEST 
> > + SHIM_EXCLUSIVE
> > Xen build system      No change                      New build target for 
> > shim 
> > Guest console         Output only                    Bi-directional
> > Guest domid           1 or set via shim option       1 or retrieved via 
> > cpuid
> > Guest type            Hardware domain                Normal domain
> > Time source           Emulated                       Xen PV clock
> > Shutdown              PV + HW                        PV
> > SI mapping            Reserved page                  Fixed map, PFN chosen 
> > at runtime
> > VCPU id               Handled by L1                  Provide by L0 if 
> > available
> > VCPU runstate         Forwarded to L0                Handled by L1
> 
> Is there anything known as to which of the two might be better,
> or whether perhaps the best choice depends on other
> circumstances?

Having the runstate mapped into L0 can let the L2 guest have accurate
stolen time accounting. I can see it is useful in a cloud environment
but not as important in a server virtualisation environment.

I think having the runstate forwarded by default would be better.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.