Rudolph: merging Vixen and Comet

Rudolph: merging Vixen and Comet

[Wei Liu]

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
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
Xen version           L0 version                     L1 version
CPUID faulting        None                           Changes for Intel and AMD
Grant table           What is forwarded is more or less the same but differs in implementation
Event channel setup   3 mechanisms                   1 mechanism
Event channel         ECS_PROXY state                Use ECS_RESERVED
                      Differences in what gets forwarded
Migration             No                             Yes
CPU hotplug           No                             Yes
Memory hotplug        No                             Yes

These are the things I can think of when comparing the two series side
by side.  Feel free to provide addition and / or correction.  The list
serves as a guidance on what areas need attention.

Thanks,
Wei.

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

Re: Rudolph: merging Vixen and Comet

[Jan Beulich]

>>> On 12.01.18 at 14:24, <wei.liu2@citrix.com> 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?

> Xen version           L0 version                     L1 version

I think this should really the smaller of the two.

Jan


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

Re: Rudolph: merging Vixen and Comet

[Wei Liu]

On Fri, Jan 12, 2018 at 06:57:09AM -0700, Jan Beulich wrote:
> >>> On 12.01.18 at 14:24, <wei.liu2@citrix.com> 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Rudolph: merging Vixen and Comet

[Olaf Hering]

