Radical proposal: ship not-fully-tidied shim as 4.10.1

Radical proposal: ship not-fully-tidied shim as 4.10.1

[Ian Jackson]

AIUI we have a series for pv-in-pvh shim which is nearing completion
in the sense that it will have been well-tested (especially the
hypervisor parts) and has good functionality.  (Wei is handling the
assembly of this series.)

The series, however, needs proper review and tidying up.
Specifically, it needs the kind of tidying up that fixes code
structure and style issues that will hinder future Xen development.
I.e. the kind of technical debt which does not directly cause bugs now
but will cause trouble (including bugs) in the future.

IMO that kind of tidying up is definitely essential for
xen.git#master.  However, it is much less of an issue for Xen 4.10.
Xen 4.10, as a stable branch, will get much more limited further
development.  Failure to tidy things up there will make backporting
other changes more awkward but the overall impact is both lower and
time-bound.

Currently the Xen Project has no published resolution for PV guests
that can't be booted as, or converted to, PVH or HVM.  (And HVM guests
bring their own problems.)  We need to provide our users with more
good options as quickly as possible.

I would like to suggest that a good way of doing this would be to ship
the shim series as 4.10.1 within the next very few days.  It needs
some minor bugfixing (build breakage etc.) but is basically ready for
use.

Speaking as a sysadmin (even, a very conservative sysadmin many of
whose systems are running Debian oldstable), I have already taken a
decision to rapidly advance to new software, in one context, because
of these vulnerabilities - and take and fix whatever impact that has.
I think many of our users would like to make the same choice.

Releaseing 4.10.1 this week with pv-in-pvh support would give many of
our users with PV guests an immediately deployable update, even though
of course the version bump to get to 4.10 may be disruptive.

Doing this would be a departure from our uusual non-security-bug
process of committing changes to xen.git#staging, and then backporting
only after the patches have been sitting in xen.git#master for some
time.  It's also a departure from our usual security-bug process of
developing and testing and committing patches for all supported
versions in parallel.

But this is not a usual situation.  This time, we don't have the time
to wait.

Opinions ?

Ian.

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Anthony Liguori]

On Mon, Jan 8, 2018 at 9:45 AM, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
> AIUI we have a series for pv-in-pvh shim which is nearing completion
> in the sense that it will have been well-tested (especially the
> hypervisor parts) and has good functionality.  (Wei is handling the
> assembly of this series.)
>
> The series, however, needs proper review and tidying up.
> Specifically, it needs the kind of tidying up that fixes code
> structure and style issues that will hinder future Xen development.
> I.e. the kind of technical debt which does not directly cause bugs now
> but will cause trouble (including bugs) in the future.
>
> IMO that kind of tidying up is definitely essential for
> xen.git#master.  However, it is much less of an issue for Xen 4.10.
> Xen 4.10, as a stable branch, will get much more limited further
> development.  Failure to tidy things up there will make backporting
> other changes more awkward but the overall impact is both lower and
> time-bound.
>
> Currently the Xen Project has no published resolution for PV guests
> that can't be booted as, or converted to, PVH or HVM.  (And HVM guests
> bring their own problems.)  We need to provide our users with more
> good options as quickly as possible.
>
> I would like to suggest that a good way of doing this would be to ship
> the shim series as 4.10.1 within the next very few days.  It needs
> some minor bugfixing (build breakage etc.) but is basically ready for
> use.
>
> Speaking as a sysadmin (even, a very conservative sysadmin many of
> whose systems are running Debian oldstable), I have already taken a
> decision to rapidly advance to new software, in one context, because
> of these vulnerabilities - and take and fix whatever impact that has.
> I think many of our users would like to make the same choice.
>
> Releaseing 4.10.1 this week with pv-in-pvh support would give many of
> our users with PV guests an immediately deployable update, even though
> of course the version bump to get to 4.10 may be disruptive.
>
> Doing this would be a departure from our uusual non-security-bug
> process of committing changes to xen.git#staging, and then backporting
> only after the patches have been sitting in xen.git#master for some
> time.  It's also a departure from our usual security-bug process of
> developing and testing and committing patches for all supported
> versions in parallel.
>
> But this is not a usual situation.  This time, we don't have the time
> to wait.
>
> Opinions ?

Whatever solution is chosen, I agree getting a solution merged and a new
release cut is critical.  Getting variant 2 addressed is also
important but variant
3 is a much bigger practical risk IMHO.

Regards,

Anthony Liguori

> Ian.
>
> _______________________________________________
> 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: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Konrad Rzeszutek Wilk]

On Mon, Jan 08, 2018 at 05:45:32PM +0000, Ian Jackson wrote:
> AIUI we have a series for pv-in-pvh shim which is nearing completion
> in the sense that it will have been well-tested (especially the
> hypervisor parts) and has good functionality.  (Wei is handling the
> assembly of this series.)
> 
> The series, however, needs proper review and tidying up.
> Specifically, it needs the kind of tidying up that fixes code
> structure and style issues that will hinder future Xen development.
> I.e. the kind of technical debt which does not directly cause bugs now
> but will cause trouble (including bugs) in the future.
> 
> IMO that kind of tidying up is definitely essential for
> xen.git#master.  However, it is much less of an issue for Xen 4.10.
> Xen 4.10, as a stable branch, will get much more limited further
> development.  Failure to tidy things up there will make backporting
> other changes more awkward but the overall impact is both lower and
> time-bound.
> 
> Currently the Xen Project has no published resolution for PV guests
> that can't be booted as, or converted to, PVH or HVM.  (And HVM guests
> bring their own problems.)  We need to provide our users with more
> good options as quickly as possible.
> 
> I would like to suggest that a good way of doing this would be to ship
> the shim series as 4.10.1 within the next very few days.  It needs
> some minor bugfixing (build breakage etc.) but is basically ready for
> use.
> 
> Speaking as a sysadmin (even, a very conservative sysadmin many of
> whose systems are running Debian oldstable), I have already taken a
> decision to rapidly advance to new software, in one context, because
> of these vulnerabilities - and take and fix whatever impact that has.
> I think many of our users would like to make the same choice.
> 
> Releaseing 4.10.1 this week with pv-in-pvh support would give many of
> our users with PV guests an immediately deployable update, even though
> of course the version bump to get to 4.10 may be disruptive.
> 
> Doing this would be a departure from our uusual non-security-bug
> process of committing changes to xen.git#staging, and then backporting
> only after the patches have been sitting in xen.git#master for some
> time.  It's also a departure from our usual security-bug process of
> developing and testing and committing patches for all supported
> versions in parallel.
> 
> But this is not a usual situation.  This time, we don't have the time
> to wait.
> 
> Opinions ?

<sighs>

+1

But I am not exactly sure how one would actually boot this hybrid thing.

As in I didn't see any libxl patches, or hvmloader or any of that
that would 'slurp' this up and make the 'xl create' work out of the box
so that PV guests are booted as HVM.

Or does the admin have to do some of the 'migration' themselves?


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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Anthony Liguori]

On Mon, Jan 8, 2018 at 10:13 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Mon, Jan 08, 2018 at 05:45:32PM +0000, Ian Jackson wrote:
>> AIUI we have a series for pv-in-pvh shim which is nearing completion
>> in the sense that it will have been well-tested (especially the
>> hypervisor parts) and has good functionality.  (Wei is handling the
>> assembly of this series.)
>>
>> The series, however, needs proper review and tidying up.
>> Specifically, it needs the kind of tidying up that fixes code
>> structure and style issues that will hinder future Xen development.
>> I.e. the kind of technical debt which does not directly cause bugs now
>> but will cause trouble (including bugs) in the future.
>>
>> IMO that kind of tidying up is definitely essential for
>> xen.git#master.  However, it is much less of an issue for Xen 4.10.
>> Xen 4.10, as a stable branch, will get much more limited further
>> development.  Failure to tidy things up there will make backporting
>> other changes more awkward but the overall impact is both lower and
>> time-bound.
>>
>> Currently the Xen Project has no published resolution for PV guests
>> that can't be booted as, or converted to, PVH or HVM.  (And HVM guests
>> bring their own problems.)  We need to provide our users with more
>> good options as quickly as possible.
>>
>> I would like to suggest that a good way of doing this would be to ship
>> the shim series as 4.10.1 within the next very few days.  It needs
>> some minor bugfixing (build breakage etc.) but is basically ready for
>> use.
>>
>> Speaking as a sysadmin (even, a very conservative sysadmin many of
>> whose systems are running Debian oldstable), I have already taken a
>> decision to rapidly advance to new software, in one context, because
>> of these vulnerabilities - and take and fix whatever impact that has.
>> I think many of our users would like to make the same choice.
>>
>> Releaseing 4.10.1 this week with pv-in-pvh support would give many of
>> our users with PV guests an immediately deployable update, even though
>> of course the version bump to get to 4.10 may be disruptive.
>>
>> Doing this would be a departure from our uusual non-security-bug
>> process of committing changes to xen.git#staging, and then backporting
>> only after the patches have been sitting in xen.git#master for some
>> time.  It's also a departure from our usual security-bug process of
>> developing and testing and committing patches for all supported
>> versions in parallel.
>>
>> But this is not a usual situation.  This time, we don't have the time
>> to wait.
>>
>> Opinions ?
>
> <sighs>
>
> +1
>
> But I am not exactly sure how one would actually boot this hybrid thing.
>
> As in I didn't see any libxl patches, or hvmloader or any of that
> that would 'slurp' this up and make the 'xl create' work out of the box
> so that PV guests are booted as HVM.
>
> Or does the admin have to do some of the 'migration' themselves?

For the HVM approach, yes, self migration is needed.  I think it would be pretty
easy to write a script that worked with most configuration files to do the
conversion.

Regards,

Anthony Liguori


>
> _______________________________________________
> 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: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Lars Kurth]

> On 8 Jan 2018, at 17:45, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
> 
> 
> But this is not a usual situation.  This time, we don't have the time
> to wait.
> 
> Opinions ?
> 
> Ian.

+1

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Rich Persaud]

> On Jan 8, 2018, at 12:45, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
> 
> AIUI we have a series for pv-in-pvh shim which is nearing completion
> in the sense that it will have been well-tested (especially the
> hypervisor parts) and has good functionality.  (Wei is handling the
> assembly of this series.)
> 
> The series, however, needs proper review and tidying up.
> Specifically, it needs the kind of tidying up that fixes code
> structure and style issues that will hinder future Xen development.
> I.e. the kind of technical debt which does not directly cause bugs now
> but will cause trouble (including bugs) in the future.
> 
> IMO that kind of tidying up is definitely essential for
> xen.git#master.  However, it is much less of an issue for Xen 4.10.
> Xen 4.10, as a stable branch, will get much more limited further
> development.  Failure to tidy things up there will make backporting
> other changes more awkward but the overall impact is both lower and
> time-bound.
> 
> Currently the Xen Project has no published resolution for PV guests
> that can't be booted as, or converted to, PVH or HVM.  (And HVM guests
> bring their own problems.)  We need to provide our users with more
> good options as quickly as possible.
> 
> I would like to suggest that a good way of doing this would be to ship
> the shim series as 4.10.1 within the next very few days.  It needs
> some minor bugfixing (build breakage etc.) but is basically ready for
> use.
> 
> Speaking as a sysadmin (even, a very conservative sysadmin many of
> whose systems are running Debian oldstable), I have already taken a
> decision to rapidly advance to new software, in one context, because
> of these vulnerabilities - and take and fix whatever impact that has.
> I think many of our users would like to make the same choice.
> 
> Releaseing 4.10.1 this week with pv-in-pvh support would give many of
> our users with PV guests an immediately deployable update, even though
> of course the version bump to get to 4.10 may be disruptive.
> 
> Doing this would be a departure from our uusual non-security-bug
> process of committing changes to xen.git#staging, and then backporting
> only after the patches have been sitting in xen.git#master for some
> time.  It's also a departure from our usual security-bug process of
> developing and testing and committing patches for all supported
> versions in parallel.
> 
> But this is not a usual situation.  This time, we don't have the time
> to wait.
> 
> Opinions ?
> 
> Ian.

On a similarly pragmatic note: would a variation of Anthony's vixen patch series be suitable for pre-PVH Xen 4.6 - 4.9?  These versions are currently documented as security-supported (Oct 2018 - July 2020).

There are production environments where upgrading to Xen 4.10 in a timeframe of days or weeks is not practical.

Will PCI passthrough for PV guests be supported in any of the solutions that are being considered?  If not, it would be helpful to document this in the Spectre/Meltdown XSA and/or FAQ, including timeline or complexity estimates for the return of security support for Xen PV driver domains.  SUPPORT.md will also need an update.

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Anthony Liguori]

On Mon, Jan 8, 2018 at 1:01 PM, Rich Persaud <persaur@gmail.com> wrote:
>> On Jan 8, 2018, at 12:45, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
>>
>> AIUI we have a series for pv-in-pvh shim which is nearing completion
>> in the sense that it will have been well-tested (especially the
>> hypervisor parts) and has good functionality.  (Wei is handling the
>> assembly of this series.)
>>
>> The series, however, needs proper review and tidying up.
>> Specifically, it needs the kind of tidying up that fixes code
>> structure and style issues that will hinder future Xen development.
>> I.e. the kind of technical debt which does not directly cause bugs now
>> but will cause trouble (including bugs) in the future.
>>
>> IMO that kind of tidying up is definitely essential for
>> xen.git#master.  However, it is much less of an issue for Xen 4.10.
>> Xen 4.10, as a stable branch, will get much more limited further
>> development.  Failure to tidy things up there will make backporting
>> other changes more awkward but the overall impact is both lower and
>> time-bound.
>>
>> Currently the Xen Project has no published resolution for PV guests
>> that can't be booted as, or converted to, PVH or HVM.  (And HVM guests
>> bring their own problems.)  We need to provide our users with more
>> good options as quickly as possible.
>>
>> I would like to suggest that a good way of doing this would be to ship
>> the shim series as 4.10.1 within the next very few days.  It needs
>> some minor bugfixing (build breakage etc.) but is basically ready for
>> use.
>>
>> Speaking as a sysadmin (even, a very conservative sysadmin many of
>> whose systems are running Debian oldstable), I have already taken a
>> decision to rapidly advance to new software, in one context, because
>> of these vulnerabilities - and take and fix whatever impact that has.
>> I think many of our users would like to make the same choice.
>>
>> Releaseing 4.10.1 this week with pv-in-pvh support would give many of
>> our users with PV guests an immediately deployable update, even though
>> of course the version bump to get to 4.10 may be disruptive.
>>
>> Doing this would be a departure from our uusual non-security-bug
>> process of committing changes to xen.git#staging, and then backporting
>> only after the patches have been sitting in xen.git#master for some
>> time.  It's also a departure from our usual security-bug process of
>> developing and testing and committing patches for all supported
>> versions in parallel.
>>
>> But this is not a usual situation.  This time, we don't have the time
>> to wait.
>>
>> Opinions ?
>>
>> Ian.
>
> On a similarly pragmatic note: would a variation of Anthony's vixen patch series be suitable for pre-PVH Xen 4.6 - 4.9?  These versions are currently documented as security-supported (Oct 2018 - July 2020).
>
> There are production environments where upgrading to Xen 4.10 in a timeframe of days or weeks is not practical.
>
> Will PCI passthrough for PV guests be supported in any of the solutions that are being considered?  If not, it would be helpful to document this in the Spectre/Meltdown XSA and/or FAQ, including timeline or complexity estimates for the return of security support for Xen PV driver domains.  SUPPORT.md will also need an update.

It's not particularly hard to plumb through I think but if you are
using PCI passthrough for PV, then you really shouldn't worry about
Spectre/Meltdown.  That PV guest can already read all of physical
memory (since no IOMMU is used) and they can also write to all
physical memory which is far worse than what you can do with
Spectre/Meltdown.

So if you're using PCI passthrough for PV, just keep using normal PV.

Regards,

Anthony Liguori

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Rich Persaud]

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

> On Jan 8, 2018, at 16:44, Anthony Liguori <anthony@codemonkey.ws> wrote:
>> On Mon, Jan 8, 2018 at 1:01 PM, Rich Persaud <persaur@gmail.com> wrote:
>> On a similarly pragmatic note: would a variation of Anthony's vixen patch series be suitable for pre-PVH Xen 4.6 - 4.9?  These versions are currently documented as security-supported (Oct 2018 - July 2020).
>> 
>> There are production environments where upgrading to Xen 4.10 in a timeframe of days or weeks is not practical.
>> 
>> Will PCI passthrough for PV guests be supported in any of the solutions that are being considered?  If not, it would be helpful to document this in the Spectre/Meltdown XSA and/or FAQ, including timeline or complexity estimates for the return of security support for Xen PV driver domains.  SUPPORT.md will also need an update.
> 
> It's not particularly hard to plumb through I think

An earlier discussion [1] suggested that it was feasible but not easy.  This feature is used for device driver (e.g. NIC or USB) domains in OpenXT and Qubes deployments.


> but if you are using PCI passthrough for PV, then you really shouldn't worry about
> Spectre/Meltdown.  That PV guest can already read all of physical
> memory (since no IOMMU is used) and they can also write to all
> physical memory which is far worse than what you can do with
> Spectre/Meltdown.

We may be using different terminology?  OpenXT and Qubes typically require IOMMU for PV driver domains.  XSM can [2] enforce a policy which requires that an IOMMU be present before a driver domain is started.   

Rich

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

[2] https://www.mail-archive.com/xen-devel@lists.xen.org/msg118728.html


[-- Attachment #1.2: Type: text/html, Size: 3023 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: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Andrew Cooper]

On 08/01/2018 17:45, Ian Jackson wrote:
> AIUI we have a series for pv-in-pvh shim which is nearing completion
> in the sense that it will have been well-tested (especially the
> hypervisor parts) and has good functionality.  (Wei is handling the
> assembly of this series.)
>
> The series, however, needs proper review and tidying up.
> Specifically, it needs the kind of tidying up that fixes code
> structure and style issues that will hinder future Xen development.
> I.e. the kind of technical debt which does not directly cause bugs now
> but will cause trouble (including bugs) in the future.
>
> IMO that kind of tidying up is definitely essential for
> xen.git#master.  However, it is much less of an issue for Xen 4.10.
> Xen 4.10, as a stable branch, will get much more limited further
> development.  Failure to tidy things up there will make backporting
> other changes more awkward but the overall impact is both lower and
> time-bound.
>
> Currently the Xen Project has no published resolution for PV guests
> that can't be booted as, or converted to, PVH or HVM.  (And HVM guests
> bring their own problems.)  We need to provide our users with more
> good options as quickly as possible.
>
> I would like to suggest that a good way of doing this would be to ship
> the shim series as 4.10.1 within the next very few days.  It needs
> some minor bugfixing (build breakage etc.) but is basically ready for
> use.
>
> Speaking as a sysadmin (even, a very conservative sysadmin many of
> whose systems are running Debian oldstable), I have already taken a
> decision to rapidly advance to new software, in one context, because
> of these vulnerabilities - and take and fix whatever impact that has.
> I think many of our users would like to make the same choice.
>
> Releaseing 4.10.1 this week with pv-in-pvh support would give many of
> our users with PV guests an immediately deployable update, even though
> of course the version bump to get to 4.10 may be disruptive.
>
> Doing this would be a departure from our uusual non-security-bug
> process of committing changes to xen.git#staging, and then backporting
> only after the patches have been sitting in xen.git#master for some
> time.  It's also a departure from our usual security-bug process of
> developing and testing and committing patches for all supported
> versions in parallel.
>
> But this is not a usual situation.  This time, we don't have the time
> to wait.
>
> Opinions ?

Given the situation, getting a mitigation in place is urgent.  That
said, we should err on the side of haste rather than panic.

As a first requirement, nothing should go into 4.10 which isn't in
staging.  (The two are very close together at the moment but) the moment
we start committing straight to 4.10, we will loose some subtle change
from staging, and it will take ages to spot.  What I mean by this is
that, if we agree to go along this route, patches should be committed to
staging then immediately cherrypicked to staging-4.10, rather than
committed to staging-4.10 directly.  This ensures that we don't
accidentally miss functionality in the mainline.

We must ensure that perfection doesn't get in the way of expediency. 
Therefore, reviews should be extra careful about which review comments
are nice-to-have, and which are mandatory.  Technical arguments are part
of the course, but should compromise on the easier solution when it
doesn't affect a correctness issue.

Some nice-to-haves (such as minor corrections to coding style) can be
easily fixed on commit.  Not-so-minor nice-to-haves which still don't
impact the technical correctness of the issue should be deferred.  The
list of not-so-minor nice-to-haves should be maintained and be blockers
for 4.11 (as the code wouldn't have normally gotten in), and for want of
anyone better, I nominate Juergen as the release manager for 4.11 to be
in charge of this list.

Does this sound fair?  Pressing times call for extraordinary measures,
but in this case, I think it is the better course of action for the
project as a whole.

~Andrew

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Jan Beulich]

>>> On 09.01.18 at 01:14, <andrew.cooper3@citrix.com> wrote:
> On 08/01/2018 17:45, Ian Jackson wrote:
>> AIUI we have a series for pv-in-pvh shim which is nearing completion
>> in the sense that it will have been well-tested (especially the
>> hypervisor parts) and has good functionality.  (Wei is handling the
>> assembly of this series.)
>>
>> The series, however, needs proper review and tidying up.
>> Specifically, it needs the kind of tidying up that fixes code
>> structure and style issues that will hinder future Xen development.
>> I.e. the kind of technical debt which does not directly cause bugs now
>> but will cause trouble (including bugs) in the future.
>>
>> IMO that kind of tidying up is definitely essential for
>> xen.git#master.  However, it is much less of an issue for Xen 4.10.
>> Xen 4.10, as a stable branch, will get much more limited further
>> development.  Failure to tidy things up there will make backporting
>> other changes more awkward but the overall impact is both lower and
>> time-bound.
>>
>> Currently the Xen Project has no published resolution for PV guests
>> that can't be booted as, or converted to, PVH or HVM.  (And HVM guests
>> bring their own problems.)  We need to provide our users with more
>> good options as quickly as possible.
>>
>> I would like to suggest that a good way of doing this would be to ship
>> the shim series as 4.10.1 within the next very few days.  It needs
>> some minor bugfixing (build breakage etc.) but is basically ready for
>> use.
>>
>> Speaking as a sysadmin (even, a very conservative sysadmin many of
>> whose systems are running Debian oldstable), I have already taken a
>> decision to rapidly advance to new software, in one context, because
>> of these vulnerabilities - and take and fix whatever impact that has.
>> I think many of our users would like to make the same choice.
>>
>> Releaseing 4.10.1 this week with pv-in-pvh support would give many of
>> our users with PV guests an immediately deployable update, even though
>> of course the version bump to get to 4.10 may be disruptive.

Such a version bump may be impossible to do for distros.
Nevertheless I agree with the underlying idea, not the least
because I expect distros with older hypervisors still wanting
to use a 4.10 based shim (backporting host hypervisor and
tool stack changes as necessary).

One thing I'd like to be considered though before rushing
things into 4.10 (and, see below, staging as a prereq) is the
goal of at least somewhat converging the two shim
implementations. Especially from the tools side I understand
that using the Citrix variant on anything older than 4.8 may
end up being close to impossible, so at least for 4.7 and older
the Amazon variant may be the only option. Hence as little
divergence between the two as possible (within reasonable
time constraints) would seem rather desirable.

>> Doing this would be a departure from our uusual non-security-bug
>> process of committing changes to xen.git#staging, and then backporting
>> only after the patches have been sitting in xen.git#master for some
>> time.  It's also a departure from our usual security-bug process of
>> developing and testing and committing patches for all supported
>> versions in parallel.
>>
>> But this is not a usual situation.  This time, we don't have the time
>> to wait.
>>
>> Opinions ?
> 
> Given the situation, getting a mitigation in place is urgent.  That
> said, we should err on the side of haste rather than panic.
> 
> As a first requirement, nothing should go into 4.10 which isn't in
> staging.  (The two are very close together at the moment but) the moment
> we start committing straight to 4.10, we will loose some subtle change
> from staging, and it will take ages to spot.  What I mean by this is
> that, if we agree to go along this route, patches should be committed to
> staging then immediately cherrypicked to staging-4.10, rather than
> committed to staging-4.10 directly.  This ensures that we don't
> accidentally miss functionality in the mainline.

I definitely agree with this aspect.

Jan

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[George Dunlap]

On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud <persaur@gmail.com> wrote:
> On a similarly pragmatic note: would a variation of Anthony's vixen patch series be suitable for pre-PVH Xen 4.6 - 4.9?  These versions are currently documented as security-supported (Oct 2018 - July 2020).

