Re: [Xen-devel] 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  wrote:
> > On Tue, Jan 16, 2018 at 4:42 PM, 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 onlyBi-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: [Xen-devel] Rudolph: merging Vixen and Comet

[Wei Liu]

On Tue, Jan 16, 2018 at 05:55:38PM +, Andrew Cooper wrote:
> On 16/01/18 17:11, Jan Beulich wrote:
>  On 16.01.18 at 17:52,  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

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

[Anthony Liguori]

On Tue, Jan 16, 2018 at 5:51 PM, George Dunlap  wrote:
> On Tue, Jan 16, 2018 at 4:42 PM, 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 onlyBi-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: [Xen-devel] 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 onlyBi-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: [Xen-devel] Rudolph: merging Vixen and Comet

[Wei Liu]

On Tue, Jan 16, 2018 at 12:46:10PM +, Wei Liu wrote:
> On Fri, Jan 12, 2018 at 01:24:09PM +, 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 HVMPVH + HVM
> > Kconfig options   XEN_GUEST  XEN_GUEST + PVH_GUEST 
> > + SHIM_EXCLUSIVE
> > Xen build system  No change  New build target for 
> > shim 
> > Guest console Output onlyBi-directional
> > Guest domid   1 or set via shim option   1 or retrieved via 
> > cpuid
> > Guest typeHardware domainNormal domain
> > Time source   Emulated   Xen PV clock
> > Shutdown  PV + HWPV
> > SI mappingReserved page  Fixed map, PFN chosen 
> > at runtime
> > VCPU id   Handled by L1  Provide by L0 if 
> > available
> > VCPU runstate Forwarded to L0Handled by L1
> > Xen version   L0 version L1 version
> > CPUID faultingNone   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 stateUse ECS_RESERVED
> >   Differences in what gets forwarded
> > Migration No Yes
> > CPU hotplug   No Yes
> > Memory hotplugNo 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: [Xen-devel] Rudolph: merging Vixen and Comet

[George Dunlap]

On Tue, Jan 16, 2018 at 4:42 PM, 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 onlyBi-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: [Xen-devel] Rudolph: merging Vixen and Comet

[Doug Goldstein]

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



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[Wei Liu]

On Tue, Jan 16, 2018 at 01:03:06PM +, Roger Pau Monné wrote:
> On Tue, Jan 16, 2018 at 12:46:10PM +, Wei Liu wrote:
> > On Fri, Jan 12, 2018 at 01:24:09PM +, 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 HVMPVH + HVM
> > > Kconfig options   XEN_GUEST  XEN_GUEST + 
> > > PVH_GUEST + SHIM_EXCLUSIVE
> > > Xen build system  No change  New build target for 
> > > shim 
> > > Guest console Output onlyBi-directional
> > > Guest domid   1 or set via shim option   1 or retrieved via 
> > > cpuid
> > > Guest typeHardware domainNormal domain
> > > Time source   Emulated   Xen PV clock
> > > Shutdown  PV + HWPV
> > > SI mappingReserved page  Fixed map, PFN 
> > > chosen at runtime
> > > VCPU id   Handled by L1  Provide by L0 if 
> > > available
> > > VCPU runstate Forwarded to L0Handled by L1
> > > Xen version   L0 version L1 version
> > > CPUID faultingNone   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 stateUse ECS_RESERVED
> > >   Differences in what gets forwarded
> > > Migration No Yes
> > > CPU hotplug   No Yes
> > > Memory hotplugNo 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: [Xen-devel] Rudolph: merging Vixen and Comet

[Roger Pau Monné]

On Tue, Jan 16, 2018 at 12:46:10PM +, Wei Liu wrote:
> On Fri, Jan 12, 2018 at 01:24:09PM +, 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 HVMPVH + HVM
> > Kconfig options   XEN_GUEST  XEN_GUEST + PVH_GUEST 
> > + SHIM_EXCLUSIVE
> > Xen build system  No change  New build target for 
> > shim 
> > Guest console Output onlyBi-directional
> > Guest domid   1 or set via shim option   1 or retrieved via 
> > cpuid
> > Guest typeHardware domainNormal domain
> > Time source   Emulated   Xen PV clock
> > Shutdown  PV + HWPV
> > SI mappingReserved page  Fixed map, PFN chosen 
> > at runtime
> > VCPU id   Handled by L1  Provide by L0 if 
> > available
> > VCPU runstate Forwarded to L0Handled by L1
> > Xen version   L0 version L1 version
> > CPUID faultingNone   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 stateUse ECS_RESERVED
> >   Differences in what gets forwarded
> > Migration No Yes
> > CPU hotplug   No Yes
> > Memory hotplugNo 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: [Xen-devel] Rudolph: merging Vixen and Comet

[Wei Liu]

On Fri, Jan 12, 2018 at 01:24:09PM +, 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 HVMPVH + HVM
> Kconfig options   XEN_GUEST  XEN_GUEST + PVH_GUEST + 
> SHIM_EXCLUSIVE
> Xen build system  No change  New build target for 
> shim 
> Guest console Output onlyBi-directional
> Guest domid   1 or set via shim option   1 or retrieved via cpuid
> Guest typeHardware domainNormal domain
> Time source   Emulated   Xen PV clock
> Shutdown  PV + HWPV
> SI mappingReserved page  Fixed map, PFN chosen at 
> runtime
> VCPU id   Handled by L1  Provide by L0 if 
> available
> VCPU runstate Forwarded to L0Handled by L1
> Xen version   L0 version L1 version
> CPUID faultingNone   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 stateUse ECS_RESERVED
>   Differences in what gets forwarded
> Migration No Yes
> CPU hotplug   No Yes
> Memory hotplugNo 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: [Xen-devel] Rudolph: merging Vixen and Comet

[Wei Liu]

On Fri, Jan 12, 2018 at 02:18:33PM +, Roger Pau Monné wrote:
> On Fri, Jan 12, 2018 at 01:24:09PM +, 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 HVMPVH + HVM
> > Kconfig options   XEN_GUEST  XEN_GUEST + PVH_GUEST 
> > + SHIM_EXCLUSIVE
> > Xen build system  No change  New build target for 
> > shim 
> > Guest console Output onlyBi-directional
> > Guest domid   1 or set via shim option   1 or retrieved via 
> > cpuid
> > Guest typeHardware domainNormal 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 + HWPV
> > SI mappingReserved 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 idsmp_processor_idFrom L0 or 
smp_processor_id

> 
> > VCPU runstate Forwarded to L0Handled 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 faultingNone   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: [Xen-devel] 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 onlyBi-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: [Xen-devel] 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,  wrote:
> > Here I list the differences between the two implementations.
> 
> Thanks for the summary.
> 
> >   Vixen  Comet
> > Boot mode HVMPVH + HVM
> > Kconfig options   XEN_GUEST  XEN_GUEST + PVH_GUEST 
> > + SHIM_EXCLUSIVE
> > Xen build system  No change  New build target for 
> > shim 
> > Guest console Output onlyBi-directional
> > Guest domid   1 or set via shim option   1 or retrieved via 
> > cpuid
> > Guest typeHardware domainNormal domain
> > Time source   Emulated   Xen PV clock
> > Shutdown  PV + HWPV
> > SI mappingReserved page  Fixed map, PFN chosen 
> > at runtime
> > VCPU id   Handled by L1  Provide by L0 if 
> > available
> > VCPU runstate Forwarded to L0Handled 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: [Xen-devel] Rudolph: merging Vixen and Comet

[Jan Beulich]

>>> On 12.01.18 at 14:24,  wrote:
> Here I list the differences between the two implementations.

Thanks for the summary.

>   Vixen  Comet
> Boot mode HVMPVH + HVM
> Kconfig options   XEN_GUEST  XEN_GUEST + PVH_GUEST + 
> SHIM_EXCLUSIVE
> Xen build system  No change  New build target for 
> shim 
> Guest console Output onlyBi-directional
> Guest domid   1 or set via shim option   1 or retrieved via cpuid
> Guest typeHardware domainNormal domain
> Time source   Emulated   Xen PV clock
> Shutdown  PV + HWPV
> SI mappingReserved page  Fixed map, PFN chosen at 
> runtime
> VCPU id   Handled by L1  Provide by L0 if 
> available
> VCPU runstate Forwarded to L0Handled 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

[Xen-devel] 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 HVMPVH + HVM
Kconfig options   XEN_GUEST  XEN_GUEST + PVH_GUEST + 
SHIM_EXCLUSIVE
Xen build system  No change  New build target for shim 
Guest console Output onlyBi-directional
Guest domid   1 or set via shim option   1 or retrieved via cpuid
Guest typeHardware domainNormal domain
Time source   Emulated   Xen PV clock
Shutdown  PV + HWPV
SI mappingReserved page  Fixed map, PFN chosen at 
runtime
VCPU id   Handled by L1  Provide by L0 if available
VCPU runstate Forwarded to L0Handled by L1
Xen version   L0 version L1 version
CPUID faultingNone   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 stateUse ECS_RESERVED
  Differences in what gets forwarded
Migration No Yes
CPU hotplug   No Yes
Memory hotplugNo 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