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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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).

> 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.

> 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.

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"?

Thanks, Roger.

[0] https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00184.html

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