Hmm, Ian's mail seems to be focusing on the idea of checking in a
non-polished series to 4.10, rather than exctly what the content of
that series would be.

In the IRL conversation that preceeded this mail, the new short-term
target we discussed was:
1. A 4.10-based shim that could boot either under HVM or PVH
2. A script that would take an existing PV config, and spit out a) a
bootable ISO with the shim & whatever was needed, and b) a new config
that would boot the same VM, but in HVM mode with the shim

The script + a 4.10 shim binary *should* allow most PV guests to boot
without any changes whatsoever for most older versions of Xen.

There are a number of people for whom this won't work; I think we also
need to provide a way to transparently change PV guests into PVshim
guests.  But that will necessarily involve significant toolstack
functionality, at which point you might as well backport PVH as well.

 -George

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Ian Jackson]

Andrew Cooper writes ("Re: Radical proposal: ship not-fully-tidied shim as 4.10.1"):
> Does this sound fair?

Everything is on fire.  Your proposal seems much less radical than
mine.  I doubt it will produce a release to our users tomorrow, let
alone this week.

If we can't get agreement to commit an under-reviewed and under-tested
series to staging-4.10, then IMO we should fork 4.10 and make an
emergency security release off the fork, instead.

Ian.

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Ian Jackson]

Andrew Cooper writes ("Re: Radical proposal: ship not-fully-tidied shim as 4.10.1"):
> What I mean by this is
> that, if we agree to go along this route, patches should be committed to
> staging then immediately cherrypicked to staging-4.10, rather than
> committed to staging-4.10 directly. This ensures that we don't
> accidentally miss functionality in the mainline.

I don't think we are in any danger of "accidentally missing
functionality in the mainline".  If that is a concern, we could close
staging..  We could also attempt to git merge staging-4.10 into
staging or simply git rebase everything after we start on this
approach.

And as my other mail suggests, I don't think we should allow this work
to be blocked by outstanding reviewed.  IMO we should ship what we
have ASAP.

Ian.

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[George Dunlap]

On 01/09/2018 10:53 AM, Ian Jackson wrote:
> Andrew Cooper writes ("Re: Radical proposal: ship not-fully-tidied shim as 4.10.1"):
>> What I mean by this is
>> that, if we agree to go along this route, patches should be committed to
>> staging then immediately cherrypicked to staging-4.10, rather than
>> committed to staging-4.10 directly. This ensures that we don't
>> accidentally miss functionality in the mainline.
> 
> I don't think we are in any danger of "accidentally missing
> functionality in the mainline".  If that is a concern, we could close
> staging..  We could also attempt to git merge staging-4.10 into
> staging or simply git rebase everything after we start on this
> approach.
> 
> And as my other mail suggests, I don't think we should allow this work
> to be blocked by outstanding reviewed.  IMO we should ship what we
> have ASAP.

Well "what we have" boot under HVM?

 -George

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Ian Jackson]

George Dunlap writes ("Re: Radical proposal: ship not-fully-tidied shim as 4.10.1"):
> On 01/09/2018 10:53 AM, Ian Jackson wrote:
> > And as my other mail suggests, I don't think we should allow this work
> > to be blocked by outstanding reviewed.  IMO we should ship what we
> > have ASAP.
> 
> Well "what we have" boot under HVM?

No, so that does need to be fixed.  We could ship Amazon's series but
that has no migration and no ballooning.

I was hoping someone would have an opinion about how hard it would be
to take Amazon's early boot approach and stuff it into Citrix's
more-comprehensive shim series.

Ian.

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Wei Liu]

On Tue, Jan 09, 2018 at 01:24:02AM -0700, Jan Beulich wrote:
> >>> On 09.01.18 at 01:14, <andrew.cooper3@citrix.com> wrote:
> > On 08/01/2018 17:45, Ian Jackson wrote:
> >> AIUI we have a series for pv-in-pvh shim which is nearing completion
> >> in the sense that it will have been well-tested (especially the
> >> hypervisor parts) and has good functionality.  (Wei is handling the
> >> assembly of this series.)
> >>
> >> The series, however, needs proper review and tidying up.
> >> Specifically, it needs the kind of tidying up that fixes code
> >> structure and style issues that will hinder future Xen development.
> >> I.e. the kind of technical debt which does not directly cause bugs now
> >> but will cause trouble (including bugs) in the future.
> >>
> >> IMO that kind of tidying up is definitely essential for
> >> xen.git#master.  However, it is much less of an issue for Xen 4.10.
> >> Xen 4.10, as a stable branch, will get much more limited further
> >> development.  Failure to tidy things up there will make backporting
> >> other changes more awkward but the overall impact is both lower and
> >> time-bound.
> >>
> >> Currently the Xen Project has no published resolution for PV guests
> >> that can't be booted as, or converted to, PVH or HVM.  (And HVM guests
> >> bring their own problems.)  We need to provide our users with more
> >> good options as quickly as possible.
> >>
> >> I would like to suggest that a good way of doing this would be to ship
> >> the shim series as 4.10.1 within the next very few days.  It needs
> >> some minor bugfixing (build breakage etc.) but is basically ready for
> >> use.
> >>
> >> Speaking as a sysadmin (even, a very conservative sysadmin many of
> >> whose systems are running Debian oldstable), I have already taken a
> >> decision to rapidly advance to new software, in one context, because
> >> of these vulnerabilities - and take and fix whatever impact that has.
> >> I think many of our users would like to make the same choice.
> >>
> >> Releaseing 4.10.1 this week with pv-in-pvh support would give many of
> >> our users with PV guests an immediately deployable update, even though
> >> of course the version bump to get to 4.10 may be disruptive.
> 
> Such a version bump may be impossible to do for distros.
> Nevertheless I agree with the underlying idea, not the least
> because I expect distros with older hypervisors still wanting
> to use a 4.10 based shim (backporting host hypervisor and
> tool stack changes as necessary).
> 
> One thing I'd like to be considered though before rushing
> things into 4.10 (and, see below, staging as a prereq) is the
> goal of at least somewhat converging the two shim
> implementations. Especially from the tools side I understand
> that using the Citrix variant on anything older than 4.8 may
> end up being close to impossible, so at least for 4.7 and older
> the Amazon variant may be the only option. Hence as little
> divergence between the two as possible (within reasonable
> time constraints) would seem rather desirable.
> 

We haven't tested booting the series I posted in HVM mode, but off the
top of my head it should work in HVM mode as well -- the multiboot path
is left intact.

Wei.

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Anthony Liguori]

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

On Jan 9, 2018 2:59 AM, "Ian Jackson" <ian.jackson@eu.citrix.com> wrote:

George Dunlap writes ("Re: Radical proposal: ship not-fully-tidied shim as
4.10.1"):
> On 01/09/2018 10:53 AM, Ian Jackson wrote:
> > And as my other mail suggests, I don't think we should allow this work
> > to be blocked by outstanding reviewed.  IMO we should ship what we
> > have ASAP.
>
> Well "what we have" boot under HVM?

No, so that does need to be fixed.  We could ship Amazon's series but
that has no migration and no ballooning.


Why do we think migration doesn't work?  I haven't tested but I cannot
imagine why it wouldn't.

Ballooning is trivial.  I can send a V3 this morning with ballooning.

Regards,

Anthony Liguori


I was hoping someone would have an opinion about how hard it would be
to take Amazon's early boot approach and stuff it into Citrix's
more-comprehensive shim series.

Ian.

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

[-- Attachment #1.2: Type: text/html, Size: 2214 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: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Roger Pau Monné]

On Tue, Jan 09, 2018 at 06:08:53AM -0800, Anthony Liguori wrote:
> On Jan 9, 2018 2:59 AM, "Ian Jackson" <ian.jackson@eu.citrix.com> wrote:
> 
> George Dunlap writes ("Re: Radical proposal: ship not-fully-tidied shim as
> 4.10.1"):
> > On 01/09/2018 10:53 AM, Ian Jackson wrote:
> > > And as my other mail suggests, I don't think we should allow this work
> > > to be blocked by outstanding reviewed.  IMO we should ship what we
> > > have ASAP.
> >
> > Well "what we have" boot under HVM?
> 
> No, so that does need to be fixed.  We could ship Amazon's series but
> that has no migration and no ballooning.
> 
> 
> Why do we think migration doesn't work?  I haven't tested but I cannot
> imagine why it wouldn't.

You need something like the following commit to make migration work:

http://xenbits.xen.org/gitweb/?p=people/liuw/xen.git;a=commit;h=ded375c74b435e6f03d6dbcaa11257a2568e7740

Roger.

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Anthony Liguori]

On Tue, Jan 9, 2018 at 2:49 AM, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
> Andrew Cooper writes ("Re: Radical proposal: ship not-fully-tidied shim as 4.10.1"):
>> Does this sound fair?
>
> Everything is on fire.  Your proposal seems much less radical than
> mine.  I doubt it will produce a release to our users tomorrow, let
> alone this week.
>
> If we can't get agreement to commit an under-reviewed and under-tested
> series to staging-4.10, then IMO we should fork 4.10 and make an
> emergency security release off the fork, instead.

My series is on top of staging and I already have a backport to 4.9
and 4.10 stable published.

I will cherry pick as much as I can from Wei's branch this morning and
send out a v3.  I will try
to close the migration, hotplug, ballooning gap.

I do think it's useful for folks to review the series deeply.  It's
not that big so it should take all that
long to do so.

I think v3 of my series is likely the closest to something that can be
merged this week.

Regards,

Anthony Liguori

> Ian.
>
> _______________________________________________
> 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: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Stefano Stabellini]

On Tue, 9 Jan 2018, George Dunlap wrote:
> On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud <persaur@gmail.com> wrote:
> > On a similarly pragmatic note: would a variation of Anthony's vixen patch series be suitable for pre-PVH Xen 4.6 - 4.9?  These versions are currently documented as security-supported (Oct 2018 - July 2020).
> 
> Hmm, Ian's mail seems to be focusing on the idea of checking in a
> non-polished series to 4.10, rather than exctly what the content of
> that series would be.
> 
> In the IRL conversation that preceeded this mail, the new short-term
> target we discussed was:
> 1. A 4.10-based shim that could boot either under HVM or PVH
> 2. A script that would take an existing PV config, and spit out a) a
> bootable ISO with the shim & whatever was needed, and b) a new config
> that would boot the same VM, but in HVM mode with the shim
> 
> The script + a 4.10 shim binary *should* allow most PV guests to boot
> without any changes whatsoever for most older versions of Xen.
> 
> There are a number of people for whom this won't work; I think we also
> need to provide a way to transparently change PV guests into PVshim
> guests.  But that will necessarily involve significant toolstack
> functionality, at which point you might as well backport PVH as well.

Yes, there will be a number of people that won't be covered by this fix,
including those that can't use HVM/PVH mode because VT-x isn't available
at all in their environment. That is the only reason to run PV today.
Providing a way to transparently change PV guests into PVshim guests
won't cover any of these cases. A more complete workaround to SP3 is
along the lines of https://marc.info/?l=xen-devel&m=151509740625690.

That said, I realize that we are only trying to do the best we can in a
very difficult situation, with very little time in our hands. I agree
with Ian that we should commit something unpolished and only partially
reviewed soon, even though it doesn't cover a good chunk of the userbase
for one reason or another. Even if migration doesn't work, it will still
help all that don't require it. It is only a partial fix by nature
anyway.

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Anthony Liguori]

On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini
<sstabellini@kernel.org> wrote:
> On Tue, 9 Jan 2018, George Dunlap wrote:
>> On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud <persaur@gmail.com> wrote:
>> > On a similarly pragmatic note: would a variation of Anthony's vixen patch series be suitable for pre-PVH Xen 4.6 - 4.9?  These versions are currently documented as security-supported (Oct 2018 - July 2020).
>>
>> Hmm, Ian's mail seems to be focusing on the idea of checking in a
>> non-polished series to 4.10, rather than exctly what the content of
>> that series would be.
>>
>> In the IRL conversation that preceeded this mail, the new short-term
>> target we discussed was:
>> 1. A 4.10-based shim that could boot either under HVM or PVH
>> 2. A script that would take an existing PV config, and spit out a) a
>> bootable ISO with the shim & whatever was needed, and b) a new config
>> that would boot the same VM, but in HVM mode with the shim
>>
>> The script + a 4.10 shim binary *should* allow most PV guests to boot
>> without any changes whatsoever for most older versions of Xen.
>>
>> There are a number of people for whom this won't work; I think we also
>> need to provide a way to transparently change PV guests into PVshim
>> guests.  But that will necessarily involve significant toolstack
>> functionality, at which point you might as well backport PVH as well.
>
> Yes, there will be a number of people that won't be covered by this fix,
> including those that can't use HVM/PVH mode because VT-x isn't available
> at all in their environment. That is the only reason to run PV today.
> Providing a way to transparently change PV guests into PVshim guests
> won't cover any of these cases. A more complete workaround to SP3 is
> along the lines of https://marc.info/?l=xen-devel&m=151509740625690.
>
> That said, I realize that we are only trying to do the best we can in a
> very difficult situation, with very little time in our hands. I agree
> with Ian that we should commit something unpolished and only partially
> reviewed soon, even though it doesn't cover a good chunk of the userbase
> for one reason or another. Even if migration doesn't work, it will still
> help all that don't require it. It is only a partial fix by nature
> anyway.

Can people be a bit more explicit about what they think should be done here?

I'm happy to redirect effort to PVH shim if that's what the solution
is going to be.

I obviously prefer the HVM approach as it works on a broad range of Xen versions
without modification but I'm keen to get something done quickly and
don't want to
waste effort.

Where are people's heads at?

Regards,

Anthony Liguori


> _______________________________________________
> 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: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Jan Beulich]

>>> On 09.01.18 at 18:23, <anthony@codemonkey.ws> wrote:
> On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini
> <sstabellini@kernel.org> wrote:
>> On Tue, 9 Jan 2018, George Dunlap wrote:
>>> On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud <persaur@gmail.com> wrote:
>>> > On a similarly pragmatic note: would a variation of Anthony's vixen patch 
> series be suitable for pre-PVH Xen 4.6 - 4.9?  These versions are currently 
> documented as security-supported (Oct 2018 - July 2020).
>>>
>>> Hmm, Ian's mail seems to be focusing on the idea of checking in a
>>> non-polished series to 4.10, rather than exctly what the content of
>>> that series would be.
>>>
>>> In the IRL conversation that preceeded this mail, the new short-term
>>> target we discussed was:
>>> 1. A 4.10-based shim that could boot either under HVM or PVH
>>> 2. A script that would take an existing PV config, and spit out a) a
>>> bootable ISO with the shim & whatever was needed, and b) a new config
>>> that would boot the same VM, but in HVM mode with the shim
>>>
>>> The script + a 4.10 shim binary *should* allow most PV guests to boot
>>> without any changes whatsoever for most older versions of Xen.
>>>
>>> There are a number of people for whom this won't work; I think we also
>>> need to provide a way to transparently change PV guests into PVshim
>>> guests.  But that will necessarily involve significant toolstack
>>> functionality, at which point you might as well backport PVH as well.
>>
>> Yes, there will be a number of people that won't be covered by this fix,
>> including those that can't use HVM/PVH mode because VT-x isn't available
>> at all in their environment. That is the only reason to run PV today.
>> Providing a way to transparently change PV guests into PVshim guests
>> won't cover any of these cases. A more complete workaround to SP3 is
>> along the lines of https://marc.info/?l=xen-devel&m=151509740625690.
>>
>> That said, I realize that we are only trying to do the best we can in a
>> very difficult situation, with very little time in our hands. I agree
>> with Ian that we should commit something unpolished and only partially
>> reviewed soon, even though it doesn't cover a good chunk of the userbase
>> for one reason or another. Even if migration doesn't work, it will still
>> help all that don't require it. It is only a partial fix by nature
>> anyway.
> 
> Can people be a bit more explicit about what they think should be done here?
> 
> I'm happy to redirect effort to PVH shim if that's what the solution
> is going to be.
> 
> I obviously prefer the HVM approach as it works on a broad range of Xen 
> versions
> without modification but I'm keen to get something done quickly and
> don't want to
> waste effort.

From what I've read today, I have no reason to believe the PVH
shim won't work in HVM mode. How would the HVM-only approach
be better in that case?

Jan


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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Anthony Liguori]

On Tue, Jan 9, 2018 at 9:33 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 09.01.18 at 18:23, <anthony@codemonkey.ws> wrote:
>> On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini
>> <sstabellini@kernel.org> wrote:
>>> On Tue, 9 Jan 2018, George Dunlap wrote:
>>>> On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud <persaur@gmail.com> wrote:
>>>> > On a similarly pragmatic note: would a variation of Anthony's vixen patch
>> series be suitable for pre-PVH Xen 4.6 - 4.9?  These versions are currently
>> documented as security-supported (Oct 2018 - July 2020).
>>>>
>>>> Hmm, Ian's mail seems to be focusing on the idea of checking in a
>>>> non-polished series to 4.10, rather than exctly what the content of
>>>> that series would be.
>>>>
>>>> In the IRL conversation that preceeded this mail, the new short-term
>>>> target we discussed was:
>>>> 1. A 4.10-based shim that could boot either under HVM or PVH
>>>> 2. A script that would take an existing PV config, and spit out a) a
>>>> bootable ISO with the shim & whatever was needed, and b) a new config
>>>> that would boot the same VM, but in HVM mode with the shim
>>>>
>>>> The script + a 4.10 shim binary *should* allow most PV guests to boot
>>>> without any changes whatsoever for most older versions of Xen.
>>>>
>>>> There are a number of people for whom this won't work; I think we also
>>>> need to provide a way to transparently change PV guests into PVshim
>>>> guests.  But that will necessarily involve significant toolstack
>>>> functionality, at which point you might as well backport PVH as well.
>>>
>>> Yes, there will be a number of people that won't be covered by this fix,
>>> including those that can't use HVM/PVH mode because VT-x isn't available
>>> at all in their environment. That is the only reason to run PV today.
>>> Providing a way to transparently change PV guests into PVshim guests
>>> won't cover any of these cases. A more complete workaround to SP3 is
>>> along the lines of https://marc.info/?l=xen-devel&m=151509740625690.
>>>
>>> That said, I realize that we are only trying to do the best we can in a
>>> very difficult situation, with very little time in our hands. I agree
>>> with Ian that we should commit something unpolished and only partially
>>> reviewed soon, even though it doesn't cover a good chunk of the userbase
>>> for one reason or another. Even if migration doesn't work, it will still
>>> help all that don't require it. It is only a partial fix by nature
>>> anyway.
>>
>> Can people be a bit more explicit about what they think should be done here?
>>
>> I'm happy to redirect effort to PVH shim if that's what the solution
>> is going to be.
>>
>> I obviously prefer the HVM approach as it works on a broad range of Xen
>> versions
>> without modification but I'm keen to get something done quickly and
>> don't want to
>> waste effort.
>
> From what I've read today, I have no reason to believe the PVH
> shim won't work in HVM mode. How would the HVM-only approach
> be better in that case?

PVShim doesn't work on HVM.  I haven't debugged it but I get an early
panic due when constructing dom0.

There isn't adequate compatibility in the series too to support
anything but very recent Xen versions (for event channels at least).

The HVM-only approach is known to work on a wide set of Xen versions.

Regards,

Anthony Liguori

> Jan
>

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Doug Goldstein]

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

On 1/9/18 11:33 AM, Jan Beulich wrote:
>>>> On 09.01.18 at 18:23, <anthony@codemonkey.ws> wrote:
>> On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini
>> <sstabellini@kernel.org> wrote:
>>> On Tue, 9 Jan 2018, George Dunlap wrote:
>>>> On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud <persaur@gmail.com> wrote:
>>>>> On a similarly pragmatic note: would a variation of Anthony's vixen patch 
>> series be suitable for pre-PVH Xen 4.6 - 4.9?  These versions are currently 
>> documented as security-supported (Oct 2018 - July 2020).
>>>>
>>>> Hmm, Ian's mail seems to be focusing on the idea of checking in a
>>>> non-polished series to 4.10, rather than exctly what the content of
>>>> that series would be.
>>>>
>>>> In the IRL conversation that preceeded this mail, the new short-term
>>>> target we discussed was:
>>>> 1. A 4.10-based shim that could boot either under HVM or PVH
>>>> 2. A script that would take an existing PV config, and spit out a) a
>>>> bootable ISO with the shim & whatever was needed, and b) a new config
>>>> that would boot the same VM, but in HVM mode with the shim
>>>>
>>>> The script + a 4.10 shim binary *should* allow most PV guests to boot
>>>> without any changes whatsoever for most older versions of Xen.
>>>>
>>>> There are a number of people for whom this won't work; I think we also
>>>> need to provide a way to transparently change PV guests into PVshim
>>>> guests.  But that will necessarily involve significant toolstack
>>>> functionality, at which point you might as well backport PVH as well.
>>>
>>> Yes, there will be a number of people that won't be covered by this fix,
>>> including those that can't use HVM/PVH mode because VT-x isn't available
>>> at all in their environment. That is the only reason to run PV today.
>>> Providing a way to transparently change PV guests into PVshim guests
>>> won't cover any of these cases. A more complete workaround to SP3 is
>>> along the lines of https://marc.info/?l=xen-devel&m=151509740625690.
>>>
>>> That said, I realize that we are only trying to do the best we can in a
>>> very difficult situation, with very little time in our hands. I agree
>>> with Ian that we should commit something unpolished and only partially
>>> reviewed soon, even though it doesn't cover a good chunk of the userbase
>>> for one reason or another. Even if migration doesn't work, it will still
>>> help all that don't require it. It is only a partial fix by nature
>>> anyway.
>>
>> Can people be a bit more explicit about what they think should be done here?
>>
>> I'm happy to redirect effort to PVH shim if that's what the solution
>> is going to be.
>>
>> I obviously prefer the HVM approach as it works on a broad range of Xen 
>> versions
>> without modification but I'm keen to get something done quickly and
>> don't want to
>> waste effort.
> 
> From what I've read today, I have no reason to believe the PVH
> shim won't work in HVM mode. How would the HVM-only approach
> be better in that case?
> 
> Jan

I feel like I should state the obvious here. Its tested over a large
data set.
-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 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: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Doug Goldstein]

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

On 1/8/18 3:44 PM, Anthony Liguori wrote:
> 
> It's not particularly hard to plumb through I think but if you are
> using PCI passthrough for PV, then you really shouldn't worry about
> Spectre/Meltdown.  That PV guest can already read all of physical
> memory (since no IOMMU is used) and they can also write to all
> physical memory which is far worse than what you can do with
> Spectre/Meltdown.
> 

That's certainly not true. The IOMMU is used by default with PV if its
available since Xen 4.0.1. Prior to that there was an option that was
"iommu=pv" which was not the default for 4.0.0. Its certainly possible
that's true for Xen 3.4 however.

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 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: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Stefano Stabellini]

On Tue, 9 Jan 2018, Doug Goldstein wrote:
> On 1/9/18 11:33 AM, Jan Beulich wrote:
> >>>> On 09.01.18 at 18:23, <anthony@codemonkey.ws> wrote:
> >> On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini
> >> <sstabellini@kernel.org> wrote:
> >>> On Tue, 9 Jan 2018, George Dunlap wrote:
> >>>> On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud <persaur@gmail.com> wrote:
> >>>>> On a similarly pragmatic note: would a variation of Anthony's vixen patch 
> >> series be suitable for pre-PVH Xen 4.6 - 4.9?  These versions are currently 
> >> documented as security-supported (Oct 2018 - July 2020).
> >>>>
> >>>> Hmm, Ian's mail seems to be focusing on the idea of checking in a
> >>>> non-polished series to 4.10, rather than exctly what the content of
> >>>> that series would be.
> >>>>
> >>>> In the IRL conversation that preceeded this mail, the new short-term
> >>>> target we discussed was:
> >>>> 1. A 4.10-based shim that could boot either under HVM or PVH
> >>>> 2. A script that would take an existing PV config, and spit out a) a
> >>>> bootable ISO with the shim & whatever was needed, and b) a new config
> >>>> that would boot the same VM, but in HVM mode with the shim
> >>>>
> >>>> The script + a 4.10 shim binary *should* allow most PV guests to boot
> >>>> without any changes whatsoever for most older versions of Xen.
> >>>>
> >>>> There are a number of people for whom this won't work; I think we also
> >>>> need to provide a way to transparently change PV guests into PVshim
> >>>> guests.  But that will necessarily involve significant toolstack
> >>>> functionality, at which point you might as well backport PVH as well.
> >>>
> >>> Yes, there will be a number of people that won't be covered by this fix,
> >>> including those that can't use HVM/PVH mode because VT-x isn't available
> >>> at all in their environment. That is the only reason to run PV today.
> >>> Providing a way to transparently change PV guests into PVshim guests
> >>> won't cover any of these cases. A more complete workaround to SP3 is
> >>> along the lines of https://marc.info/?l=xen-devel&m=151509740625690.
> >>>
> >>> That said, I realize that we are only trying to do the best we can in a
> >>> very difficult situation, with very little time in our hands. I agree
> >>> with Ian that we should commit something unpolished and only partially
> >>> reviewed soon, even though it doesn't cover a good chunk of the userbase
> >>> for one reason or another. Even if migration doesn't work, it will still
> >>> help all that don't require it. It is only a partial fix by nature
> >>> anyway.
> >>
> >> Can people be a bit more explicit about what they think should be done here?
> >>
> >> I'm happy to redirect effort to PVH shim if that's what the solution
> >> is going to be.
> >>
> >> I obviously prefer the HVM approach as it works on a broad range of Xen 
> >> versions
> >> without modification but I'm keen to get something done quickly and
> >> don't want to
> >> waste effort.
> > 
> > From what I've read today, I have no reason to believe the PVH
> > shim won't work in HVM mode. How would the HVM-only approach
> > be better in that case?
> > 
> > Jan
> 
> I feel like I should state the obvious here. Its tested over a large
> data set.

Right: if we are going to commit something unpolished and unreviewed,
let it be at least very well tested by the submitter. Honest question:
how much more dev&test we need on PVShim before we get it to similar
levels of confidence?

This is about an emergency stop-gap, we can work on a nice and shiny new
fix for the next release. We can even revert Anthony's series entirely
and start from scratch again, if that is required.

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Wei Liu]

On Tue, Jan 09, 2018 at 09:23:03AM -0800, Anthony Liguori wrote:
> On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini
> <sstabellini@kernel.org> wrote:
> > On Tue, 9 Jan 2018, George Dunlap wrote:
> >> On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud <persaur@gmail.com> wrote:
> >> > On a similarly pragmatic note: would a variation of Anthony's vixen patch series be suitable for pre-PVH Xen 4.6 - 4.9?  These versions are currently documented as security-supported (Oct 2018 - July 2020).
> >>
> >> Hmm, Ian's mail seems to be focusing on the idea of checking in a
> >> non-polished series to 4.10, rather than exctly what the content of
> >> that series would be.
> >>
> >> In the IRL conversation that preceeded this mail, the new short-term
> >> target we discussed was:
> >> 1. A 4.10-based shim that could boot either under HVM or PVH
> >> 2. A script that would take an existing PV config, and spit out a) a
> >> bootable ISO with the shim & whatever was needed, and b) a new config
> >> that would boot the same VM, but in HVM mode with the shim
> >>
> >> The script + a 4.10 shim binary *should* allow most PV guests to boot
> >> without any changes whatsoever for most older versions of Xen.
> >>
> >> There are a number of people for whom this won't work; I think we also
> >> need to provide a way to transparently change PV guests into PVshim
> >> guests.  But that will necessarily involve significant toolstack
> >> functionality, at which point you might as well backport PVH as well.
> >
> > Yes, there will be a number of people that won't be covered by this fix,
> > including those that can't use HVM/PVH mode because VT-x isn't available
> > at all in their environment. That is the only reason to run PV today.
> > Providing a way to transparently change PV guests into PVshim guests
> > won't cover any of these cases. A more complete workaround to SP3 is
> > along the lines of https://marc.info/?l=xen-devel&m=151509740625690.
> >
> > That said, I realize that we are only trying to do the best we can in a
> > very difficult situation, with very little time in our hands. I agree
> > with Ian that we should commit something unpolished and only partially
> > reviewed soon, even though it doesn't cover a good chunk of the userbase
> > for one reason or another. Even if migration doesn't work, it will still
> > help all that don't require it. It is only a partial fix by nature
> > anyway.
> 
> Can people be a bit more explicit about what they think should be done here?
> 
> I'm happy to redirect effort to PVH shim if that's what the solution
> is going to be.
> 
> I obviously prefer the HVM approach as it works on a broad range of Xen versions
> without modification but I'm keen to get something done quickly and
> don't want to
> waste effort.
> 

Ian, George, Roger and I had discussions yesterday and today to see what
we can do in the short term and we think the HVM approach is very
attractive. And we certainly appreciate your effort and willing to help.

After going through the PV in PVH work we thought it should work in HVM
mode the same way as it does in PVH. So today we tested our PV in PVH
branch, which booted fine in an HVM guest (turned out only one small fix
is needed!), and everything which worked under PVH mode works in HVM
mode as well.

So basically we've been working on your idea of running PV in HVM the
whole day -- to make it work with our branch, to provide sidecar
generation mechanism.

Ian has been busy writing the sidecar script and Roger and I have been
working on cleaning up the branch.  We want to post a new version as
soon as possible (tomorrow or even tonight).

All in all: yes, we like the idea  and we're working on it. Code-wise,
we start from the PV in PVH branch because it is more functionally
complete.  I want to take in some of the code from Amazon later when
necessary (for example I like the ECS_PROXY state but haven't had time
to think deeply about it). The final shim is going to be able to run in
HVM and PVH.  When running in HVM, users need to use the sidecar
mechanism, and this is only the short term solution. The same shim is
going to be able to run in PVH, so user can smoothly upgrade to a new
PVH capable version of Xen when required.

Ian, George and Roger please correct me if I'm wrong.

Anthony, you are welcome to join #xendevel to have a quick chat about
your ideas / concerns / whatever. It is far easy to grab our attention
there. :-)

Wei.

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Doug Goldstein]

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

On 1/9/18 5:50 AM, Wei Liu wrote:
> 
> We haven't tested booting the series I posted in HVM mode, but off the
> top of my head it should work in HVM mode as well -- the multiboot path
> is left intact.
> 

Can we actually do this before committing to this series? I've seen a
number of "this should work" in this thread and other threads but no
actual confirmation.

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 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: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Wei Liu]

On Tue, Jan 09, 2018 at 11:59:01AM -0600, Doug Goldstein wrote:
> On 1/9/18 5:50 AM, Wei Liu wrote:
> > 
> > We haven't tested booting the series I posted in HVM mode, but off the
> > top of my head it should work in HVM mode as well -- the multiboot path
> > is left intact.
> > 
> 
> Can we actually do this before committing to this series? I've seen a
> number of "this should work" in this thread and other threads but no
> actual confirmation.
> 

Oops, people are so quick to reply to this thread -- see my reply a few
minutes ago to Anthony.

Wei.

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Doug Goldstein]

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

On 1/8/18 11:45 AM, Ian Jackson wrote:
> But this is not a usual situation.  This time, we don't have the time
> to wait.
> 
> Opinions ?

I'm going to follow up with a top post with my feelings and from info on
various parts of the thread.

We have 2 versions of PV shim, the Citrix version and the Amazon
version. The proposal here is to go with the Citrix version. I'll
compare the two how I see them.

Citrix Version
--------------
- based on PVH which means 4.10 only
  - supported on 4.8 and 4.9 if we backport changes to the toolstack
- no solution for 4.7 and prior versions
- no backports currently available
- supports *most* Xen PV features
  - no support for PCI pass through
- confirmed to not work on HVM [1] [2]

Amazon Version
--------------
- based on HVM
- tested and deployed across Amazon's large fleet
- works from Xen 3.4 and up
- backported to 4.9 and 4.10 [3]
- supports *most* Xen PV features
  - ballooning is broken but Anthony has committed to providing a v3
with this support. [4]
  - migration is currently untested

If the primary driver for getting these patches in is for end users and
consumers of Xen, a large portion of them who have not yet deployed Xen
4.10 then why are we moving forard with an approach that requires them
to potentially upgrade or change a lot more of their environment. This
seems down right hostile to their concerns and needs.


[1]
https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00711.html
[2]
https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00778.html
[3]
https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00751.html
[4]
https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00736.html
-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 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: Radical proposal: ship not-fully-tidied shim as 4.10.1

[George Dunlap]

On 01/09/2018 06:13 PM, Doug Goldstein wrote:
> On 1/8/18 11:45 AM, Ian Jackson wrote:
>> But this is not a usual situation.  This time, we don't have the time
>> to wait.
>>
>> Opinions ?
> 
> I'm going to follow up with a top post with my feelings and from info on
> various parts of the thread.
> 
> We have 2 versions of PV shim, the Citrix version and the Amazon
> version. The proposal here is to go with the Citrix version. I'll
> compare the two how I see them.
> 
> Citrix Version
> --------------
> - based on PVH which means 4.10 only
>   - supported on 4.8 and 4.9 if we backport changes to the toolstack
> - no solution for 4.7 and prior versions

We are committed to having HVM support along with PVH support (if we go
this route).

We can change this to:
 - For 4.10, and 4.8 / 4.9 with backports, users will be able to boot PV
guests without a sidecar or qemu, and (hopefully) transparently to the
toolstack
 - For 4.7 and prior, or 4.8+ without backports, available with sidecar
boot disk (and added qemu instance)

> - no backports currently available
> - supports *most* Xen PV features
>   - no support for PCI pass through
> - confirmed to not work on HVM [1] [2]
> 
> Amazon Version
> --------------
> - based on HVM
> - tested and deployed across Amazon's large fleet
> - works from Xen 3.4 and up

 - But requires "sidecar boot disk", and will add a qemu instance per guest

> - backported to 4.9 and 4.10 [3]
> - supports *most* Xen PV features
>   - ballooning is broken but Anthony has committed to providing a v3
> with this support. [4]
>   - migration is currently untested

 -George

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Rich Persaud]

>> On Jan 9, 2018, at 12:56, Stefano Stabellini <sstabellini@kernel.org> wrote:
>> 
>> On Tue, 9 Jan 2018, Doug Goldstein wrote:
>> On 1/9/18 11:33 AM, Jan Beulich wrote:
>>>>>> On 09.01.18 at 18:23, <anthony@codemonkey.ws> wrote:
>>>> On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini
>>>> <sstabellini@kernel.org> wrote:
>>>>>>> On Tue, 9 Jan 2018, George Dunlap wrote:
>>>>>>> On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud <persaur@gmail.com> wrote:
>>>>>>> On a similarly pragmatic note: would a variation of Anthony's vixen patch
>>>> series be suitable for pre-PVH Xen 4.6 - 4.9?  These versions are currently 
>>>> documented as security-supported (Oct 2018 - July 2020).
>>>>>> 
>>>>>> Hmm, Ian's mail seems to be focusing on the idea of checking in a
>>>>>> non-polished series to 4.10, rather than exctly what the content of
>>>>>> that series would be.
>>>>>> 
>>>>>> In the IRL conversation that preceeded this mail, the new short-term
>>>>>> target we discussed was:
>>>>>> 1. A 4.10-based shim that could boot either under HVM or PVH
>>>>>> 2. A script that would take an existing PV config, and spit out a) a
>>>>>> bootable ISO with the shim & whatever was needed, and b) a new config
>>>>>> that would boot the same VM, but in HVM mode with the shim
>>>>>> 
>>>>>> The script + a 4.10 shim binary *should* allow most PV guests to boot
>>>>>> without any changes whatsoever for most older versions of Xen.
>>>>>> 
>>>>>> There are a number of people for whom this won't work; I think we also
>>>>>> need to provide a way to transparently change PV guests into PVshim
>>>>>> guests.  But that will necessarily involve significant toolstack
>>>>>> functionality, at which point you might as well backport PVH as well.
>>>>> 
>>>>> Yes, there will be a number of people that won't be covered by this fix,
>>>>> including those that can't use HVM/PVH mode because VT-x isn't available
>>>>> at all in their environment. That is the only reason to run PV today.
>>>>> Providing a way to transparently change PV guests into PVshim guests
>>>>> won't cover any of these cases. A more complete workaround to SP3 is
>>>>> along the lines of https://marc.info/?l=xen-devel&m=151509740625690.
>>>>> 
>>>>> That said, I realize that we are only trying to do the best we can in a
>>>>> very difficult situation, with very little time in our hands. I agree
>>>>> with Ian that we should commit something unpolished and only partially
>>>>> reviewed soon, even though it doesn't cover a good chunk of the userbase
>>>>> for one reason or another. Even if migration doesn't work, it will still
>>>>> help all that don't require it. It is only a partial fix by nature
>>>>> anyway.
>>>> 
>>>> Can people be a bit more explicit about what they think should be done here?
>>>> 
>>>> I'm happy to redirect effort to PVH shim if that's what the solution
>>>> is going to be.
>>>> 
>>>> I obviously prefer the HVM approach as it works on a broad range of Xen 
>>>> versions
>>>> without modification but I'm keen to get something done quickly and
>>>> don't want to
>>>> waste effort.
>>> 
>>> From what I've read today, I have no reason to believe the PVH
>>> shim won't work in HVM mode. How would the HVM-only approach
>>> be better in that case?
>>> 
>>> Jan
>> 
>> I feel like I should state the obvious here. Its tested over a large
>> data set.
> 
> Right: if we are going to commit something unpolished and unreviewed,
> let it be at least very well tested by the submitter. Honest question:
> how much more dev&test we need on PVShim before we get it to similar
> levels of confidence?

Since the primary audience for security fixes are production deployments of Xen where customer assets are at risk, is there an estimate for the percentage/size of Xen deployments where PVH (not only Xen 4.10) has already been deployed for production customers?  That could give other customers more confidence in deploying PVH in production.

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Wei Liu]

On Mon, Jan 08, 2018 at 05:45:32PM +0000, Ian Jackson wrote:
> AIUI we have a series for pv-in-pvh shim which is nearing completion
> in the sense that it will have been well-tested (especially the
> hypervisor parts) and has good functionality.  (Wei is handling the
> assembly of this series.)
> 
> The series, however, needs proper review and tidying up.
> Specifically, it needs the kind of tidying up that fixes code
> structure and style issues that will hinder future Xen development.
> I.e. the kind of technical debt which does not directly cause bugs now
> but will cause trouble (including bugs) in the future.
> 
> IMO that kind of tidying up is definitely essential for
> xen.git#master.  However, it is much less of an issue for Xen 4.10.
> Xen 4.10, as a stable branch, will get much more limited further
> development.  Failure to tidy things up there will make backporting
> other changes more awkward but the overall impact is both lower and
> time-bound.
> 
> Currently the Xen Project has no published resolution for PV guests
> that can't be booted as, or converted to, PVH or HVM.  (And HVM guests
> bring their own problems.)  We need to provide our users with more
> good options as quickly as possible.
> 
> I would like to suggest that a good way of doing this would be to ship
> the shim series as 4.10.1 within the next very few days.  It needs
> some minor bugfixing (build breakage etc.) but is basically ready for
> use.
> 
> Speaking as a sysadmin (even, a very conservative sysadmin many of
> whose systems are running Debian oldstable), I have already taken a
> decision to rapidly advance to new software, in one context, because
> of these vulnerabilities - and take and fix whatever impact that has.
> I think many of our users would like to make the same choice.
> 
> Releaseing 4.10.1 this week with pv-in-pvh support would give many of
> our users with PV guests an immediately deployable update, even though
> of course the version bump to get to 4.10 may be disruptive.
> 
> Doing this would be a departure from our uusual non-security-bug
> process of committing changes to xen.git#staging, and then backporting
> only after the patches have been sitting in xen.git#master for some
> time.  It's also a departure from our usual security-bug process of
> developing and testing and committing patches for all supported
> versions in parallel.
> 
> But this is not a usual situation.  This time, we don't have the time
> to wait.
> 
> Opinions ?
> 

Anthony and others joined #xendevel to express their findings and
opinions.

Converging the PVH and HVM solution is doable and essential in the long
run, but merging the two series in two or three days (if we want to make
something ready this week) is not possible. It all comes down to which
series should we use for the temporary solution.

We discussed the test coverage of both series. It seems that the PV in
PVH series has had in depth testing done on 4.7 and 4.10, while PV in
HVM series has had testing done from Xen 3.4 onward with various old and
new guests. Anthony also pointed out that PV in PVH shim won't work for
some configurations -- there are far too many subtleties to fix without
time and testing resources (both of which upstream lacks). These are
rather strong arguments for the PV in HVM series, because being able to
run on older versions of Xen and older versions of guest kernels
provides our users with the maximum coverage.

An argument for PV in PVH series is that it has more functionalities,
but I think migration etc are just nice-to-have's in the context of this
security fix series.

I think providing a well tested solution to our users as soon as
possible, even if the solution has reduced functionality, is better than
delaying for the perfect solution.  I suggest we go with Amazon's series
first and produce something this week, then we seek to merge the two
solutions. Anthony has agreed to be on the hook to review future
patches. ;-)

Wei.

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Anthony Liguori]

On Tue, Jan 9, 2018 at 11:43 AM, Wei Liu <wei.liu2@citrix.com> wrote:
> On Mon, Jan 08, 2018 at 05:45:32PM +0000, Ian Jackson wrote:
>> AIUI we have a series for pv-in-pvh shim which is nearing completion
>> in the sense that it will have been well-tested (especially the
>> hypervisor parts) and has good functionality.  (Wei is handling the
>> assembly of this series.)
>>
>> The series, however, needs proper review and tidying up.
>> Specifically, it needs the kind of tidying up that fixes code
>> structure and style issues that will hinder future Xen development.
>> I.e. the kind of technical debt which does not directly cause bugs now
>> but will cause trouble (including bugs) in the future.
>>
>> IMO that kind of tidying up is definitely essential for
>> xen.git#master.  However, it is much less of an issue for Xen 4.10.
>> Xen 4.10, as a stable branch, will get much more limited further
>> development.  Failure to tidy things up there will make backporting
>> other changes more awkward but the overall impact is both lower and
>> time-bound.
>>
>> Currently the Xen Project has no published resolution for PV guests
>> that can't be booted as, or converted to, PVH or HVM.  (And HVM guests
>> bring their own problems.)  We need to provide our users with more
>> good options as quickly as possible.
>>
>> I would like to suggest that a good way of doing this would be to ship
>> the shim series as 4.10.1 within the next very few days.  It needs
>> some minor bugfixing (build breakage etc.) but is basically ready for
>> use.
>>
>> Speaking as a sysadmin (even, a very conservative sysadmin many of
>> whose systems are running Debian oldstable), I have already taken a
>> decision to rapidly advance to new software, in one context, because
>> of these vulnerabilities - and take and fix whatever impact that has.
>> I think many of our users would like to make the same choice.
>>
>> Releaseing 4.10.1 this week with pv-in-pvh support would give many of
>> our users with PV guests an immediately deployable update, even though
>> of course the version bump to get to 4.10 may be disruptive.
>>
>> Doing this would be a departure from our uusual non-security-bug
>> process of committing changes to xen.git#staging, and then backporting
>> only after the patches have been sitting in xen.git#master for some
>> time.  It's also a departure from our usual security-bug process of
>> developing and testing and committing patches for all supported
>> versions in parallel.
>>
>> But this is not a usual situation.  This time, we don't have the time
>> to wait.
>>
>> Opinions ?
>>
>
> Anthony and others joined #xendevel to express their findings and
> opinions.
>
> Converging the PVH and HVM solution is doable and essential in the long
> run, but merging the two series in two or three days (if we want to make
> something ready this week) is not possible. It all comes down to which
> series should we use for the temporary solution.
>
> We discussed the test coverage of both series. It seems that the PV in
> PVH series has had in depth testing done on 4.7 and 4.10, while PV in
> HVM series has had testing done from Xen 3.4 onward with various old and
> new guests. Anthony also pointed out that PV in PVH shim won't work for
> some configurations -- there are far too many subtleties to fix without
> time and testing resources (both of which upstream lacks). These are
> rather strong arguments for the PV in HVM series, because being able to
> run on older versions of Xen and older versions of guest kernels
> provides our users with the maximum coverage.
>
> An argument for PV in PVH series is that it has more functionalities,
> but I think migration etc are just nice-to-have's in the context of this
> security fix series.
>
> I think providing a well tested solution to our users as soon as
> possible, even if the solution has reduced functionality, is better than
> delaying for the perfect solution.  I suggest we go with Amazon's series
> first and produce something this week, then we seek to merge the two
> solutions. Anthony has agreed to be on the hook to review future
> patches. ;-)

Thanks Wei.

I merged in ballooning support and that seems to be working okay.

Unfortunately, vcpu hotplug crashes during SMP boot up because we're
passing through runstate registration to make steal time accounting work
but there seems to be an incompatibility with that and how hotplug works
in PVShim.

I'm going to port over the migration bits next and then I'll send out a v3.

Regards,

Anthony Liguori

> Wei.
>
> _______________________________________________
> 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: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Matt Wilson]

On Tue, Jan 09, 2018 at 05:58:46PM +0000, Wei Liu wrote:
> 
> Ian has been busy writing the sidecar script and Roger and I have been
> working on cleaning up the branch.  We want to post a new version as
> soon as possible (tomorrow or even tonight).

Ian,

Let me know if you need any help with the sidecar script. Generally
it's straightforward enough to build so I'm sure you won't have any
trouble. Here's one that I used for local testing on my laptop in a
CentOS-ish chroot (we have other bits responsible for this in
EC2). Please excuse the cruft, including the use of legacy GRUB.

---------------------- 8< -------------------
#!/bin/bash
if [ $# -lt 2 ]; then
    echo "usage: $0 xen.gz kernel.gz [initrd.img]"
    exit 1
fi

if [ $# -eq 3 ]; then
    INITRD=$2
fi

if [ ! -f /usr/share/grub/x86_64-redhat/stage2_eltorito ]; then
    echo "/usr/share/grub/x86_64-redhat/stage2_eltorito not found."
    echo "Install grub RPM?"
    exit 1
fi

if [ ! -f $1 ]; then
    echo "$1 is not a file"
    exit 1
fi

if [ ! -f $2 ]; then
    echo "$2 is not a file"
    exit 1
fi

TMPDIR=$(mktemp -d)
cat >> $TMPDIR/menu.lst <<EOF
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal serial
timeout=0
default=0
hiddenmenu
title Vixen
root (cd)
kernel /boot/xen.gz loglvl=all guest_loglvl=all com1=115200,8n1 console=com1,qemu console_timestamps=datems conswitch=b
module /boot/kernel.gz root=/dev/sda1 ro console=hvc0 4
EOF
if [ x"$INITRD" != x ]; then
    echo "module /boot/initrd.img" >> $TMPDIR/menu.lst
    INITRD_GRAFT=boot/initrd.img=$INITRD
fi
cp $TMPDIR/menu.lst $TMPDIR/grub.conf
cp /usr/share/grub/x86_64-redhat/stage2_eltorito $TMPDIR/

mkisofs -output vixen.iso \
    -input-charset utf-8 \
    -joliet -rational-rock \
    -translation-table \
    -eltorito-boot boot/grub/stage2_eltorito \
    -no-emul-boot \
    -boot-load-size 4 \
    -boot-info-table \
    -graft-points \
        boot/grub/stage2_eltorito=$TMPDIR/stage2_eltorito \
        boot/xen.gz=$1 \
        boot/kernel.gz=$2 \
        $INITRD_GRAFT \
        boot/grub/menu.lst=$TMPDIR/menu.lst \
        boot/grub/grub.conf=$TMPDIR/grub.conf

rm -rf $TMPDIR
---------------------- 8< -------------------

Everything but ancient xend based Xen can sideload while avoiding a PV
domU block device by passing in device_model_args like this:

...
boot="d"
device_model_args=[ '-drive', 'file=/path/to/vixen.iso,media=cdrom,format=raw' ]
...

For xend versions we craft a qemu-dm wrapper script and change
device_model to use it.

--msw

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Hans van Kranenburg]

On 01/09/2018 07:22 PM, Rich Persaud wrote:
>>> On Jan 9, 2018, at 12:56, Stefano Stabellini <sstabellini@kernel.org> wrote:
>>>
>>> On Tue, 9 Jan 2018, Doug Goldstein wrote:
>>> On 1/9/18 11:33 AM, Jan Beulich wrote:
>>>>>>> On 09.01.18 at 18:23, <anthony@codemonkey.ws> wrote:
>>>>> On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini
>>>>> <sstabellini@kernel.org> wrote:
>>>>>>>> On Tue, 9 Jan 2018, George Dunlap wrote:
>>>>>>>> On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud <persaur@gmail.com> wrote:
>>>>>>>> On a similarly pragmatic note: would a variation of Anthony's vixen patch
>>>>> series be suitable for pre-PVH Xen 4.6 - 4.9?  These versions are currently 
>>>>> documented as security-supported (Oct 2018 - July 2020).
>>>>>>>
>>>>>>> Hmm, Ian's mail seems to be focusing on the idea of checking in a
>>>>>>> non-polished series to 4.10, rather than exctly what the content of
>>>>>>> that series would be.
>>>>>>>
>>>>>>> In the IRL conversation that preceeded this mail, the new short-term
>>>>>>> target we discussed was:
>>>>>>> 1. A 4.10-based shim that could boot either under HVM or PVH
>>>>>>> 2. A script that would take an existing PV config, and spit out a) a
>>>>>>> bootable ISO with the shim & whatever was needed, and b) a new config
>>>>>>> that would boot the same VM, but in HVM mode with the shim
>>>>>>>
>>>>>>> The script + a 4.10 shim binary *should* allow most PV guests to boot
>>>>>>> without any changes whatsoever for most older versions of Xen.
>>>>>>>
>>>>>>> There are a number of people for whom this won't work; I think we also
>>>>>>> need to provide a way to transparently change PV guests into PVshim
>>>>>>> guests.  But that will necessarily involve significant toolstack
>>>>>>> functionality, at which point you might as well backport PVH as well.
>>>>>>
>>>>>> Yes, there will be a number of people that won't be covered by this fix,
>>>>>> including those that can't use HVM/PVH mode because VT-x isn't available
>>>>>> at all in their environment. That is the only reason to run PV today.
>>>>>> Providing a way to transparently change PV guests into PVshim guests
>>>>>> won't cover any of these cases. A more complete workaround to SP3 is
>>>>>> along the lines of https://marc.info/?l=xen-devel&m=151509740625690.
>>>>>>
>>>>>> That said, I realize that we are only trying to do the best we can in a
>>>>>> very difficult situation, with very little time in our hands. I agree
>>>>>> with Ian that we should commit something unpolished and only partially
>>>>>> reviewed soon, even though it doesn't cover a good chunk of the userbase
>>>>>> for one reason or another. Even if migration doesn't work, it will still
>>>>>> help all that don't require it. It is only a partial fix by nature
>>>>>> anyway.
>>>>>
>>>>> Can people be a bit more explicit about what they think should be done here?
>>>>>
>>>>> I'm happy to redirect effort to PVH shim if that's what the solution
>>>>> is going to be.
>>>>>
>>>>> I obviously prefer the HVM approach as it works on a broad range of Xen 
>>>>> versions
>>>>> without modification but I'm keen to get something done quickly and
>>>>> don't want to
>>>>> waste effort.
>>>>
>>>> From what I've read today, I have no reason to believe the PVH
>>>> shim won't work in HVM mode. How would the HVM-only approach
>>>> be better in that case?
>>>>
>>>> Jan
>>>
>>> I feel like I should state the obvious here. Its tested over a large
>>> data set.
>>
>> Right: if we are going to commit something unpolished and unreviewed,
>> let it be at least very well tested by the submitter. Honest question:
>> how much more dev&test we need on PVShim before we get it to similar
>> levels of confidence?
> 

> Since the primary audience for security fixes are production
> deployments of Xen where customer assets are at risk, is there an
> estimate for the percentage/size of Xen deployments where PVH (not
> only Xen 4.10) has already been deployed for production customers?
> That could give other customers more confidence in deploying PVH in
> production.
+1

I have been hearing mostly-very-positive stories around, except for the
missing pvgrub2 support. :)

But as a sysadmin who's also strongly considering to jump to 4.10 and
PVH I'd definitely like to hear more stories.

Hans

Hans

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[pedro]

On 2018-01-10 11:11, Hans van Kranenburg wrote:

> 
>> Since the primary audience for security fixes are production
>> deployments of Xen where customer assets are at risk, is there an
>> estimate for the percentage/size of Xen deployments where PVH (not
>> only Xen 4.10) has already been deployed for production customers?
>> That could give other customers more confidence in deploying PVH in
>> production.
> +1
> 
> I have been hearing mostly-very-positive stories around, except for the
> missing pvgrub2 support. :)
> 
> But as a sysadmin who's also strongly considering to jump to 4.10 and
> PVH I'd definitely like to hear more stories.
> 
> Hans

I deployed deployed Xen 4.10 PVHv2 (from Xen 4.7/4.9 PV) to a good 
number of hosts, VMs.  Not seeing anything too alarming as yet.

Some issues per email thread 'DomU not starting under pvhv2' where some 
CPUs don't appear to work for me.  Seems like these older CPUs are 
giving us problems:  cat /proc/cpuinfo | egrep -qai ' E4600 | E3110 | 
E5310 | E5320 | E5410 | E5420 | X3220 |Processor 4284|Processor 2212$| 
Q6600 | E4500 ' &&   echo "CPU not supporting PVHv2"

Still needing/wanting a solution for VMs currently running pv-grub or PV 
DomUs stuck on old distros that fail with pvh compatible kernels 
(4.??+).

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Mike Latimer]

On 01/09/2018 01:57 PM, Matt Wilson wrote:
> Let me know if you need any help with the sidecar script. Generally
> it's straightforward enough to build so I'm sure you won't have any
> trouble. Here's one that I used for local testing on my laptop in a
> CentOS-ish chroot (we have other bits responsible for this in
> EC2).

Thanks for posting the script. It's been helpful to address some
outstanding questions about this adventure. One point that I'm still
wondering about is the kernel and initrd that are added to this sidecar
ISO. Should these match the kernel and initrd of the host (dom0), or the
kernel and initrd of the guest? If it's the guest, I guess there will
(potentially) be a 1:1 ratio of sidecar ISOs to guests?

I understand the script is just an example, but one error is worth
pointing out:
>  Please excuse the cruft, including the use of legacy GRUB.
>
> ---------------------- 8< -------------------
> #!/bin/bash
> if [ $# -lt 2 ]; then
>     echo "usage: $0 xen.gz kernel.gz [initrd.img]"
>     exit 1
> fi
>
> if [ $# -eq 3 ]; then
>     INITRD=$2

    INITRD=$3

> fi

Thanks,
Mike


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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Juergen Gross]

On 09/01/18 23:11, Hans van Kranenburg wrote:
> On 01/09/2018 07:22 PM, Rich Persaud wrote:
>>>> On Jan 9, 2018, at 12:56, Stefano Stabellini <sstabellini@kernel.org> wrote:
>>>>
>>>> On Tue, 9 Jan 2018, Doug Goldstein wrote:
>>>> On 1/9/18 11:33 AM, Jan Beulich wrote:
>>>>>>>> On 09.01.18 at 18:23, <anthony@codemonkey.ws> wrote:
>>>>>> On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini
>>>>>> <sstabellini@kernel.org> wrote:
>>>>>>>>> On Tue, 9 Jan 2018, George Dunlap wrote:
>>>>>>>>> On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud <persaur@gmail.com> wrote:
>>>>>>>>> On a similarly pragmatic note: would a variation of Anthony's vixen patch
>>>>>> series be suitable for pre-PVH Xen 4.6 - 4.9?  These versions are currently 
>>>>>> documented as security-supported (Oct 2018 - July 2020).
>>>>>>>>
>>>>>>>> Hmm, Ian's mail seems to be focusing on the idea of checking in a
>>>>>>>> non-polished series to 4.10, rather than exctly what the content of
>>>>>>>> that series would be.
>>>>>>>>
>>>>>>>> In the IRL conversation that preceeded this mail, the new short-term
>>>>>>>> target we discussed was:
>>>>>>>> 1. A 4.10-based shim that could boot either under HVM or PVH
>>>>>>>> 2. A script that would take an existing PV config, and spit out a) a
>>>>>>>> bootable ISO with the shim & whatever was needed, and b) a new config
>>>>>>>> that would boot the same VM, but in HVM mode with the shim
>>>>>>>>
>>>>>>>> The script + a 4.10 shim binary *should* allow most PV guests to boot
>>>>>>>> without any changes whatsoever for most older versions of Xen.
>>>>>>>>
>>>>>>>> There are a number of people for whom this won't work; I think we also
>>>>>>>> need to provide a way to transparently change PV guests into PVshim
>>>>>>>> guests.  But that will necessarily involve significant toolstack
>>>>>>>> functionality, at which point you might as well backport PVH as well.
>>>>>>>
>>>>>>> Yes, there will be a number of people that won't be covered by this fix,
>>>>>>> including those that can't use HVM/PVH mode because VT-x isn't available
>>>>>>> at all in their environment. That is the only reason to run PV today.
>>>>>>> Providing a way to transparently change PV guests into PVshim guests
>>>>>>> won't cover any of these cases. A more complete workaround to SP3 is
>>>>>>> along the lines of https://marc.info/?l=xen-devel&m=151509740625690.
>>>>>>>
>>>>>>> That said, I realize that we are only trying to do the best we can in a
>>>>>>> very difficult situation, with very little time in our hands. I agree
>>>>>>> with Ian that we should commit something unpolished and only partially
>>>>>>> reviewed soon, even though it doesn't cover a good chunk of the userbase
>>>>>>> for one reason or another. Even if migration doesn't work, it will still
>>>>>>> help all that don't require it. It is only a partial fix by nature
>>>>>>> anyway.
>>>>>>
>>>>>> Can people be a bit more explicit about what they think should be done here?
>>>>>>
>>>>>> I'm happy to redirect effort to PVH shim if that's what the solution
>>>>>> is going to be.
>>>>>>
>>>>>> I obviously prefer the HVM approach as it works on a broad range of Xen 
>>>>>> versions
>>>>>> without modification but I'm keen to get something done quickly and
>>>>>> don't want to
>>>>>> waste effort.
>>>>>
>>>>> From what I've read today, I have no reason to believe the PVH
>>>>> shim won't work in HVM mode. How would the HVM-only approach
>>>>> be better in that case?
>>>>>
>>>>> Jan
>>>>
>>>> I feel like I should state the obvious here. Its tested over a large
>>>> data set.
>>>
>>> Right: if we are going to commit something unpolished and unreviewed,
>>> let it be at least very well tested by the submitter. Honest question:
>>> how much more dev&test we need on PVShim before we get it to similar
>>> levels of confidence?
>>
> 
>> Since the primary audience for security fixes are production
>> deployments of Xen where customer assets are at risk, is there an
>> estimate for the percentage/size of Xen deployments where PVH (not
>> only Xen 4.10) has already been deployed for production customers?
>> That could give other customers more confidence in deploying PVH in
>> production.
> +1
> 
> I have been hearing mostly-very-positive stories around, except for the
> missing pvgrub2 support. :)

https://lists.xen.org/archives/html/xen-devel/2017-11/msg01795.html

Juergen

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Roger Pau Monné]

On Tue, Jan 09, 2018 at 07:43:51PM +0000, Wei Liu wrote:
> On Mon, Jan 08, 2018 at 05:45:32PM +0000, Ian Jackson wrote:
> > AIUI we have a series for pv-in-pvh shim which is nearing completion
> > in the sense that it will have been well-tested (especially the
> > hypervisor parts) and has good functionality.  (Wei is handling the
> > assembly of this series.)
> > 
> > The series, however, needs proper review and tidying up.
> > Specifically, it needs the kind of tidying up that fixes code
> > structure and style issues that will hinder future Xen development.
> > I.e. the kind of technical debt which does not directly cause bugs now
> > but will cause trouble (including bugs) in the future.
> > 
> > IMO that kind of tidying up is definitely essential for
> > xen.git#master.  However, it is much less of an issue for Xen 4.10.
> > Xen 4.10, as a stable branch, will get much more limited further
> > development.  Failure to tidy things up there will make backporting
> > other changes more awkward but the overall impact is both lower and
> > time-bound.
> > 
> > Currently the Xen Project has no published resolution for PV guests
> > that can't be booted as, or converted to, PVH or HVM.  (And HVM guests
> > bring their own problems.)  We need to provide our users with more
> > good options as quickly as possible.
> > 
> > I would like to suggest that a good way of doing this would be to ship
> > the shim series as 4.10.1 within the next very few days.  It needs
> > some minor bugfixing (build breakage etc.) but is basically ready for
> > use.
> > 
> > Speaking as a sysadmin (even, a very conservative sysadmin many of
> > whose systems are running Debian oldstable), I have already taken a
> > decision to rapidly advance to new software, in one context, because
> > of these vulnerabilities - and take and fix whatever impact that has.
> > I think many of our users would like to make the same choice.
> > 
> > Releaseing 4.10.1 this week with pv-in-pvh support would give many of
> > our users with PV guests an immediately deployable update, even though
> > of course the version bump to get to 4.10 may be disruptive.
> > 
> > Doing this would be a departure from our uusual non-security-bug
> > process of committing changes to xen.git#staging, and then backporting
> > only after the patches have been sitting in xen.git#master for some
> > time.  It's also a departure from our usual security-bug process of
> > developing and testing and committing patches for all supported
> > versions in parallel.
> > 
> > But this is not a usual situation.  This time, we don't have the time
> > to wait.
> > 
> > Opinions ?
> > 
> 
> Anthony and others joined #xendevel to express their findings and
> opinions.
> 
> Converging the PVH and HVM solution is doable and essential in the long
> run, but merging the two series in two or three days (if we want to make
> something ready this week) is not possible. It all comes down to which
> series should we use for the temporary solution.
> 
> We discussed the test coverage of both series. It seems that the PV in
> PVH series has had in depth testing done on 4.7 and 4.10, while PV in
> HVM series has had testing done from Xen 3.4 onward with various old and
> new guests. Anthony also pointed out that PV in PVH shim won't work for
> some configurations -- there are far too many subtleties to fix without
> time and testing resources (both of which upstream lacks). These are
> rather strong arguments for the PV in HVM series, because being able to
> run on older versions of Xen and older versions of guest kernels
> provides our users with the maximum coverage.
> 
> An argument for PV in PVH series is that it has more functionalities,
> but I think migration etc are just nice-to-have's in the context of this
> security fix series.
> 
> I think providing a well tested solution to our users as soon as
> possible, even if the solution has reduced functionality, is better than
> delaying for the perfect solution.  I suggest we go with Amazon's series
> first and produce something this week, then we seek to merge the two
> solutions. Anthony has agreed to be on the hook to review future
> patches. ;-)

I think this point is moot the moment vixen starts merging code from
the pvshim branch, at which point we get some kind of Frankenstein
shim which has more functionality than the original vixen code, but
has neither been tested by Amazon nor by Citrix, ie: the worse of both
scenarios.

If the vixen series has to be merged, I think the version merged
should be the one extensively tested by Amazon, or else the testing
point in the argument above it's just not true.

Roger.

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Wei Liu]

On Wed, Jan 10, 2018 at 08:32:24AM +0000, Roger Pau Monné wrote:
> On Tue, Jan 09, 2018 at 07:43:51PM +0000, Wei Liu wrote:
> > On Mon, Jan 08, 2018 at 05:45:32PM +0000, Ian Jackson wrote:
> > > AIUI we have a series for pv-in-pvh shim which is nearing completion
> > > in the sense that it will have been well-tested (especially the
> > > hypervisor parts) and has good functionality.  (Wei is handling the
> > > assembly of this series.)
> > > 
> > > The series, however, needs proper review and tidying up.
> > > Specifically, it needs the kind of tidying up that fixes code
> > > structure and style issues that will hinder future Xen development.
> > > I.e. the kind of technical debt which does not directly cause bugs now
> > > but will cause trouble (including bugs) in the future.
> > > 
> > > IMO that kind of tidying up is definitely essential for
> > > xen.git#master.  However, it is much less of an issue for Xen 4.10.
> > > Xen 4.10, as a stable branch, will get much more limited further
> > > development.  Failure to tidy things up there will make backporting
> > > other changes more awkward but the overall impact is both lower and
> > > time-bound.
> > > 
> > > Currently the Xen Project has no published resolution for PV guests
> > > that can't be booted as, or converted to, PVH or HVM.  (And HVM guests
> > > bring their own problems.)  We need to provide our users with more
> > > good options as quickly as possible.
> > > 
> > > I would like to suggest that a good way of doing this would be to ship
> > > the shim series as 4.10.1 within the next very few days.  It needs
> > > some minor bugfixing (build breakage etc.) but is basically ready for
> > > use.
> > > 
> > > Speaking as a sysadmin (even, a very conservative sysadmin many of
> > > whose systems are running Debian oldstable), I have already taken a
> > > decision to rapidly advance to new software, in one context, because
> > > of these vulnerabilities - and take and fix whatever impact that has.
> > > I think many of our users would like to make the same choice.
> > > 
> > > Releaseing 4.10.1 this week with pv-in-pvh support would give many of
> > > our users with PV guests an immediately deployable update, even though
> > > of course the version bump to get to 4.10 may be disruptive.
> > > 
> > > Doing this would be a departure from our uusual non-security-bug
> > > process of committing changes to xen.git#staging, and then backporting
> > > only after the patches have been sitting in xen.git#master for some
> > > time.  It's also a departure from our usual security-bug process of
> > > developing and testing and committing patches for all supported
> > > versions in parallel.
> > > 
> > > But this is not a usual situation.  This time, we don't have the time
> > > to wait.
> > > 
> > > Opinions ?
> > > 
> > 
> > Anthony and others joined #xendevel to express their findings and
> > opinions.
> > 
> > Converging the PVH and HVM solution is doable and essential in the long
> > run, but merging the two series in two or three days (if we want to make
> > something ready this week) is not possible. It all comes down to which
> > series should we use for the temporary solution.
> > 
> > We discussed the test coverage of both series. It seems that the PV in
> > PVH series has had in depth testing done on 4.7 and 4.10, while PV in
> > HVM series has had testing done from Xen 3.4 onward with various old and
> > new guests. Anthony also pointed out that PV in PVH shim won't work for
> > some configurations -- there are far too many subtleties to fix without
> > time and testing resources (both of which upstream lacks). These are
> > rather strong arguments for the PV in HVM series, because being able to
> > run on older versions of Xen and older versions of guest kernels
> > provides our users with the maximum coverage.
> > 
> > An argument for PV in PVH series is that it has more functionalities,
> > but I think migration etc are just nice-to-have's in the context of this
> > security fix series.
> > 
> > I think providing a well tested solution to our users as soon as
> > possible, even if the solution has reduced functionality, is better than
> > delaying for the perfect solution.  I suggest we go with Amazon's series
> > first and produce something this week, then we seek to merge the two
> > solutions. Anthony has agreed to be on the hook to review future
> > patches. ;-)
> 
> I think this point is moot the moment vixen starts merging code from
> the pvshim branch, at which point we get some kind of Frankenstein
> shim which has more functionality than the original vixen code, but
> has neither been tested by Amazon nor by Citrix, ie: the worse of both
> scenarios.
> 
> If the vixen series has to be merged, I think the version merged
> should be the one extensively tested by Amazon, or else the testing
> point in the argument above it's just not true.
> 

Yes, if the consensus is to use the vixen series,  we should use the
well-tested patches instead of trying to merge the two implementations
in a hurry.

Wei.

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

sidecar (hvm shim) creation script

[Ian Jackson]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 733 bytes --]

The attached script works for me.  I have been testing it with a
Citrix pvshim shim series and a shim binary that Wei passed me under
the table.  It makes a bootable HVM guest config for a PV guest.

Things that I see are wrong:

 * My guest is trying to balloon up but due to the extra memory used
   by the shim it can't.  I hope Amazon's vixen series has some kind
   of bodge for this ?

 * I see this message when I create the domain:
     xc: error: ERROR: Not a Xen-ELF image: No ELF notes or '__xen_guest'
     section found: Invalid kernel
   which I hope is something to do with the shim series (which
   I also built my tools from) or the shim binary I am using.

I don't know what the default shim path should be.

Ian.


[-- Attachment #2: pvshim sidecar script --]
[-- Type: text/plain, Size: 6309 bytes --]

#!/usr/bin/perl -w
#
# usage:
#   pvshim-converter [OPTIONS] OLD-CONFIG NEW-CONFIG
#
# options:
#   --sidecars-directory DIR   default is /var/lib/xen/pvshim-sidecars
#   --shim SHIM                overrides domain config file
#   --debug                    verbose, and leaves sidecar prep dir around
#
# What we do
#
#  read existing config file using python
#  determine kernel, ramdisk and cmdline
#  use them to produce sidecar and save it under domain name
#  mess with the things that need to be messed with
#  spit out new config file

use strict;

use Getopt::Long;
use JSON;
use IO::Handle;
use POSIX;
use Fcntl qw(:flock);

our $debug;

sub runcmd {
    print STDERR "+ @_\n" if $debug;
    $!=0; $?=0; system @_ and die "$_[0]: $! $?";
}

our $shim;
our $sidecars_dir = '/var/lib/xen/pvshim-sidecars';

GetOptions('sidecars-directory=s' => \$sidecars_dir,
           'shim=s' => \$shim,
           'debug' => \$debug)
    or die "pvshim-converter: bad options\n";

@ARGV==2 or die "pvshim-converter: need old and new config filenames";

our ($in,$out) = @ARGV;

our $indata;

if ($in ne '-') {
    open I, '<', "$in" or die "open input config file: $!\n";
} else {
    open I, '<&STDIN' or die $!;
}
{
    local $/;
    $indata = <I>;
}
I->error and die $!;
close I;

open P, "-|", qw(python -c), <<END, $indata or die $!;
import sys
import json
l = {}
exec sys.argv[1] in l
for k in l.keys():
	if k.startswith("_"):
		del l[k]
print json.dumps(l)
END

our $c;

{
    local $/;
    $_ = <P>;
    $!=0; $?=0; close P or die "$! $?";
    $c = decode_json $_;
}

die "no domain name ?" unless exists $c->{name};
die "bootloader not yet supported" if $c->{bootloader};
die "no kernel" unless $c->{kernel};

our $sidecar = $c->{pvshim_sidecar_path} || "$sidecars_dir/$c->{name}.iso";
our $dmwrap = $c->{pvshim_sidecar_path} || "$sidecars_dir/$c->{name}.dm";

$shim ||= $c->{pvshim_path};
$shim ||= '/usr/local/lib/xen/boot/xen-shim';

our $shim_cmdline = $c->{pvshim_cmdline} || 'pv-shim console=xen,pv sched=null';
$shim_cmdline .= ' '.$c->{pvshim_extra} if $c->{pvshim_extra};

our $kernel_cmdline = $c->{cmdline} || '';
$kernel_cmdline .= ' root='.$c->{root} if $c->{root};
$kernel_cmdline .= ' '.$c->{extra} if $c->{extra};

print "pvshim-converter: creating sidecar in $sidecar\n";

runcmd qw(mkdir -m700 -p --), $sidecars_dir;

open L, ">", "$sidecar.lock" or die "$sidecar.lock: open $!";
flock L, LOCK_EX or die "$sidecar.lock: lock: $!";

my $sd = "$sidecar.dir";

system qw(rm -rf --), $sd;
mkdir $sd, 0700;

runcmd qw(cp --), $shim, "$sd/shim";
runcmd qw(cp --), $c->{kernel}, "$sd/kernel";
runcmd qw(cp --), $c->{ramdisk}, "$sd/ramdisk" if $c->{ramdisk};

my $grubcfg = <<END;
serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
terminal_input serial
terminal_output serial

set timeout=0

menuentry 'Xen shim' {
	insmod gzio
	insmod xzio
        multiboot (cd)/shim placeholder $shim_cmdline
        module (cd)/kernel placeholder $kernel_cmdline
        module (cd)/ramdisk
}
END

runcmd qw(mkdir -p --), "$sd/boot/grub";
open G, ">", "$sd/boot/grub/grub.cfg" or die "$sd, grub.cfg: $!";
print G $grubcfg or die $!;
close G or die $!;

unlink "$sidecar.new" or $!==ENOENT or die "$sidecar.new: rm: $!";
runcmd qw(grub-mkrescue -o), "$sidecar.new", "$sidecar.dir";
if (!stat "$sidecar.new") {
    $!==ENOENT or die "$sidecar.new: stat: $!";

    print STDERR <<END;
pvshim-converter: grub-mkrescue exited with status zero but failed to make iso.
NB that grub-mkrescue has a tendency to lie in its error messages.
END
    my $missing;
    foreach my $check (qw(xorriso mformat)) {
        $missing |= system qw(sh -c), "type $check";
    }

    if ($missing) {
        print STDERR <<END;
You seem to have some program(s) missing which grub-mkrescue depends on,
see above.  ("mformat" is normally in the package "mtools".)
Installing those programs will probably help.
END
    } else {
        print STDERR <<END;
And older grub-mkrescue has a tendency not to notice certain problems.
Maybe strace will tell you what is wrong.  :-/
END
    }
    die "pvshim-converter: grub-mkrescue did not make iso\n";
}

runcmd qw(rm -rf --), "$sidecar.dir" unless $debug;

open Q, ">", "$dmwrap.new" or die "$dmwrap: $!";
print Q <<'END_DMWRAP';
#!/bin/bash

set -x
: "$@"
set +x

newargs=()

newarg () {
    newargs+=("$1")
}

while [ $# -gt 1 ]; do
    case "$1" in
	-no-shutdown|-nodefaults|-no-user-config)
	    newarg "$1"; shift
	    ;;
	-xen-domid|-chardev|-mon|-display|-boot|-m|-machine)
	    newarg "$1"; shift
	    newarg "$1"; shift
	    ;;
        -name)
            newarg "$1"; shift
            name="$1"; shift
            newarg "$name"
            ;;
	-netdev|-cdrom)
	    : fixme
	    newarg "$1"; shift
	    newarg "$1"; shift
	    ;;
	-drive|-kernel|-initrd|-append|-vnc)
	    shift; shift
	    ;;
	-device)
	    shift
	    case "$1" in
		XXXrtl8139*)
		    newarg "-device"
		    newarg "$1"; shift
		    ;;
		*)
		    shift
		    ;;
	    esac
	    ;;
	*)
	    echo >&2 "warning: unexpected argument $1 being passed through"
	    newarg "$1"; shift
	    ;;
    esac
done

if [ "x$name" != x ]; then
    logdir=/var/log/xen
    logfile="$logdir/shim-$name.log"
    savelog "$logfile" ||:
    newarg -serial
    newarg "file:$logfile"
fi

set -x
exec /usr/local/lib/xen/bin/qemu-system-i386 "${newargs[@]}"
END_DMWRAP

chmod 0755, "$dmwrap.new" or die "$dmwrap: chmod: $!";

close Q or die $!;

rename "$sidecar.new", $sidecar or die "$sidecar: install: $!";
rename "$dmwrap.new",  $dmwrap  or die "$dmwrap: install: $!";

print STDERR <<END;
pvshim-converter: wrote qemu wrapper to $dmwrap
pvshim-converter: wrote sidecar to $sidecar
END

my $append = <<END;
builder='hvm'
type='hvm'
device_model_version='qemu-xen'
device_model_override='$dmwrap'
device_model_args_hvm=['-cdrom','$sidecar']
boot='c'
END

if ($out ne '-') {
    open O, ">", "$out.tmp" or die "open output config temp: $out.tmp: $!\n";
} else {
    open O, ">&STDOUT" or die $!;
}

print O $indata, "\n", $append or die "write output: $!";
close O or die "close output: $!";

if ($out ne '-') {
    rename "$out.tmp", $out or die "install output: $!";
    print STDERR "pvshim-converter: wrote new guest config to $out\n";
} else {
    print STDERR "pvshim-converter: wrote new guest config to stdout\n";
}

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

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

Re: sidecar (hvm shim) creation script

[Wei Liu]

On Wed, Jan 10, 2018 at 01:07:33PM +0000, Ian Jackson wrote:
> The attached script works for me.  I have been testing it with a
> Citrix pvshim shim series and a shim binary that Wei passed me under
> the table.  It makes a bootable HVM guest config for a PV guest.
> 
> Things that I see are wrong:
> 
>  * My guest is trying to balloon up but due to the extra memory used
>    by the shim it can't.  I hope Amazon's vixen series has some kind
>    of bodge for this ?

I don't think they do anything special in that regard. They probably
don't use ballooning or don't care.

> 
>  * I see this message when I create the domain:
>      xc: error: ERROR: Not a Xen-ELF image: No ELF notes or '__xen_guest'
>      section found: Invalid kernel
>    which I hope is something to do with the shim series (which
>    I also built my tools from) or the shim binary I am using.
> 

That's some extraneous output. Not critical.

> I don't know what the default shim path should be.
> 

Along side the hvmloader? We can treat it as a firmware.

Wei.

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

Re: sidecar (hvm shim) creation script

[Anthony Liguori]

On Wed, Jan 10, 2018 at 5:07 AM, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
> The attached script works for me.  I have been testing it with a
> Citrix pvshim shim series and a shim binary that Wei passed me under
> the table.  It makes a bootable HVM guest config for a PV guest.
>
> Things that I see are wrong:
>
>  * My guest is trying to balloon up but due to the extra memory used
>    by the shim it can't.  I hope Amazon's vixen series has some kind
>    of bodge for this ?

Max memory gets set in dom0 construction so the guest will try every
minute but fail.  It results in spurious debug printks if you have guest
loglvl set to debug but no real harm otherwise.

Regards,

Anthony Liguori

>  * I see this message when I create the domain:
>      xc: error: ERROR: Not a Xen-ELF image: No ELF notes or '__xen_guest'
>      section found: Invalid kernel
>    which I hope is something to do with the shim series (which
>    I also built my tools from) or the shim binary I am using.
>
> I don't know what the default shim path should be.
>
> Ian.
>
>
> #!/usr/bin/perl -w
> #
> # usage:
> #   pvshim-converter [OPTIONS] OLD-CONFIG NEW-CONFIG
> #
> # options:
> #   --sidecars-directory DIR   default is /var/lib/xen/pvshim-sidecars
> #   --shim SHIM                overrides domain config file
> #   --debug                    verbose, and leaves sidecar prep dir around
> #
> # What we do
> #
> #  read existing config file using python
> #  determine kernel, ramdisk and cmdline
> #  use them to produce sidecar and save it under domain name
> #  mess with the things that need to be messed with
> #  spit out new config file
>
> use strict;
>
> use Getopt::Long;
> use JSON;
> use IO::Handle;
> use POSIX;
> use Fcntl qw(:flock);
>
> our $debug;
>
> sub runcmd {
>     print STDERR "+ @_\n" if $debug;
>     $!=0; $?=0; system @_ and die "$_[0]: $! $?";
> }
>
> our $shim;
> our $sidecars_dir = '/var/lib/xen/pvshim-sidecars';
>
> GetOptions('sidecars-directory=s' => \$sidecars_dir,
>            'shim=s' => \$shim,
>            'debug' => \$debug)
>     or die "pvshim-converter: bad options\n";
>
> @ARGV==2 or die "pvshim-converter: need old and new config filenames";
>
> our ($in,$out) = @ARGV;
>
> our $indata;
>
> if ($in ne '-') {
>     open I, '<', "$in" or die "open input config file: $!\n";
> } else {
>     open I, '<&STDIN' or die $!;
> }
> {
>     local $/;
>     $indata = <I>;
> }
> I->error and die $!;
> close I;
>
> open P, "-|", qw(python -c), <<END, $indata or die $!;
> import sys
> import json
> l = {}
> exec sys.argv[1] in l
> for k in l.keys():
>         if k.startswith("_"):
>                 del l[k]
> print json.dumps(l)
> END
>
> our $c;
>
> {
>     local $/;
>     $_ = <P>;
>     $!=0; $?=0; close P or die "$! $?";
>     $c = decode_json $_;
> }
>
> die "no domain name ?" unless exists $c->{name};
> die "bootloader not yet supported" if $c->{bootloader};
> die "no kernel" unless $c->{kernel};
>
> our $sidecar = $c->{pvshim_sidecar_path} || "$sidecars_dir/$c->{name}.iso";
> our $dmwrap = $c->{pvshim_sidecar_path} || "$sidecars_dir/$c->{name}.dm";
>
> $shim ||= $c->{pvshim_path};
> $shim ||= '/usr/local/lib/xen/boot/xen-shim';
>
> our $shim_cmdline = $c->{pvshim_cmdline} || 'pv-shim console=xen,pv sched=null';
> $shim_cmdline .= ' '.$c->{pvshim_extra} if $c->{pvshim_extra};
>
> our $kernel_cmdline = $c->{cmdline} || '';
> $kernel_cmdline .= ' root='.$c->{root} if $c->{root};
> $kernel_cmdline .= ' '.$c->{extra} if $c->{extra};
>
> print "pvshim-converter: creating sidecar in $sidecar\n";
>
> runcmd qw(mkdir -m700 -p --), $sidecars_dir;
>
> open L, ">", "$sidecar.lock" or die "$sidecar.lock: open $!";
> flock L, LOCK_EX or die "$sidecar.lock: lock: $!";
>
> my $sd = "$sidecar.dir";
>
> system qw(rm -rf --), $sd;
> mkdir $sd, 0700;
>
> runcmd qw(cp --), $shim, "$sd/shim";
> runcmd qw(cp --), $c->{kernel}, "$sd/kernel";
> runcmd qw(cp --), $c->{ramdisk}, "$sd/ramdisk" if $c->{ramdisk};
>
> my $grubcfg = <<END;
> serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
> terminal_input serial
> terminal_output serial
>
> set timeout=0
>
> menuentry 'Xen shim' {
>         insmod gzio
>         insmod xzio
>         multiboot (cd)/shim placeholder $shim_cmdline
>         module (cd)/kernel placeholder $kernel_cmdline
>         module (cd)/ramdisk
> }
> END
>
> runcmd qw(mkdir -p --), "$sd/boot/grub";
> open G, ">", "$sd/boot/grub/grub.cfg" or die "$sd, grub.cfg: $!";
> print G $grubcfg or die $!;
> close G or die $!;
>
> unlink "$sidecar.new" or $!==ENOENT or die "$sidecar.new: rm: $!";
> runcmd qw(grub-mkrescue -o), "$sidecar.new", "$sidecar.dir";
> if (!stat "$sidecar.new") {
>     $!==ENOENT or die "$sidecar.new: stat: $!";
>
>     print STDERR <<END;
> pvshim-converter: grub-mkrescue exited with status zero but failed to make iso.
> NB that grub-mkrescue has a tendency to lie in its error messages.
> END
>     my $missing;
>     foreach my $check (qw(xorriso mformat)) {
>         $missing |= system qw(sh -c), "type $check";
>     }
>
>     if ($missing) {
>         print STDERR <<END;
> You seem to have some program(s) missing which grub-mkrescue depends on,
> see above.  ("mformat" is normally in the package "mtools".)
> Installing those programs will probably help.
> END
>     } else {
>         print STDERR <<END;
> And older grub-mkrescue has a tendency not to notice certain problems.
> Maybe strace will tell you what is wrong.  :-/
> END
>     }
>     die "pvshim-converter: grub-mkrescue did not make iso\n";
> }
>
> runcmd qw(rm -rf --), "$sidecar.dir" unless $debug;
>
> open Q, ">", "$dmwrap.new" or die "$dmwrap: $!";
> print Q <<'END_DMWRAP';
> #!/bin/bash
>
> set -x
> : "$@"
> set +x
>
> newargs=()
>
> newarg () {
>     newargs+=("$1")
> }
>
> while [ $# -gt 1 ]; do
>     case "$1" in
>         -no-shutdown|-nodefaults|-no-user-config)
>             newarg "$1"; shift
>             ;;
>         -xen-domid|-chardev|-mon|-display|-boot|-m|-machine)
>             newarg "$1"; shift
>             newarg "$1"; shift
>             ;;
>         -name)
>             newarg "$1"; shift
>             name="$1"; shift
>             newarg "$name"
>             ;;
>         -netdev|-cdrom)
>             : fixme
>             newarg "$1"; shift
>             newarg "$1"; shift
>             ;;
>         -drive|-kernel|-initrd|-append|-vnc)
>             shift; shift
>             ;;
>         -device)
>             shift
>             case "$1" in
>                 XXXrtl8139*)
>                     newarg "-device"
>                     newarg "$1"; shift
>                     ;;
>                 *)
>                     shift
>                     ;;
>             esac
>             ;;
>         *)
>             echo >&2 "warning: unexpected argument $1 being passed through"
>             newarg "$1"; shift
>             ;;
>     esac
> done
>
> if [ "x$name" != x ]; then
>     logdir=/var/log/xen
>     logfile="$logdir/shim-$name.log"
>     savelog "$logfile" ||:
>     newarg -serial
>     newarg "file:$logfile"
> fi
>
> set -x
> exec /usr/local/lib/xen/bin/qemu-system-i386 "${newargs[@]}"
> END_DMWRAP
>
> chmod 0755, "$dmwrap.new" or die "$dmwrap: chmod: $!";
>
> close Q or die $!;
>
> rename "$sidecar.new", $sidecar or die "$sidecar: install: $!";
> rename "$dmwrap.new",  $dmwrap  or die "$dmwrap: install: $!";
>
> print STDERR <<END;
> pvshim-converter: wrote qemu wrapper to $dmwrap
> pvshim-converter: wrote sidecar to $sidecar
> END
>
> my $append = <<END;
> builder='hvm'
> type='hvm'
> device_model_version='qemu-xen'
> device_model_override='$dmwrap'
> device_model_args_hvm=['-cdrom','$sidecar']
> boot='c'
> END
>
> if ($out ne '-') {
>     open O, ">", "$out.tmp" or die "open output config temp: $out.tmp: $!\n";
> } else {
>     open O, ">&STDOUT" or die $!;
> }
>
> print O $indata, "\n", $append or die "write output: $!";
> close O or die "close output: $!";
>
> if ($out ne '-') {
>     rename "$out.tmp", $out or die "install output: $!";
>     print STDERR "pvshim-converter: wrote new guest config to $out\n";
> } else {
>     print STDERR "pvshim-converter: wrote new guest config to stdout\n";
> }
>
> _______________________________________________
> 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: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Anthony Liguori]

On Wed, Jan 10, 2018 at 4:27 AM, Wei Liu <wei.liu2@citrix.com> wrote:
> On Wed, Jan 10, 2018 at 08:32:24AM +0000, Roger Pau Monné wrote:
>> On Tue, Jan 09, 2018 at 07:43:51PM +0000, Wei Liu wrote:
>> > On Mon, Jan 08, 2018 at 05:45:32PM +0000, Ian Jackson wrote:
>> > > AIUI we have a series for pv-in-pvh shim which is nearing completion
>> > > in the sense that it will have been well-tested (especially the
>> > > hypervisor parts) and has good functionality.  (Wei is handling the
>> > > assembly of this series.)
>> > >
>> > > The series, however, needs proper review and tidying up.
>> > > Specifically, it needs the kind of tidying up that fixes code
>> > > structure and style issues that will hinder future Xen development.
>> > > I.e. the kind of technical debt which does not directly cause bugs now
>> > > but will cause trouble (including bugs) in the future.
>> > >
>> > > IMO that kind of tidying up is definitely essential for
>> > > xen.git#master.  However, it is much less of an issue for Xen 4.10.
>> > > Xen 4.10, as a stable branch, will get much more limited further
>> > > development.  Failure to tidy things up there will make backporting
>> > > other changes more awkward but the overall impact is both lower and
>> > > time-bound.
>> > >
>> > > Currently the Xen Project has no published resolution for PV guests
>> > > that can't be booted as, or converted to, PVH or HVM.  (And HVM guests
>> > > bring their own problems.)  We need to provide our users with more
>> > > good options as quickly as possible.
>> > >
>> > > I would like to suggest that a good way of doing this would be to ship
>> > > the shim series as 4.10.1 within the next very few days.  It needs
>> > > some minor bugfixing (build breakage etc.) but is basically ready for
>> > > use.
>> > >
>> > > Speaking as a sysadmin (even, a very conservative sysadmin many of
>> > > whose systems are running Debian oldstable), I have already taken a
>> > > decision to rapidly advance to new software, in one context, because
>> > > of these vulnerabilities - and take and fix whatever impact that has.
>> > > I think many of our users would like to make the same choice.
>> > >
>> > > Releaseing 4.10.1 this week with pv-in-pvh support would give many of
>> > > our users with PV guests an immediately deployable update, even though
>> > > of course the version bump to get to 4.10 may be disruptive.
>> > >
>> > > Doing this would be a departure from our uusual non-security-bug
>> > > process of committing changes to xen.git#staging, and then backporting
>> > > only after the patches have been sitting in xen.git#master for some
>> > > time.  It's also a departure from our usual security-bug process of
>> > > developing and testing and committing patches for all supported
>> > > versions in parallel.
>> > >
>> > > But this is not a usual situation.  This time, we don't have the time
>> > > to wait.
>> > >
>> > > Opinions ?
>> > >
>> >
>> > Anthony and others joined #xendevel to express their findings and
>> > opinions.
>> >
>> > Converging the PVH and HVM solution is doable and essential in the long
>> > run, but merging the two series in two or three days (if we want to make
>> > something ready this week) is not possible. It all comes down to which
>> > series should we use for the temporary solution.
>> >
>> > We discussed the test coverage of both series. It seems that the PV in
>> > PVH series has had in depth testing done on 4.7 and 4.10, while PV in
>> > HVM series has had testing done from Xen 3.4 onward with various old and
>> > new guests. Anthony also pointed out that PV in PVH shim won't work for
>> > some configurations -- there are far too many subtleties to fix without
>> > time and testing resources (both of which upstream lacks). These are
>> > rather strong arguments for the PV in HVM series, because being able to
>> > run on older versions of Xen and older versions of guest kernels
>> > provides our users with the maximum coverage.
>> >
>> > An argument for PV in PVH series is that it has more functionalities,
>> > but I think migration etc are just nice-to-have's in the context of this
>> > security fix series.
>> >
>> > I think providing a well tested solution to our users as soon as
>> > possible, even if the solution has reduced functionality, is better than
>> > delaying for the perfect solution.  I suggest we go with Amazon's series
>> > first and produce something this week, then we seek to merge the two
>> > solutions. Anthony has agreed to be on the hook to review future
>> > patches. ;-)
>>
>> I think this point is moot the moment vixen starts merging code from
>> the pvshim branch, at which point we get some kind of Frankenstein
>> shim which has more functionality than the original vixen code, but
>> has neither been tested by Amazon nor by Citrix, ie: the worse of both
>> scenarios.
>>
>> If the vixen series has to be merged, I think the version merged
>> should be the one extensively tested by Amazon, or else the testing
>> point in the argument above it's just not true.
>>
>
> Yes, if the consensus is to use the vixen series,  we should use the
> well-tested patches instead of trying to merge the two implementations
> in a hurry.

I agree, and that's v1.

Regards,

Anthony Liguori

> Wei.
>
> _______________________________________________
> 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: sidecar (hvm shim) creation script

[Ian Jackson]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 121 bytes --]

Here is the converter script where I just got my guest to boot with
the Vixen shim, as built and provided by Wei.

Ian.


[-- Attachment #2: for vixen --]
[-- Type: text/plain, Size: 6330 bytes --]

#!/usr/bin/perl -w
#
# usage:
#   pvshim-converter [OPTIONS] OLD-CONFIG NEW-CONFIG
#
# options:
#   --sidecars-directory DIR   default is /var/lib/xen/pvshim-sidecars
#   --shim SHIM                overrides domain config file
#   --debug                    verbose, and leaves sidecar prep dir around
#
# What we do
#
#  read existing config file using python
#  determine kernel, ramdisk and cmdline
#  use them to produce sidecar and save it under domain name
#  mess with the things that need to be messed with
#  spit out new config file

use strict;

use Getopt::Long;
use JSON;
use IO::Handle;
use POSIX;
use Fcntl qw(:flock);

our $debug;

sub runcmd {
    print STDERR "+ @_\n" if $debug;
    $!=0; $?=0; system @_ and die "$_[0]: $! $?";
}

our $shim;
our $sidecars_dir = '/var/lib/xen/pvshim-sidecars';

GetOptions('sidecars-directory=s' => \$sidecars_dir,
           'shim=s' => \$shim,
           'debug' => \$debug)
    or die "pvshim-converter: bad options\n";

@ARGV==2 or die "pvshim-converter: need old and new config filenames";

our ($in,$out) = @ARGV;

our $indata;

if ($in ne '-') {
    open I, '<', "$in" or die "open input config file: $!\n";
} else {
    open I, '<&STDIN' or die $!;
}
{
    local $/;
    $indata = <I>;
}
I->error and die $!;
close I;

open P, "-|", qw(python -c), <<END, $indata or die $!;
import sys
import json
l = {}
exec sys.argv[1] in l
for k in l.keys():
	if k.startswith("_"):
		del l[k]
print json.dumps(l)
END

our $c;

{
    local $/;
    $_ = <P>;
    $!=0; $?=0; close P or die "$! $?";
    $c = decode_json $_;
}

die "no domain name ?" unless exists $c->{name};
die "bootloader not yet supported" if $c->{bootloader};
die "no kernel" unless $c->{kernel};

our $sidecar = $c->{pvshim_sidecar_path} || "$sidecars_dir/$c->{name}.iso";
our $dmwrap = $c->{pvshim_sidecar_path} || "$sidecars_dir/$c->{name}.dm";

$shim ||= $c->{pvshim_path};
$shim ||= '/usr/local/lib/xen/boot/xen-shim';

our $shim_cmdline = $c->{pvshim_cmdline} || 'console=com1 com1=115200n1 loglvl=all guest_loglvl=all';
$shim_cmdline .= ' '.$c->{pvshim_extra} if $c->{pvshim_extra};

our $kernel_cmdline = $c->{cmdline} || '';
$kernel_cmdline .= ' root='.$c->{root} if $c->{root};
$kernel_cmdline .= ' '.$c->{extra} if $c->{extra};

print "pvshim-converter: creating sidecar in $sidecar\n";

runcmd qw(mkdir -m700 -p --), $sidecars_dir;

open L, ">", "$sidecar.lock" or die "$sidecar.lock: open $!";
flock L, LOCK_EX or die "$sidecar.lock: lock: $!";

my $sd = "$sidecar.dir";

system qw(rm -rf --), $sd;
mkdir $sd, 0700;

runcmd qw(cp --), $shim, "$sd/shim";
runcmd qw(cp --), $c->{kernel}, "$sd/kernel";
runcmd qw(cp --), $c->{ramdisk}, "$sd/ramdisk" if $c->{ramdisk};

my $grubcfg = <<END;
serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
terminal_input serial
terminal_output serial

set timeout=1

menuentry 'Xen shim' {
	insmod gzio
	insmod xzio
        multiboot (cd)/shim placeholder $shim_cmdline
        module (cd)/kernel placeholder $kernel_cmdline
        module (cd)/ramdisk
}
END

runcmd qw(mkdir -p --), "$sd/boot/grub";
open G, ">", "$sd/boot/grub/grub.cfg" or die "$sd, grub.cfg: $!";
print G $grubcfg or die $!;
close G or die $!;

unlink "$sidecar.new" or $!==ENOENT or die "$sidecar.new: rm: $!";
runcmd qw(grub-mkrescue -o), "$sidecar.new", "$sidecar.dir";
if (!stat "$sidecar.new") {
    $!==ENOENT or die "$sidecar.new: stat: $!";

    print STDERR <<END;
pvshim-converter: grub-mkrescue exited with status zero but failed to make iso.
NB that grub-mkrescue has a tendency to lie in its error messages.
END
    my $missing;
    foreach my $check (qw(xorriso mformat)) {
        $missing |= system qw(sh -c), "type $check";
    }

    if ($missing) {
        print STDERR <<END;
You seem to have some program(s) missing which grub-mkrescue depends on,
see above.  ("mformat" is normally in the package "mtools".)
Installing those programs will probably help.
END
    } else {
        print STDERR <<END;
And older grub-mkrescue has a tendency not to notice certain problems.
Maybe strace will tell you what is wrong.  :-/
END
    }
    die "pvshim-converter: grub-mkrescue did not make iso\n";
}

runcmd qw(rm -rf --), "$sidecar.dir" unless $debug;

open Q, ">", "$dmwrap.new" or die "$dmwrap: $!";
print Q <<'END_DMWRAP';
#!/bin/bash

set -x
: "$@"
set +x

newargs=()

newarg () {
    newargs+=("$1")
}

while [ $# -gt 1 ]; do
    case "$1" in
	-no-shutdown|-nodefaults|-no-user-config)
	    newarg "$1"; shift
	    ;;
	-xen-domid|-chardev|-mon|-display|-boot|-m|-machine)
	    newarg "$1"; shift
	    newarg "$1"; shift
	    ;;
        -name)
            newarg "$1"; shift
            name="$1"; shift
            newarg "$name"
            ;;
	-netdev|-cdrom)
	    : fixme
	    newarg "$1"; shift
	    newarg "$1"; shift
	    ;;
	-drive|-kernel|-initrd|-append|-vnc)
	    shift; shift
	    ;;
	-device)
	    shift
	    case "$1" in
		XXXrtl8139*)
		    newarg "-device"
		    newarg "$1"; shift
		    ;;
		*)
		    shift
		    ;;
	    esac
	    ;;
	*)
	    echo >&2 "warning: unexpected argument $1 being passed through"
	    newarg "$1"; shift
	    ;;
    esac
done

if [ "x$name" != x ]; then
    logdir=/var/log/xen
    logfile="$logdir/shim-$name.log"
    savelog "$logfile" ||:
    newarg -serial
    newarg "file:$logfile"
fi

set -x
exec /usr/local/lib/xen/bin/qemu-system-i386 "${newargs[@]}"
END_DMWRAP

chmod 0755, "$dmwrap.new" or die "$dmwrap: chmod: $!";

close Q or die $!;

rename "$sidecar.new", $sidecar or die "$sidecar: install: $!";
rename "$dmwrap.new",  $dmwrap  or die "$dmwrap: install: $!";

print STDERR <<END;
pvshim-converter: wrote qemu wrapper to $dmwrap
pvshim-converter: wrote sidecar to $sidecar
END

my $append = <<END;
builder='hvm'
type='hvm'
device_model_version='qemu-xen'
device_model_override='$dmwrap'
device_model_args_hvm=['-cdrom','$sidecar']
boot='c'
END

if ($out ne '-') {
    open O, ">", "$out.tmp" or die "open output config temp: $out.tmp: $!\n";
} else {
    open O, ">&STDOUT" or die $!;
}

print O $indata, "\n", $append or die "write output: $!";
close O or die "close output: $!";

if ($out ne '-') {
    rename "$out.tmp", $out or die "install output: $!";
    print STDERR "pvshim-converter: wrote new guest config to $out\n";
} else {
    print STDERR "pvshim-converter: wrote new guest config to stdout\n";
}

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

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

Re: sidecar (hvm shim) creation script

[Ian Jackson]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 334 bytes --]

Ian Jackson writes ("Re: sidecar (hvm shim) creation script"):
> Here is the converter script where I just got my guest to boot with
> the Vixen shim, as built and provided by Wei.

And here is one which handles the guest console correctly.  Vixen
sends the L2 guest console to the emulated serial, along with the
shim's own output.


[-- Attachment #2: for vixen, fixed the console --]
[-- Type: text/plain, Size: 6350 bytes --]

#!/usr/bin/perl -w
#
# usage:
#   pvshim-converter [OPTIONS] OLD-CONFIG NEW-CONFIG
#
# options:
#   --sidecars-directory DIR   default is /var/lib/xen/pvshim-sidecars
#   --shim SHIM                overrides domain config file
#   --debug                    verbose, and leaves sidecar prep dir around
#
# What we do
#
#  read existing config file using python
#  determine kernel, ramdisk and cmdline
#  use them to produce sidecar and save it under domain name
#  mess with the things that need to be messed with
#  spit out new config file

use strict;

use Getopt::Long;
use JSON;
use IO::Handle;
use POSIX;
use Fcntl qw(:flock);

our $debug;

sub runcmd {
    print STDERR "+ @_\n" if $debug;
    $!=0; $?=0; system @_ and die "$_[0]: $! $?";
}

our $shim;
our $sidecars_dir = '/var/lib/xen/pvshim-sidecars';

GetOptions('sidecars-directory=s' => \$sidecars_dir,
           'shim=s' => \$shim,
           'debug' => \$debug)
    or die "pvshim-converter: bad options\n";

@ARGV==2 or die "pvshim-converter: need old and new config filenames";

our ($in,$out) = @ARGV;

our $indata;

if ($in ne '-') {
    open I, '<', "$in" or die "open input config file: $!\n";
} else {
    open I, '<&STDIN' or die $!;
}
{
    local $/;
    $indata = <I>;
}
I->error and die $!;
close I;

open P, "-|", qw(python -c), <<END, $indata or die $!;
import sys
import json
l = {}
exec sys.argv[1] in l
for k in l.keys():
	if k.startswith("_"):
		del l[k]
print json.dumps(l)
END

our $c;

{
    local $/;
    $_ = <P>;
    $!=0; $?=0; close P or die "$! $?";
    $c = decode_json $_;
}

die "no domain name ?" unless exists $c->{name};
die "bootloader not yet supported" if $c->{bootloader};
die "no kernel" unless $c->{kernel};

our $sidecar = $c->{pvshim_sidecar_path} || "$sidecars_dir/$c->{name}.iso";
our $dmwrap = $c->{pvshim_sidecar_path} || "$sidecars_dir/$c->{name}.dm";

$shim ||= $c->{pvshim_path};
$shim ||= '/usr/local/lib/xen/boot/xen-shim';

our $shim_cmdline = $c->{pvshim_cmdline} || 'console=com1 com1=115200n1 loglvl=all guest_loglvl=all';
$shim_cmdline .= ' '.$c->{pvshim_extra} if $c->{pvshim_extra};

our $kernel_cmdline = $c->{cmdline} || '';
$kernel_cmdline .= ' root='.$c->{root} if $c->{root};
$kernel_cmdline .= ' '.$c->{extra} if $c->{extra};

print "pvshim-converter: creating sidecar in $sidecar\n";

runcmd qw(mkdir -m700 -p --), $sidecars_dir;

open L, ">", "$sidecar.lock" or die "$sidecar.lock: open $!";
flock L, LOCK_EX or die "$sidecar.lock: lock: $!";

my $sd = "$sidecar.dir";

system qw(rm -rf --), $sd;
mkdir $sd, 0700;

runcmd qw(cp --), $shim, "$sd/shim";
runcmd qw(cp --), $c->{kernel}, "$sd/kernel";
runcmd qw(cp --), $c->{ramdisk}, "$sd/ramdisk" if $c->{ramdisk};

my $grubcfg = <<END;
serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
terminal_input serial
terminal_output serial

set timeout=0

menuentry 'Xen shim' {
	insmod gzio
	insmod xzio
        multiboot (cd)/shim placeholder $shim_cmdline
        module (cd)/kernel placeholder $kernel_cmdline
        module (cd)/ramdisk
}
END

runcmd qw(mkdir -p --), "$sd/boot/grub";
open G, ">", "$sd/boot/grub/grub.cfg" or die "$sd, grub.cfg: $!";
print G $grubcfg or die $!;
close G or die $!;

unlink "$sidecar.new" or $!==ENOENT or die "$sidecar.new: rm: $!";
runcmd qw(grub-mkrescue -o), "$sidecar.new", "$sidecar.dir";
if (!stat "$sidecar.new") {
    $!==ENOENT or die "$sidecar.new: stat: $!";

    print STDERR <<END;
pvshim-converter: grub-mkrescue exited with status zero but failed to make iso.
NB that grub-mkrescue has a tendency to lie in its error messages.
END
    my $missing;
    foreach my $check (qw(xorriso mformat)) {
        $missing |= system qw(sh -c), "type $check";
    }

    if ($missing) {
        print STDERR <<END;
You seem to have some program(s) missing which grub-mkrescue depends on,
see above.  ("mformat" is normally in the package "mtools".)
Installing those programs will probably help.
END
    } else {
        print STDERR <<END;
And older grub-mkrescue has a tendency not to notice certain problems.
Maybe strace will tell you what is wrong.  :-/
END
    }
    die "pvshim-converter: grub-mkrescue did not make iso\n";
}

runcmd qw(rm -rf --), "$sidecar.dir" unless $debug;

open Q, ">", "$dmwrap.new" or die "$dmwrap: $!";
print Q <<'END_DMWRAP';
#!/bin/bash

set -x
: "$@"
set +x

newargs=()

newarg () {
    newargs+=("$1")
}

while [ $# -gt 1 ]; do
    case "$1" in
	-no-shutdown|-nodefaults|-no-user-config)
	    newarg "$1"; shift
	    ;;
	-xen-domid|-chardev|-mon|-display|-boot|-m|-machine)
	    newarg "$1"; shift
	    newarg "$1"; shift
	    ;;
        -name)
            newarg "$1"; shift
            name="$1"; shift
            newarg "$name"
            ;;
	-netdev|-cdrom)
	    : fixme
	    newarg "$1"; shift
	    newarg "$1"; shift
	    ;;
	-drive|-kernel|-initrd|-append|-vnc)
	    shift; shift
	    ;;
	-device)
	    shift
	    case "$1" in
		XXXrtl8139*)
		    newarg "-device"
		    newarg "$1"; shift
		    ;;
		*)
		    shift
		    ;;
	    esac
	    ;;
	*)
	    echo >&2 "warning: unexpected argument $1 being passed through"
	    newarg "$1"; shift
	    ;;
    esac
done

#if [ "x$name" != x ]; then
#    logdir=/var/log/xen
#    logfile="$logdir/shim-$name.log"
#    savelog "$logfile" ||:
#    newarg -serial
#    newarg "file:$logfile"
#fi

set -x
exec /usr/local/lib/xen/bin/qemu-system-i386 "${newargs[@]}"
END_DMWRAP

chmod 0755, "$dmwrap.new" or die "$dmwrap: chmod: $!";

close Q or die $!;

rename "$sidecar.new", $sidecar or die "$sidecar: install: $!";
rename "$dmwrap.new",  $dmwrap  or die "$dmwrap: install: $!";

print STDERR <<END;
pvshim-converter: wrote qemu wrapper to $dmwrap
pvshim-converter: wrote sidecar to $sidecar
END

my $append = <<END;
builder='hvm'
type='hvm'
device_model_version='qemu-xen'
device_model_override='$dmwrap'
device_model_args_hvm=['-cdrom','$sidecar']
boot='c'
serial='pty'
END

if ($out ne '-') {
    open O, ">", "$out.tmp" or die "open output config temp: $out.tmp: $!\n";
} else {
    open O, ">&STDOUT" or die $!;
}

print O $indata, "\n", $append or die "write output: $!";
close O or die "close output: $!";

if ($out ne '-') {
    rename "$out.tmp", $out or die "install output: $!";
    print STDERR "pvshim-converter: wrote new guest config to $out\n";
} else {
    print STDERR "pvshim-converter: wrote new guest config to stdout\n";
}

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

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

Re: sidecar (hvm shim) creation script

[Ian Jackson]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 258 bytes --]

Ian Jackson writes ("Re: sidecar (hvm shim) creation script"):
> And here is one which handles the guest console correctly.  Vixen
> sends the L2 guest console to the emulated serial, along with the
> shim's own output.

Some debugging stuff removed again.


[-- Attachment #2: this time for real --]
[-- Type: text/plain, Size: 6322 bytes --]

#!/usr/bin/perl -w
#
# usage:
#   pvshim-converter [OPTIONS] OLD-CONFIG NEW-CONFIG
#
# options:
#   --sidecars-directory DIR   default is /var/lib/xen/pvshim-sidecars
#   --shim SHIM                overrides domain config file
#   --debug                    verbose, and leaves sidecar prep dir around
#
# What we do
#
#  read existing config file using python
#  determine kernel, ramdisk and cmdline
#  use them to produce sidecar and save it under domain name
#  mess with the things that need to be messed with
#  spit out new config file

use strict;

use Getopt::Long;
use JSON;
use IO::Handle;
use POSIX;
use Fcntl qw(:flock);

our $debug;

sub runcmd {
    print STDERR "+ @_\n" if $debug;
    $!=0; $?=0; system @_ and die "$_[0]: $! $?";
}

our $shim;
our $sidecars_dir = '/var/lib/xen/pvshim-sidecars';

GetOptions('sidecars-directory=s' => \$sidecars_dir,
           'shim=s' => \$shim,
           'debug' => \$debug)
    or die "pvshim-converter: bad options\n";

@ARGV==2 or die "pvshim-converter: need old and new config filenames";

our ($in,$out) = @ARGV;

our $indata;

if ($in ne '-') {
    open I, '<', "$in" or die "open input config file: $!\n";
} else {
    open I, '<&STDIN' or die $!;
}
{
    local $/;
    $indata = <I>;
}
I->error and die $!;
close I;

open P, "-|", qw(python -c), <<END, $indata or die $!;
import sys
import json
l = {}
exec sys.argv[1] in l
for k in l.keys():
	if k.startswith("_"):
		del l[k]
print json.dumps(l)
END

our $c;

{
    local $/;
    $_ = <P>;
    $!=0; $?=0; close P or die "$! $?";
    $c = decode_json $_;
}

die "no domain name ?" unless exists $c->{name};
die "bootloader not yet supported" if $c->{bootloader};
die "no kernel" unless $c->{kernel};

our $sidecar = $c->{pvshim_sidecar_path} || "$sidecars_dir/$c->{name}.iso";
our $dmwrap = $c->{pvshim_sidecar_path} || "$sidecars_dir/$c->{name}.dm";

$shim ||= $c->{pvshim_path};
$shim ||= '/usr/local/lib/xen/boot/xen-shim';

our $shim_cmdline = $c->{pvshim_cmdline} || 'console=com1 com1=115200n1';
$shim_cmdline .= ' '.$c->{pvshim_extra} if $c->{pvshim_extra};

our $kernel_cmdline = $c->{cmdline} || '';
$kernel_cmdline .= ' root='.$c->{root} if $c->{root};
$kernel_cmdline .= ' '.$c->{extra} if $c->{extra};

print "pvshim-converter: creating sidecar in $sidecar\n";

runcmd qw(mkdir -m700 -p --), $sidecars_dir;

open L, ">", "$sidecar.lock" or die "$sidecar.lock: open $!";
flock L, LOCK_EX or die "$sidecar.lock: lock: $!";

my $sd = "$sidecar.dir";

system qw(rm -rf --), $sd;
mkdir $sd, 0700;

runcmd qw(cp --), $shim, "$sd/shim";
runcmd qw(cp --), $c->{kernel}, "$sd/kernel";
runcmd qw(cp --), $c->{ramdisk}, "$sd/ramdisk" if $c->{ramdisk};

my $grubcfg = <<END;
serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
terminal_input serial
terminal_output serial

set timeout=0

menuentry 'Xen shim' {
	insmod gzio
	insmod xzio
        multiboot (cd)/shim placeholder $shim_cmdline
        module (cd)/kernel placeholder $kernel_cmdline
        module (cd)/ramdisk
}
END

runcmd qw(mkdir -p --), "$sd/boot/grub";
open G, ">", "$sd/boot/grub/grub.cfg" or die "$sd, grub.cfg: $!";
print G $grubcfg or die $!;
close G or die $!;

unlink "$sidecar.new" or $!==ENOENT or die "$sidecar.new: rm: $!";
runcmd qw(grub-mkrescue -o), "$sidecar.new", "$sidecar.dir";
if (!stat "$sidecar.new") {
    $!==ENOENT or die "$sidecar.new: stat: $!";

    print STDERR <<END;
pvshim-converter: grub-mkrescue exited with status zero but failed to make iso.
NB that grub-mkrescue has a tendency to lie in its error messages.
END
    my $missing;
    foreach my $check (qw(xorriso mformat)) {
        $missing |= system qw(sh -c), "type $check";
    }

    if ($missing) {
        print STDERR <<END;
You seem to have some program(s) missing which grub-mkrescue depends on,
see above.  ("mformat" is normally in the package "mtools".)
Installing those programs will probably help.
END
    } else {
        print STDERR <<END;
And older grub-mkrescue has a tendency not to notice certain problems.
Maybe strace will tell you what is wrong.  :-/
END
    }
    die "pvshim-converter: grub-mkrescue did not make iso\n";
}

runcmd qw(rm -rf --), "$sidecar.dir" unless $debug;

open Q, ">", "$dmwrap.new" or die "$dmwrap: $!";
print Q <<'END_DMWRAP';
#!/bin/bash

set -x
: "$@"
set +x

newargs=()

newarg () {
    newargs+=("$1")
}

while [ $# -gt 1 ]; do
    case "$1" in
	-no-shutdown|-nodefaults|-no-user-config)
	    newarg "$1"; shift
	    ;;
	-xen-domid|-chardev|-mon|-display|-boot|-m|-machine)
	    newarg "$1"; shift
	    newarg "$1"; shift
	    ;;
        -name)
            newarg "$1"; shift
            name="$1"; shift
            newarg "$name"
            ;;
	-netdev|-cdrom)
	    : fixme
	    newarg "$1"; shift
	    newarg "$1"; shift
	    ;;
	-drive|-kernel|-initrd|-append|-vnc)
	    shift; shift
	    ;;
	-device)
	    shift
	    case "$1" in
		XXXrtl8139*)
		    newarg "-device"
		    newarg "$1"; shift
		    ;;
		*)
		    shift
		    ;;
	    esac
	    ;;
	*)
	    echo >&2 "warning: unexpected argument $1 being passed through"
	    newarg "$1"; shift
	    ;;
    esac
done

#if [ "x$name" != x ]; then
#    logdir=/var/log/xen
#    logfile="$logdir/shim-$name.log"
#    savelog "$logfile" ||:
#    newarg -serial
#    newarg "file:$logfile"
#fi

set -x
exec /usr/local/lib/xen/bin/qemu-system-i386 "${newargs[@]}"
END_DMWRAP

chmod 0755, "$dmwrap.new" or die "$dmwrap: chmod: $!";

close Q or die $!;

rename "$sidecar.new", $sidecar or die "$sidecar: install: $!";
rename "$dmwrap.new",  $dmwrap  or die "$dmwrap: install: $!";

print STDERR <<END;
pvshim-converter: wrote qemu wrapper to $dmwrap
pvshim-converter: wrote sidecar to $sidecar
END

my $append = <<END;
builder='hvm'
type='hvm'
device_model_version='qemu-xen'
device_model_override='$dmwrap'
device_model_args_hvm=['-cdrom','$sidecar']
boot='c'
serial='pty'
END

if ($out ne '-') {
    open O, ">", "$out.tmp" or die "open output config temp: $out.tmp: $!\n";
} else {
    open O, ">&STDOUT" or die $!;
}

print O $indata, "\n", $append or die "write output: $!";
close O or die "close output: $!";

if ($out ne '-') {
    rename "$out.tmp", $out or die "install output: $!";
    print STDERR "pvshim-converter: wrote new guest config to $out\n";
} else {
    print STDERR "pvshim-converter: wrote new guest config to stdout\n";
}

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

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

Re: sidecar (hvm shim) creation script

[Ian Jackson]

Draft README.

My git branch is bere
   xenbits.xen.org:/home/iwj/ext/xen.git#wip.sidecar

(This contains the converter script too.  The git history is not very
useful and the files are in the wrong place, but I needed somewhere to
do my work.)

Ian.


                PV-in-HVM shim with "sidecar" ISO
                =================================

Summary
-------

This README describes a mitigation strategy for Meltdown.

The basic principle is to run PV guests (which can read all of host
memory due to the hardware bugs) as HVM guests (which cannot, at least
not due to Meltdown).  The PV environment is still provided to the
guest by an embedded copy of Xen, the "shim".


Properties of this approach
---------------------------

This strategy has the following inherent properties:

  * It is readily deployable
  * No hypervisor reboot is required
  * Guest reboots are required
  * Guest configs must be fed through a converter program
  * The converter program spits out a small guest-specific .iso
    image (we call this a "sidecar") used for booting
  * Because the result is an HVM guest, this approach involves
    running qemu as a PC emulator (this is done automatically)

The embedded copy of Xen we recommend using with this strategy implies
the following properties:

  * This shim has been subjected to intensive testing by Amazon
  * Therefore we think it is very stable
  * We believe it is compatible back to Xen 3.4
  * Unfortunately, various Xen features are not supported, notably:
    migration, dynamic guest memory adjustment ("ballooning"),
    vcpu hotplug.

The current implementation of the converter program implies:

  * "bootloader=" in config files - notably, "pygrub",
    is not currently supported.
  * pvgrub (pvgrub1, pvgrub2) is, however, supported.
  * direct kernel boot is supported
  * xl domain configurations are supported.
  * xm domain configurations have not been tested but may work.
  * libvirt's domain configuration arrangements are not supported.


Alternative approaches
----------------------

 * PVH

   Users who are using Xen 4.10 (or can upgrade) should use PVH
   for guests which support it.  (PVH aka "PVHv2" requires guest
   kernel support.)

   We intend to backport PVH support to Xen 4.8.

 * PV-in-PVH

   We have a work-in-progress which runs PV guests with a shim, as
   above, but where the shim runs as a PVH rather than PV guest.
   This will be available for Xen 4.10 in the first instance,
   but is not available today.


What you will need
------------------

 * Your host must be able to run grub-mkrescue to generate a .iso
 * You will therefore need xorriso and mtools
 * You must be using xl and able to use an alternative your guest config

 * You will need the script "pvshim-converter"
 * You will need the xen.git branch XXXX TBD


Instructions
------------

1. On a suitable system (perhaps a different host)
      git clone XXXXX TBD
      git checkout XXXXX TBD
      XXXX runes to configure and build only the whim

This will build a file
      dist/install/usr/local/lib/xen/boot/XXX-SOMETHING

2. Copy that file to your dom0.

3. Copy the script pvshim-converter to your dom0 and make
   it executable:
      chmod +x pvshim-converter

4. For each guest

  (i) if the guest is currently booted with pygrub you must first
   switch to direct kernel boot, by manually copying the kernel and
   initramfs out of the guest, and configuring the command line in the
   domain configuration file.

  (ii) run
      ./pvshim-converter /etc/xen/GUEST.cfg /etc/xen/GUEST.with-shim-cfg

  (iii) shut the guest down cleanly

  (iv) create the guest with the new config
      xl create /etc/xen/GUEST.with-shim-cfg

  (v) Check that it boots properly.  xl console should work.

  (vi) Make arrangements so that autostarting of the guest will use
     the new config file rather than the old one


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

Re: sidecar (hvm shim) creation script

[George Dunlap]

On 01/10/2018 04:25 PM, Ian Jackson wrote:
> Draft README.
> 
> My git branch is bere
>    xenbits.xen.org:/home/iwj/ext/xen.git#wip.sidecar
> 
> (This contains the converter script too.  The git history is not very
> useful and the files are in the wrong place, but I needed somewhere to
> do my work.)
> 
> Ian.
> 
> 
>                 PV-in-HVM shim with "sidecar" ISO
>                 =================================
> 
> Summary
> -------
> 
> This README describes a mitigation strategy for Meltdown.
> 
> The basic principle is to run PV guests (which can read all of host
> memory due to the hardware bugs) as HVM guests (which cannot, at least
> not due to Meltdown).  The PV environment is still provided to the
> guest by an embedded copy of Xen, the "shim".
> 
> 
> Properties of this approach
> ---------------------------

What about "Who should use this approach"?

You might consider this approach if:

- You want to deploy a fix immediately
- You can't, or would like to avoid, updating to Xen 4.8 or newer
- You can:
 - Run a script to modify each domain config
 - Afford an extra 80MiB per guest
 - Tolerate having an extra QEMU around
- You don't need migration, memory ballooning, vcpu hotplug, or guest
console

You might want to avoid this approach if:
- You're on 4.8 or later already
- You don't want an extra QEMU around
- You need migration, memory ballooning, vcpu hotplug, or guest console

Along those lines.

> Alternative approaches
> ----------------------
> 
>  * PVH
> 
>    Users who are using Xen 4.10 (or can upgrade) should use PVH
>    for guests which support it.  (PVH aka "PVHv2" requires guest
>    kernel support.)
> 
>    We intend to backport PVH support to Xen 4.8.

I've posted RFC patches fro this already.

>  * PV-in-PVH
> 
>    We have a work-in-progress which runs PV guests with a shim, as
>    above, but where the shim runs as a PVH rather than PV guest.
>    This will be available for Xen 4.10 in the first instance,
>    but is not available today.
> 
> 
> What you will need
> ------------------
> 
>  * Your host must be able to run grub-mkrescue to generate a .iso
>  * You will therefore need xorriso and mtools
>  * You must be using xl and able to use an alternative your guest config
> 
>  * You will need the script "pvshim-converter"
>  * You will need the xen.git branch XXXX TBD
> 
> 
> Instructions
> ------------
> 
> 1. On a suitable system (perhaps a different host)
>       git clone XXXXX TBD
>       git checkout XXXXX TBD
>       XXXX runes to configure and build only the whim
> 
> This will build a file
>       dist/install/usr/local/lib/xen/boot/XXX-SOMETHING
> 
> 2. Copy that file to your dom0.
> 
> 3. Copy the script pvshim-converter to your dom0 and make
>    it executable:
>       chmod +x pvshim-converter
> 
> 4. For each guest
> 
>   (i) if the guest is currently booted with pygrub you must first
>    switch to direct kernel boot, by manually copying the kernel and
>    initramfs out of the guest, and configuring the command line in the
>    domain configuration file.

pvgrub / pvgrub2?

 -George

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

Re: sidecar (hvm shim) creation script

[Doug Goldstein]

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

