[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |