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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Fri, Jan 12, 2018 at 02:18:33PM +0000, Roger Pau Monné wrote:
> On Fri, Jan 12, 2018 at 01:24:09PM +0000, Wei Liu wrote:
> > Hi all,
> > 
> > Two solutions are proposed to mitigate Meltdown. One is called Vixen and the
> > other is called Comet. The long term goal is to merge the two 
> > implementations
> > to one.
> > 
> > Here I list the differences between the two implementations.
> > 
> >                       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
> 
> Clock source for Comet is the PV wallclack.
> Timer source for Comet is the emulated LAPIC.
> 
> IIRC there's only support for fetching the PV wallclock in Comet, but
> there's no support for the PV timer (VCPUOP_set_singleshot_timer or
> similar).

That's right.

> 
> > Shutdown              PV + HW                        PV
> > SI mapping            Reserved page                  Fixed map, PFN chosen 
> > at runtime
> > VCPU id               Handled by L1                  Provide by L0 if 
> > available
> 
> I think this field is not very clear. For Vixen vcpu_id ==
> smp_processor_id, for Comet vcpu_id is fetched from L0 if provided via
> cpuid, or else smp_processor_id is used.
> 
> But the vcpu_id provided to the guest doesn't depend on that.

Right. This should be revised to

L1 CPU id                smp_processor_id                From L0 or 
smp_processor_id

> 
> > VCPU runstate         Forwarded to L0                Handled by L1
> 
> The runstate information provided to the guest should be the L0 one,
> or else it's just not accurate. I consider this a cosmetic issue,
> since it's not going to affect how the guest runs, it's just a nice to
> have piece of information.
> 
> > Xen version           L0 version                     L1 version
> > CPUID faulting        None                           Changes for Intel and 
> > AMD
> 
> That's not exactly true from my understanding. Vixen also needs the
> AMD cpuid faulting patch [0] in order to run Vixen reliably on AMD
> hardware. This same patch is also needed for Comet to run in AMD
> hardware.

This is about what is implemented, not whether it is needed or not. So
"None" here is accurate.

I agree with you that both will need to have CPUID faulting support.

> 
> Since both are mitigations for Meltdown, and Meltdown only affects
> Intel processors I would say that in order to deploy the mitigation
> _on affected processors_ no CPUID faulting changes are needed for
> L0.
> 
> > Grant table           What is forwarded is more or less the same but 
> > differs in implementation
> 
> Yes, I think both Vixen and Comet only support GNTTABOP_setup_table
> and GNTTABOP_query_size.
> 
> Comet has the bonus that it uses unpopulated PFNs to map the grant
> table frames, while Vixen uses populated PFNs.
> 
> > Event channel setup   3 mechanisms                   1 mechanism
> 
> Maybe "Event channel interrupt setup"?
> 

Sure.

Wei.

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