On 1/10/18 10:36 AM, George Dunlap wrote:
> On 01/10/2018 04:25 PM, Ian Jackson wrote:
>> Draft README.
>>
>> My git branch is bere
>>    xenbits.xen.org:/home/iwj/ext/xen.git#wip.sidecar
>>
>> (This contains the converter script too.  The git history is not very
>> useful and the files are in the wrong place, but I needed somewhere to
>> do my work.)
>>
>> Ian.
>>
>>
>>                 PV-in-HVM shim with "sidecar" ISO
>>                 =================================
>>
>> Summary
>> -------
>>
>> This README describes a mitigation strategy for Meltdown.
>>
>> The basic principle is to run PV guests (which can read all of host
>> memory due to the hardware bugs) as HVM guests (which cannot, at least
>> not due to Meltdown).  The PV environment is still provided to the
>> guest by an embedded copy of Xen, the "shim".
>>
>>
>> Properties of this approach
>> ---------------------------
> 
> What about "Who should use this approach"?
> 
> You might consider this approach if:
> 
> - You want to deploy a fix immediately
> - You can't, or would like to avoid, updating to Xen 4.8 or newer
> - You can:
>  - Run a script to modify each domain config
>  - Afford an extra 80MiB per guest
>  - Tolerate having an extra QEMU around
> - You don't need migration, memory ballooning, vcpu hotplug, or guest
> console

Didn't Ian get guest console working in v2 of his script? Didn't Anthony
get memory ballooning working in v3 of Vixen?

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 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: sidecar (hvm shim) creation script

[Dario Faggioli]

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

On Wed, 2018-01-10 at 15:41 +0000, Ian Jackson wrote:
> Ian Jackson writes ("Re: sidecar (hvm shim) creation script"):
> > And here is one which handles the guest console correctly.  Vixen
> > sends the L2 guest console to the emulated serial, along with the
> > shim's own output.
> 
So, I've got a PV guest that works.