[-- Attachment #1.1: Type: text/plain, Size: 253 bytes --]

On Fri, Jan 12, Wei Liu wrote:

>                       Vixen                          Comet
> Guest console         Output only                    Bi-directional

With the proper patch input works for Vixen. Unless this item mean
something else.

Olaf

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: Rudolph: merging Vixen and Comet

[Wei Liu]

On Fri, Jan 12, 2018 at 03:17:04PM +0100, Olaf Hering wrote:
> On Fri, Jan 12, Wei Liu wrote:
> 
> >                       Vixen                          Comet
> > Guest console         Output only                    Bi-directional
> 
> With the proper patch input works for Vixen. Unless this item mean
> something else.

Vixen means the version upstream put into the advisory. The patch you
talked about is not provided in that branch.

Wei.

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

Re: Rudolph: merging Vixen and Comet

[Doug Goldstein]

[-- Attachment #1.1.1: Type: text/plain, Size: 889 bytes --]

On 1/12/18 8:20 AM, Wei Liu wrote:
> On Fri, Jan 12, 2018 at 03:17:04PM +0100, Olaf Hering wrote:
>> On Fri, Jan 12, Wei Liu wrote:
>>
>>>                       Vixen                          Comet
>>> Guest console         Output only                    Bi-directional
>>
>> With the proper patch input works for Vixen. Unless this item mean
>> something else.
> 
> Vixen means the version upstream put into the advisory. The patch you
> talked about is not provided in that branch.
> 
> Wei.
> 

Can we merge some fixes people have proposed into the Vixen branch?
There are a number of virtualization providers that have rolled forward
with Vixen. They are clearly contributing patches on the ML and having
one place to work together would be nice.

We can always host a fork on GitHub and merge patches there as well if
that's preferred.

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: Rudolph: merging Vixen and Comet

[George Dunlap]

On Tue, Jan 16, 2018 at 4:42 PM, Doug Goldstein <cardoe@cardoe.com> wrote:
> On 1/12/18 8:20 AM, Wei Liu wrote:
>> On Fri, Jan 12, 2018 at 03:17:04PM +0100, Olaf Hering wrote:
>>> On Fri, Jan 12, Wei Liu wrote:
>>>
>>>>                       Vixen                          Comet
>>>> Guest console         Output only                    Bi-directional
>>>
>>> With the proper patch input works for Vixen. Unless this item mean
>>> something else.
>>
>> Vixen means the version upstream put into the advisory. The patch you
>> talked about is not provided in that branch.
>>
>> Wei.
>>
>
> Can we merge some fixes people have proposed into the Vixen branch?
> There are a number of virtualization providers that have rolled forward
> with Vixen. They are clearly contributing patches on the ML and having
> one place to work together would be nice.

If Anthony is OK, we can call him the "maintainer" for the Vixen
branch; the committers can check in anything that has his Ack to the
Vixen branch, and the Security Team can post new signed tags when
appropriate.

It looked like Anthony had some issues with the most recent patch though.

 -George

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

Re: Rudolph: merging Vixen and Comet

[Anthony Liguori]

On Tue, Jan 16, 2018 at 5:51 PM, George Dunlap <dunlapg@umich.edu> wrote:
> On Tue, Jan 16, 2018 at 4:42 PM, Doug Goldstein <cardoe@cardoe.com> wrote:
>> On 1/12/18 8:20 AM, Wei Liu wrote:
>>> On Fri, Jan 12, 2018 at 03:17:04PM +0100, Olaf Hering wrote:
>>>> On Fri, Jan 12, Wei Liu wrote:
>>>>
>>>>>                       Vixen                          Comet
>>>>> Guest console         Output only                    Bi-directional
>>>>
>>>> With the proper patch input works for Vixen. Unless this item mean
>>>> something else.
>>>
>>> Vixen means the version upstream put into the advisory. The patch you
>>> talked about is not provided in that branch.
>>>
>>> Wei.
>>>
>>
>> Can we merge some fixes people have proposed into the Vixen branch?
>> There are a number of virtualization providers that have rolled forward
>> with Vixen. They are clearly contributing patches on the ML and having
>> one place to work together would be nice.
>
> If Anthony is OK, we can call him the "maintainer" for the Vixen
> branch; the committers can check in anything that has his Ack to the
> Vixen branch, and the Security Team can post new signed tags when
> appropriate.
>
> It looked like Anthony had some issues with the most recent patch though.

I am very happy to review stuff for the Vixen branch but I'm even more
eager to get Vixen and Comet merged.  Getting Comet into staging will
help out us a lot.

Regards,

Anthony Liguori

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

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

Re: Rudolph: merging Vixen and Comet

[Wei Liu]

On Tue, Jan 16, 2018 at 07:23:43PM +0100, Anthony Liguori wrote:
> On Tue, Jan 16, 2018 at 5:51 PM, George Dunlap <dunlapg@umich.edu> wrote:
> > On Tue, Jan 16, 2018 at 4:42 PM, Doug Goldstein <cardoe@cardoe.com> wrote:
> >> On 1/12/18 8:20 AM, Wei Liu wrote:
> >>> On Fri, Jan 12, 2018 at 03:17:04PM +0100, Olaf Hering wrote:
> >>>> On Fri, Jan 12, Wei Liu wrote:
> >>>>
> >>>>>                       Vixen                          Comet
> >>>>> Guest console         Output only                    Bi-directional
> >>>>
> >>>> With the proper patch input works for Vixen. Unless this item mean
> >>>> something else.
> >>>
> >>> Vixen means the version upstream put into the advisory. The patch you
> >>> talked about is not provided in that branch.
> >>>
> >>> Wei.
> >>>
> >>
> >> Can we merge some fixes people have proposed into the Vixen branch?
> >> There are a number of virtualization providers that have rolled forward
> >> with Vixen. They are clearly contributing patches on the ML and having
> >> one place to work together would be nice.
> >
> > If Anthony is OK, we can call him the "maintainer" for the Vixen
> > branch; the committers can check in anything that has his Ack to the
> > Vixen branch, and the Security Team can post new signed tags when
> > appropriate.
> >
> > It looked like Anthony had some issues with the most recent patch though.
> 
> I am very happy to review stuff for the Vixen branch but I'm even more
> eager to get Vixen and Comet merged.  Getting Comet into staging will
> help out us a lot.
> 

I just pushed a bunch of comet patches to staging. I will push some of
the pending fixes tomorrow.

Wei.

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

Re: Rudolph: merging Vixen and Comet

[Wei Liu]

On Tue, Jan 16, 2018 at 10:42:17AM -0600, Doug Goldstein wrote:
> On 1/12/18 8:20 AM, Wei Liu wrote:
> > On Fri, Jan 12, 2018 at 03:17:04PM +0100, Olaf Hering wrote:
> >> On Fri, Jan 12, Wei Liu wrote:
> >>
> >>>                       Vixen                          Comet
> >>> Guest console         Output only                    Bi-directional
> >>
> >> With the proper patch input works for Vixen. Unless this item mean
> >> something else.
> > 
> > Vixen means the version upstream put into the advisory. The patch you
> > talked about is not provided in that branch.
> > 
> > Wei.
> > 
> 
> Can we merge some fixes people have proposed into the Vixen branch?
> There are a number of virtualization providers that have rolled forward
> with Vixen. They are clearly contributing patches on the ML and having
> one place to work together would be nice.
> 

There will be update to that branch.

> We can always host a fork on GitHub and merge patches there as well if
> that's preferred.
> 

No please don't. :-)

Wei.

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

Re: Rudolph: merging Vixen and Comet

[Roger Pau Monné]

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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Rudolph: merging Vixen and Comet

[Wei Liu]

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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Rudolph: merging Vixen and Comet

[Wei Liu]

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
> 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
> Xen version           L0 version                     L1 version
> CPUID faulting        None                           Changes for Intel and AMD
> Grant table           What is forwarded is more or less the same but differs in implementation
> Event channel setup   3 mechanisms                   1 mechanism
> Event channel         ECS_PROXY state                Use ECS_RESERVED
>                       Differences in what gets forwarded
> Migration             No                             Yes
> CPU hotplug           No                             Yes
> Memory hotplug        No                             Yes
> 
> These are the things I can think of when comparing the two series side
> by side.  Feel free to provide addition and / or correction.  The list
> serves as a guidance on what areas need attention.

We've come to agree on the following goals among stakeholders:

1. We will use Comet as base to develop Rudolph.
2. We will start to commit patches into staging and develop there.
3. We will maintain Vixen and Comet until Rudolph is ready. We will
   be cherry-picking bug fixes to Vixen and Comet as we develop Rudolph.

In order to make goal #3 easier, I suggest we commit Comet almost as-is
to minimise the difference between staging and backported Comet
branches.

I will post a version of Comet suitable for committing to staging as
soon as possible.  We will start porting over functionalities from Vixen
once Comet is committed.

In the meantime I will also collect patches for Vixen and Comet and
forward port them when necessary.

Wei.

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

Re: Rudolph: merging Vixen and Comet

[Roger Pau Monné]

On Tue, Jan 16, 2018 at 12:46:10PM +0000, Wei Liu 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
> > 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
> > Xen version           L0 version                     L1 version
> > CPUID faulting        None                           Changes for Intel and AMD
> > Grant table           What is forwarded is more or less the same but differs in implementation
> > Event channel setup   3 mechanisms                   1 mechanism
> > Event channel         ECS_PROXY state                Use ECS_RESERVED
> >                       Differences in what gets forwarded
> > Migration             No                             Yes
> > CPU hotplug           No                             Yes
> > Memory hotplug        No                             Yes
> > 
> > These are the things I can think of when comparing the two series side
> > by side.  Feel free to provide addition and / or correction.  The list
> > serves as a guidance on what areas need attention.
> 
> We've come to agree on the following goals among stakeholders:
> 
> 1. We will use Comet as base to develop Rudolph.
> 2. We will start to commit patches into staging and develop there.
> 3. We will maintain Vixen and Comet until Rudolph is ready. We will
>    be cherry-picking bug fixes to Vixen and Comet as we develop Rudolph.
> 
> In order to make goal #3 easier, I suggest we commit Comet almost as-is
> to minimise the difference between staging and backported Comet
> branches.
> 
> I will post a version of Comet suitable for committing to staging as
> soon as possible.

Iff maintainers agree that a version of Comet will be committed to
staging now I think it should be 4.10.0-shim-comet rebased into
staging, so that further patches (including bugfixes) can be easily
backported to the 4.10.0-shim-comet branch.

Or else the whole point of committing something to staging is not so
important IMHO.

Roger.

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

Re: Rudolph: merging Vixen and Comet

[Wei Liu]

On Tue, Jan 16, 2018 at 01:03:06PM +0000, Roger Pau Monné wrote:
> On Tue, Jan 16, 2018 at 12:46:10PM +0000, Wei Liu 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
> > > 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
> > > Xen version           L0 version                     L1 version
> > > CPUID faulting        None                           Changes for Intel and AMD
> > > Grant table           What is forwarded is more or less the same but differs in implementation
> > > Event channel setup   3 mechanisms                   1 mechanism
> > > Event channel         ECS_PROXY state                Use ECS_RESERVED
> > >                       Differences in what gets forwarded
> > > Migration             No                             Yes
> > > CPU hotplug           No                             Yes
> > > Memory hotplug        No                             Yes
> > > 
> > > These are the things I can think of when comparing the two series side
> > > by side.  Feel free to provide addition and / or correction.  The list
> > > serves as a guidance on what areas need attention.
> > 
> > We've come to agree on the following goals among stakeholders:
> > 
> > 1. We will use Comet as base to develop Rudolph.
> > 2. We will start to commit patches into staging and develop there.
> > 3. We will maintain Vixen and Comet until Rudolph is ready. We will
> >    be cherry-picking bug fixes to Vixen and Comet as we develop Rudolph.
> > 
> > In order to make goal #3 easier, I suggest we commit Comet almost as-is
> > to minimise the difference between staging and backported Comet
> > branches.
> > 
> > I will post a version of Comet suitable for committing to staging as
> > soon as possible.
> 
> Iff maintainers agree that a version of Comet will be committed to
> staging now I think it should be 4.10.0-shim-comet rebased into
> staging, so that further patches (including bugfixes) can be easily
> backported to the 4.10.0-shim-comet branch.
> 

There isn't any substantial difference between comet-4.10 and the
version I'm going to post other than I clean up the commit message a bit
and collect tags if applicable. I can also pick comet-4.10 if people
prefer that.  I don't really care.

Wei.

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

Re: Rudolph: merging Vixen and Comet

[Wei Liu]

On Tue, Jan 16, 2018 at 12:46:10PM +0000, Wei Liu 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
> > 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
> > Xen version           L0 version                     L1 version
> > CPUID faulting        None                           Changes for Intel and AMD
> > Grant table           What is forwarded is more or less the same but differs in implementation
> > Event channel setup   3 mechanisms                   1 mechanism
> > Event channel         ECS_PROXY state                Use ECS_RESERVED
> >                       Differences in what gets forwarded
> > Migration             No                             Yes
> > CPU hotplug           No                             Yes
> > Memory hotplug        No                             Yes
> > 
> > These are the things I can think of when comparing the two series side
> > by side.  Feel free to provide addition and / or correction.  The list
> > serves as a guidance on what areas need attention.
> 
> We've come to agree on the following goals among stakeholders:
> 
> 1. We will use Comet as base to develop Rudolph.
> 2. We will start to commit patches into staging and develop there.
> 3. We will maintain Vixen and Comet until Rudolph is ready. We will
>    be cherry-picking bug fixes to Vixen and Comet as we develop Rudolph.
> 
> In order to make goal #3 easier, I suggest we commit Comet almost as-is
> to minimise the difference between staging and backported Comet
> branches.
> 
> I will post a version of Comet suitable for committing to staging as
> soon as possible.  We will start porting over functionalities from Vixen
> once Comet is committed.

I've pushed comet-for-unstable to my xenbits/xen.git. That branch is a
forward port of 4.10.0-shim-comet branch to staging.

https://xenbits.xen.org/gitweb/?p=people/liuw/xen.git;a=shortlog;h=refs/heads/comet-for-unstable

There will be follow-up patches to fix some bugs, which have not been
pushed to that branch yet:

1. Michael Young's -xen-attach patch
2. Roger's patch to move mapping vcpu_info earlier

(Due to things go in parallel, they are probably not yet on list)

Jan and Andrew, please check the branch and explicitly ack the action of
committing that branch.

Wei.

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

Re: Rudolph: merging Vixen and Comet

[Jan Beulich]

>>> On 16.01.18 at 17:52, <wei.liu2@citrix.com> wrote:
> I've pushed comet-for-unstable to my xenbits/xen.git. That branch is a
> forward port of 4.10.0-shim-comet branch to staging.
> 
> https://xenbits.xen.org/gitweb/?p=people/liuw/xen.git;a=shortlog;h=refs/head 
> s/comet-for-unstable
> 
> There will be follow-up patches to fix some bugs, which have not been
> pushed to that branch yet:
> 
> 1. Michael Young's -xen-attach patch
> 2. Roger's patch to move mapping vcpu_info earlier
> 
> (Due to things go in parallel, they are probably not yet on list)
> 
> Jan and Andrew, please check the branch and explicitly ack the action of
> committing that branch.

Looks plausible, but of course I don't have the time to go through
the individual commit. "No objection" is the best you're going to get,
and here you go: No objection.

Jan


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

Re: Rudolph: merging Vixen and Comet

[Andrew Cooper]

On 16/01/18 17:11, Jan Beulich wrote:
>>>> On 16.01.18 at 17:52, <wei.liu2@citrix.com> wrote:
>> I've pushed comet-for-unstable to my xenbits/xen.git. That branch is a
>> forward port of 4.10.0-shim-comet branch to staging.
>>
>> https://xenbits.xen.org/gitweb/?p=people/liuw/xen.git;a=shortlog;h=refs/head 
>> s/comet-for-unstable
>>
>> There will be follow-up patches to fix some bugs, which have not been
>> pushed to that branch yet:
>>
>> 1. Michael Young's -xen-attach patch
>> 2. Roger's patch to move mapping vcpu_info earlier
>>
>> (Due to things go in parallel, they are probably not yet on list)
>>
>> Jan and Andrew, please check the branch and explicitly ack the action of
>> committing that branch.
> Looks plausible, but of course I don't have the time to go through
> the individual commit. "No objection" is the best you're going to get,
> and here you go: No objection.

Throw it in.  It is easier to iterate on fixes with some stuff committed
to being with.

I too won't have any time to look at the series until I've refreshed my
SP2 work.

~Andrew

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

Re: Rudolph: merging Vixen and Comet

[Wei Liu]

On Tue, Jan 16, 2018 at 05:55:38PM +0000, Andrew Cooper wrote:
> On 16/01/18 17:11, Jan Beulich wrote:
> >>>> On 16.01.18 at 17:52, <wei.liu2@citrix.com> wrote:
> >> I've pushed comet-for-unstable to my xenbits/xen.git. That branch is a
> >> forward port of 4.10.0-shim-comet branch to staging.
> >>
> >> https://xenbits.xen.org/gitweb/?p=people/liuw/xen.git;a=shortlog;h=refs/head 
> >> s/comet-for-unstable
> >>
> >> There will be follow-up patches to fix some bugs, which have not been
> >> pushed to that branch yet:
> >>
> >> 1. Michael Young's -xen-attach patch
> >> 2. Roger's patch to move mapping vcpu_info earlier
> >>
> >> (Due to things go in parallel, they are probably not yet on list)
> >>
> >> Jan and Andrew, please check the branch and explicitly ack the action of
> >> committing that branch.
> > Looks plausible, but of course I don't have the time to go through
> > the individual commit. "No objection" is the best you're going to get,
> > and here you go: No objection.
> 
> Throw it in.  It is easier to iterate on fixes with some stuff committed
> to being with.
> 

Thanks. I rebased my branch and fixed two trivial conflicts. Built and
ran some smoke test and pushed the code to staging.

Wei.

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