Now I shut it down, run this script, and do `xl create -c' on the
resulting config file, but it dies. :-(

I'm using what's in this branch https://github.com/aliguori/xen/tree/vi
xen-upstream-v2 both as the host hypervisor and as the shim.

So, here's what I see on what I think is vixen's console:

error: Can't get controller info..
 __  __            _  _    _ _                    _        _     _      
 \ \/ /___ _ __   | || |  / / |   _   _ _ __  ___| |_ __ _| |__ | | ___ 
  \  // _ \ '_ \  | || |_ | | |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
  /  \  __/ | | | |__   _|| | |__| |_| | | | \__ \ || (_| | |_) | |  __/
 /_/\_\___|_| |_|    |_|(_)_|_|   \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
                                                                        
(XEN) Xen version 4.11-unstable (dario@fritz.box) (gcc (Debian 7.2.0-19) 7.2.0) debug=y  Wed Jan 10 13:28:20 UTC 2018
(XEN) Latest ChangeSet: Wed Dec 20 11:09:09 2017 +0000 git:d80556acd4
(XEN) Bootloader: GRUB 2.02-2
(XEN) Command line: placeholder console=com1 com1=115200n1
(XEN) Xen image load base address: 0
(XEN) Video information:
(XEN)  No VGA detected
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 0 EDD information structures
(XEN) Vixen running under Xen 4.11
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009fc00 (usable)
(XEN)  000000000009fc00 - 00000000000a0000 (reserved)
(XEN)  00000000000f0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 000000007f7ff000 (usable)
(XEN)  000000007f7ff000 - 000000007f800000 (reserved)
(XEN)  00000000fc000000 - 00000000feff0000 (reserved)
(XEN)  00000000feff0000 - 0000000100000000 (usable)



While this is L0's console:

(XEN) [  298.886732] grant_table.c:1681:d0v2 Expanding d2 grant table from 0 to 1 frames
(XEN) [  299.087102] HVM2 save: CPU
(XEN) [  299.087105] HVM2 save: PIC
(XEN) [  299.087108] HVM2 save: IOAPIC
(XEN) [  299.087111] HVM2 save: LAPIC
(XEN) [  299.087113] HVM2 save: LAPIC_REGS
(XEN) [  299.087117] HVM2 save: PCI_IRQ
(XEN) [  299.087119] HVM2 save: ISA_IRQ
(XEN) [  299.087121] HVM2 save: PCI_LINK
(XEN) [  299.087123] HVM2 save: PIT
(XEN) [  299.087125] HVM2 save: RTC
(XEN) [  299.087128] HVM2 save: HPET
(XEN) [  299.087131] HVM2 save: PMTIMER
(XEN) [  299.087133] HVM2 save: MTRR
(XEN) [  299.087141] HVM2 save: VIRIDIAN_DOMAIN
(XEN) [  299.087143] HVM2 save: CPU_XSAVE
(XEN) [  299.087149] HVM2 save: VIRIDIAN_VCPU
(XEN) [  299.087151] HVM2 save: VMCE_VCPU
(XEN) [  299.087153] HVM2 save: TSC_ADJUST
(XEN) [  299.087155] HVM2 save: CPU_MSR
(XEN) [  299.087195] HVM2 restore: CPU 0
[  293.712868] tun: Universal TUN/TAP device driver, 1.6^M
[  293.940987] xenbr0: port 2(vif2.0) entered blocking state^M
[  293.941014] xenbr0: port 2(vif2.0) entered disabled state^M
[  293.941111] device vif2.0 entered promiscuous mode^M
[  293.946041] IPv6: ADDRCONF(NETDEV_UP): vif2.0: link is not ready^M
[  294.139158] xenbr0: port 3(vif2.0-emu) entered blocking state^M
[  294.139202] xenbr0: port 3(vif2.0-emu) entered disabled state^M
[  294.139261] device vif2.0-emu entered promiscuous mode^M
[  294.144532] xenbr0: port 3(vif2.0-emu) entered blocking state^M
[  294.144544] xenbr0: port 3(vif2.0-emu) entered listening state^M
(d2) [  300.952702] HVM Loader
(d2) [  300.952773] Detected Xen v4.11-unstable
(d2) [  300.952850] Xenbus rings @0xfeffc000, event channel 1
(d2) [  300.953103] System requested SeaBIOS
(d2) [  300.953139] CPU speed is 2394 MHz
(d2) [  300.953491] Relocating guest memory for lowmem MMIO space disabled
(XEN) [  300.954017] irq.c:334: Dom2 PCI link 0 changed 0 -> 5
(d2) [  300.954246] PCI-ISA link 0 routed to IRQ5
(XEN) [  300.954423] irq.c:334: Dom2 PCI link 1 changed 0 -> 10
(d2) [  300.954633] PCI-ISA link 1 routed to IRQ10
(XEN) [  300.954794] irq.c:334: Dom2 PCI link 2 changed 0 -> 11
(d2) [  300.954999] PCI-ISA link 2 routed to IRQ11
(XEN) [  300.955233] irq.c:334: Dom2 PCI link 3 changed 0 -> 5
(d2) [  300.955415] PCI-ISA link 3 routed to IRQ5
(d2) [  300.971627] pci dev 01:3 INTA->IRQ10
(d2) [  300.975567] pci dev 02:0 INTA->IRQ11
(d2) [  300.997380] No RAM in high memory; setting high_mem resource base to 100000000
(d2) [  300.997576] pci dev 02:0 bar 14 size 001000000: 0f0000008
(d2) [  300.998673] pci dev 02:0 bar 10 size 000000100: 00000c001
(d2) [  300.999767] pci dev 01:1 bar 20 size 000000010: 00000c101
(d2) [  301.000817] Multiprocessor initialisation:
(d2) [  301.000951]  - CPU0 ... 40-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
(d2) [  301.001249]  - CPU1 ... 40-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
(d2) [  301.001562]  - CPU2 ... 40-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
(d2) [  301.001870]  - CPU3 ... 40-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
(d2) [  301.001953] Testing HVM environment:
(d2) [  301.002002] Using scratch memory at 400000
(d2) [  301.019991]  - REP INSB across page boundaries ... passed
(d2) [  301.031612]  - REP INSW across page boundaries ... passed
(d2) [  301.041228]  - GS base MSRs and SWAPGS ... passed
(d2) [  301.041249] Passed 3 of 3 tests
(d2) [  301.041275] Writing SMBIOS tables ...
(d2) [  301.042145] Loading SeaBIOS ...
(d2) [  301.042231] Creating MP tables ...
(d2) [  301.042387] Loading ACPI ...
(d2) [  301.043421] CONV disabled
(d2) [  301.043630] vm86 TSS at fc00a780
(d2) [  301.044162] BIOS map:
(d2) [  301.044196]  10000-100e3: Scratch space
(d2) [  301.044219]  c0000-fffff: Main BIOS
(d2) [  301.044259] E820 table:
(d2) [  301.044308]  [00]: 00000000:00000000 - 00000000:000a0000: RAM
(d2) [  301.044353]  HOLE: 00000000:000a0000 - 00000000:000c0000
(d2) [  301.044403]  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
(d2) [  301.044449]  [02]: 00000000:00100000 - 00000000:7f800000: RAM
(d2) [  301.044491]  HOLE: 00000000:7f800000 - 00000000:fc000000
(d2) [  301.044545]  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
(d2) [  301.044642] Invoking SeaBIOS ...
(d2) [  301.045027] SeaBIOS (version rel-1.10.2-0-g5f4c7b1)
(d2) [  301.045096] BUILD: gcc: (Debian 7.2.0-19) 7.2.0 binutils: (GNU Binutils for Debian) 2.29.1
(d2) [  301.045099] 
(d2) [  301.045138] Found Xen hypervisor signature at 40000000
(d2) [  301.045442] Running on QEMU (i440fx)
(d2) [  301.045465] xen: copy e820...
(d2) [  301.045524] Relocating init from 0x000daf80 to 0x7f7ad360 (size 76800)
(d2) [  301.048415] Found 5 PCI devices (max PCI bus is 00)
(d2) [  301.048456] Allocated Xen hypercall page at 7f7ff000
(d2) [  301.048492] Detected Xen v4.11-unstable
(d2) [  301.048518] xen: copy BIOS tables...
(d2) [  301.048576] Copying SMBIOS entry point from 0x00010020 to 0x000f6b20
(d2) [  301.048631] Copying MPTABLE from 0xfc0011f0/fc001200 to 0x000f6a00
(d2) [  301.048674] Copying PIR from 0x00010040 to 0x000f6980
(d2) [  301.048718] Copying ACPI RSDP from 0x000100c0 to 0x000f6950
(d2) [  301.048747] Using pmtimer, ioport 0xb008
(d2) [  301.048893] Scan for VGA option rom
(d2) [  301.050267] ATA controller 1 at 1f0/3f4/c100 (irq 14 dev 9)
(d2) [  301.051553] ATA controller 2 at 170/374/c108 (irq 15 dev 9)
(d2) [  301.052569] Found 0 lpt ports
(d2) [  301.052762] Found 1 serial ports
(d2) [  301.055677] DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD]
(d2) [  301.055731] Searching bootorder for: /pci@i0cf8/*@1,1/drive@1/disk@0
(d2) [  301.056943] PS2 keyboard initialized
(d2) [  301.056965] All threads complete.
(d2) [  301.056986] Scan for option roms
(d2) [  301.058379] 
(d2) [  301.065610] Press ESC for boot menu.
(d2) [  301.066100] 
[  296.154652] xenbr0: port 3(vif2.0-emu) entered learning state^M
(d2) [  303.684355] Searching bootorder for: HALT
(d2) [  303.684666] Space available for UMB: c0000-ec800, f6340-f68b0
(d2) [  303.684720] Returned 258048 bytes of ZoneHigh
(d2) [  303.684755] e820 map has 6 items:
(d2) [  303.684828]   0: 0000000000000000 - 000000000009fc00 = 1 RAM
(d2) [  303.684909]   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
(d2) [  303.684990]   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
(d2) [  303.685064]   3: 0000000000100000 - 000000007f7ff000 = 1 RAM
(d2) [  303.685144]   4: 000000007f7ff000 - 000000007f800000 = 2 RESERVED
(d2) [  303.685225]   5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
(d2) [  303.686459] enter handle_19:
(d2) [  303.686473]   NULL
(d2) [  303.694760] Booting from DVD/CD...
(d2) [  303.701138] Booting from 0000:7c00
[  298.170547] xenbr0: port 3(vif2.0-emu) entered forwarding state^M
[  298.170616] xenbr0: topology change detected, propagating^M
(XEN) [  314.149788] d2v0 Triple fault - invoking HVM shutdown action 1
(XEN) [  314.149791] *** Dumping Dom2 vcpu#0 state: ***
(XEN) [  314.149796] ----[ Xen-4.11-unstable  x86_64  debug=y   Not tainted ]----
(XEN) [  314.149798] CPU:    15
(XEN) [  314.149801] RIP:    e008:[<ffff82d080417368>]
(XEN) [  314.149803] RFLAGS: 0000000000010002   CONTEXT: hvm guest (d2v0)
(XEN) [  314.149807] rax: ffff8300ffe80000   rbx: 00000000ffe73000   rcx: 0000000000000000
(XEN) [  314.149810] rdx: ffff82d080480000   rsi: 0000000000000020   rdi: ffff8300ffe88000
(XEN) [  314.149814] rbp: ffff82d080487f08   rsp: ffff82d080487dd8   r8:  fff0000000000fff
(XEN) [  314.149817] r9:  000ffffffffff000   r10: 000000ffffffffff   r11: 0000000000001000
(XEN) [  314.149820] r12: ffff830000000000   r13: 00000000ffa00000   r14: 00000000ff000000
(XEN) [  314.149823] r15: ffff82d0804552bc   cr0: 0000000080050033   cr4: 0000000000000020
(XEN) [  314.149825] cr3: 00000000ffe73000   cr2: ffff82d080417368
(XEN) [  314.149827] fsb: 0000000000000000   gsb: 0000000000000000   gss: 0000000000000002
(XEN) [  314.149830] ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008



Also, find attached the various log files.

So... what am I doing wrong? :-)

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, Software Engineer @ SUSE
http://about.me/dario.faggioli

[-- Attachment #1.1.2: xl-vm10.log --]
[-- Type: text/x-log, Size: 212 bytes --]

Waiting for domain vm10 (domid 2) to die [pid 2041]
Domain 2 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is destroy
Domain 2 needs to be cleaned up: destroying the domain
Done. Exiting now

[-- Attachment #1.1.3: qemu-dm-vm10.log --]
[-- Type: text/x-log, Size: 1759 bytes --]

+ : -xen-domid 2 -chardev socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-2,server,nowait -no-shutdown -mon chardev=libxl-cmd,mode=control -chardev socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-2,server,nowait -mon chardev=libxenstat-cmd,mode=control -nodefaults -no-user-config -name vm10 -vnc 127.0.0.1:0,to=99 -display none -kernel /root/vm10/vmlinuz-4.14.0-3-amd64 -initrd /root/vm10/initrd.img-4.14.0-3-amd64 -append 'root=/dev/xvda1 ro' -serial pty -device cirrus-vga,vgamem_mb=8 -boot order=c -smp 4,maxcpus=4 -device rtl8139,id=nic0,netdev=net0,mac=00:16:3e:6c:5a:d4 -netdev type=tap,id=net0,ifname=vif2.0-emu,script=no,downscript=no -machine xenfv -cdrom /var/lib/xen/pvshim-sidecars/vm10.iso -m 2040 -drive file=/dev/vms/vm10-disk,if=ide,index=0,media=disk,format=raw,cache=writeback
+ set +x
warning: unexpected argument -serial being passed through
warning: unexpected argument pty being passed through
warning: unexpected argument -smp being passed through
warning: unexpected argument 4,maxcpus=4 being passed through
+ exec /usr/local/lib/xen/bin/qemu-system-i386 -xen-domid 2 -chardev socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-2,server,nowait -no-shutdown -mon chardev=libxl-cmd,mode=control -chardev socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-2,server,nowait -mon chardev=libxenstat-cmd,mode=control -nodefaults -no-user-config -name vm10 -display none -serial pty -boot order=c -smp 4,maxcpus=4 -netdev type=tap,id=net0,ifname=vif2.0-emu,script=no,downscript=no -machine xenfv -cdrom /var/lib/xen/pvshim-sidecars/vm10.iso -m 2040
qemu-system-i386: -serial pty: char device redirected to /dev/pts/2 (label serial0)
Warning: netdev net0 has no peer
qemu-system-i386: terminating on signal 1 from pid 2041 (xl)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 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: sidecar (hvm shim) creation script

[Dario Faggioli]

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

On Wed, 2018-01-10 at 15:41 +0000, Ian Jackson wrote:
> Ian Jackson writes ("Re: sidecar (hvm shim) creation script"):
> > And here is one which handles the guest console correctly.  Vixen
> > sends the L2 guest console to the emulated serial, along with the
> > shim's own output.

So, I've got a PV guest that works.

Now I shut it down, run this script, and do `xl create -c' on the
resulting config file, but it dies. :-(

I'm using what's in this branch https://github.com/aliguori/xen/tree/vi
xen-upstream-v2 both as the host hypervisor and as the shim.

So, here's what I see on what I think is vixen's console:

error: Can't get controller info..
 __  __            _  _    _
_                    _        _     _      
 \ \/ /___ _ __   | || |  / / |   _   _ _ __  ___| |_ __ _| |__ | |
___ 
  \  // _ \ '_ \  | || |_ | | |__| | | | '_ \/ __| __/ _` | '_ \| |/ _
\
  /  \  __/ | | | |__   _|| | |__| |_| | | | \__ \ || (_| | |_) |
|  __/
 /_/\_\___|_| |_|    |_|(_)_|_|   \__,_|_|
|_|___/\__\__,_|_.__/|_|\___|
                                                                       
 
(XEN) Xen version 4.11-unstable (dario@fritz.box) (gcc (Debian 7.2.0-
19) 7.2.0) debug=y  Wed Jan 10 13:28:20 UTC 2018
(XEN) Latest ChangeSet: Wed Dec 20 11:09:09 2017 +0000 git:d80556acd4
(XEN) Bootloader: GRUB 2.02-2
(XEN) Command line: placeholder console=com1 com1=115200n1
(XEN) Xen image load base address: 0
(XEN) Video information:
(XEN)  No VGA detected
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 0 EDD information structures
(XEN) Vixen running under Xen 4.11
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009fc00 (usable)
(XEN)  000000000009fc00 - 00000000000a0000 (reserved)
(XEN)  00000000000f0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 000000007f7ff000 (usable)
(XEN)  000000007f7ff000 - 000000007f800000 (reserved)
(XEN)  00000000fc000000 - 00000000feff0000 (reserved)
(XEN)  00000000feff0000 - 0000000100000000 (usable)



While this is L0's console:

(XEN) [  298.886732] grant_table.c:1681:d0v2 Expanding d2 grant table
from 0 to 1 frames
(XEN) [  299.087102] HVM2 save: CPU
(XEN) [  299.087105] HVM2 save: PIC
(XEN) [  299.087108] HVM2 save: IOAPIC
(XEN) [  299.087111] HVM2 save: LAPIC
(XEN) [  299.087113] HVM2 save: LAPIC_REGS
(XEN) [  299.087117] HVM2 save: PCI_IRQ
(XEN) [  299.087119] HVM2 save: ISA_IRQ
(XEN) [  299.087121] HVM2 save: PCI_LINK
(XEN) [  299.087123] HVM2 save: PIT
(XEN) [  299.087125] HVM2 save: RTC
(XEN) [  299.087128] HVM2 save: HPET
(XEN) [  299.087131] HVM2 save: PMTIMER
(XEN) [  299.087133] HVM2 save: MTRR
(XEN) [  299.087141] HVM2 save: VIRIDIAN_DOMAIN
(XEN) [  299.087143] HVM2 save: CPU_XSAVE
(XEN) [  299.087149] HVM2 save: VIRIDIAN_VCPU
(XEN) [  299.087151] HVM2 save: VMCE_VCPU
(XEN) [  299.087153] HVM2 save: TSC_ADJUST
(XEN) [  299.087155] HVM2 save: CPU_MSR
(XEN) [  299.087195] HVM2 restore: CPU 0
[  293.712868] tun: Universal TUN/TAP device driver, 1.6^M
[  293.940987] xenbr0: port 2(vif2.0) entered blocking state^M
[  293.941014] xenbr0: port 2(vif2.0) entered disabled state^M
[  293.941111] device vif2.0 entered promiscuous mode^M
[  293.946041] IPv6: ADDRCONF(NETDEV_UP): vif2.0: link is not ready^M
[  294.139158] xenbr0: port 3(vif2.0-emu) entered blocking state^M
[  294.139202] xenbr0: port 3(vif2.0-emu) entered disabled state^M
[  294.139261] device vif2.0-emu entered promiscuous mode^M
[  294.144532] xenbr0: port 3(vif2.0-emu) entered blocking state^M
[  294.144544] xenbr0: port 3(vif2.0-emu) entered listening state^M
(d2) [  300.952702] HVM Loader
(d2) [  300.952773] Detected Xen v4.11-unstable
(d2) [  300.952850] Xenbus rings @0xfeffc000, event channel 1
(d2) [  300.953103] System requested SeaBIOS
(d2) [  300.953139] CPU speed is 2394 MHz
(d2) [  300.953491] Relocating guest memory for lowmem MMIO space
disabled
(XEN) [  300.954017] irq.c:334: Dom2 PCI link 0 changed 0 -> 5
(d2) [  300.954246] PCI-ISA link 0 routed to IRQ5
(XEN) [  300.954423] irq.c:334: Dom2 PCI link 1 changed 0 -> 10
(d2) [  300.954633] PCI-ISA link 1 routed to IRQ10
(XEN) [  300.954794] irq.c:334: Dom2 PCI link 2 changed 0 -> 11
(d2) [  300.954999] PCI-ISA link 2 routed to IRQ11
(XEN) [  300.955233] irq.c:334: Dom2 PCI link 3 changed 0 -> 5
(d2) [  300.955415] PCI-ISA link 3 routed to IRQ5
(d2) [  300.971627] pci dev 01:3 INTA->IRQ10
(d2) [  300.975567] pci dev 02:0 INTA->IRQ11
(d2) [  300.997380] No RAM in high memory; setting high_mem resource
base to 100000000
(d2) [  300.997576] pci dev 02:0 bar 14 size 001000000: 0f0000008
(d2) [  300.998673] pci dev 02:0 bar 10 size 000000100: 00000c001
(d2) [  300.999767] pci dev 01:1 bar 20 size 000000010: 00000c101
(d2) [  301.000817] Multiprocessor initialisation:
(d2) [  301.000951]  - CPU0 ... 40-bit phys ... fixed MTRRs ... var
MTRRs [1/8] ... done.
(d2) [  301.001249]  - CPU1 ... 40-bit phys ... fixed MTRRs ... var
MTRRs [1/8] ... done.
(d2) [  301.001562]  - CPU2 ... 40-bit phys ... fixed MTRRs ... var
MTRRs [1/8] ... done.
(d2) [  301.001870]  - CPU3 ... 40-bit phys ... fixed MTRRs ... var
MTRRs [1/8] ... done.
(d2) [  301.001953] Testing HVM environment:
(d2) [  301.002002] Using scratch memory at 400000
(d2) [  301.019991]  - REP INSB across page boundaries ... passed
(d2) [  301.031612]  - REP INSW across page boundaries ... passed
(d2) [  301.041228]  - GS base MSRs and SWAPGS ... passed
(d2) [  301.041249] Passed 3 of 3 tests
(d2) [  301.041275] Writing SMBIOS tables ...
(d2) [  301.042145] Loading SeaBIOS ...
(d2) [  301.042231] Creating MP tables ...
(d2) [  301.042387] Loading ACPI ...
(d2) [  301.043421] CONV disabled
(d2) [  301.043630] vm86 TSS at fc00a780
(d2) [  301.044162] BIOS map:
(d2) [  301.044196]  10000-100e3: Scratch space
(d2) [  301.044219]  c0000-fffff: Main BIOS
(d2) [  301.044259] E820 table:
(d2) [  301.044308]  [00]: 00000000:00000000 - 00000000:000a0000: RAM
(d2) [  301.044353]  HOLE: 00000000:000a0000 - 00000000:000c0000
(d2) [  301.044403]  [01]: 00000000:000c0000 - 00000000:00100000:
RESERVED
(d2) [  301.044449]  [02]: 00000000:00100000 - 00000000:7f800000: RAM
(d2) [  301.044491]  HOLE: 00000000:7f800000 - 00000000:fc000000
(d2) [  301.044545]  [03]: 00000000:fc000000 - 00000001:00000000:
RESERVED
(d2) [  301.044642] Invoking SeaBIOS ...
(d2) [  301.045027] SeaBIOS (version rel-1.10.2-0-g5f4c7b1)
(d2) [  301.045096] BUILD: gcc: (Debian 7.2.0-19) 7.2.0 binutils: (GNU
Binutils for Debian) 2.29.1
(d2) [  301.045099] 
(d2) [  301.045138] Found Xen hypervisor signature at 40000000
(d2) [  301.045442] Running on QEMU (i440fx)
(d2) [  301.045465] xen: copy e820...
(d2) [  301.045524] Relocating init from 0x000daf80 to 0x7f7ad360 (size
76800)
(d2) [  301.048415] Found 5 PCI devices (max PCI bus is 00)
(d2) [  301.048456] Allocated Xen hypercall page at 7f7ff000
(d2) [  301.048492] Detected Xen v4.11-unstable
(d2) [  301.048518] xen: copy BIOS tables...
(d2) [  301.048576] Copying SMBIOS entry point from 0x00010020 to
0x000f6b20
(d2) [  301.048631] Copying MPTABLE from 0xfc0011f0/fc001200 to
0x000f6a00
(d2) [  301.048674] Copying PIR from 0x00010040 to 0x000f6980
(d2) [  301.048718] Copying ACPI RSDP from 0x000100c0 to 0x000f6950
(d2) [  301.048747] Using pmtimer, ioport 0xb008
(d2) [  301.048893] Scan for VGA option rom
(d2) [  301.050267] ATA controller 1 at 1f0/3f4/c100 (irq 14 dev 9)
(d2) [  301.051553] ATA controller 2 at 170/374/c108 (irq 15 dev 9)
(d2) [  301.052569] Found 0 lpt ports
(d2) [  301.052762] Found 1 serial ports
(d2) [  301.055677] DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD]
(d2) [  301.055731] Searching bootorder for: /pci@i0cf8/*@1,1/drive@1/d
isk@0
(d2) [  301.056943] PS2 keyboard initialized
(d2) [  301.056965] All threads complete.
(d2) [  301.056986] Scan for option roms
(d2) [  301.058379] 
(d2) [  301.065610] Press ESC for boot menu.
(d2) [  301.066100] 
[  296.154652] xenbr0: port 3(vif2.0-emu) entered learning state^M
(d2) [  303.684355] Searching bootorder for: HALT
(d2) [  303.684666] Space available for UMB: c0000-ec800, f6340-f68b0
(d2) [  303.684720] Returned 258048 bytes of ZoneHigh
(d2) [  303.684755] e820 map has 6 items:
(d2) [  303.684828]   0: 0000000000000000 - 000000000009fc00 = 1 RAM
(d2) [  303.684909]   1: 000000000009fc00 - 00000000000a0000 = 2
RESERVED
(d2) [  303.684990]   2: 00000000000f0000 - 0000000000100000 = 2
RESERVED
(d2) [  303.685064]   3: 0000000000100000 - 000000007f7ff000 = 1 RAM
(d2) [  303.685144]   4: 000000007f7ff000 - 000000007f800000 = 2
RESERVED
(d2) [  303.685225]   5: 00000000fc000000 - 0000000100000000 = 2
RESERVED
(d2) [  303.686459] enter handle_19:
(d2) [  303.686473]   NULL
(d2) [  303.694760] Booting from DVD/CD...
(d2) [  303.701138] Booting from 0000:7c00
[  298.170547] xenbr0: port 3(vif2.0-emu) entered forwarding state^M
[  298.170616] xenbr0: topology change detected, propagating^M
(XEN) [  314.149788] d2v0 Triple fault - invoking HVM shutdown action 1
(XEN) [  314.149791] *** Dumping Dom2 vcpu#0 state: ***
(XEN) [  314.149796] ----[ Xen-4.11-unstable  x86_64  debug=y   Not
tainted ]----
(XEN) [  314.149798] CPU:    15
(XEN) [  314.149801] RIP:    e008:[<ffff82d080417368>]
(XEN) [  314.149803] RFLAGS: 0000000000010002   CONTEXT: hvm guest
(d2v0)
(XEN) [  314.149807] rax: ffff8300ffe80000   rbx:
00000000ffe73000   rcx: 0000000000000000
(XEN) [  314.149810] rdx: ffff82d080480000   rsi:
0000000000000020   rdi: ffff8300ffe88000
(XEN) [  314.149814] rbp: ffff82d080487f08   rsp:
ffff82d080487dd8   r8:  fff0000000000fff
(XEN) [  314.149817] r9:  000ffffffffff000   r10:
000000ffffffffff   r11: 0000000000001000
(XEN) [  314.149820] r12: ffff830000000000   r13:
00000000ffa00000   r14: 00000000ff000000
(XEN) [  314.149823] r15: ffff82d0804552bc   cr0:
0000000080050033   cr4: 0000000000000020
(XEN) [  314.149825] cr3: 00000000ffe73000   cr2: ffff82d080417368
(XEN) [  314.149827] fsb: 0000000000000000   gsb:
0000000000000000   gss: 0000000000000002
(XEN) [  314.149830] ds: 0000   es: 0000   fs: 0000   gs: 0000   ss:
0000   cs: e008



Also, find attached the various log files.

So... what am I doing wrong? :-)

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

[-- Attachment #1.1.2: xl-vm10.log --]
[-- Type: text/x-log, Size: 212 bytes --]

Waiting for domain vm10 (domid 2) to die [pid 2041]
Domain 2 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is destroy
Domain 2 needs to be cleaned up: destroying the domain
Done. Exiting now

[-- Attachment #1.1.3: qemu-dm-vm10.log --]
[-- Type: text/x-log, Size: 1759 bytes --]

+ : -xen-domid 2 -chardev socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-2,server,nowait -no-shutdown -mon chardev=libxl-cmd,mode=control -chardev socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-2,server,nowait -mon chardev=libxenstat-cmd,mode=control -nodefaults -no-user-config -name vm10 -vnc 127.0.0.1:0,to=99 -display none -kernel /root/vm10/vmlinuz-4.14.0-3-amd64 -initrd /root/vm10/initrd.img-4.14.0-3-amd64 -append 'root=/dev/xvda1 ro' -serial pty -device cirrus-vga,vgamem_mb=8 -boot order=c -smp 4,maxcpus=4 -device rtl8139,id=nic0,netdev=net0,mac=00:16:3e:6c:5a:d4 -netdev type=tap,id=net0,ifname=vif2.0-emu,script=no,downscript=no -machine xenfv -cdrom /var/lib/xen/pvshim-sidecars/vm10.iso -m 2040 -drive file=/dev/vms/vm10-disk,if=ide,index=0,media=disk,format=raw,cache=writeback
+ set +x
warning: unexpected argument -serial being passed through
warning: unexpected argument pty being passed through
warning: unexpected argument -smp being passed through
warning: unexpected argument 4,maxcpus=4 being passed through
+ exec /usr/local/lib/xen/bin/qemu-system-i386 -xen-domid 2 -chardev socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-2,server,nowait -no-shutdown -mon chardev=libxl-cmd,mode=control -chardev socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-2,server,nowait -mon chardev=libxenstat-cmd,mode=control -nodefaults -no-user-config -name vm10 -display none -serial pty -boot order=c -smp 4,maxcpus=4 -netdev type=tap,id=net0,ifname=vif2.0-emu,script=no,downscript=no -machine xenfv -cdrom /var/lib/xen/pvshim-sidecars/vm10.iso -m 2040
qemu-system-i386: -serial pty: char device redirected to /dev/pts/2 (label serial0)
Warning: netdev net0 has no peer
qemu-system-i386: terminating on signal 1 from pid 2041 (xl)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 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: sidecar (hvm shim) creation script

[Anthony Liguori]

On Wed, Jan 10, 2018 at 9:44 AM, Dario Faggioli <raistlin@linux.it> wrote:
> On Wed, 2018-01-10 at 15:41 +0000, Ian Jackson wrote:
>> Ian Jackson writes ("Re: sidecar (hvm shim) creation script"):
>> > And here is one which handles the guest console correctly.  Vixen
>> > sends the L2 guest console to the emulated serial, along with the
>> > shim's own output.
>
> So, I've got a PV guest that works.
>
> Now I shut it down, run this script, and do `xl create -c' on the
> resulting config file, but it dies. :-(
>
> I'm using what's in this branch https://github.com/aliguori/xen/tree/vi
> xen-upstream-v2 both as the host hypervisor and as the shim.

Please test with v1.

Regards,

Anthony Liguori

>
> So, here's what I see on what I think is vixen's console:
>
> error: Can't get controller info..
>  __  __            _  _    _
> _                    _        _     _
>  \ \/ /___ _ __   | || |  / / |   _   _ _ __  ___| |_ __ _| |__ | |
> ___
>   \  // _ \ '_ \  | || |_ | | |__| | | | '_ \/ __| __/ _` | '_ \| |/ _
> \
>   /  \  __/ | | | |__   _|| | |__| |_| | | | \__ \ || (_| | |_) |
> |  __/
>  /_/\_\___|_| |_|    |_|(_)_|_|   \__,_|_|
> |_|___/\__\__,_|_.__/|_|\___|
>
>
> (XEN) Xen version 4.11-unstable (dario@fritz.box) (gcc (Debian 7.2.0-
> 19) 7.2.0) debug=y  Wed Jan 10 13:28:20 UTC 2018
> (XEN) Latest ChangeSet: Wed Dec 20 11:09:09 2017 +0000 git:d80556acd4
> (XEN) Bootloader: GRUB 2.02-2
> (XEN) Command line: placeholder console=com1 com1=115200n1
> (XEN) Xen image load base address: 0
> (XEN) Video information:
> (XEN)  No VGA detected
> (XEN) Disc information:
> (XEN)  Found 0 MBR signatures
> (XEN)  Found 0 EDD information structures
> (XEN) Vixen running under Xen 4.11
> (XEN) Xen-e820 RAM map:
> (XEN)  0000000000000000 - 000000000009fc00 (usable)
> (XEN)  000000000009fc00 - 00000000000a0000 (reserved)
> (XEN)  00000000000f0000 - 0000000000100000 (reserved)
> (XEN)  0000000000100000 - 000000007f7ff000 (usable)
> (XEN)  000000007f7ff000 - 000000007f800000 (reserved)
> (XEN)  00000000fc000000 - 00000000feff0000 (reserved)
> (XEN)  00000000feff0000 - 0000000100000000 (usable)
>
>
>
> While this is L0's console:
>
> (XEN) [  298.886732] grant_table.c:1681:d0v2 Expanding d2 grant table
> from 0 to 1 frames
> (XEN) [  299.087102] HVM2 save: CPU
> (XEN) [  299.087105] HVM2 save: PIC
> (XEN) [  299.087108] HVM2 save: IOAPIC
> (XEN) [  299.087111] HVM2 save: LAPIC
> (XEN) [  299.087113] HVM2 save: LAPIC_REGS
> (XEN) [  299.087117] HVM2 save: PCI_IRQ
> (XEN) [  299.087119] HVM2 save: ISA_IRQ
> (XEN) [  299.087121] HVM2 save: PCI_LINK
> (XEN) [  299.087123] HVM2 save: PIT
> (XEN) [  299.087125] HVM2 save: RTC
> (XEN) [  299.087128] HVM2 save: HPET
> (XEN) [  299.087131] HVM2 save: PMTIMER
> (XEN) [  299.087133] HVM2 save: MTRR
> (XEN) [  299.087141] HVM2 save: VIRIDIAN_DOMAIN
> (XEN) [  299.087143] HVM2 save: CPU_XSAVE
> (XEN) [  299.087149] HVM2 save: VIRIDIAN_VCPU
> (XEN) [  299.087151] HVM2 save: VMCE_VCPU
> (XEN) [  299.087153] HVM2 save: TSC_ADJUST
> (XEN) [  299.087155] HVM2 save: CPU_MSR
> (XEN) [  299.087195] HVM2 restore: CPU 0
> [  293.712868] tun: Universal TUN/TAP device driver, 1.6^M
> [  293.940987] xenbr0: port 2(vif2.0) entered blocking state^M
> [  293.941014] xenbr0: port 2(vif2.0) entered disabled state^M
> [  293.941111] device vif2.0 entered promiscuous mode^M
> [  293.946041] IPv6: ADDRCONF(NETDEV_UP): vif2.0: link is not ready^M
> [  294.139158] xenbr0: port 3(vif2.0-emu) entered blocking state^M
> [  294.139202] xenbr0: port 3(vif2.0-emu) entered disabled state^M
> [  294.139261] device vif2.0-emu entered promiscuous mode^M
> [  294.144532] xenbr0: port 3(vif2.0-emu) entered blocking state^M
> [  294.144544] xenbr0: port 3(vif2.0-emu) entered listening state^M
> (d2) [  300.952702] HVM Loader
> (d2) [  300.952773] Detected Xen v4.11-unstable
> (d2) [  300.952850] Xenbus rings @0xfeffc000, event channel 1
> (d2) [  300.953103] System requested SeaBIOS
> (d2) [  300.953139] CPU speed is 2394 MHz
> (d2) [  300.953491] Relocating guest memory for lowmem MMIO space
> disabled
> (XEN) [  300.954017] irq.c:334: Dom2 PCI link 0 changed 0 -> 5
> (d2) [  300.954246] PCI-ISA link 0 routed to IRQ5
> (XEN) [  300.954423] irq.c:334: Dom2 PCI link 1 changed 0 -> 10
> (d2) [  300.954633] PCI-ISA link 1 routed to IRQ10
> (XEN) [  300.954794] irq.c:334: Dom2 PCI link 2 changed 0 -> 11
> (d2) [  300.954999] PCI-ISA link 2 routed to IRQ11
> (XEN) [  300.955233] irq.c:334: Dom2 PCI link 3 changed 0 -> 5
> (d2) [  300.955415] PCI-ISA link 3 routed to IRQ5
> (d2) [  300.971627] pci dev 01:3 INTA->IRQ10
> (d2) [  300.975567] pci dev 02:0 INTA->IRQ11
> (d2) [  300.997380] No RAM in high memory; setting high_mem resource
> base to 100000000
> (d2) [  300.997576] pci dev 02:0 bar 14 size 001000000: 0f0000008
> (d2) [  300.998673] pci dev 02:0 bar 10 size 000000100: 00000c001
> (d2) [  300.999767] pci dev 01:1 bar 20 size 000000010: 00000c101
> (d2) [  301.000817] Multiprocessor initialisation:
> (d2) [  301.000951]  - CPU0 ... 40-bit phys ... fixed MTRRs ... var
> MTRRs [1/8] ... done.
> (d2) [  301.001249]  - CPU1 ... 40-bit phys ... fixed MTRRs ... var
> MTRRs [1/8] ... done.
> (d2) [  301.001562]  - CPU2 ... 40-bit phys ... fixed MTRRs ... var
> MTRRs [1/8] ... done.
> (d2) [  301.001870]  - CPU3 ... 40-bit phys ... fixed MTRRs ... var
> MTRRs [1/8] ... done.
> (d2) [  301.001953] Testing HVM environment:
> (d2) [  301.002002] Using scratch memory at 400000
> (d2) [  301.019991]  - REP INSB across page boundaries ... passed
> (d2) [  301.031612]  - REP INSW across page boundaries ... passed
> (d2) [  301.041228]  - GS base MSRs and SWAPGS ... passed
> (d2) [  301.041249] Passed 3 of 3 tests
> (d2) [  301.041275] Writing SMBIOS tables ...
> (d2) [  301.042145] Loading SeaBIOS ...
> (d2) [  301.042231] Creating MP tables ...
> (d2) [  301.042387] Loading ACPI ...
> (d2) [  301.043421] CONV disabled
> (d2) [  301.043630] vm86 TSS at fc00a780
> (d2) [  301.044162] BIOS map:
> (d2) [  301.044196]  10000-100e3: Scratch space
> (d2) [  301.044219]  c0000-fffff: Main BIOS
> (d2) [  301.044259] E820 table:
> (d2) [  301.044308]  [00]: 00000000:00000000 - 00000000:000a0000: RAM
> (d2) [  301.044353]  HOLE: 00000000:000a0000 - 00000000:000c0000
> (d2) [  301.044403]  [01]: 00000000:000c0000 - 00000000:00100000:
> RESERVED
> (d2) [  301.044449]  [02]: 00000000:00100000 - 00000000:7f800000: RAM
> (d2) [  301.044491]  HOLE: 00000000:7f800000 - 00000000:fc000000
> (d2) [  301.044545]  [03]: 00000000:fc000000 - 00000001:00000000:
> RESERVED
> (d2) [  301.044642] Invoking SeaBIOS ...
> (d2) [  301.045027] SeaBIOS (version rel-1.10.2-0-g5f4c7b1)
> (d2) [  301.045096] BUILD: gcc: (Debian 7.2.0-19) 7.2.0 binutils: (GNU
> Binutils for Debian) 2.29.1
> (d2) [  301.045099]
> (d2) [  301.045138] Found Xen hypervisor signature at 40000000
> (d2) [  301.045442] Running on QEMU (i440fx)
> (d2) [  301.045465] xen: copy e820...
> (d2) [  301.045524] Relocating init from 0x000daf80 to 0x7f7ad360 (size
> 76800)
> (d2) [  301.048415] Found 5 PCI devices (max PCI bus is 00)
> (d2) [  301.048456] Allocated Xen hypercall page at 7f7ff000
> (d2) [  301.048492] Detected Xen v4.11-unstable
> (d2) [  301.048518] xen: copy BIOS tables...
> (d2) [  301.048576] Copying SMBIOS entry point from 0x00010020 to
> 0x000f6b20
> (d2) [  301.048631] Copying MPTABLE from 0xfc0011f0/fc001200 to
> 0x000f6a00
> (d2) [  301.048674] Copying PIR from 0x00010040 to 0x000f6980
> (d2) [  301.048718] Copying ACPI RSDP from 0x000100c0 to 0x000f6950
> (d2) [  301.048747] Using pmtimer, ioport 0xb008
> (d2) [  301.048893] Scan for VGA option rom
> (d2) [  301.050267] ATA controller 1 at 1f0/3f4/c100 (irq 14 dev 9)
> (d2) [  301.051553] ATA controller 2 at 170/374/c108 (irq 15 dev 9)
> (d2) [  301.052569] Found 0 lpt ports
> (d2) [  301.052762] Found 1 serial ports
> (d2) [  301.055677] DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD]
> (d2) [  301.055731] Searching bootorder for: /pci@i0cf8/*@1,1/drive@1/d
> isk@0
> (d2) [  301.056943] PS2 keyboard initialized
> (d2) [  301.056965] All threads complete.
> (d2) [  301.056986] Scan for option roms
> (d2) [  301.058379]
> (d2) [  301.065610] Press ESC for boot menu.
> (d2) [  301.066100]
> [  296.154652] xenbr0: port 3(vif2.0-emu) entered learning state^M
> (d2) [  303.684355] Searching bootorder for: HALT
> (d2) [  303.684666] Space available for UMB: c0000-ec800, f6340-f68b0
> (d2) [  303.684720] Returned 258048 bytes of ZoneHigh
> (d2) [  303.684755] e820 map has 6 items:
> (d2) [  303.684828]   0: 0000000000000000 - 000000000009fc00 = 1 RAM
> (d2) [  303.684909]   1: 000000000009fc00 - 00000000000a0000 = 2
> RESERVED
> (d2) [  303.684990]   2: 00000000000f0000 - 0000000000100000 = 2
> RESERVED
> (d2) [  303.685064]   3: 0000000000100000 - 000000007f7ff000 = 1 RAM
> (d2) [  303.685144]   4: 000000007f7ff000 - 000000007f800000 = 2
> RESERVED
> (d2) [  303.685225]   5: 00000000fc000000 - 0000000100000000 = 2
> RESERVED
> (d2) [  303.686459] enter handle_19:
> (d2) [  303.686473]   NULL
> (d2) [  303.694760] Booting from DVD/CD...
> (d2) [  303.701138] Booting from 0000:7c00
> [  298.170547] xenbr0: port 3(vif2.0-emu) entered forwarding state^M
> [  298.170616] xenbr0: topology change detected, propagating^M
> (XEN) [  314.149788] d2v0 Triple fault - invoking HVM shutdown action 1
> (XEN) [  314.149791] *** Dumping Dom2 vcpu#0 state: ***
> (XEN) [  314.149796] ----[ Xen-4.11-unstable  x86_64  debug=y   Not
> tainted ]----
> (XEN) [  314.149798] CPU:    15
> (XEN) [  314.149801] RIP:    e008:[<ffff82d080417368>]
> (XEN) [  314.149803] RFLAGS: 0000000000010002   CONTEXT: hvm guest
> (d2v0)
> (XEN) [  314.149807] rax: ffff8300ffe80000   rbx:
> 00000000ffe73000   rcx: 0000000000000000
> (XEN) [  314.149810] rdx: ffff82d080480000   rsi:
> 0000000000000020   rdi: ffff8300ffe88000
> (XEN) [  314.149814] rbp: ffff82d080487f08   rsp:
> ffff82d080487dd8   r8:  fff0000000000fff
> (XEN) [  314.149817] r9:  000ffffffffff000   r10:
> 000000ffffffffff   r11: 0000000000001000
> (XEN) [  314.149820] r12: ffff830000000000   r13:
> 00000000ffa00000   r14: 00000000ff000000
> (XEN) [  314.149823] r15: ffff82d0804552bc   cr0:
> 0000000080050033   cr4: 0000000000000020
> (XEN) [  314.149825] cr3: 00000000ffe73000   cr2: ffff82d080417368
> (XEN) [  314.149827] fsb: 0000000000000000   gsb:
> 0000000000000000   gss: 0000000000000002
> (XEN) [  314.149830] ds: 0000   es: 0000   fs: 0000   gs: 0000   ss:
> 0000   cs: e008
>
>
>
> Also, find attached the various log files.
>
> So... what am I doing wrong? :-)
>
> Regards,
> Dario
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Software Engineer @ SUSE https://www.suse.com/
> _______________________________________________
> 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: sidecar (hvm shim) creation script

[Doug Goldstein]

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

On 1/10/18 9:39 AM, Ian Jackson wrote:
> Ian Jackson writes ("Re: sidecar (hvm shim) creation script"):
>> Here is the converter script where I just got my guest to boot with
>> the Vixen shim, as built and provided by Wei.
> 
> And here is one which handles the guest console correctly.  Vixen
> sends the L2 guest console to the emulated serial, along with the
> shim's own output.
> 
> 

So, not that I don't like executing another language interpreter from
another language interpreter (insert yodawg meme here), but how would
you feel about a Python version? The system I'm currently dealing with
needs to import this code as a Python module so I figured I'd slap a
main() and some argparse on it and it should be good.

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 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: sidecar (hvm shim) creation script

[George Dunlap]

On 01/10/2018 11:08 PM, Doug Goldstein wrote:
> On 1/10/18 9:39 AM, Ian Jackson wrote:
>> Ian Jackson writes ("Re: sidecar (hvm shim) creation script"):
>>> Here is the converter script where I just got my guest to boot with
>>> the Vixen shim, as built and provided by Wei.
>>
>> And here is one which handles the guest console correctly.  Vixen
>> sends the L2 guest console to the emulated serial, along with the
>> shim's own output.
>>
>>
> 
> So, not that I don't like executing another language interpreter from
> another language interpreter (insert yodawg meme here), but how would
> you feel about a Python version? The system I'm currently dealing with
> needs to import this code as a Python module so I figured I'd slap a
> main() and some argparse on it and it should be good.

From what I understand, Ian's decision tree looked like this:

1. For parsing xl.cfg, the options are "use python" or "write a brand
new parser for the python-like xl.cfg syntax".  That's pretty much a
no-brainer.

2. Given that the aim of the shim is to hand to people running systems
as old as Xen 3.4, the script needs to run identically, without issue,
on a wide range of systems.  In his estimation, his ability to write
such "lowest-common-denominator" perl was much higher than his ability
to write "lowest-common-denominator" python.

If anyone stepped to write and maintain a version of the script that can
run as well under Python 2.2 as under 2.7, he'd probably be happy to
avoid using three different languages.

 -George

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

Re: Radical proposal: ship not-fully-tidied shim as 4.10.1

[Hans van Kranenburg]

On 01/10/2018 06:50 AM, Juergen Gross wrote:
> On 09/01/18 23:11, Hans van Kranenburg wrote:
>> On 01/09/2018 07:22 PM, Rich Persaud wrote:
>>>
>>
>>> Since the primary audience for security fixes are production
>>> deployments of Xen where customer assets are at risk, is there an
>>> estimate for the percentage/size of Xen deployments where PVH (not
>>> only Xen 4.10) has already been deployed for production customers?
>>> That could give other customers more confidence in deploying PVH in
>>> production.
>> +1
>>
>> I have been hearing mostly-very-positive stories around, except for the
>> missing pvgrub2 support. :)
> 
> https://lists.xen.org/archives/html/xen-devel/2017-11/msg01795.html

Ah thanks. I also found the links to kernel changes and a xen change.

http://lists.gnu.org/archive/html/grub-devel/2017-12/msg00002.html

I'm going to play around with it, see if I can get it running. Being
able to use pvgrub2 will mean ending up with an incredibly smooth
migration path to Xen 4.10 and PVHv2...

Hans


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