Re: [Xen-devel] [PATCH RFC v1 23/74] x86/entry: Probe for Xen early during boot

[Jan Beulich]

>>> On 10.01.18 at 18:45,  wrote:
> On Fri, Jan 05, 2018 at 06:40:29AM -0700, Jan Beulich wrote:
>> >>> On 04.01.18 at 14:05,  wrote:
>> > --- a/xen/include/asm-x86/guest.h
>> > +++ b/xen/include/asm-x86/guest.h
>> > @@ -20,6 +20,7 @@
>> >  #define __X86_GUEST_H__
>> >  
>> >  #include 
>> > +#include 
>> >  
>> >  #endif /* __X86_GUEST_H__ */
>> 
>> I'm increasingly curious to understand what this header's purpose
>> is meant to be. It looks as if you mean source files to only ever
>> include this one, but why? Rather than exposing everything at
> 
> Yes there will be file that only includes this header -- the PV in HVM
> work doesn't need the PVH bits.

Either I'm not understanding your reply or you didn't understand
mine: I was trying to understand the purpose of guest.h if it
consists of only #include-s. In such a case, why can't the sources
needing certain bits simply include the headers they need, instead
of this container one?

Jan


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

[Xen-devel] [qemu-upstream-4.10-testing test] 117761: regressions - FAIL

[osstest service owner]

flight 117761 qemu-upstream-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117761/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 117345

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 117345

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 qemuubb019fb2cbbe23e2419e07bf347f45415360677d
baseline version:
 qemuua4166a0a50dda967f30c9d85fa8aa2ea2539798e

Last test of basis   117345  2017-12-19 18:48:50 Z   22 days
Testing same since   117730  2018-01-08 17:14:22 Z2 days2 attempts


People who touched revisions under test:
  Alex Williamson 
  Alexey Kardashevskiy 
  Anthony PERARD 
  Daniel Henrique Barboza 
  Daniel P. Berrange 
  David Gibson 
  Eric Auger 
  Eric Blake 
  Gerd Hoffmann 
  Greg 

Re: [Xen-devel] Consensus in Parallel Universe Responses to Spectre/Meltdown

[Anthony Liguori]

On Wed, Jan 10, 2018 at 7:38 PM, Rich Persaud  wrote:
> On Jan 10, 2018, at 11:39, Ian Jackson  wrote:
>
>
> [ Disclaimer: non-technical, PM-oriented message ahead.  Opinions expressed
> are those of this individual and not former/current employers or clients. ]
>

[Snip]

We had a plan and have been working together in a common direction but
the embargo broke early and we ran out of time.

We are now trying to figure out what to do given that.  We're all
trying to make the best of a bad situation.

Regards,

Anthony Liguori

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

[Xen-devel] Consensus in Parallel Universe Responses to Spectre/Meltdown

[Rich Persaud]

> On Jan 10, 2018, at 11:39, Ian Jackson  wrote:
> 
> Jan Beulich writes ("Re: Radical proposal v2: Publish Amazon's verison now, 
> Citrix's version soon"):
>> There are a couple of instances of "a branch", and I'm not really
>> clear on which one that would be, yet in part my opinion depends
>> on that, as this will affect what state certain branches will be in
>> for subsequent work. As I agree with the PVH shim being the
>> better baseline for work going forward, in particular I wouldn't like
>> to see the Vixen series becoming the base of any branch going to
>> be maintained going forward.
> 
> Anthony Liguori writes ("Re: [Xen-devel] Radical proposal v2: Publish 
> Amazon's verison now, Citrix's version soon"):
>> What I would suggest is the following:
>> 1) Merge Vixen into staging
>> 2) Backport Vixen into stable-4.10 and cut a release
> 
> We do not have time any longer (if we had time to start with) to
> reconcile these divergent views.

[ Disclaimer: non-technical, PM-oriented message ahead.  Opinions expressed are 
those of this individual and not former/current employers or clients. ]

Having worked with Xen since 2005, helping to ship XenServer, XenClient and 
OpenXT, I would like to challenge assertions that the community of Xen (or 
$HW_vendor or $OS_vendor or $APP_vendor) developers and users must settle for a 
non-consensus long-term mitigation.

Across the computer industry, it is clear that a small subset of specialists 
have known about this issue for some time:  developers who worked on candidate 
fixes ahead of the public announcement, experts who warned about 
microarchitecture risks years ago, and any adversaries who acted on their 
warnings.  Some people had advance information & time to consider candidate 
solutions, most [1] of the world did not.

As a customer of $HW_vendor / Xen / $OS_vendor / $APP_vendor, the last thing I 
want to hear is that world-class specialists who have had weeks/months to 
evaluate candidate fixes have been unable to reach agreement and propose to 
delegate the decision TO CUSTOMERS (?!)  That would be customers with only days 
of exposure to the CVE details, who still have to keep their regular business 
running, while trying to understand a complex security issue that eluded 
experts for decades.

As a general-purpose open-source hypervisor not tied to one operating system or 
use case, Xen has always been susceptible to fragmentation.  It can seem easier 
to make private modifications vs. upstreaming/revising changes for acceptance 
to a public codebase that serves many stakeholders.  The non-upstreamed Xen 
forks of Amazon EC2, Citrix XenClient and Bromium have made the Xen community 
less strong, by reducing public Xen contributions, including but not limited to 
security.

Yet… a once-in-decades (?) security issue has brought forth a public 
contribution from the private, parallel Xen universe that is Amazon EC2, 
accompanied by engineering resources to review and test a long-term solution 
that could be acceptable to the public Xen codebase.  If merged, this 
contribution could reduce fragmentation, increase dev/test resources and expand 
the risk pool of Xen customers sharing a common, battle-tested mitigation.  
Reconciliation of private/public Xen universes is never easy, but in this 
unique instance it would make the Xen community stronger.

Notes:

1) PVH is widely acknowledged as the long-term future of Xen.  The recent 
security issue makes it even more important that PVH be well designed and 
widely tested with resources from the broader Xen community.  Strategic PVH 
improvements need not be rushed to solve a tactical security issue. There are a 
number of Xen and security companies who have not yet contributed to recent 
public Xen design discussions, including Bromium.  If there is lack of design 
consensus, we can call upon additional Xen contributors to help achieve 
consensus.

2) Security:  large swathes of customers in many markets have neither the time 
nor expertise to make complex security decisions which involve functional 
tradeoffs and non-obvious interactions among opaque operating systems, 
microcode and hardware.  This category of customer wants to know that, (a) they 
are no worse off than "most" other customers, (b) they are on a supported path 
that will lead to a widely deployed long-term solution, and (c) they have clear 
documentation on operational constraints during their journey from temporary 
fix to long-term solution.

3) Community:  given the unprecedented nature of this Amazon code contribution, 
it is in the interest of the Xen community for Amazon EC2 to migrate to a 
solution that is used by upstream Xen customers.  This requires an incremental, 
bisectable path between already-deployed EC2 Vixen and in-development PVH shim. 
 The reason for the Xen community to support this approach, however difficult, 
is to un-fork Amazon's version of Xen, in exchange for expanding the pool 

[Xen-devel] [xen-unstable test] 117759: regressions - FAIL

[osstest service owner]

flight 117759 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117759/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail REGR. vs. 117311

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 117311
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 117311
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 117311
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 117311
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 117311
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 117311
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 117311
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 117311
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 117311
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 117311
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  d51baf310e530659f73e714acf57bdc46303
baseline version:
 xen  ec320542e4f4de12305551ef5e3cd4d2ced85771

Last test of basis   117311  2017-12-19 02:35:18 Z   23 days
Failing since117365  2017-12-20 07:31:12 Z   21 days8 attempts
Testing same since   117759  2018-01-09 19:35:58 Z1 days1 attempts


People who touched revisions 

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

[Stefano Stabellini]

On Fri, 22 Dec 2017, Mirela Simonovic wrote:
> This document contains our design specification for "suspend to RAM"
> support for ARM in Xen. It covers the basic suspend to RAM mechanism
> based on ARM PSCI standard, that would allow individual guests and
> Xen itself to suspend/resume.
> 
> We would appreciate your feedback.
> 
> Signed-off-by: Mirela Simonovic 

Sounds good to me

Acked-by: Stefano Stabellini 


> ---
> v2:
> -Improved specification according to comments
> -Added more implementation details
> -Incremented revision number to 1.1
> ---
>  docs/misc/arm/suspend-to-ram.txt | 266 
> +++
>  1 file changed, 266 insertions(+)
>  create mode 100644 docs/misc/arm/suspend-to-ram.txt
> 
> diff --git a/docs/misc/arm/suspend-to-ram.txt 
> b/docs/misc/arm/suspend-to-ram.txt
> new file mode 100644
> index 00..6e8f10d1ce
> --- /dev/null
> +++ b/docs/misc/arm/suspend-to-ram.txt
> @@ -0,0 +1,266 @@
> +% Suspend to RAM Support in Xen for ARM
> +% Revision 1.1
> +
> +
> +Overview
> +
> +
> +Suspend to RAM (in the following text 'suspend') for ARM in Xen should be
> +coordinated using ARM PSCI standard [1].
> +
> +Ideally, EL1/2 should suspend in the following order:
> +1) Unprivileged guests (DomUs) suspend
> +2) Privileged guest (Dom0) suspends
> +3) Xen suspends
> +
> +However, suspending unprivileged guests is not mandatory for suspending
> +Dom0 and Xen. System suspend initiated by Dom0 (step 2) is considered to be 
> an
> +ultimate decision to suspend the physical machine. Suspending of Xen (step 3)
> +is triggered whenever Dom0 completes suspend. Xen suspend leads to the full
> +suspend of EL2.
> +
> +If an unprivileged guest is not suspended at the moment when Dom0 initiates
> +its own suspend, the guest will be paused on Xen's suspend and unpaused on
> +Xen's resume. That way, a guest which doesn't have power management support
> +cannot prevent the physical system from suspending when the decision to 
> suspend
> +is made by privileged software (Dom0).
> +
> +Each guest in the system is responsible for suspending the devices it owns.
> +If a guest does not suspend a device, the device will continue to operate as
> +it is configured at the moment when the system suspends. If a device triggers
> +an interrupt while the physical system is suspended, the system will resume.
> +
> +It is recommended for an unprivileged guest to participate in power 
> management
> +in the following scenario:
> +Assume unprivileged guest owns a device which will trigger interrupt at some
> +point. This interrupt will wake-up the system. If such a behavior is not 
> wanted,
> +coordination between Dom0 and the guest is required in order to inform the 
> guest
> +about the intended physical system suspend. Then, the guest will have a 
> chance
> +to suspend the device or respond to the request in an abort fashion.
> +
> +Since this proposal is focused on implementing PSCI-based suspend mechanisms 
> in
> +Xen, communication with or among the guests is not covered by this document.
> +The order of suspending the guests is assumed to be guaranteed by the 
> software
> +running in EL1.
> +
> +This document covers the following:
> +1) Mechanism for suspending/resuming a guest:
> + 1.1) Suspend is initiated by the guest
> + 1.2) Resume is initiated by a device interrupt
> +2) Mechanism for pausing/unpausing running guests when Dom0 suspends
> +3) Mechanism for suspending/resuming Xen when Dom0 completes suspend
> +4) Resuming from any state on a wake-up event (device interrupt):
> + 4.1) Resume DomU on wake-up event when Dom0 is still running
> + 4.2) Resume DomU on wake-up event when Xen is suspended
> + 4.3) Resume Dom0 on wake-up event
> +
> +Mechanisms enumerated above will allow different kind of policies and
> +coordination among guests to be implemented in EL1. That is out of the scope 
> of
> +this document.
> +
> +-
> +Suspending Guests
> +-
> +
> +Suspend procedure for a guest consists of the following:
> +1) Suspending devices
> +2) Suspending non-boot CPUs (based on hotplug/PSCI)
> +3) System suspend, performed by the boot CPU
> +
> +Each guest should suspend the devices it owns just like it would when running
> +without Xen.
> +
> +Guests should suspend their non-boot vCPUs using the hotplug mechanism.
> +Virtual CPUs should be put offline using the already implemented PSCI 
> vCPU_OFF
> +call (prefix 'v' is added to distinguish PSCI calls made by guests to Xen, 
> which
> +affect virtual machines; as opposed to PSCI calls made by Xen to the EL3, 
> which
> +can affect power state of the physical machine).
> +
> +After suspending its non-boot vCPUs a guest should finalize the suspend by
> +making the vSYSTEM_SUSPEND PSCI call. The resume address is specified by the
> +guest via the vSYSTEM_SUSPEND entry_point_address argument. The 
> vSYSTEM_SUSPEND
> 

[Xen-devel] [linux-linus test] 117748: tolerable FAIL - PUSHED

[osstest service owner]

flight 117748 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117748/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 115643
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 115643
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 115643
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115643
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 115643
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115643
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 115643
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 115643
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 115643
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linuxef7f8cec80a0ba7bd00ece46844c8994117dc910
baseline version:
 linuxe4880bc5dfb1f02b152e62a894b5c6f3e995b3cf

Last test of basis   115643  2017-11-07 12:06:20 Z   64 days
Failing since115658  2017-11-08 02:33:06 Z   63 days   55 attempts
Testing same since   117748  2018-01-09 12:17:54 Z1 days1 attempts


2407 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm

[Xen-devel] [xen-4.9-testing baseline-only test] 74214: trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 74214 xen-4.9-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74214/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64  broken
 build-amd64-prev broken
 build-i386   broken
 build-armhf-pvopsbroken
 build-i386-xsm   broken
 build-amd64-xtf  broken
 build-amd64-xsm  broken
 build-amd64-pvopsbroken
 build-i386-pvops broken
 build-armhf-xsm  broken
 build-armhf  broken
 build-i386-prev  broken
 build-armhf-xsm   4 host-install(4) broken REGR. vs. 72498
 build-armhf   4 host-install(4) broken REGR. vs. 72498
 build-armhf-pvops 4 host-install(4) broken REGR. vs. 72498
 build-amd64   4 host-install(4) broken REGR. vs. 72498
 build-i3864 host-install(4) broken REGR. vs. 72498
 build-amd64-pvops 4 host-install(4) broken REGR. vs. 72498
 build-amd64-prev  4 host-install(4) broken REGR. vs. 72498
 build-i386-xsm4 host-install(4) broken REGR. vs. 72498
 build-amd64-xtf   4 host-install(4) broken REGR. vs. 72498
 build-amd64-xsm   4 host-install(4) broken REGR. vs. 72498
 build-i386-pvops  4 host-install(4) broken REGR. vs. 72498
 build-i386-prev   4 host-install(4) broken REGR. vs. 72498
 build-armhf-pvops 3 syslog-serverrunning
 build-armhf   3 syslog-serverrunning
 build-armhf-xsm   3 syslog-serverrunning

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-xtf-amd64-amd64-11 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-win10-i386  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 build-i386-rumprun1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-21 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 

Re: [Xen-devel] [RFC PATCH 01/60] hyper_dmabuf: initial working version of hyper_dmabuf drv

[Dongwon Kim]

On Wed, Dec 20, 2017 at 09:17:07AM +0100, Juergen Gross wrote:
> On 20/12/17 00:27, Dongwon Kim wrote:
> > I forgot to include this brief information about this patch series.
> > 
> > This patch series contains the implementation of a new device driver,
> > hyper_dmabuf, which provides a method for DMA-BUF sharing across
> > different OSes running on the same virtual OS platform powered by
> > a hypervisor.
> 
> Some general remarks regarding this series:
> 
> You are starting the whole driver in drivers/xen/ and in the last patch
> you move it over to drivers/dma-buf/. Why don't you use drivers/dma-buf/
> from the beginning? The same applies to e.g. patch 22 changing the
> license. Please make it easier for the reviewers by not letting us
> review the development history of your work.

Yeah, I tried to clean up our developement history but because of
dependencies among patches, I couldn't make those things clear in the
first place.

I will try to clean things up further.

> 
> Please run ./scripts/checkpatch.pl on each patch and correct the issues
> it is reporting. At the first glance I've seen several style problems
> which I won't comment until the next round.

hmm.. I ran the script only on the final version and try to fix all the
issues after that. If it's required for individual patches, I will clean
up every patch once again.

> 
> Please add the maintainers as Cc:, not only the related mailing lists.
> As you seem to aim supporting other hypervisors than Xen you might want
> to add virtualizat...@lists.linux-foundation.org as well.

Ok, thanks!

> 
> 
> Juergen

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

Re: [Xen-devel] [RFC PATCH 01/60] hyper_dmabuf: initial working version of hyper_dmabuf drv

[Dongwon Kim]

Yes, I will post a test application.
Thanks

On Wed, Dec 20, 2017 at 10:38:08AM +0200, Oleksandr Andrushchenko wrote:
> 
> On 12/20/2017 01:27 AM, Dongwon Kim wrote:
> >This patch series contains the implementation of a new device driver,
> >hyper_dmabuf, which provides a method for DMA-BUF sharing across
> >different OSes running on the same virtual OS platform powered by
> >a hypervisor.
> This is very interesting at least in context of embedded systems.
> Could you please share use-cases for this work and, if possible,
> sources of the test applications if any.
> 
> Thank you,
> Oleksandr

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

Re: [Xen-devel] [RFC PATCH 01/60] hyper_dmabuf: initial working version of hyper_dmabuf drv

[Dongwon Kim]

On Wed, Dec 20, 2017 at 10:59:57AM +0100, Daniel Vetter wrote:
> On Tue, Dec 19, 2017 at 03:27:31PM -0800, Dongwon Kim wrote:
> > I forgot to include this brief information about this patch series.
> > 
> > This patch series contains the implementation of a new device driver,
> > hyper_dmabuf, which provides a method for DMA-BUF sharing across
> > different OSes running on the same virtual OS platform powered by
> > a hypervisor.
> > 
> > Detailed information about this driver is described in a high-level doc
> > added by the second patch of the series.
> > 
> > [RFC PATCH 02/60] hyper_dmabuf: added a doc for hyper_dmabuf sharing
> > 
> > I am attaching 'Overview' section here as a summary.
> > 
> > --
> > Section 1. Overview
> > --
> > 
> > Hyper_DMABUF driver is a Linux device driver running on multiple Virtual
> > achines (VMs), which expands DMA-BUF sharing capability to the VM 
> > environment
> > where multiple different OS instances need to share same physical data 
> > without
> > data-copy across VMs.
> > 
> > To share a DMA_BUF across VMs, an instance of the Hyper_DMABUF drv on the
> > exporting VM (so called, “exporter”) imports a local DMA_BUF from the 
> > original
> > producer of the buffer, then re-exports it with an unique ID, 
> > hyper_dmabuf_id
> > for the buffer to the importing VM (so called, “importer”).
> > 
> > Another instance of the Hyper_DMABUF driver on importer registers
> > a hyper_dmabuf_id together with reference information for the shared 
> > physical
> > pages associated with the DMA_BUF to its database when the export happens.
> > 
> > The actual mapping of the DMA_BUF on the importer’s side is done by
> > the Hyper_DMABUF driver when user space issues the IOCTL command to access
> > the shared DMA_BUF. The Hyper_DMABUF driver works as both an importing and
> > exporting driver as is, that is, no special configuration is required.
> > Consequently, only a single module per VM is needed to enable cross-VM 
> > DMA_BUF
> > exchange.
> 
> So I know that most dma-buf implementations (especially lots of importers
> in drivers/gpu) break this, but fundamentally only the original exporter
> is allowed to know about the underlying pages. There's various scenarios
> where a dma-buf isn't backed by anything like a struct page.
> 
> So your first step of noodling the underlying struct page out from the
> dma-buf is kinda breaking the abstraction, and I think it's not a good
> idea to have that. Especially not for sharing across VMs.
> 
> I think a better design would be if hyper-dmabuf would be the dma-buf
> exporter in both of the VMs, and you'd import it everywhere you want to in
> some gpu/video/whatever driver in the VMs. That way hyper-dmabuf is always
> in control of the pages, and a lot of the troubling forwarding you
> currently need to do disappears.

It could be another way to implement dma-buf sharing however, it would break
the flexibility and transparency that this driver has now. With suggested
method, there will be two different types of dma-buf exist in general usage
model, one is local-dmabuf, a traditional dmabuf that can be shared only
within in the same OS instance and the other is cross-vm sharable dmabuf
created by hyper_dmabuf driver. 

The problem with this approach is that an application needs to know whether
the contents will be shared or not across VMs in advance before deciding
what type of dma-buf it needs to create. Otherwise, the application should
always use hyper_dmabuf as the exporter for all contents that can be possibly
shared in the future and I think this will require significant amount of
application changes and also adds unnecessary dependency on hyper_dmabuf driver.

> 
> 2nd thing: This seems very much related to what's happening around gvt and
> allowing at least the host (in a kvm based VM environment) to be able to
> access some of the dma-buf (or well, framebuffers in general) that the
> client is using. Adding some mailing lists for that.

I think you are talking about exposing framebuffer to another domain via GTT
memory sharing. And yes, one of primary use cases for hyper_dmabuf is to share
a framebuffer or other graphic object across VMs but it is designed to do it
via more general way using existing dma-buf framework. Also, we wanted to
make this feature available virtually for any sharable contents which can
currently be shared via dma-buf locally.

> -Daniel
> 
> > 
> > --
> > 
> > There is a git repository at github.com where this series of patches are all
> > integrated in Linux kernel tree based on the commit:
> > 
> > commit ae64f9bd1d3621b5e60d7363bc20afb46aede215
> > Author: Linus Torvalds 
> > Date:   Sun Dec 3 11:01:47 2017 -0500
> > 
> >  

Re: [Xen-devel] sidecar (hvm shim) creation script

[Doug Goldstein]

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



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

[Xen-devel] [PATCH v7 14/17] x86/entry: Clobber the Return Stack Buffer/Return Address Stack on entry to Xen

[Andrew Cooper]

ret instructions are speculated directly to values recorded in the RSB/RAS, as
there is no uncertainty in well-formed code.  Guests can take advantage of
this in two ways:

  1) If they can find a path in Xen which executes more ret instructions than
 call instructions.  (At least one in the waitqueue infrastructure,
 probably others.)
  2) Use the fact that the RSB/RAS in hardware is actually a circular stack
 without a concept of empty.  (When it logically empties, stale values
 will start being used.)

To mitigate, unconditionally overwrite the RSB on entry to Xen with gadgets
which will capture and contain rogue speculation.

Signed-off-by: Andrew Cooper 
---
v7:
 * Rewritten almost from scratch.  See code comments for details.
---
 docs/misc/xen-command-line.markdown |  6 +-
 xen/arch/x86/spec_ctrl.c| 34 +--
 xen/include/asm-x86/cpufeatures.h   |  2 ++
 xen/include/asm-x86/nops.h  |  1 +
 xen/include/asm-x86/spec_ctrl_asm.h | 40 +
 5 files changed, 80 insertions(+), 3 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 1aa1225..8510e47 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -246,7 +246,7 @@ enough. Setting this to a high value may cause boot 
failure, particularly if
 the NMI watchdog is also enabled.
 
 ### bti (x86)
-> `= List of [ thunk=retpoline|lfence|jmp, ibrs= ]`
+> `= List of [ thunk=retpoline|lfence|jmp, ibrs=, 
rsb_{vmexit,native}= ]`
 
 Branch Target Injection controls.  By default, Xen will pick the most
 appropriate BTI mitigations based on compiled in support, loaded microcode,
@@ -265,6 +265,10 @@ On hardware supporting IBRS, the `ibrs=` option can be 
used to force or
 prevent Xen using the feature itself.  If Xen is not using IBRS itself,
 functionality is still set up so IBRS can be virtualised for guests.
 
+The `rsb_vmexit=` and `rsb_native=` options can be used to fine tune when the
+RSB gets overwritten.  There are individual controls for an entry from HVM
+context, and an entry from a native (PV or Xen) context.
+
 ### xenheap\_megabytes (arm32)
 > `= `
 
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 7b0daaf..680fabe 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -33,6 +33,7 @@ static enum ind_thunk {
 THUNK_JMP,
 } opt_thunk __initdata = THUNK_DEFAULT;
 static int opt_ibrs __initdata = -1;
+static bool opt_rsb_native __initdata = true, opt_rsb_vmexit __initdata = true;
 
 static int __init parse_bti(const char *s)
 {
@@ -59,6 +60,10 @@ static int __init parse_bti(const char *s)
 }
 else if ( (val = parse_boolean("ibrs", s, ss)) >= 0 )
 opt_ibrs = val;
+else if ( (val = parse_boolean("rsb_native", s, ss)) >= 0 )
+opt_rsb_native = val;
+else if ( (val = parse_boolean("rsb_vmexit", s, ss)) >= 0 )
+opt_rsb_vmexit = val;
 else
 rc = -EINVAL;
 
@@ -95,13 +100,15 @@ static void __init print_details(enum ind_thunk thunk)
 printk(XENLOG_DEBUG "  Compiled-in support: INDIRECT_THUNK\n");
 
 printk(XENLOG_INFO
-   "BTI mitigations: Thunk %s, Others:%s\n",
+   "BTI mitigations: Thunk %s, Others:%s%s%s\n",
thunk == THUNK_NONE  ? "N/A" :
thunk == THUNK_RETPOLINE ? "RETPOLINE" :
thunk == THUNK_LFENCE? "LFENCE" :
thunk == THUNK_JMP   ? "JMP" : "?",
boot_cpu_has(X86_FEATURE_XEN_IBRS_SET)? " IBRS+" :
-   boot_cpu_has(X86_FEATURE_XEN_IBRS_CLEAR)  ? " IBRS-"  : "");
+   boot_cpu_has(X86_FEATURE_XEN_IBRS_CLEAR)  ? " IBRS-"  : "",
+   boot_cpu_has(X86_FEATURE_RSB_NATIVE)  ? " RSB_NATIVE" : "",
+   boot_cpu_has(X86_FEATURE_RSB_VMEXIT)  ? " RSB_VMEXIT" : "");
 }
 
 /* Calculate whether Retpoline is known-safe on this CPU. */
@@ -243,6 +250,29 @@ void __init init_speculation_mitigations(void)
 setup_force_cpu_cap(X86_FEATURE_XEN_IBRS_CLEAR);
 }
 
+/*
+ * PV guests can poison the RSB to any virtual address from which
+ * they can execute a call instruction.  This is necessarily outside
+ * of the Xen supervisor mappings.
+ *
+ * With SMEP enabled, the processor won't speculate into user
+ * mappings.  Therefore, we don't need to worry about poisoned
+ * entries from 64bit PV guests.
+ *
+ * 32bit PV guest kernels run in ring 1, so use supervisor mappings.
+ * If a processors speculates to 32bit PV guest kernel mappings, it is
+ * speculating in 64bit supervisor mode, and can leak data.
+ */
+if ( opt_rsb_native )
+setup_force_cpu_cap(X86_FEATURE_RSB_NATIVE);
+
+/*
+ * HVM guests can always poison the RSB to point at Xen supervisor
+ * mappings.
+ */
+if ( opt_rsb_vmexit )
+   

[Xen-devel] [PATCH v7 11/17] x86: Protect unaware domains from meddling hyperthreads

[Andrew Cooper]

Set STIBP behind the guests back if it knows about IBRS but not STIBP, and no
MSR_SPEC_CTRL protection active.

Signed-off-by: Andrew Cooper 
---
v7:
 * Move logic into a static inline helper.
---
 xen/arch/x86/domain.c|  8 
 xen/arch/x86/msr.c   |  3 ++-
 xen/include/asm-x86/cpufeature.h |  3 +++
 xen/include/asm-x86/spec_ctrl.h  | 21 +
 4 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index da1bf1a..8849e3f 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -65,6 +65,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
@@ -2030,6 +2031,13 @@ int domain_relinquish_resources(struct domain *d)
  */
 void cpuid_policy_updated(struct vcpu *v)
 {
+const struct cpuid_policy *cp = v->domain->arch.cpuid;
+struct msr_vcpu_policy *vp = v->arch.msr;
+
+/* Calculate a safe host default. */
+if ( cp->feat.ibrsb )
+vp->spec_ctrl.host = spec_ctrl_host_val(v->domain, 
vp->spec_ctrl.guest);
+
 if ( is_hvm_vcpu(v) )
 hvm_cpuid_policy_changed(v);
 }
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index 697cc6e..45c4d78 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct msr_domain_policy __read_mostly hvm_max_msr_domain_policy,
  __read_mostly  pv_max_msr_domain_policy;
@@ -181,7 +182,7 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
  (cp->feat.stibp ? SPEC_CTRL_STIBP : 0)) )
 goto gp_fault; /* Rsvd bit set? */
 vp->spec_ctrl.guest = val;
-vp->spec_ctrl.host  = val;
+vp->spec_ctrl.host = spec_ctrl_host_val(d, val);
 break;
 
 case MSR_PRED_CMD:
diff --git a/xen/include/asm-x86/cpufeature.h b/xen/include/asm-x86/cpufeature.h
index adc333f..988a834 100644
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -100,6 +100,9 @@
 /* CPUID level 0x8007.edx */
 #define cpu_has_itscboot_cpu_has(X86_FEATURE_ITSC)
 
+/* CPUID level 0x0007:0.edx */
+#define cpu_has_stibp   boot_cpu_has(X86_FEATURE_STIBP)
+
 /* Synthesized. */
 #define cpu_has_arch_perfmonboot_cpu_has(X86_FEATURE_ARCH_PERFMON)
 #define cpu_has_cpuid_faulting  boot_cpu_has(X86_FEATURE_CPUID_FAULTING)
diff --git a/xen/include/asm-x86/spec_ctrl.h b/xen/include/asm-x86/spec_ctrl.h
index e088a55..77f7c60 100644
--- a/xen/include/asm-x86/spec_ctrl.h
+++ b/xen/include/asm-x86/spec_ctrl.h
@@ -20,8 +20,29 @@
 #ifndef __X86_SPEC_CTRL_H__
 #define __X86_SPEC_CTRL_H__
 
+#include 
+
 void init_speculation_mitigations(void);
 
+/*
+ * For guests which know about IBRS but are not told about STIBP running on
+ * hardware supporting hyperthreading, the guest doesn't know to protect
+ * itself fully.  (Such a guest won't be permitted direct access to the MSR.)
+ * Have Xen fill in the gaps, so an unaware guest can't be interfered with by
+ * a meddling guest on an adjacent hyperthread.
+ */
+static inline unsigned int spec_ctrl_host_val(const struct domain *d,
+  unsigned int guest_val)
+{
+const struct cpuid_policy *cp = d->arch.cpuid;
+
+if ( !cp->feat.stibp && cpu_has_stibp &&
+ !(guest_val & (SPEC_CTRL_IBRS | SPEC_CTRL_STIBP)) )
+return SPEC_CTRL_STIBP;
+else
+return guest_val;
+}
+
 #endif /* !__X86_SPEC_CTRL_H__ */
 
 /*
-- 
2.1.4


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

[Xen-devel] [PATCH v7 17/17] x86/idle: Clear SPEC_CTRL while idle

[Andrew Cooper]

On contemporary hardware, setting IBRS/STIBP has a performance impact on
adjacent hyperthreads.  It is therefore recommended to clear the setting
before becoming idle, to avoid an idle core preventing adjacent userspace
execution from running at full performance.

Care must be taken to ensure there are no ret or indirect branch instructions
between spec_ctrl_{enter,exit}_idle() invocations, which are forced always
inline.  Care must also be taken to avoid using spec_ctrl_enter_idle() between
flushing caches and becoming idle, in cases where that matters.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
---
 xen/arch/x86/acpi/cpu_idle.c| 21 +
 xen/arch/x86/cpu/mwait-idle.c   |  7 +++
 xen/arch/x86/domain.c   |  8 
 xen/include/asm-x86/spec_ctrl.h | 34 ++
 4 files changed, 70 insertions(+)

diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index cb1c5da..3f72bda 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -55,6 +55,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*#define DEBUG_PM_CX*/
 
@@ -414,8 +415,14 @@ void mwait_idle_with_hints(unsigned int eax, unsigned int 
ecx)
  */
 if ( (expires > NOW() || expires == 0) && !softirq_pending(cpu) )
 {
+struct cpu_info *info = get_cpu_info();
+
 cpumask_set_cpu(cpu, _mwait_flags);
+
+spec_ctrl_enter_idle(info);
 __mwait(eax, ecx);
+spec_ctrl_exit_idle(info);
+
 cpumask_clear_cpu(cpu, _mwait_flags);
 }
 
@@ -430,6 +437,8 @@ static void acpi_processor_ffh_cstate_enter(struct 
acpi_processor_cx *cx)
 
 static void acpi_idle_do_entry(struct acpi_processor_cx *cx)
 {
+struct cpu_info *info = get_cpu_info();
+
 switch ( cx->entry_method )
 {
 case ACPI_CSTATE_EM_FFH:
@@ -437,15 +446,19 @@ static void acpi_idle_do_entry(struct acpi_processor_cx 
*cx)
 acpi_processor_ffh_cstate_enter(cx);
 return;
 case ACPI_CSTATE_EM_SYSIO:
+spec_ctrl_enter_idle(info);
 /* IO port based C-state */
 inb(cx->address);
 /* Dummy wait op - must do something useless after P_LVL2 read
because chipsets cannot guarantee that STPCLK# signal
gets asserted in time to freeze execution properly. */
 inl(pmtmr_ioport);
+spec_ctrl_exit_idle(info);
 return;
 case ACPI_CSTATE_EM_HALT:
+spec_ctrl_enter_idle(info);
 safe_halt();
+spec_ctrl_exit_idle(info);
 local_irq_disable();
 return;
 }
@@ -573,7 +586,13 @@ static void acpi_processor_idle(void)
 if ( pm_idle_save )
 pm_idle_save();
 else
+{
+struct cpu_info *info = get_cpu_info();
+
+spec_ctrl_enter_idle(info);
 safe_halt();
+spec_ctrl_exit_idle(info);
+}
 return;
 }
 
@@ -752,6 +771,7 @@ void acpi_dead_idle(void)
  * Otherwise, CPU may still hold dirty data, breaking cache coherency,
  * leading to strange errors.
  */
+spec_ctrl_enter_idle(get_cpu_info());
 wbinvd();
 
 while ( 1 )
@@ -781,6 +801,7 @@ void acpi_dead_idle(void)
 u32 address = cx->address;
 u32 pmtmr_ioport_local = pmtmr_ioport;
 
+spec_ctrl_enter_idle(get_cpu_info());
 wbinvd();
 
 while ( 1 )
diff --git a/xen/arch/x86/cpu/mwait-idle.c b/xen/arch/x86/cpu/mwait-idle.c
index 762dff1..e357f29 100644
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -58,6 +58,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define MWAIT_IDLE_VERSION "0.4.1"
@@ -736,7 +737,13 @@ static void mwait_idle(void)
if (pm_idle_save)
pm_idle_save();
else
+   {
+   struct cpu_info *info = get_cpu_info();
+
+   spec_ctrl_enter_idle(info);
safe_halt();
+   spec_ctrl_exit_idle(info);
+   }
return;
}
 
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ba10ed9..04e9902 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -55,6 +55,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -75,9 +76,15 @@ void (*dead_idle) (void) __read_mostly = default_dead_idle;
 
 static void default_idle(void)
 {
+struct cpu_info *info = get_cpu_info();
+
 local_irq_disable();
 if ( cpu_is_haltable(smp_processor_id()) )
+{
+spec_ctrl_enter_idle(info);
 safe_halt();
+spec_ctrl_exit_idle(info);
+}
 else
 local_irq_enable();
 }
@@ -89,6 +96,7 @@ void default_dead_idle(void)
  * held by the CPUs spinning here indefinitely, and get discarded by
  * a subsequent INIT.
  */
+

[Xen-devel] [PATCH v7 15/17] x86/ctxt: Issue a speculation barrier between vcpu contexts

[Andrew Cooper]

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
---
v7:
 * Use the opt_ibpb boolean rather than using a cpufeature flag.
---
 docs/misc/xen-command-line.markdown |  5 -
 xen/arch/x86/domain.c   |  3 +++
 xen/arch/x86/spec_ctrl.c| 10 +-
 xen/include/asm-x86/spec_ctrl.h |  2 ++
 4 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 8510e47..a24d585 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -246,7 +246,7 @@ enough. Setting this to a high value may cause boot 
failure, particularly if
 the NMI watchdog is also enabled.
 
 ### bti (x86)
-> `= List of [ thunk=retpoline|lfence|jmp, ibrs=, 
rsb_{vmexit,native}= ]`
+> `= List of [ thunk=retpoline|lfence|jmp, ibrs=, ibpb=, 
rsb_{vmexit,native}= ]`
 
 Branch Target Injection controls.  By default, Xen will pick the most
 appropriate BTI mitigations based on compiled in support, loaded microcode,
@@ -265,6 +265,9 @@ On hardware supporting IBRS, the `ibrs=` option can be used 
to force or
 prevent Xen using the feature itself.  If Xen is not using IBRS itself,
 functionality is still set up so IBRS can be virtualised for guests.
 
+On hardware supporting IBPB, the `ibpb=` option can be used to prevent Xen
+from issuing Branch Prediction Barriers on vcpu context switches.
+
 The `rsb_vmexit=` and `rsb_native=` options can be used to fine tune when the
 RSB gets overwritten.  There are individual controls for an entry from HVM
 context, and an entry from a native (PV or Xen) context.
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 8849e3f..ba10ed9 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1736,6 +1736,9 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
 }
 
 ctxt_switch_levelling(next);
+
+if ( opt_ibpb )
+wrmsrl(MSR_PRED_CMD, PRED_CMD_IBPB);
 }
 
 context_saved(prev);
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 680fabe..ae3e7d7 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -33,6 +33,7 @@ static enum ind_thunk {
 THUNK_JMP,
 } opt_thunk __initdata = THUNK_DEFAULT;
 static int opt_ibrs __initdata = -1;
+bool __read_mostly opt_ibpb = true;
 static bool opt_rsb_native __initdata = true, opt_rsb_vmexit __initdata = true;
 
 static int __init parse_bti(const char *s)
@@ -60,6 +61,8 @@ static int __init parse_bti(const char *s)
 }
 else if ( (val = parse_boolean("ibrs", s, ss)) >= 0 )
 opt_ibrs = val;
+else if ( (val = parse_boolean("ibpb", s, ss)) >= 0 )
+opt_ibpb = val;
 else if ( (val = parse_boolean("rsb_native", s, ss)) >= 0 )
 opt_rsb_native = val;
 else if ( (val = parse_boolean("rsb_vmexit", s, ss)) >= 0 )
@@ -100,13 +103,14 @@ static void __init print_details(enum ind_thunk thunk)
 printk(XENLOG_DEBUG "  Compiled-in support: INDIRECT_THUNK\n");
 
 printk(XENLOG_INFO
-   "BTI mitigations: Thunk %s, Others:%s%s%s\n",
+   "BTI mitigations: Thunk %s, Others:%s%s%s%s\n",
thunk == THUNK_NONE  ? "N/A" :
thunk == THUNK_RETPOLINE ? "RETPOLINE" :
thunk == THUNK_LFENCE? "LFENCE" :
thunk == THUNK_JMP   ? "JMP" : "?",
boot_cpu_has(X86_FEATURE_XEN_IBRS_SET)? " IBRS+" :
boot_cpu_has(X86_FEATURE_XEN_IBRS_CLEAR)  ? " IBRS-"  : "",
+   opt_ibpb  ? " IBPB"   : "",
boot_cpu_has(X86_FEATURE_RSB_NATIVE)  ? " RSB_NATIVE" : "",
boot_cpu_has(X86_FEATURE_RSB_VMEXIT)  ? " RSB_VMEXIT" : "");
 }
@@ -273,6 +277,10 @@ void __init init_speculation_mitigations(void)
 if ( opt_rsb_vmexit )
 setup_force_cpu_cap(X86_FEATURE_RSB_VMEXIT);
 
+/* Check we have hardware IBPB support before using it... */
+if ( !boot_cpu_has(X86_FEATURE_IBRSB) && !boot_cpu_has(X86_FEATURE_IBPB) )
+opt_ibpb = false;
+
 print_details(thunk);
 }
 
diff --git a/xen/include/asm-x86/spec_ctrl.h b/xen/include/asm-x86/spec_ctrl.h
index 45814d0..f139581 100644
--- a/xen/include/asm-x86/spec_ctrl.h
+++ b/xen/include/asm-x86/spec_ctrl.h
@@ -26,6 +26,8 @@
 
 void init_speculation_mitigations(void);
 
+extern bool opt_ibpb;
+
 /*
  * For guests which know about IBRS but are not told about STIBP running on
  * hardware supporting hyperthreading, the guest doesn't know to protect
-- 
2.1.4


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

[Xen-devel] [PATCH v7 10/17] x86/hvm: Permit guests direct access to MSR_{SPEC_CTRL, PRED_CMD}

[Andrew Cooper]

For performance reasons, HVM guests should have direct access to these MSRs
when possible.

Signed-off-by: Andrew Cooper 
---
v7:
 * Drop excess brackets
---
 xen/arch/x86/domctl.c  | 19 +++
 xen/arch/x86/hvm/svm/svm.c |  5 +
 xen/arch/x86/hvm/vmx/vmx.c | 18 ++
 xen/arch/x86/msr.c |  3 ++-
 xen/include/asm-x86/msr.h  |  5 -
 5 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 72b4489..e5fdde7 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -53,6 +53,7 @@ static int update_domain_cpuid_info(struct domain *d,
 struct cpuid_policy *p = d->arch.cpuid;
 const struct cpuid_leaf leaf = { ctl->eax, ctl->ebx, ctl->ecx, ctl->edx };
 int old_vendor = p->x86_vendor;
+unsigned int old_7d0 = p->feat.raw[0].d, old_e8b = p->extd.raw[8].b;
 bool call_policy_changed = false; /* Avoid for_each_vcpu() unnecessarily */
 
 /*
@@ -218,6 +219,14 @@ static int update_domain_cpuid_info(struct domain *d,
 
 d->arch.pv_domain.cpuidmasks->_7ab0 = mask;
 }
+
+/*
+ * If the IBSRB/STIBP policy has changed, we need to recalculate the
+ * MSR interception bitmaps and STIBP protection default.
+ */
+call_policy_changed = ((old_7d0 ^ p->feat.raw[0].d) &
+   (cpufeat_mask(X86_FEATURE_IBRSB) |
+cpufeat_mask(X86_FEATURE_STIBP)));
 break;
 
 case 0xa:
@@ -292,6 +301,16 @@ static int update_domain_cpuid_info(struct domain *d,
 d->arch.pv_domain.cpuidmasks->e1cd = mask;
 }
 break;
+
+case 0x8008:
+/*
+ * If the IBRB policy has changed, we need to recalculate the MSR
+ * interception bitmaps.
+ */
+call_policy_changed = (is_hvm_domain(d) &&
+   ((old_e8b ^ p->extd.raw[8].b) &
+cpufeat_mask(X86_FEATURE_IBPB)));
+break;
 }
 
 if ( call_policy_changed )
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index c48fdfa..ee47508 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -617,6 +617,7 @@ static void svm_cpuid_policy_changed(struct vcpu *v)
 {
 struct arch_svm_struct *arch_svm = >arch.hvm_svm;
 struct vmcb_struct *vmcb = arch_svm->vmcb;
+const struct cpuid_policy *cp = v->domain->arch.cpuid;
 u32 bitmap = vmcb_get_exception_intercepts(vmcb);
 
 if ( opt_hvm_fep ||
@@ -626,6 +627,10 @@ static void svm_cpuid_policy_changed(struct vcpu *v)
 bitmap &= ~(1U << TRAP_invalid_op);
 
 vmcb_set_exception_intercepts(vmcb, bitmap);
+
+/* Give access to MSR_PRED_CMD if the guest has been told about it. */
+svm_intercept_msr(v, MSR_PRED_CMD,
+  cp->extd.ibpb ? MSR_INTERCEPT_NONE : MSR_INTERCEPT_RW);
 }
 
 static void svm_sync_vmcb(struct vcpu *v)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index e036303..8609de3 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -656,6 +656,8 @@ void vmx_update_exception_bitmap(struct vcpu *v)
 
 static void vmx_cpuid_policy_changed(struct vcpu *v)
 {
+const struct cpuid_policy *cp = v->domain->arch.cpuid;
+
 if ( opt_hvm_fep ||
  (v->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor) )
 v->arch.hvm_vmx.exception_bitmap |= (1U << TRAP_invalid_op);
@@ -665,6 +667,22 @@ static void vmx_cpuid_policy_changed(struct vcpu *v)
 vmx_vmcs_enter(v);
 vmx_update_exception_bitmap(v);
 vmx_vmcs_exit(v);
+
+/*
+ * We can only pass though MSR_SPEC_CTRL if the guest knows about all bits
+ * in it.  Otherwise, Xen may be fixing up in the background.
+ */
+v->arch.msr->spec_ctrl.direct_access = cp->feat.ibrsb && cp->feat.stibp;
+if ( v->arch.msr->spec_ctrl.direct_access )
+vmx_clear_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW);
+else
+vmx_set_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW);
+
+/* MSR_PRED_CMD is safe to pass through if the guest knows about it. */
+if ( cp->feat.ibrsb || cp->extd.ibpb )
+vmx_clear_msr_intercept(v, MSR_PRED_CMD,  VMX_MSR_RW);
+else
+vmx_set_msr_intercept(v, MSR_PRED_CMD,  VMX_MSR_RW);
 }
 
 int vmx_guest_x86_mode(struct vcpu *v)
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index 02a7b49..697cc6e 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -132,7 +132,8 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr, 
uint64_t *val)
 case MSR_SPEC_CTRL:
 if ( !cp->feat.ibrsb )
 goto gp_fault;
-*val = vp->spec_ctrl.guest;
+*val = (vp->spec_ctrl.direct_access
+? vp->spec_ctrl.host : vp->spec_ctrl.guest);
 break;
 
 case MSR_INTEL_PLATFORM_INFO:
diff --git a/xen/include/asm-x86/msr.h b/xen/include/asm-x86/msr.h

[Xen-devel] [PATCH v7 12/17] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point

[Andrew Cooper]

We need to be able to either set or clear IBRS in Xen context, as well as
restore appropriate guest values in guest context.  See the documentation in
asm-x86/spec_ctrl_asm.h for details.

There is a semi-unrelated bugfix, where various asm_defn.h macros have a
hidden dependency on PAGE_SIZE, which results in an assembler error if used in
a .macro definition.

Signed-off-by: Andrew Cooper 
---
v7:
 * Spelling fixes
 * Reposition the semicolon fix.
---
 xen/arch/x86/hvm/svm/entry.S|   8 +-
 xen/arch/x86/hvm/vmx/entry.S|  11 ++
 xen/arch/x86/setup.c|   1 +
 xen/arch/x86/smpboot.c  |   2 +
 xen/arch/x86/x86_64/asm-offsets.c   |   6 +
 xen/arch/x86/x86_64/compat/entry.S  |  12 ++
 xen/arch/x86/x86_64/entry.S |  33 ++
 xen/include/asm-x86/asm_defns.h |   3 +
 xen/include/asm-x86/current.h   |   6 +
 xen/include/asm-x86/nops.h  |   6 +
 xen/include/asm-x86/spec_ctrl.h |   9 ++
 xen/include/asm-x86/spec_ctrl_asm.h | 230 
 12 files changed, 326 insertions(+), 1 deletion(-)
 create mode 100644 xen/include/asm-x86/spec_ctrl_asm.h

diff --git a/xen/arch/x86/hvm/svm/entry.S b/xen/arch/x86/hvm/svm/entry.S
index df86da0..fb1048b 100644
--- a/xen/arch/x86/hvm/svm/entry.S
+++ b/xen/arch/x86/hvm/svm/entry.S
@@ -79,6 +79,9 @@ UNLIKELY_END(svm_trace)
 or   $X86_EFLAGS_MBS,%rax
 mov  %rax,VMCB_rflags(%rcx)
 
+/* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */
+SPEC_CTRL_EXIT_TO_GUEST /* Req: b=curr %rsp=regs/cpuinfo, Clob: acd */
+
 pop  %r15
 pop  %r14
 pop  %r13
@@ -101,8 +104,11 @@ UNLIKELY_END(svm_trace)
 SAVE_ALL
 
 GET_CURRENT(bx)
-mov  VCPU_svm_vmcb(%rbx),%rcx
 
+SPEC_CTRL_ENTRY_FROM_VMEXIT /* Req: b=curr %rsp=regs/cpuinfo, Clob: 
acd */
+/* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */
+
+mov  VCPU_svm_vmcb(%rbx),%rcx
 movb $0,VCPU_svm_vmcb_in_sync(%rbx)
 mov  VMCB_rax(%rcx),%rax
 mov  %rax,UREGS_rax(%rsp)
diff --git a/xen/arch/x86/hvm/vmx/entry.S b/xen/arch/x86/hvm/vmx/entry.S
index b2f98be..21e959f 100644
--- a/xen/arch/x86/hvm/vmx/entry.S
+++ b/xen/arch/x86/hvm/vmx/entry.S
@@ -38,6 +38,9 @@ ENTRY(vmx_asm_vmexit_handler)
 movb $1,VCPU_vmx_launched(%rbx)
 mov  %rax,VCPU_hvm_guest_cr2(%rbx)
 
+SPEC_CTRL_ENTRY_FROM_VMEXIT /* Req: b=curr %rsp=regs/cpuinfo, Clob: 
acd */
+/* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */
+
 mov  %rsp,%rdi
 call vmx_vmexit_handler
 
@@ -68,6 +71,10 @@ UNLIKELY_END(realmode)
 call vmx_vmenter_helper
 test %al, %al
 jz .Lvmx_vmentry_restart
+
+/* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */
+SPEC_CTRL_EXIT_TO_GUEST /* Req: b=curr %rsp=regs/cpuinfo, Clob: acd */
+
 mov  VCPU_hvm_guest_cr2(%rbx),%rax
 
 pop  %r15
@@ -99,6 +106,10 @@ UNLIKELY_END(realmode)
 .Lvmx_vmentry_fail:
 sti
 SAVE_ALL
+
+SPEC_CTRL_ENTRY_FROM_PV /* Req: %rsp=regs/cpuinfo Clob: acd */
+/* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */
+
 call vmx_vmentry_failure
 BUG  /* vmx_vmentry_failure() shouldn't return. */
 
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 470427b..b2aa281 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -668,6 +668,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 set_processor_id(0);
 set_current(INVALID_VCPU); /* debug sanity. */
 idle_vcpu[0] = current;
+init_shadow_spec_ctrl_state();
 
 percpu_init_areas();
 
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 7b97ff8..a695d12 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -308,6 +309,7 @@ void start_secondary(void *unused)
 set_current(idle_vcpu[cpu]);
 this_cpu(curr_vcpu) = idle_vcpu[cpu];
 rdmsrl(MSR_EFER, this_cpu(efer));
+init_shadow_spec_ctrl_state();
 
 /*
  * Just as during early bootstrap, it is convenient here to disable
diff --git a/xen/arch/x86/x86_64/asm-offsets.c 
b/xen/arch/x86/x86_64/asm-offsets.c
index e136af6..7d36185 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -88,6 +88,7 @@ void __dummy__(void)
 OFFSET(VCPU_kernel_ss, struct vcpu, arch.pv_vcpu.kernel_ss);
 OFFSET(VCPU_iopl, struct vcpu, arch.pv_vcpu.iopl);
 OFFSET(VCPU_guest_context_flags, struct vcpu, arch.vgc_flags);
+OFFSET(VCPU_arch_msr, struct vcpu, arch.msr);
 OFFSET(VCPU_nmi_pending, struct vcpu, nmi_pending);
 OFFSET(VCPU_mce_pending, struct vcpu, mce_pending);
 OFFSET(VCPU_nmi_old_mask, struct vcpu, nmi_state.old_mask);
@@ -137,6 +138,8 @@ void __dummy__(void)
 

[Xen-devel] [PATCH v7 13/17] x86/boot: Calculate the most appropriate BTI mitigation to use

[Andrew Cooper]

Signed-off-by: Andrew Cooper 
---
v7:
 * static, and tweak comment
---
 docs/misc/xen-command-line.markdown |   6 ++-
 xen/arch/x86/spec_ctrl.c| 104 ++--
 2 files changed, 105 insertions(+), 5 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index b42abc6..1aa1225 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -246,7 +246,7 @@ enough. Setting this to a high value may cause boot 
failure, particularly if
 the NMI watchdog is also enabled.
 
 ### bti (x86)
-> `= List of [ thunk=retpoline|lfence|jmp ]`
+> `= List of [ thunk=retpoline|lfence|jmp, ibrs= ]`
 
 Branch Target Injection controls.  By default, Xen will pick the most
 appropriate BTI mitigations based on compiled in support, loaded microcode,
@@ -261,6 +261,10 @@ locations.  The default thunk is `retpoline` (generally 
preferred for Intel
 hardware), with the alternatives being `jmp` (a `jmp *%reg` gadget, minimal
 overhead), and `lfence` (an `lfence; jmp *%reg` gadget, preferred for AMD).
 
+On hardware supporting IBRS, the `ibrs=` option can be used to force or
+prevent Xen using the feature itself.  If Xen is not using IBRS itself,
+functionality is still set up so IBRS can be virtualised for guests.
+
 ### xenheap\_megabytes (arm32)
 > `= `
 
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 89e7287..7b0daaf 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -31,11 +32,12 @@ static enum ind_thunk {
 THUNK_LFENCE,
 THUNK_JMP,
 } opt_thunk __initdata = THUNK_DEFAULT;
+static int opt_ibrs __initdata = -1;
 
 static int __init parse_bti(const char *s)
 {
 const char *ss;
-int rc = 0;
+int val, rc = 0;
 
 do {
 ss = strchr(s, ',');
@@ -55,6 +57,8 @@ static int __init parse_bti(const char *s)
 else
 rc = -EINVAL;
 }
+else if ( (val = parse_boolean("ibrs", s, ss)) >= 0 )
+opt_ibrs = val;
 else
 rc = -EINVAL;
 
@@ -91,24 +95,82 @@ static void __init print_details(enum ind_thunk thunk)
 printk(XENLOG_DEBUG "  Compiled-in support: INDIRECT_THUNK\n");
 
 printk(XENLOG_INFO
-   "BTI mitigations: Thunk %s\n",
+   "BTI mitigations: Thunk %s, Others:%s\n",
thunk == THUNK_NONE  ? "N/A" :
thunk == THUNK_RETPOLINE ? "RETPOLINE" :
thunk == THUNK_LFENCE? "LFENCE" :
-   thunk == THUNK_JMP   ? "JMP" : "?");
+   thunk == THUNK_JMP   ? "JMP" : "?",
+   boot_cpu_has(X86_FEATURE_XEN_IBRS_SET)? " IBRS+" :
+   boot_cpu_has(X86_FEATURE_XEN_IBRS_CLEAR)  ? " IBRS-"  : "");
+}
+
+/* Calculate whether Retpoline is known-safe on this CPU. */
+static bool __init retpoline_safe(void)
+{
+unsigned int ucode_rev = this_cpu(ucode_cpu_info).cpu_sig.rev;
+
+if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+return true;
+
+if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ||
+ boot_cpu_data.x86 != 6 )
+return false;
+
+switch ( boot_cpu_data.x86_model )
+{
+case 0x17: /* Penryn */
+case 0x1d: /* Dunnington */
+case 0x1e: /* Nehalem */
+case 0x1f: /* Auburndale / Havendale */
+case 0x1a: /* Nehalem EP */
+case 0x2e: /* Nehalem EX */
+case 0x25: /* Westmere */
+case 0x2c: /* Westmere EP */
+case 0x2f: /* Westmere EX */
+case 0x2a: /* SandyBridge */
+case 0x2d: /* SandyBridge EP/EX */
+case 0x3a: /* IvyBridge */
+case 0x3e: /* IvyBridge EP/EX */
+case 0x3c: /* Haswell */
+case 0x3f: /* Haswell EX/EP */
+case 0x45: /* Haswell D */
+case 0x46: /* Haswell H */
+return true;
+
+/*
+ * Broadwell processors are retpoline-safe after specific microcode
+ * versions.
+ */
+case 0x3d: /* Broadwell */
+return ucode_rev >= 0x28;
+case 0x47: /* Broadwell H */
+return ucode_rev >= 0x1b;
+case 0x4f: /* Broadwell EP/EX */
+return ucode_rev >= 0xb25;
+case 0x56: /* Broadwell D */
+return false; /* TBD. */
+
+/*
+ * Skylake and later processors are not retpoline-safe.
+ */
+default:
+return false;
+}
 }
 
 void __init init_speculation_mitigations(void)
 {
 enum ind_thunk thunk = THUNK_DEFAULT;
+bool ibrs = false;
 
 /*
  * Has the user specified any custom BTI mitigations?  If so, follow their
  * instructions exactly and disable all heuristics.
  */
-if ( opt_thunk != THUNK_DEFAULT )
+if ( opt_thunk != THUNK_DEFAULT || opt_ibrs != -1 )
 {
 thunk = opt_thunk;
+ibrs  = !!opt_ibrs;
 }
 else
 {
@@ -124,7 +186,21 @@ void __init init_speculation_mitigations(void)
  */
 if ( 

[Xen-devel] [PATCH v7 08/17] x86/msr: Emulation of MSR_{SPEC_CTRL, PRED_CMD} for guests

[Andrew Cooper]

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
---
 xen/arch/x86/msr.c| 35 +++
 xen/include/asm-x86/msr.h | 12 
 2 files changed, 47 insertions(+)

diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index 31983ed..02a7b49 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -119,11 +119,22 @@ int init_vcpu_msr_policy(struct vcpu *v)
 
 int guest_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
 {
+const struct cpuid_policy *cp = v->domain->arch.cpuid;
 const struct msr_domain_policy *dp = v->domain->arch.msr;
 const struct msr_vcpu_policy *vp = v->arch.msr;
 
 switch ( msr )
 {
+case MSR_PRED_CMD:
+/* Write-only */
+goto gp_fault;
+
+case MSR_SPEC_CTRL:
+if ( !cp->feat.ibrsb )
+goto gp_fault;
+*val = vp->spec_ctrl.guest;
+break;
+
 case MSR_INTEL_PLATFORM_INFO:
 if ( !dp->plaform_info.available )
 goto gp_fault;
@@ -152,14 +163,38 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t 
val)
 {
 const struct vcpu *curr = current;
 struct domain *d = v->domain;
+const struct cpuid_policy *cp = d->arch.cpuid;
 struct msr_domain_policy *dp = d->arch.msr;
 struct msr_vcpu_policy *vp = v->arch.msr;
 
 switch ( msr )
 {
 case MSR_INTEL_PLATFORM_INFO:
+/* Read-only */
 goto gp_fault;
 
+case MSR_SPEC_CTRL:
+if ( !cp->feat.ibrsb )
+goto gp_fault; /* MSR available? */
+if ( val & ~(SPEC_CTRL_IBRS |
+ (cp->feat.stibp ? SPEC_CTRL_STIBP : 0)) )
+goto gp_fault; /* Rsvd bit set? */
+vp->spec_ctrl.guest = val;
+vp->spec_ctrl.host  = val;
+break;
+
+case MSR_PRED_CMD:
+if ( !cp->feat.ibrsb && !cp->extd.ibpb )
+goto gp_fault; /* MSR available? */
+
+/*
+ * The only defined behaviour is when writing PRED_CMD_IBPB.  In
+ * practice, real hardware accepts any value without faulting.
+ */
+if ( v == curr && (val & PRED_CMD_IBPB) )
+wrmsrl(MSR_PRED_CMD, PRED_CMD_IBPB);
+break;
+
 case MSR_INTEL_MISC_FEATURES_ENABLES:
 {
 uint64_t rsvd = ~0ull;
diff --git a/xen/include/asm-x86/msr.h b/xen/include/asm-x86/msr.h
index 2fbed02..3d0012d 100644
--- a/xen/include/asm-x86/msr.h
+++ b/xen/include/asm-x86/msr.h
@@ -223,6 +223,18 @@ struct msr_domain_policy
 /* MSR policy object for per-vCPU MSRs */
 struct msr_vcpu_policy
 {
+/* 0x0048 - MSR_SPEC_CTRL */
+struct {
+/*
+ * Only the bottom two bits are defined, so no need to waste space
+ * with uint64_t at the moment.  We maintain the guests idea of the
+ * value it wrote, and a value to install into hardware (extended to
+ * uint32_t to simplify the asm) which might be different.
+ */
+uint32_t host;
+uint8_t guest;
+} spec_ctrl;
+
 /* 0x0140  MSR_INTEL_MISC_FEATURES_ENABLES */
 struct {
 bool available; /* This MSR is non-architectural */
-- 
2.1.4


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

[Xen-devel] [PATCH v7 03/17] x86/boot: Report details of speculative mitigations

[Andrew Cooper]

Nothing very interesting at the moment, but the logic will grow as new
mitigations are added.

Signed-off-by: Andrew Cooper 
Acked-by: Jan Beulich 
---
 xen/arch/x86/Makefile   |  1 +
 xen/arch/x86/setup.c|  3 ++
 xen/arch/x86/spec_ctrl.c| 75 +
 xen/include/asm-x86/spec_ctrl.h | 35 +++
 4 files changed, 114 insertions(+)
 create mode 100644 xen/arch/x86/spec_ctrl.c
 create mode 100644 xen/include/asm-x86/spec_ctrl.h

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index b334366..e8c4963 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -57,6 +57,7 @@ obj-y += setup.o
 obj-y += shutdown.o
 obj-y += smp.o
 obj-y += smpboot.o
+obj-y += spec_ctrl.o
 obj-y += srat.o
 obj-y += string.o
 obj-y += sysctl.o
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 2e10c6b..470427b 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* opt_nosmp: If true, secondary processors are ignored. */
 static bool __initdata opt_nosmp;
@@ -1502,6 +1503,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 if ( cpu_has_fsgsbase )
 set_in_cr4(X86_CR4_FSGSBASE);
 
+init_speculation_mitigations();
+
 init_idle_domain();
 
 this_cpu(stubs.addr) = alloc_stub_page(smp_processor_id(),
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
new file mode 100644
index 000..256701a
--- /dev/null
+++ b/xen/arch/x86/spec_ctrl.c
@@ -0,0 +1,75 @@
+/**
+ * arch/x86/spec_ctrl.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see .
+ *
+ * Copyright (c) 2017-2018 Citrix Systems Ltd.
+ */
+#include 
+#include 
+
+#include 
+#include 
+
+enum ind_thunk {
+THUNK_DEFAULT, /* Decide which thunk to use at boot time. */
+THUNK_NONE,/* Missing compiler support for thunks. */
+
+THUNK_RETPOLINE,
+};
+
+static void __init print_details(enum ind_thunk thunk)
+{
+printk(XENLOG_DEBUG "Speculative mitigation facilities:\n");
+
+/* Compiled-in support which pertains to BTI mitigations. */
+if ( IS_ENABLED(CONFIG_INDIRECT_THUNK) )
+printk(XENLOG_DEBUG "  Compiled-in support: INDIRECT_THUNK\n");
+
+printk(XENLOG_INFO
+   "BTI mitigations: Thunk %s\n",
+   thunk == THUNK_NONE  ? "N/A" :
+   thunk == THUNK_RETPOLINE ? "RETPOLINE" : "?");
+}
+
+void __init init_speculation_mitigations(void)
+{
+enum ind_thunk thunk = THUNK_DEFAULT;
+
+/*
+ * Supplimentary minor adjustments.  Without compiler support, there are
+ * no thunks.
+ */
+if ( !IS_ENABLED(CONFIG_INDIRECT_THUNK) )
+thunk = THUNK_NONE;
+
+/*
+ * If there are still no thunk preferences, the compiled default is
+ * actually retpoline, and it is better than nothing.
+ */
+if ( thunk == THUNK_DEFAULT )
+thunk = THUNK_RETPOLINE;
+
+print_details(thunk);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-x86/spec_ctrl.h b/xen/include/asm-x86/spec_ctrl.h
new file mode 100644
index 000..e088a55
--- /dev/null
+++ b/xen/include/asm-x86/spec_ctrl.h
@@ -0,0 +1,35 @@
+/**
+ * include/asm-x86/spec_ctrl.h
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see .
+ *
+ * Copyright (c) 2017-2018 Citrix Systems Ltd.
+ */
+
+#ifndef __X86_SPEC_CTRL_H__
+#define __X86_SPEC_CTRL_H__
+
+void init_speculation_mitigations(void);
+
+#endif /* !__X86_SPEC_CTRL_H__ */

[Xen-devel] [PATCH v7 04/17] x86/amd: Try to set lfence as being Dispatch Serialising

[Andrew Cooper]

This property is required for the AMD's recommended mitigation for Branch
Target Injection, but Xen needs to cope with being unable to detect or modify
the MSR.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
---
 xen/arch/x86/cpu/amd.c| 35 ++-
 xen/include/asm-x86/cpufeature.h  |  1 +
 xen/include/asm-x86/cpufeatures.h |  1 +
 xen/include/asm-x86/msr-index.h   |  1 +
 4 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 5f36ac7..40c0bac 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -558,8 +558,41 @@ static void init_amd(struct cpuinfo_x86 *c)
wrmsr_amd_safe(0xc001100d, l, h & ~1);
}
 
+   /*
+* Attempt to set lfence to be Dispatch Serialising.  This MSR almost
+* certainly isn't virtualised (and Xen at least will leak the real
+* value in but silently discard writes), as well as being per-core
+* rather than per-thread, so do a full safe read/write/readback cycle
+* in the worst case.
+*/
+   if (c->x86 == 0x0f || c->x86 == 0x11)
+   /* Always dispatch serialising on this hardare. */
+   __set_bit(X86_FEATURE_LFENCE_DISPATCH, c->x86_capability);
+   else /* Implicily "== 0x10 || >= 0x12" by being 64bit. */ {
+   if (rdmsr_safe(MSR_AMD64_DE_CFG, value))
+   /* Unable to read.  Assume the safer default. */
+   __clear_bit(X86_FEATURE_LFENCE_DISPATCH,
+   c->x86_capability);
+   else if (value & AMD64_DE_CFG_LFENCE_SERIALISE)
+   /* Already dispatch serialising. */
+   __set_bit(X86_FEATURE_LFENCE_DISPATCH,
+ c->x86_capability);
+   else if (wrmsr_safe(MSR_AMD64_DE_CFG,
+   value | AMD64_DE_CFG_LFENCE_SERIALISE) ||
+rdmsr_safe(MSR_AMD64_DE_CFG, value) ||
+!(value & AMD64_DE_CFG_LFENCE_SERIALISE))
+   /* Attempt to set failed.  Assume the safer default. */
+   __clear_bit(X86_FEATURE_LFENCE_DISPATCH,
+   c->x86_capability);
+   else
+   /* Successfully enabled! */
+   __set_bit(X86_FEATURE_LFENCE_DISPATCH,
+ c->x86_capability);
+   }
+
/* MFENCE stops RDTSC speculation */
-   __set_bit(X86_FEATURE_MFENCE_RDTSC, c->x86_capability);
+   if (!cpu_has_lfence_dispatch)
+   __set_bit(X86_FEATURE_MFENCE_RDTSC, c->x86_capability);
 
switch(c->x86)
{
diff --git a/xen/include/asm-x86/cpufeature.h b/xen/include/asm-x86/cpufeature.h
index 84cc51d..adc333f 100644
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -104,6 +104,7 @@
 #define cpu_has_arch_perfmonboot_cpu_has(X86_FEATURE_ARCH_PERFMON)
 #define cpu_has_cpuid_faulting  boot_cpu_has(X86_FEATURE_CPUID_FAULTING)
 #define cpu_has_aperfmperf  boot_cpu_has(X86_FEATURE_APERFMPERF)
+#define cpu_has_lfence_dispatch boot_cpu_has(X86_FEATURE_LFENCE_DISPATCH)
 
 enum _cache_type {
 CACHE_TYPE_NULL = 0,
diff --git a/xen/include/asm-x86/cpufeatures.h 
b/xen/include/asm-x86/cpufeatures.h
index bc98227..58b37d6 100644
--- a/xen/include/asm-x86/cpufeatures.h
+++ b/xen/include/asm-x86/cpufeatures.h
@@ -22,3 +22,4 @@ XEN_CPUFEATURE(APERFMPERF,  (FSCAPINTS+0)*32+ 8) /* 
APERFMPERF */
 XEN_CPUFEATURE(MFENCE_RDTSC,(FSCAPINTS+0)*32+ 9) /* MFENCE synchronizes 
RDTSC */
 XEN_CPUFEATURE(XEN_SMEP,(FSCAPINTS+0)*32+10) /* SMEP gets used by Xen 
itself */
 XEN_CPUFEATURE(XEN_SMAP,(FSCAPINTS+0)*32+11) /* SMAP gets used by Xen 
itself */
+XEN_CPUFEATURE(LFENCE_DISPATCH, (FSCAPINTS+0)*32+12) /* lfence set as Dispatch 
Serialising */
diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h
index a834f3b..56f5359 100644
--- a/xen/include/asm-x86/msr-index.h
+++ b/xen/include/asm-x86/msr-index.h
@@ -207,6 +207,7 @@
 #define MSR_AMD64_IC_CFG   0xc0011021
 #define MSR_AMD64_DC_CFG   0xc0011022
 #define MSR_AMD64_DE_CFG   0xc0011029
+#define AMD64_DE_CFG_LFENCE_SERIALISE  (_AC(1, ULL) << 1)
 
 #define MSR_AMD64_DR0_ADDRESS_MASK 0xc0011027
 #define MSR_AMD64_DR1_ADDRESS_MASK 0xc0011019
-- 
2.1.4


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

[Xen-devel] [PATCH v7 06/17] x86/feature: Definitions for Indirect Branch Controls

[Andrew Cooper]

Contemporary processors are gaining Indirect Branch Controls via microcode
updates.  Intel are introducing one bit to indicate IBRS and IBPB support, and
a second bit for STIBP.  AMD are introducing IBPB only, so enumerate it with a
separate bit.

Furthermore, depending on compiler and microcode availability, we may want to
run Xen with IBRS set, or clear.

To use these facilities, we synthesise separate IBRS and IBPB bits for
internal use.  A lot of infrastructure is required before these features are
safe to offer to guests.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
Acked-by: Wei Liu 
---
v7:
 * Spelling fixes in the commit message.
---
 tools/libxl/libxl_cpuid.c   |  3 +++
 tools/misc/xen-cpuid.c  | 12 ++--
 xen/arch/x86/spec_ctrl.c| 17 +
 xen/include/asm-x86/cpufeatures.h   |  3 +++
 xen/include/asm-x86/msr-index.h |  8 
 xen/include/public/arch-x86/cpufeatureset.h |  3 +++
 xen/tools/gen-cpuid.py  |  5 +
 7 files changed, 49 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
index e692b61..81ba961 100644
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -202,6 +202,8 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list 
*cpuid, const char* str)
 
 {"avx512-4vnniw",0x0007,  0, CPUID_REG_EDX,  2,  1},
 {"avx512-4fmaps",0x0007,  0, CPUID_REG_EDX,  3,  1},
+{"ibrsb",0x0007,  0, CPUID_REG_EDX, 26,  1},
+{"stibp",0x0007,  0, CPUID_REG_EDX, 27,  1},
 
 {"lahfsahf", 0x8001, NA, CPUID_REG_ECX,  0,  1},
 {"cmplegacy",0x8001, NA, CPUID_REG_ECX,  1,  1},
@@ -239,6 +241,7 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list 
*cpuid, const char* str)
 
 {"invtsc",   0x8007, NA, CPUID_REG_EDX,  8,  1},
 
+{"ibpb", 0x8008, NA, CPUID_REG_EBX, 12,  1},
 {"nc",   0x8008, NA, CPUID_REG_ECX,  0,  8},
 {"apicidsize",   0x8008, NA, CPUID_REG_ECX, 12,  4},
 
diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
index 0831f75..8c3dac0 100644
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -149,7 +149,11 @@ static const char *str_e8b[32] =
 {
 [ 0] = "clzero",
 
-[1 ... 31] = "REZ",
+[1 ... 11] = "REZ",
+
+[12] = "ibpb",
+
+[13 ... 31] = "REZ",
 };
 
 static const char *str_7d0[32] =
@@ -158,7 +162,11 @@ static const char *str_7d0[32] =
 
 [ 2] = "avx512_4vnniw", [ 3] = "avx512_4fmaps",
 
-[4 ... 31] = "REZ",
+[4 ... 25] = "REZ",
+
+[26] = "ibrsb", [27] = "stibp",
+
+[28 ... 31] = "REZ",
 };
 
 static struct {
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index d601c02..89e7287 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -67,8 +67,25 @@ custom_param("bti", parse_bti);
 
 static void __init print_details(enum ind_thunk thunk)
 {
+unsigned int _7d0 = 0, e8b = 0, tmp;
+
+/* Collect diagnostics about available mitigations. */
+if ( boot_cpu_data.cpuid_level >= 7 )
+cpuid_count(7, 0, , , , &_7d0);
+if ( boot_cpu_data.extended_cpuid_level >= 0x8008 )
+cpuid(0x8008, , , , );
+
 printk(XENLOG_DEBUG "Speculative mitigation facilities:\n");
 
+/* Hardware features which pertain to speculative mitigations. */
+if ( (_7d0 & (cpufeat_mask(X86_FEATURE_IBRSB) |
+  cpufeat_mask(X86_FEATURE_STIBP))) ||
+ (e8b & cpufeat_mask(X86_FEATURE_IBPB)) )
+printk(XENLOG_DEBUG "  Hardware features:%s%s%s\n",
+   (_7d0 & cpufeat_mask(X86_FEATURE_IBRSB)) ? " IBRS/IBPB" : "",
+   (_7d0 & cpufeat_mask(X86_FEATURE_STIBP)) ? " STIBP" : "",
+   (e8b  & cpufeat_mask(X86_FEATURE_IBPB))  ? " IBPB"  : "");
+
 /* Compiled-in support which pertains to BTI mitigations. */
 if ( IS_ENABLED(CONFIG_INDIRECT_THUNK) )
 printk(XENLOG_DEBUG "  Compiled-in support: INDIRECT_THUNK\n");
diff --git a/xen/include/asm-x86/cpufeatures.h 
b/xen/include/asm-x86/cpufeatures.h
index ba1771b..dd2388f 100644
--- a/xen/include/asm-x86/cpufeatures.h
+++ b/xen/include/asm-x86/cpufeatures.h
@@ -25,3 +25,6 @@ XEN_CPUFEATURE(XEN_SMAP,(FSCAPINTS+0)*32+11) /* SMAP 
gets used by Xen it
 XEN_CPUFEATURE(LFENCE_DISPATCH, (FSCAPINTS+0)*32+12) /* lfence set as Dispatch 
Serialising */
 XEN_CPUFEATURE(IND_THUNK_LFENCE,(FSCAPINTS+0)*32+13) /* Use IND_THUNK_LFENCE */
 XEN_CPUFEATURE(IND_THUNK_JMP,   (FSCAPINTS+0)*32+14) /* Use IND_THUNK_JMP */
+XEN_CPUFEATURE(XEN_IBPB,(FSCAPINTS+0)*32+15) /* IBRSB || IBPB */
+XEN_CPUFEATURE(XEN_IBRS_SET,(FSCAPINTS+0)*32+16) /* IBRSB && IRBS set in 
Xen */
+XEN_CPUFEATURE(XEN_IBRS_CLEAR,  (FSCAPINTS+0)*32+17) /* IBRSB && IBRS clear in 
Xen */
diff --git 

[Xen-devel] [PATCH v7 07/17] x86/cmdline: Introduce a command line option to disable IBRS/IBPB, STIBP and IBPB

[Andrew Cooper]

Instead of gaining yet another top level boolean, introduce a more generic
cpuid= option.  Also introduce a helper function to parse a generic boolean
value.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
---
 docs/misc/xen-command-line.markdown | 12 
 xen/arch/x86/cpuid.c| 35 +++
 xen/common/kernel.c | 23 +++
 xen/include/xen/lib.h   |  7 +++
 4 files changed, 77 insertions(+)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 96e57c2..b42abc6 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -471,6 +471,18 @@ choice of `dom0-kernel` is deprecated and not supported by 
all Dom0 kernels.
   respectively.
 * `verbose` option can be included as a string or also as `verbose=`
 
+### cpuid (x86)
+> `= List of comma separated booleans`
+
+This option allows for fine tuning of the facilities Xen will use, after
+accounting for hardware capabilities as enumerated via CPUID.
+
+Currently accepted:
+
+The Speculation Control hardware features `ibrsb`, `stibp`, `ibpb` are used by
+default if avaiable.  They can be ignored, e.g. `no-ibrsb`, at which point Xen
+won't use them itself, and won't offer them to guests.
+
 ### cpuid\_mask\_cpu (AMD only)
 > `= fam_0f_rev_c | fam_0f_rev_d | fam_0f_rev_e | fam_0f_rev_f | fam_0f_rev_g 
 > | fam_10_rev_b | fam_10_rev_c | fam_11_rev_b`
 
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 5ee82d3..2ef71d2 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -18,6 +18,41 @@ static const uint32_t hvm_shadow_featuremask[] = 
INIT_HVM_SHADOW_FEATURES;
 static const uint32_t hvm_hap_featuremask[] = INIT_HVM_HAP_FEATURES;
 static const uint32_t deep_features[] = INIT_DEEP_FEATURES;
 
+static int __init parse_xen_cpuid(const char *s)
+{
+const char *ss;
+int val, rc = 0;
+
+do {
+ss = strchr(s, ',');
+if ( !ss )
+ss = strchr(s, '\0');
+
+if ( (val = parse_boolean("ibpb", s, ss)) >= 0 )
+{
+if ( !val )
+setup_clear_cpu_cap(X86_FEATURE_IBPB);
+}
+else if ( (val = parse_boolean("ibrsb", s, ss)) >= 0 )
+{
+if ( !val )
+setup_clear_cpu_cap(X86_FEATURE_IBRSB);
+}
+else if ( (val = parse_boolean("stibp", s, ss)) >= 0 )
+{
+if ( !val )
+setup_clear_cpu_cap(X86_FEATURE_STIBP);
+}
+else
+rc = -EINVAL;
+
+s = ss + 1;
+} while ( *ss );
+
+return rc;
+}
+custom_param("cpuid", parse_xen_cpuid);
+
 #define EMPTY_LEAF ((struct cpuid_leaf){})
 static void zero_leaves(struct cpuid_leaf *l,
 unsigned int first, unsigned int last)
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 8d137c5..19f9bad 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -244,6 +244,29 @@ int parse_bool(const char *s, const char *e)
 return -1;
 }
 
+int parse_boolean(const char *name, const char *s, const char *e)
+{
+size_t slen, nlen;
+int val = !!strncmp(s, "no-", 3);
+
+if ( !val )
+s += 3;
+
+slen = e ? ({ ASSERT(e >= s); e - s; }) : strlen(s);
+nlen = strlen(name);
+
+/* Does s now start with name? */
+if ( slen < nlen || strncmp(s, name, nlen) )
+return -1;
+
+switch ( s[nlen] )
+{
+case '\0': return val;
+case '=':  return parse_bool([nlen + 1], e);
+default:   return -1;
+}
+}
+
 unsigned int tainted;
 
 /**
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index ed00ae1..1d97713 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -74,6 +74,13 @@ void cmdline_parse(const char *cmdline);
 int runtime_parse(const char *line);
 int parse_bool(const char *s, const char *e);
 
+/**
+ * Given a specific name, parses a string of the form:
+ *   [no-]$NAME[=...]
+ * returning 0 or 1 for a recognised boolean, or -1 for an error.
+ */
+int parse_boolean(const char *name, const char *s, const char *e);
+
 /*#define DEBUG_TRACE_DUMP*/
 #ifdef DEBUG_TRACE_DUMP
 extern void debugtrace_dump(void);
-- 
2.1.4


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

[Xen-devel] [PATCH v7 02/17] x86: Support indirect thunks from assembly code

[Andrew Cooper]

Introduce INDIRECT_CALL and INDIRECT_JMP which either degrade to a normal
indirect branch, or dispatch to the __x86_indirect_thunk_* symbols.

Update all the manual indirect branches in to use the new thunks.  The
indirect branches in the early boot and kexec path are left intact as we can't
use the compiled-in thunks at those points.

Signed-off-by: Andrew Cooper 
---
v7:
 * Protect the jmp from the trampoline into the high mappings on the AP boot
   path, and the hand-crafted indirect jump in the PV IO emulation stubs.
 * Rebase over compiler changes
 * Spelling mistakes
 * Fix clang build
---
 xen/Rules.mk |  4 +--
 xen/arch/x86/Rules.mk|  6 +
 xen/arch/x86/boot/trampoline.S   | 24 --
 xen/arch/x86/extable.c   |  4 +--
 xen/arch/x86/pv/emul-priv-op.c   | 42 +++-
 xen/arch/x86/x86_64/entry.S  |  6 +++--
 xen/arch/x86/x86_emulate/x86_emulate.c   |  4 +--
 xen/common/wait.c|  8 +++---
 xen/include/asm-x86/asm_defns.h  |  8 ++
 xen/include/asm-x86/indirect_thunk_asm.h | 41 +++
 10 files changed, 122 insertions(+), 25 deletions(-)
 create mode 100644 xen/include/asm-x86/indirect_thunk_asm.h

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 2659f8a..3cf4075 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -66,8 +66,8 @@ endif
 
 AFLAGS-y+= -D__ASSEMBLY__
 
-# Clang's built-in assembler can't handle .code16/.code32/.code64 yet
-AFLAGS-$(clang) += -no-integrated-as
+# Clang's built-in assembler can't handle embedded .include's
+CFLAGS-$(clang) += -no-integrated-as
 
 ALL_OBJS := $(ALL_OBJS-y)
 
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index abcc4d4..70e9d8f 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -37,3 +37,9 @@ CFLAGS += -mindirect-branch=thunk-extern 
-mindirect-branch-register
 CFLAGS += -DCONFIG_INDIRECT_THUNK
 export CONFIG_INDIRECT_THUNK=y
 endif
+
+# Set up the assembler include path properly for older GCC toolchains.  Clang
+# objects to the agument being passed however.
+ifneq ($(clang),y)
+CFLAGS += -Wa,-I$(BASEDIR)/include
+endif
diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S
index 4d640f3..abf40f3 100644
--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -153,8 +153,28 @@ trampoline_protmode_entry:
 .code64
 start64:
 /* Jump to high mappings. */
-movabs  $__high_start,%rax
-jmpq*%rax
+movabs  $__high_start, %rdi
+
+#ifdef CONFIG_INDIRECT_THUNK
+/*
+ * If booting virtualised, or hot-onlining a CPU, sibling threads can
+ * attempt Branch Target Injection against this jmp.
+ *
+ * We've got no usable stack so can't use a RETPOLINE thunk, and are
+ * further than +- 2G from the high mappings so couldn't use JUMP_THUNK
+ * even if was a non-RETPOLINE thunk.  Futhermore, an LFENCE isn't
+ * necesserily safe to use at this point.
+ *
+ * As this isn't a hotpath, use a fully serialising event to reduce
+ * the speculation window as much as possible.  %ebx needs preserving
+ * for __high_start.
+ */
+mov %ebx, %esi
+cpuid
+mov %esi, %ebx
+#endif
+
+jmpq*%rdi
 
 #include "wakeup.S"
 
diff --git a/xen/arch/x86/extable.c b/xen/arch/x86/extable.c
index 6fffe05..72f30d9 100644
--- a/xen/arch/x86/extable.c
+++ b/xen/arch/x86/extable.c
@@ -158,7 +158,7 @@ static int __init stub_selftest(void)
 memcpy(ptr, tests[i].opc, ARRAY_SIZE(tests[i].opc));
 unmap_domain_page(ptr);
 
-asm volatile ( "call *%[stb]\n"
+asm volatile ( "INDIRECT_CALL %[stb]\n"
".Lret%=:\n\t"
".pushsection .fixup,\"ax\"\n"
".Lfix%=:\n\t"
@@ -167,7 +167,7 @@ static int __init stub_selftest(void)
".popsection\n\t"
_ASM_EXTABLE(.Lret%=, .Lfix%=)
: [exn] "+m" (res)
-   : [stb] "rm" (addr), "a" (tests[i].rax));
+   : [stb] "r" (addr), "a" (tests[i].rax));
 ASSERT(res == tests[i].res.raw);
 }
 
diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index 4087cf2..2e83451 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -73,42 +73,60 @@ void (*pv_post_outb_hook)(unsigned int port, u8 value);
 
 typedef void io_emul_stub_t(struct cpu_user_regs *);
 
+void __x86_indirect_thunk_rcx(void);
+
 static io_emul_stub_t *io_emul_stub_setup(struct priv_op_ctxt *ctxt, u8 opcode,
   unsigned int port, unsigned int 
bytes)
 {
+struct stubs *this_stubs = _cpu(stubs);
+unsigned long stub_va = 

[Xen-devel] [PATCH v7 09/17] x86/migrate: Move MSR_SPEC_CTRL on migrate

[Andrew Cooper]

Signed-off-by: Andrew Cooper 
Reviewed-by: Wei Liu 
Reviewed-by: Jan Beulich 
---
 xen/arch/x86/domctl.c  | 2 ++
 xen/arch/x86/hvm/hvm.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 5973d9f..72b4489 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1290,6 +1290,7 @@ long arch_do_domctl(
 struct xen_domctl_vcpu_msr msr = {};
 struct vcpu *v;
 static const uint32_t msrs_to_send[] = {
+MSR_SPEC_CTRL,
 MSR_INTEL_MISC_FEATURES_ENABLES,
 };
 uint32_t nr_msrs = ARRAY_SIZE(msrs_to_send);
@@ -1413,6 +1414,7 @@ long arch_do_domctl(
 
 switch ( msr.index )
 {
+case MSR_SPEC_CTRL:
 case MSR_INTEL_MISC_FEATURES_ENABLES:
 if ( guest_wrmsr(v, msr.index, msr.value) != X86EMUL_OKAY )
 break;
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index db282b5..ed36598 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1323,6 +1323,7 @@ static int hvm_load_cpu_xsave_states(struct domain *d, 
hvm_domain_context_t *h)
 
 #define HVM_CPU_MSR_SIZE(cnt) offsetof(struct hvm_msr, msr[cnt])
 static const uint32_t msrs_to_send[] = {
+MSR_SPEC_CTRL,
 MSR_INTEL_MISC_FEATURES_ENABLES,
 };
 static unsigned int __read_mostly msr_count_max = ARRAY_SIZE(msrs_to_send);
@@ -1458,6 +1459,7 @@ static int hvm_load_cpu_msrs(struct domain *d, 
hvm_domain_context_t *h)
 {
 int rc;
 
+case MSR_SPEC_CTRL:
 case MSR_INTEL_MISC_FEATURES_ENABLES:
 rc = guest_wrmsr(v, ctxt->msr[i].index, ctxt->msr[i].val);
 
-- 
2.1.4


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

[Xen-devel] [PATCH v7 05/17] x86: Introduce alternative indirect thunks

[Andrew Cooper]

Depending on hardware and microcode availability, we will want to replace
IND_THUNK_REPOLINE with other implementations.

For AMD hardware, choose IND_THUNK_LFENCE in preference to retpoline if lfence
is known to be (or was successfully made) dispatch serialising.

Signed-off-by: Andrew Cooper 
---
v7:
 * Rebase over compiler changes
 * Spelling/grammar fixes
 * Make opt_thunk static
---
 docs/misc/xen-command-line.markdown | 16 
 xen/arch/x86/indirect-thunk.S   | 17 +++--
 xen/arch/x86/spec_ctrl.c| 75 +++--
 xen/include/asm-x86/cpufeatures.h   |  2 +
 4 files changed, 104 insertions(+), 6 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 781110d..96e57c2 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -245,6 +245,22 @@ and not running softirqs. Reduce this if softirqs are not 
being run frequently
 enough. Setting this to a high value may cause boot failure, particularly if
 the NMI watchdog is also enabled.
 
+### bti (x86)
+> `= List of [ thunk=retpoline|lfence|jmp ]`
+
+Branch Target Injection controls.  By default, Xen will pick the most
+appropriate BTI mitigations based on compiled in support, loaded microcode,
+and hardware details.
+
+**WARNING: Any use of this option may interfere with heuristics.  Use with
+extreme care.**
+
+If Xen was compiled with INDIRECT_THUNK support, `thunk=` can be used to
+select which of the thunks gets patched into the `__x86_indirect_thunk_%reg`
+locations.  The default thunk is `retpoline` (generally preferred for Intel
+hardware), with the alternatives being `jmp` (a `jmp *%reg` gadget, minimal
+overhead), and `lfence` (an `lfence; jmp *%reg` gadget, preferred for AMD).
+
 ### xenheap\_megabytes (arm32)
 > `= `
 
diff --git a/xen/arch/x86/indirect-thunk.S b/xen/arch/x86/indirect-thunk.S
index 6289d0f..b7cb857 100644
--- a/xen/arch/x86/indirect-thunk.S
+++ b/xen/arch/x86/indirect-thunk.S
@@ -10,15 +10,26 @@
 ret
 .endm
 
+.macro IND_THUNK_LFENCE reg:req
+lfence
+jmp *%\reg
+.endm
+
+.macro IND_THUNK_JMP reg:req
+jmp *%\reg
+.endm
+
 /*
- * Build the __x86_indirect_thunk_* symbols.  Currently implement the
- * retpoline thunk only.
+ * Build the __x86.indirect_thunk.* symbols.  Execution lands on an
+ * alternative patch point which implements one of the above THUNK_*'s
  */
 .macro GEN_INDIRECT_THUNK reg:req
 .section .text.__x86_indirect_thunk_\reg, "ax", @progbits
 
 ENTRY(__x86_indirect_thunk_\reg)
-IND_THUNK_RETPOLINE \reg
+ALTERNATIVE_2 __stringify(IND_THUNK_RETPOLINE \reg),  \
+__stringify(IND_THUNK_LFENCE \reg), X86_FEATURE_IND_THUNK_LFENCE, \
+__stringify(IND_THUNK_JMP \reg),X86_FEATURE_IND_THUNK_JMP
 .endm
 
 /* Instantiate GEN_INDIRECT_THUNK for each register except %rsp. */
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 256701a..d601c02 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -16,18 +16,54 @@
  *
  * Copyright (c) 2017-2018 Citrix Systems Ltd.
  */
+#include 
 #include 
 #include 
 
 #include 
 #include 
 
-enum ind_thunk {
+static enum ind_thunk {
 THUNK_DEFAULT, /* Decide which thunk to use at boot time. */
 THUNK_NONE,/* Missing compiler support for thunks. */
 
 THUNK_RETPOLINE,
-};
+THUNK_LFENCE,
+THUNK_JMP,
+} opt_thunk __initdata = THUNK_DEFAULT;
+
+static int __init parse_bti(const char *s)
+{
+const char *ss;
+int rc = 0;
+
+do {
+ss = strchr(s, ',');
+if ( !ss )
+ss = strchr(s, '\0');
+
+if ( !strncmp(s, "thunk=", 6) )
+{
+s += 6;
+
+if ( !strncmp(s, "retpoline", ss - s) )
+opt_thunk = THUNK_RETPOLINE;
+else if ( !strncmp(s, "lfence", ss - s) )
+opt_thunk = THUNK_LFENCE;
+else if ( !strncmp(s, "jmp", ss - s) )
+opt_thunk = THUNK_JMP;
+else
+rc = -EINVAL;
+}
+else
+rc = -EINVAL;
+
+s = ss + 1;
+} while ( *ss );
+
+return rc;
+}
+custom_param("bti", parse_bti);
 
 static void __init print_details(enum ind_thunk thunk)
 {
@@ -40,7 +76,9 @@ static void __init print_details(enum ind_thunk thunk)
 printk(XENLOG_INFO
"BTI mitigations: Thunk %s\n",
thunk == THUNK_NONE  ? "N/A" :
-   thunk == THUNK_RETPOLINE ? "RETPOLINE" : "?");
+   thunk == THUNK_RETPOLINE ? "RETPOLINE" :
+   thunk == THUNK_LFENCE? "LFENCE" :
+   thunk == THUNK_JMP   ? "JMP" : "?");
 }
 
 void __init init_speculation_mitigations(void)
@@ -48,6 +86,31 @@ void __init init_speculation_mitigations(void)
 enum ind_thunk thunk = THUNK_DEFAULT;
 
 /*
+ * Has the user specified any custom BTI mitigations?  If so, follow their
+ * 

[Xen-devel] [PATCH v7 00/17] x86: Mitigations for SP2/CVE-2017-5715/Branch Target Injection

[Andrew Cooper]

In addition to this software series, you will need the following:

  1) A compiler which understands -mindirect-branch=thunk-external and
 -mindirect-branch-register.  A GCC patch series implementing this should
 be available imminently.  In the meantime, a development branch can be
 obtained from:

 https://github.com/hjl-tools/gcc/commits/hjl/indirect/gcc-7-branch/master

  2) New microcode from Intel and AMD.  These provide new MSRs for Xen to use,
 and virtualise for guest kernels to use.

There are some limitations, even with the work presented here.

  1) vCPU-to-vCPU SP2 attacks can only be mitigated at the hypervisor level
 with IBPB support, which for internal pipeline reasons, we do not expect
 to be made available on older processors.  For now, I will leave these
 details to the hardware vendors.

  2) Hardware lacking SMEP is in a worse position than hardware with SMEP.  If
 you have SMEP (Intel IvyBridge and later, Some AMD Fam16h and all Fam17h
 and later), make absolutely sure it is enabled in the BIOS and working.

  3) On hardware lacking SMEP support, it is still an open question how to
 protect against RSB-to-SMM speculation.  Native operating systems can fix
 this by prohibiting userspace from mmap()'ing addresses which alias the
 SMM range, but Xen has no feasible way of enforcing this restriction on
 PV guests, even if we could tolerate the ABI breakage.  (However, see the
 forthcoming SP3 mitigation series for alternatives for un trusted PV
 guests).

Please see the commit messages and comments for more details about mitigation
details and available options/impacts.  Its more complicated than I care to
reproduce here (and risk introducing a contradition).

~Andrew

Major changes in v7:
 * Adjust thunks to latest upstream gcc
 * Fix clang build
 * Rework RSB filling from scratch

Andrew Cooper (17):
  x86: Support compiling with indirect branch thunks
  x86: Support indirect thunks from assembly code
  x86/boot: Report details of speculative mitigations
  x86/amd: Try to set lfence as being Dispatch Serialising
  x86: Introduce alternative indirect thunks
  x86/feature: Definitions for Indirect Branch Controls
  x86/cmdline: Introduce a command line option to disable IBRS/IBPB, STIBP and 
IBPB
  x86/msr: Emulation of MSR_{SPEC_CTRL,PRED_CMD} for guests
  x86/migrate: Move MSR_SPEC_CTRL on migrate
  x86/hvm: Permit guests direct access to MSR_{SPEC_CTRL,PRED_CMD}
  x86: Protect unaware domains from meddling hyperthreads
  x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point
  x86/boot: Calculate the most appropriate BTI mitigation to use
  x86/entry: Clobber the Return Stack Buffer/Return Address Stack on entry to 
Xen
  x86/ctxt: Issue a speculation barrier between vcpu contexts
  x86/cpuid: Offer Indirect Branch Controls to guests
  x86/idle: Clear SPEC_CTRL while idle

 docs/misc/xen-command-line.markdown |  39 
 tools/libxc/xc_cpuid_x86.c  |   4 +-
 tools/libxl/libxl_cpuid.c   |   3 +
 tools/misc/xen-cpuid.c  |  12 +-
 xen/Rules.mk|   4 +-
 xen/arch/x86/Makefile   |   2 +
 xen/arch/x86/Rules.mk   |  13 ++
 xen/arch/x86/acpi/cpu_idle.c|  21 ++
 xen/arch/x86/boot/trampoline.S  |  24 ++-
 xen/arch/x86/cpu/amd.c  |  35 +++-
 xen/arch/x86/cpu/mwait-idle.c   |   7 +
 xen/arch/x86/cpuid.c|  43 
 xen/arch/x86/domain.c   |  19 ++
 xen/arch/x86/domctl.c   |  21 ++
 xen/arch/x86/extable.c  |   4 +-
 xen/arch/x86/hvm/hvm.c  |   2 +
 xen/arch/x86/hvm/svm/entry.S|   8 +-
 xen/arch/x86/hvm/svm/svm.c  |   5 +
 xen/arch/x86/hvm/vmx/entry.S|  11 ++
 xen/arch/x86/hvm/vmx/vmx.c  |  18 ++
 xen/arch/x86/indirect-thunk.S   |  38 
 xen/arch/x86/msr.c  |  37 
 xen/arch/x86/pv/emul-priv-op.c  |  42 ++--
 xen/arch/x86/setup.c|   4 +
 xen/arch/x86/smpboot.c  |   2 +
 xen/arch/x86/spec_ctrl.c| 295 
 xen/arch/x86/x86_64/asm-offsets.c   |   6 +
 xen/arch/x86/x86_64/compat/entry.S  |  12 ++
 xen/arch/x86/x86_64/entry.S |  39 +++-
 xen/arch/x86/x86_emulate/x86_emulate.c  |   4 +-
 xen/arch/x86/xen.lds.S  |   1 +
 xen/common/kernel.c |  23 +++
 xen/common/wait.c   |   8 +-
 xen/include/asm-x86/asm_defns.h |  11 ++
 xen/include/asm-x86/cpufeature.h|   4 +
 xen/include/asm-x86/cpufeatures.h   |   8 +
 xen/include/asm-x86/current.h   |   6 +
 xen/include/asm-x86/indirect_thunk_asm.h

Re: [Xen-devel] [BUG] kernel bug encountered at drivers/net/xen-netback/netback.c:430!

[Alex Braunegg]

> Actually no need... The underlying issue was really a bug and has
> been fixed in 4.14.11.

Thanks for tracking this down & spending time looking at this Paul.

Best regards,

Alex




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

Re: [Xen-devel] sidecar (hvm shim) creation script

[Dario Faggioli]

On Wed, 2018-01-10 at 15:41 +, 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 (da...@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 + 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)   - 0009fc00 (usable)
(XEN)  0009fc00 - 000a (reserved)
(XEN)  000f - 0010 (reserved)
(XEN)  0010 - 7f7ff000 (usable)
(XEN)  7f7ff000 - 7f80 (reserved)
(XEN)  fc00 - feff (reserved)
(XEN)  feff - 0001 (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.94] 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 
1
(d2) [  300.997576] pci dev 02:0 bar 14 size 00100: 0f008
(d2) [  300.998673] pci dev 02:0 bar 10 size 00100: 0c001
(d2) [  300.999767] pci dev 01:1 bar 20 size 00010: 0c101
(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] 

[Xen-devel] [xen-4.10-testing test] 117741: tolerable FAIL - PUSHED

[osstest service owner]

flight 117741 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117741/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  a87ec4833af47cdd166294f3f4db21231930d65d
baseline version:
 xen  44ce23c0d811c08bb559c46a171b234c3ff714a2

Last test of basis   117130  2017-12-14 07:54:15 Z   27 days
Failing since117522  2018-01-02 16:48:28 Z8 days7 attempts
Testing same since   117647  2018-01-05 07:14:51 Z5 days4 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel Kiper 
  Ingo Molnar 
  Jan Beulich 

Re: [Xen-devel] [PATCH RFC v1 20/74] x86: produce a binary that can be booted as PVH

[Wei Liu]

On Fri, Jan 05, 2018 at 04:39:33AM -0700, Jan Beulich wrote:
> > +#if defined(CONFIG_PVH_GUEST) && !defined(EFI)
> 
> The EFI part here then also wouldn't be necessary, afaict.

It is necessary otherwise efi.lds will contain .Xen.note directives,
which breaks the build.

Wei.

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

Re: [Xen-devel] [PATCH] MAINTAINERS: update my entries to new email address.

[Juergen Gross]

On 10/01/18 19:20, Dario Faggioli wrote:
> Signed-off-by: Dario Faggioli 

Acked-by: Juergen Gross 


Juergen

> ---
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> Cc: Juergen Gross 
> Cc: Meng Xu 
> ---
> Yes, I know. Again! Well, what can I say... Sorry for the nuisance. :-P
> ---
>  MAINTAINERS |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4d7092324a..64226e191a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -183,7 +183,7 @@ F:tools/blktap2/
>  
>  CPU POOLS
>  M:   Juergen Gross 
> -M:   Dario Faggioli 
> +M:   Dario Faggioli 
>  S:   Supported
>  F:   xen/common/cpupool.c
>  
> @@ -335,14 +335,14 @@ F:  tools/hotplug/Linux/remus-netbuf-setup
>  F:   tools/hotplug/Linux/block-drbd-probe
>  
>  RTDS SCHEDULER
> -M:   Dario Faggioli 
> +M:   Dario Faggioli 
>  M:   Meng Xu 
>  S:   Supported
>  F:   xen/common/sched_rt.c
>  
>  SCHEDULING
>  M:   George Dunlap 
> -M:   Dario Faggioli 
> +M:   Dario Faggioli 
>  S:   Supported
>  F:   xen/common/sched*
>  
> 
> 


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

Re: [Xen-devel] [PATCH] MAINTAINERS: update my entries to new email address.

[Konrad Rzeszutek Wilk]

On Wed, Jan 10, 2018 at 07:20:34PM +0100, Dario Faggioli wrote:
> Signed-off-by: Dario Faggioli 
> ---
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> Cc: Juergen Gross 
> Cc: Meng Xu 
> ---
> Yes, I know. Again! Well, what can I say... Sorry for the nuisance. :-P

Congratulations!!

> ---
>  MAINTAINERS |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4d7092324a..64226e191a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -183,7 +183,7 @@ F:tools/blktap2/
>  
>  CPU POOLS
>  M:   Juergen Gross 
> -M:   Dario Faggioli 
> +M:   Dario Faggioli 
>  S:   Supported
>  F:   xen/common/cpupool.c
>  
> @@ -335,14 +335,14 @@ F:  tools/hotplug/Linux/remus-netbuf-setup
>  F:   tools/hotplug/Linux/block-drbd-probe
>  
>  RTDS SCHEDULER
> -M:   Dario Faggioli 
> +M:   Dario Faggioli 
>  M:   Meng Xu 
>  S:   Supported
>  F:   xen/common/sched_rt.c
>  
>  SCHEDULING
>  M:   George Dunlap 
> -M:   Dario Faggioli 
> +M:   Dario Faggioli 
>  S:   Supported
>  F:   xen/common/sched*
>  
> 

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

Re: [Xen-devel] [PATCH] MAINTAINERS: update my entries to new email address.

[Meng Xu]

On Wed, Jan 10, 2018 at 1:20 PM, Dario Faggioli  wrote:
>
> Signed-off-by: Dario Faggioli 
> ---
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> Cc: Juergen Gross 
> Cc: Meng Xu 
> ---


Acked-by: Meng Xu 

Glad to see you back. :)

Best Regards,

Meng

---
Meng Xu
Ph.D. Candidate in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] Radical proposal v2: Publish Amazon's verison now, Citrix's version soon

[Anthony Liguori]

On Wed, Jan 10, 2018 at 5:51 AM, Juergen Gross  wrote:
> On 10/01/18 14:34, George Dunlap wrote:
>> * Executive summary
>>
>> - We've agreed on a "convergence" point for PV shim functionality that
>>   covers as many users as possible:
>>  - 'HVM' functionality: boots in HVM mode, has support for Xen 3.4
>>event channels, , booted via 'sidecar'
>>  - 'PVH' functionality: boots in PVH mode, booted via toolstack
>>changes
>>
>> - "Vixen" (the Amazon shim) and PVH shim (mostly developed by Citrix)
>>   each cover some users and not others; neither one (yet) covers all
>>   users
>>
>> - Vixen is ready for immediate release; PVH shim still needs some
>>   minor revision, and the toolstack component
>>
>> - Proposal:
>>  - Release "HOWTO" for Amazon shim v1 immediately (including a signed
>>tag on xenbits with the requisite patches)
>>  - Release "HOWTO" for PVH shim as soon as it's ready (including a
>>signed tag or tags on xenbits with the requisite patches)
>>  - Base future development on the PVH shim (porting over functionality
>>from the Amazon series)
>>
>> * Discussion
>>
>> In our discussions, we've generally identified four kinds of users /
>> consumers of Xen:
>>
>> 1. Those for whom upgrading to a newer version of Xen is the biggest
>> problem
>>
>> This could be people who have local changes they can't forward-port,
>> people whose SLAs forbid updating versions, or any number of other
>> things that make updating to a newer version of Xen unpalatable or
>> impossible.
>>
>> 2. Those for whom adding a QEMU instance to all PV guests is the
>> biggest problem
>>
>> Many users I've talked to extremely dislike the idea of adding QEMU
>> instances to all their PV guests, and would rather do upgrades and/or
>> modify guest types to avoid this
>>
>> 3. Those for whom modifying guest parameters is the biggest problem
>>
>> Many users I've talked to are using software which severely limits the
>> flexibility they have in terms of how guests are created
>>
>> 4. Those for whom some subset of features (migration, ballooning, vcpu
>> hotplug, ) is the biggest problem.
>>
>> This includes users who rely on these features, as well as software
>> providers that provide those features.
>>
>> Amazon is in the first category, and have developed a "PV shim"
>> series that addresses their needs.  They have also very kindly
>> shared the patches publicly for the community to be able to use.
>>
>> Citrix is in the fourth category, and have developed a "PV shim"
>> series that addresses their needs.  This shim also satisfies category 2,
>> and with some work could support category 3.
>>
>> Going forward, the best solutions for new hypervisors (Xen 4.11+)
>> would be to avoid needing QEMU, building the sidecar, and so on.  But
>> we still want to be able to support people running the 'HVM shim with
>> sidecar' version going forward.  So the "convergence point" we've all
>> seemed to agree on is to have a shim capable of satisfying all groups:
>>
>> - Can run in HVM mode back as far as Xen 3.4
>> - Can run in PVH mode, without QEMU or "sidecar", and doesn't require
>>   many toolstack changes
>> - Has feature parity with PV mode (migration, ballooning, vcpu
>>   migration, )
>>
>> The issue has been made public for nearly a week now, so there is a
>> lot of pressure to get a solution to our users as soon as possible; by
>> the end of the week at absolute latest, but today if possible.
>>
>> Amazon's v1 series:
>> - Has support for 'legacy' event channels
>>
>> - Has been tested by Amazon over a wide range of their hypervisor
>>   versions and guest types (including pvgrub types) back as far as Xen
>>   3.4
>>
>> - Uses HVM mode, and so has the overhead and security implications of
>>   running QEMU
>>
>> - Requires no L0 hypervisor or toolstack changes
>>
>> - Requires users to build a "boot sidecar" image for each unique guest
>>   boot configuration
>>
>> - Is missing many features, such as migration, memory ballooning, and
>>   vcpu hotplug
>>
>> - Has accurate 'stolen time' support
>>
>> Citrix's series:
>> - Has been extensively tested by XenServer's XenRT for Xen 4.7 (with
>>   PVH backports) and 4.10
>> - Uses PVH mode, and so doesn't have the overhead and security
>>   implications of running QEMU
>> - No need to build "boot sidecar"
>> - Requires hypervisor changes for versions for versions before 4.10
>>   which cannot reasonably be backported by the open-source team beyond
>>   Xen 4.8
>> - Requires toolstack changes in all versions
>> - Has migration, memory ballooning, and vcpu hotplug (extensively
>>   tested by XenRT)
>> - Doesn't have accurate 'stolen time' support
>> - Currently is missing a clean toolstack interface
>>
>> With some tweaks, Citrix's version has been made to boot in HVM mode.
>> However, this modified version:
>> - Doesn't support the 'legacy' event channel mode, and so won't work
>>   for versions as old as Amazon's
>> - Hasn't been tested extensively 

Re: [Xen-devel] [PATCH] MAINTAINERS: update my entries to new email address.

[Stefano Stabellini]

On Wed, 10 Jan 2018, Dario Faggioli wrote:
> Signed-off-by: Dario Faggioli 

Acked-by: Stefano Stabellini 


> ---
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> Cc: Juergen Gross 
> Cc: Meng Xu 
> ---
> Yes, I know. Again! Well, what can I say... Sorry for the nuisance. :-P
> ---
>  MAINTAINERS |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4d7092324a..64226e191a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -183,7 +183,7 @@ F:tools/blktap2/
>  
>  CPU POOLS
>  M:   Juergen Gross 
> -M:   Dario Faggioli 
> +M:   Dario Faggioli 
>  S:   Supported
>  F:   xen/common/cpupool.c
>  
> @@ -335,14 +335,14 @@ F:  tools/hotplug/Linux/remus-netbuf-setup
>  F:   tools/hotplug/Linux/block-drbd-probe
>  
>  RTDS SCHEDULER
> -M:   Dario Faggioli 
> +M:   Dario Faggioli 
>  M:   Meng Xu 
>  S:   Supported
>  F:   xen/common/sched_rt.c
>  
>  SCHEDULING
>  M:   George Dunlap 
> -M:   Dario Faggioli 
> +M:   Dario Faggioli 
>  S:   Supported
>  F:   xen/common/sched*
>  
> 

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

Re: [Xen-devel] [PATCH] MAINTAINERS: update my entries to new email address.

[Wei Liu]

On Wed, Jan 10, 2018 at 07:20:34PM +0100, Dario Faggioli wrote:
> Signed-off-by: Dario Faggioli 

Acked-by: Wei Liu 

Welcome back!

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

[Xen-devel] [PATCH] MAINTAINERS: update my entries to new email address.

[Dario Faggioli]

Signed-off-by: Dario Faggioli 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Juergen Gross 
Cc: Meng Xu 
---
Yes, I know. Again! Well, what can I say... Sorry for the nuisance. :-P
---
 MAINTAINERS |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4d7092324a..64226e191a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -183,7 +183,7 @@ F:  tools/blktap2/
 
 CPU POOLS
 M: Juergen Gross 
-M: Dario Faggioli 
+M: Dario Faggioli 
 S: Supported
 F: xen/common/cpupool.c
 
@@ -335,14 +335,14 @@ F:tools/hotplug/Linux/remus-netbuf-setup
 F: tools/hotplug/Linux/block-drbd-probe
 
 RTDS SCHEDULER
-M: Dario Faggioli 
+M: Dario Faggioli 
 M: Meng Xu 
 S: Supported
 F: xen/common/sched_rt.c
 
 SCHEDULING
 M: George Dunlap 
-M: Dario Faggioli 
+M: Dario Faggioli 
 S: Supported
 F: xen/common/sched*
 


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

Re: [Xen-devel] [BUG] kernel bug encountered at drivers/net/xen-netback/netback.c:430!

['Christoph Moench-Tegeder']

## Paul Durrant (paul.durr...@citrix.com):

> Actually no need... The underlying issue was really a bug and has
> been fixed in 4.14.11.

Oh. That explains why reverting the other patch "fixed" the problem -
I had skipped 4.14.10 and 4.14.11 - and the problem has gone away
independently of that.
Cool, I'll try vanilla 4.14.13 really soon now (once I'm home...)

Thanks for the investigation,
Christoph

-- 
Spare Space.

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

Re: [Xen-devel] [PATCH RFC v1 23/74] x86/entry: Probe for Xen early during boot

[Wei Liu]

On Fri, Jan 05, 2018 at 06:40:29AM -0700, Jan Beulich wrote:
> >>> On 04.01.18 at 14:05,  wrote:
> > --- /dev/null
> > +++ b/xen/arch/x86/guest/xen.c
> > @@ -0,0 +1,75 @@
> > +/**
> > + * arch/x86/guest/xen.c
> > + *
> > + * Support for detecting and running under Xen.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program; If not, see .
> > + *
> > + * Copyright (c) 2017 Citrix Systems Ltd.
> > + */
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +bool xen_guest;
> 
> __read_mostly?
> 
> > +static uint32_t xen_cpuid_base;
> 
> Depending on future use, __initdata or __read_mostly?
> 
> > --- a/xen/include/asm-x86/guest.h
> > +++ b/xen/include/asm-x86/guest.h
> > @@ -20,6 +20,7 @@
> >  #define __X86_GUEST_H__
> >  
> >  #include 
> > +#include 
> >  
> >  #endif /* __X86_GUEST_H__ */
> 
> I'm increasingly curious to understand what this header's purpose
> is meant to be. It looks as if you mean source files to only ever
> include this one, but why? Rather than exposing everything at

Yes there will be file that only includes this header -- the PV in HVM
work doesn't need the PVH bits.

Wei.

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

Re: [Xen-devel] sidecar (hvm shim) creation script

[Dario Faggioli]

On Wed, 2018-01-10 at 15:41 +, 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 (da...@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 + 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)   - 0009fc00 (usable)
(XEN)  0009fc00 - 000a (reserved)
(XEN)  000f - 0010 (reserved)
(XEN)  0010 - 7f7ff000 (usable)
(XEN)  7f7ff000 - 7f80 (reserved)
(XEN)  fc00 - feff (reserved)
(XEN)  feff - 0001 (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.94] 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 1
(d2) [  300.997576] pci dev 02:0 bar 14 size 00100: 0f008
(d2) [  300.998673] pci dev 02:0 bar 10 size 00100: 0c001
(d2) [  300.999767] pci dev 01:1 bar 20 size 00010: 0c101
(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] ... 

Re: [Xen-devel] Radical proposal v2: Publish Amazon's verison now, Citrix's version soon

[Stefano Stabellini]

On Wed, 10 Jan 2018, George Dunlap wrote:
> * Executive summary
> 
> - We've agreed on a "convergence" point for PV shim functionality that
>   covers as many users as possible:
>  - 'HVM' functionality: boots in HVM mode, has support for Xen 3.4
>event channels, , booted via 'sidecar'
>  - 'PVH' functionality: boots in PVH mode, booted via toolstack
>changes
> 
> - "Vixen" (the Amazon shim) and PVH shim (mostly developed by Citrix)
>   each cover some users and not others; neither one (yet) covers all
>   users

Sorry for being punctilious, but neither one can cover all users: there
are users without VT-x on their platform, and both approaches require
VT-x.

Both can only be temporary stop-gaps. I made a couple of more comments
in this respect below.



> - Vixen is ready for immediate release; PVH shim still needs some
>   minor revision, and the toolstack component
> 
> - Proposal:
>  - Release "HOWTO" for Amazon shim v1 immediately (including a signed
>tag on xenbits with the requisite patches)
>  - Release "HOWTO" for PVH shim as soon as it's ready (including a
>signed tag or tags on xenbits with the requisite patches)
>  - Base future development on the PVH shim (porting over functionality
>from the Amazon series)
> 
> * Discussion
> 
> In our discussions, we've generally identified four kinds of users /
> consumers of Xen:
> 
> 1. Those for whom upgrading to a newer version of Xen is the biggest
> problem
> 
> This could be people who have local changes they can't forward-port,
> people whose SLAs forbid updating versions, or any number of other
> things that make updating to a newer version of Xen unpalatable or
> impossible.
> 
> 2. Those for whom adding a QEMU instance to all PV guests is the
> biggest problem
> 
> Many users I've talked to extremely dislike the idea of adding QEMU
> instances to all their PV guests, and would rather do upgrades and/or
> modify guest types to avoid this
> 
> 3. Those for whom modifying guest parameters is the biggest problem
> 
> Many users I've talked to are using software which severely limits the
> flexibility they have in terms of how guests are created
> 
> 4. Those for whom some subset of features (migration, ballooning, vcpu
> hotplug, ) is the biggest problem.
> 
> This includes users who rely on these features, as well as software
> providers that provide those features.

5. Those that cannot deploy neither Vixen nor PVShim due to lack of VT-x



> Amazon is in the first category, and have developed a "PV shim"
> series that addresses their needs.  They have also very kindly
> shared the patches publicly for the community to be able to use.
> 
> Citrix is in the fourth category, and have developed a "PV shim"
> series that addresses their needs.  This shim also satisfies category 2,
> and with some work could support category 3.
> 
> Going forward, the best solutions for new hypervisors (Xen 4.11+)
> would be to avoid needing QEMU, building the sidecar, and so on.  But
> we still want to be able to support people running the 'HVM shim with
> sidecar' version going forward.  So the "convergence point" we've all
> seemed to agree on is to have a shim capable of satisfying all groups:

Going forward, the best solutions for new hypervisors (Xen 4.11+) is to
fix PV in a way that is secure without needing VT-x.



> - Can run in HVM mode back as far as Xen 3.4
> - Can run in PVH mode, without QEMU or "sidecar", and doesn't require
>   many toolstack changes
> - Has feature parity with PV mode (migration, ballooning, vcpu
>   migration, )
>
> The issue has been made public for nearly a week now, so there is a
> lot of pressure to get a solution to our users as soon as possible; by
> the end of the week at absolute latest, but today if possible.
> 
> Amazon's v1 series:
> - Has support for 'legacy' event channels
> 
> - Has been tested by Amazon over a wide range of their hypervisor
>   versions and guest types (including pvgrub types) back as far as Xen
>   3.4
> 
> - Uses HVM mode, and so has the overhead and security implications of
>   running QEMU
> 
> - Requires no L0 hypervisor or toolstack changes
> 
> - Requires users to build a "boot sidecar" image for each unique guest
>   boot configuration
> 
> - Is missing many features, such as migration, memory ballooning, and
>   vcpu hotplug
> 
> - Has accurate 'stolen time' support
> 
> Citrix's series:
> - Has been extensively tested by XenServer's XenRT for Xen 4.7 (with
>   PVH backports) and 4.10
> - Uses PVH mode, and so doesn't have the overhead and security
>   implications of running QEMU
> - No need to build "boot sidecar"
> - Requires hypervisor changes for versions for versions before 4.10
>   which cannot reasonably be backported by the open-source team beyond
>   Xen 4.8
> - Requires toolstack changes in all versions
> - Has migration, memory ballooning, and vcpu hotplug (extensively
>   tested by XenRT)
> - Doesn't have accurate 'stolen time' support
> - Currently is missing 

Re: [Xen-devel] [PATCH v4 02/39] arm/p2m: Add first altp2m HVMOP stubs

[Julien Grall]

On 10/01/18 17:16, Sergej Proskurin wrote:

Hi Julien,


Hi,



On 10/09/2017 06:43 PM, Julien Grall wrote:

Hi Sergej,

On 30/08/17 19:32, Sergej Proskurin wrote:

This commit copies and extends the altp2m-related code from x86 to ARM.
Functions that are no yet supported notify the caller or print a BUG
message stating their absence.


I am still concerned on the locking differing between x86 and Arm
(likely the former is wrong) and for maintain POV in the future.

Last year you said you were working on getting do_altp2m_op common
between x86 and Arm. What's the status?


I remember us having the discussion about pulling out common code of
both architectures. I still believe that this is necessary. Yet, as I
told you the last time, I really would like to first get the
implementation for ARM into mainline before blowing up this patch series
even more.


That's a no-go from my side from 2 reasons:
	1) You add burden in review. I have to make sure that every new code 
you add and make sure you don't get the locking wrong. Common code makes 
easier for that
	2) Most of features added to Arm that already coming from x86 are 
usually consolidated.


So to make clear, the current state:

NAcked-by: Julien Grall 

Cheers,

--
Julien Grall

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

[Xen-devel] [PATCH] vixen: port of shadow PV console's page for L2 DomU

[Sarah Newman]

The current version of vixen handles console output from the guest
but not console input to the guest. This adds guest input as in

0d50a85f x86/pv-shim: shadow PV console's page for L2 DomU,

but with read_smb moved up in guest_tx.

Signed-off-by: Sarah Newman 
---
 xen/arch/x86/guest/vixen.c| 42 +++
 xen/drivers/char/console.c|  6 +-
 xen/include/asm-x86/guest/vixen.h |  1 +
 3 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/guest/vixen.c b/xen/arch/x86/guest/vixen.c
index 08619d1..4491d82 100644
--- a/xen/arch/x86/guest/vixen.c
+++ b/xen/arch/x86/guest/vixen.c
@@ -245,6 +245,48 @@ static void vixen_interrupt(int irq, void *dev_id, struct 
cpu_user_regs *regs)
 vixen_upcall(smp_processor_id());
 }
 
+static void notify_guest(void)
+{
+struct evtchn *chn;
+chn = evtchn_from_port(hardware_domain, vixen_xencons_port);
+evtchn_port_set_pending(hardware_domain, chn->notify_vcpu_id, chn);
+}
+
+size_t vixen_guest_tx(char c)
+{
+size_t sent = 0;
+volatile struct xencons_interface *r = vixen_xencons_iface;
+XENCONS_RING_IDX cons, prod;
+
+if (r == NULL)
+return 0;
+
+cons = ACCESS_ONCE(r->in_cons);
+prod = r->in_prod;
+/* Update pointers before accessing the ring */
+smp_rmb();
+
+ASSERT((prod - cons) <= sizeof(r->in));
+
+/* Is the ring out of space? */
+if ( sizeof(r->in) - (prod - cons) == 0 )
+goto notify;
+
+
+r->in[MASK_XENCONS_IDX(prod++, r->in)] = c;
+sent++;
+
+/* Write to the ring before updating the pointer */
+smp_wmb();
+ACCESS_ONCE(r->in_prod) = prod;
+
+ notify:
+/* Always notify the guest: prevents receive path from getting stuck. */
+notify_guest();
+
+return sent;
+}
+
 bool vixen_ring_process(uint16_t port)
 {
 volatile struct xencons_interface *r = vixen_xencons_iface;
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index a83aeb2..be5875e 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -30,6 +30,7 @@
 #include  /* for do_console_io */
 #include 
 #include 
+#include 
 
 /* console: comma-separated list of console outputs. */
 static char __initdata opt_console[30] = OPT_CONSOLE_STR;
@@ -406,13 +407,16 @@ static void __serial_rx(char c, struct cpu_user_regs 
*regs)
 serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
 /* Always notify the guest: prevents receive path from getting stuck. */
 send_global_virq(VIRQ_CONSOLE);
+
+if ( is_vixen())
+vixen_guest_tx(c);
 }
 
 static void serial_rx(char c, struct cpu_user_regs *regs)
 {
 static int switch_code_count = 0;
 
-if ( switch_code && (c == switch_code) )
+if (!is_vixen() && switch_code && (c == switch_code) )
 {
 /* We eat CTRL- in groups of 3 to switch console input. */
 if ( ++switch_code_count == 3 )
diff --git a/xen/include/asm-x86/guest/vixen.h 
b/xen/include/asm-x86/guest/vixen.h
index eca263a..2e2666e 100644
--- a/xen/include/asm-x86/guest/vixen.h
+++ b/xen/include/asm-x86/guest/vixen.h
@@ -86,5 +86,6 @@ vixen_transform(struct domain *dom0,
 xen_pfn_t *pconsole_mfn, uint32_t *pconsole_evtchn);
 
 bool vixen_ring_process(uint16_t port);
+size_t vixen_guest_tx(char c);
 
 #endif
-- 
1.9.1


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

Re: [Xen-devel] [PATCH v4 02/39] arm/p2m: Add first altp2m HVMOP stubs

[Sergej Proskurin]

Hi Julien,


On 10/09/2017 06:43 PM, Julien Grall wrote:
> Hi Sergej,
>
> On 30/08/17 19:32, Sergej Proskurin wrote:
>> This commit copies and extends the altp2m-related code from x86 to ARM.
>> Functions that are no yet supported notify the caller or print a BUG
>> message stating their absence.
>
> I am still concerned on the locking differing between x86 and Arm
> (likely the former is wrong) and for maintain POV in the future.
>
> Last year you said you were working on getting do_altp2m_op common
> between x86 and Arm. What's the status?

I remember us having the discussion about pulling out common code of
both architectures. I still believe that this is necessary. Yet, as I
told you the last time, I really would like to first get the
implementation for ARM into mainline before blowing up this patch series
even more.

>
>> diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
>> index a56b3fe3fb..042bdda979 100644
>> --- a/xen/arch/arm/hvm.c
>> +++ b/xen/arch/arm/hvm.c
>> @@ -31,6 +31,99 @@
>>     #include 
>>   +#include 
>> +
>> +static int do_altp2m_op(XEN_GUEST_HANDLE_PARAM(void) arg)
>> +{
>> +    struct xen_hvm_altp2m_op a;
>> +    struct domain *d = NULL;
>> +    uint64_t mode;
>> +    int rc = 0;
>> +
>> +    if ( copy_from_guest(, arg, 1) )
>> +    return -EFAULT;
>> +
>> +    if ( a.pad1 || a.pad2 ||
>> + (a.version != HVMOP_ALTP2M_INTERFACE_VERSION) ||
>> + (a.cmd < HVMOP_altp2m_get_domain_state) ||
>> + (a.cmd > HVMOP_altp2m_change_gfn) )
>
> That exactly support my view above. You resent a series after a year
> and don't even look at what changed in x86.
>
> I don't expect any better improvement as people will add more features
> in each side.
>
> [...]
>
>> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
>> index 8dfc1d1ec2..0991a0a79d 100644
>> --- a/xen/include/asm-arm/domain.h
>> +++ b/xen/include/asm-arm/domain.h
>> @@ -145,6 +145,9 @@ struct arch_domain
>>   struct {
>>   uint8_t privileged_call_enabled : 1;
>>   } monitor;
>> +
>> +    /* altp2m: allow multiple copies of the host's p2m */
>> +    bool altp2m_active;
>
> Does it have to be in arch_domain? Can't this be done in common code?

I will investigate how to best combine this flag between both
architectures and provide a suggestion in v5.

Thanks
~Sergej


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

Re: [Xen-devel] [PATCH v4 07/39] arm/p2m: Move hostp2m init/teardown to individual functions

[Sergej Proskurin]

Hi Julien,


On 10/09/2017 07:15 PM, Julien Grall wrote:
> Hi Sergej,
>

[...]

>> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
>> index 5e86368010..3a1a38e7af 100644
>> --- a/xen/arch/arm/p2m.c
>> +++ b/xen/arch/arm/p2m.c
>> @@ -1203,27 +1203,65 @@ static void p2m_free_vmid(struct domain *d)
>>   spin_unlock(_alloc_lock);
>>   }
>>   -void p2m_teardown(struct domain *d)
>> +/* Reset this p2m table to be empty. */
>> +void p2m_flush_table(struct p2m_domain *p2m)
>>   {
>> -    struct p2m_domain *p2m = p2m_get_hostp2m(d);
>>   struct page_info *pg;
>> +    unsigned int i, j;
>> +    lpae_t *table;
>> +
>> +    if ( p2m->root )
>> +    {
>> +    /* Clear all concatenated root level pages. */
>> +    for ( i = 0; i < P2M_ROOT_PAGES; i++ )
>> +    {
>> +    table = __map_domain_page(p2m->root + i);
>> +
>> +    for ( j = 0; j < LPAE_ENTRIES; j++ )
>> +    {
>> +    lpae_t *entry = table + j;
>> +
>> +    /*
>> + * Individual altp2m views can be flushed, whilst
>> altp2m is
>> + * active. To avoid inconsistencies on CPUs that
>> continue to
>> + * use the views to be flushed (e.g., see
>> altp2m_reset), we
>> + * must remove every p2m entry atomically.
>
> When I read this comment, I wonder how this is safe to clear without
> any locking? At least to prevent multiple instance to modify the P2M
> at the same time. If you expect the caller to do it for you, then an
> ASSERT(...) is necessary at the beginning of the function.
>
> Likely you want this function do the locking.

You are correct, I was assuming the caller to lock the associated p2m.
Because of the fact that it is only the function "altp2m_reset" in
altp2m.c that flushes the p2m's without the purpose of subsequently
destroying it, I believe we should leave locking to the caller and (as
you mentioned above) use an ASSERT to ensure this behavior. Otherwise,
we would lock the p2m's everytime even if they are about to be destroyed
(as p2m_flush_table is called by p2m_teardown_one). I remember you
saying (and I agree at this point) that we should not do that as this
would be wasted cycles. Yet, if you should insist on locking the p2m
inside of p2m_flush_table, I will gladly incorporate the locking into
the upper function.

>
> Also that comment is more suitable on top of the for loop rather than
> here.

Ok, thanks.

>
>> + */
>> +    p2m_remove_pte(entry, p2m->clean_pte);
>> +    }
>> +    }
>
> You still haven't address my comment regarding the overhead you
> introduce whilst tearing down a P2M (e.g when the domain is destroyed).
>

I believe you are referring to the following comments:

> Also, this adds a small overhead when tearing down a p2m because the
> clear is not necessary. 

and

> You seem to forget the p2m teardown is also called during domain
> destruction.

Sorry, I must have missed it. To increase performance, at this point, we
could either (i) differentiate between altp2m views and the hostp2m (as
the hostp2m does not have to be cleared before it gets freed) or (ii) we
could introduce another function (e.g. p2m_clear_table) that is
responsible for doing just that. In this way, we could call
p2m_clear_table from altp2m_reset (the only place where we actually need
to clear altp2m views without subsequently destroying them) would not
need to clear the p2m's everytime we destroy one. Also, we sould need to
lock the p2m only in p2m_clear_table and not inside of p2m_flush_table
or one of its caller. What would you prefer?

>> +    }
>> +
>> +    /*
>> + * Flush TLBs before releasing remaining intermediate p2m page
>> tables to
>> + * prevent illegal access to stalled TLB entries.
>> + */
>> +    p2m_flush_tlb(p2m);
>
> Again, this is called by p2m_flush_table where the P2M may not have
> been allocated because the initialization failed. So trying to flush
> TLB may lead to a panic in Xen (the vttbr is invalid).
>
> Furthermore we already flush the TLBs when creating the domain (see
> p2m_alloc_table). So you add yet another overhead.
>

Right. Yet, we must flush the TLBs after clearing (resetting the altp2m
views through altp2m_reset) the views. That is, if you should be ok with
my suggestion above (introducing p2m_clear_table), we could limit
flushing the TLBs only to the code that actually resets the views.

>>   +    /* Free the rest of the trie pages back to the paging pool. */
>>   while ( (pg = page_list_remove_head(>pages)) )
>>   free_domheap_page(pg);
>>   +    p2m->lowest_mapped_gfn = INVALID_GFN;
>> +    p2m->max_mapped_gfn = _gfn(0);
>> +}
>> +
>> +void p2m_teardown_one(struct p2m_domain *p2m)
>> +{
>> +    p2m_flush_table(p2m);
>> +
>>   if ( p2m->root )
>>   free_domheap_pages(p2m->root, P2M_ROOT_ORDER);
>>     p2m->root = NULL;
>>   -    p2m_free_vmid(d);
>> +    p2m_free_vmid(p2m->domain);
>
> This is a bit odd 

Re: [Xen-devel] [PATCH RFC v1 57/74] x86/pv-shim: shadow PV console's page for L2 DomU

[Sergey Dyasli]

On Tue, 2018-01-09 at 09:28 -0700, Jan Beulich wrote:
> > > > On 09.01.18 at 16:43,  wrote:
> > 
> > On Tue, 2018-01-09 at 02:13 -0700, Jan Beulich wrote:
> > > > > > On 04.01.18 at 14:06,  wrote:
> > > > 
> > > > +size_t consoled_guest_rx(void)
> > > > +{
> > > > +size_t recv = 0, idx = 0;
> > > > +XENCONS_RING_IDX cons, prod;
> > > > +
> > > > +if ( !cons_ring )
> > > > +return 0;
> > > > +
> > > > +spin_lock(_lock);
> > > > +
> > > > +cons = cons_ring->out_cons;
> > > > +prod = ACCESS_ONCE(cons_ring->out_prod);
> > > > +ASSERT((prod - cons) <= sizeof(cons_ring->out));
> > > > +
> > > > +/* Is the ring empty? */
> > > > +if ( cons == prod )
> > > > +goto out;
> > > > +
> > > > +/* Update pointers before accessing the ring */
> > > > +smp_rmb();
> > > 
> > > I think this need to move up ahead of the if(). In the comment
> > > perhaps s/Update/Latch/?
> > 
> > The read/write memory barriers here are between read/write accesses to
> > ring->out_prod and ring->out array. So there is no need to move them.
> > (the same goes for the input ring)
> 
> And there is no multiple-read issue here?

As Andrew has kindly explained to me, there is an issue indeed.
So I moved smp_rmb() to be right after cons and prod read, and updated
the comment to say:

"Latch pointers before accessing the ring. Included compiler barrier also
ensures that pointers are really read only once into local variables."

-- 
Thanks,
Sergey
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] sidecar (hvm shim) creation script

[Doug Goldstein]

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



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

Re: [Xen-devel] Radical proposal v2: Publish Amazon's verison now, Citrix's version soon [and 1 more messages]

[Jan Beulich]

>>> On 10.01.18 at 17:39,  wrote:
> Jan Beulich writes ("Re: Radical proposal v2: Publish Amazon's verison now, 
> Citrix's version soon"):
>> There are a couple of instances of "a branch", and I'm not really
>> clear on which one that would be, yet in part my opinion depends
>> on that, as this will affect what state certain branches will be in
>> for subsequent work. As I agree with the PVH shim being the
>> better baseline for work going forward, in particular I wouldn't like
>> to see the Vixen series becoming the base of any branch going to
>> be maintained going forward.
> 
> Anthony Liguori writes ("Re: [Xen-devel] Radical proposal v2: Publish 
> Amazon's verison now, Citrix's version soon"):
>> What I would suggest is the following:
>> 1) Merge Vixen into staging
>> 2) Backport Vixen into stable-4.10 and cut a release
> 
> We do not have time any longer (if we had time to start with) to
> reconcile these divergent views.
> 
> 
> Hence George's suggestion, which bypasses the problem.  By "a branch"
> we mean some git branch on xenbits which is not any of our usual git
> branches, and which we expect to die fairly soon.
> 
> Jan, I suggest
> 
>https://xenbits.xen.org/git-http/xen.git 
>  refs/heads/4.10.meltdown.vixen
>  refs/tags/4.10.meltdown.vixen.1   (signed by usual key)

Fine with me.

Jan


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

Re: [Xen-devel] Radical proposal v2: Publish Amazon's verison now, Citrix's version soon [and 1 more messages]

[Roger Pau Monné]

On Wed, Jan 10, 2018 at 04:39:11PM +, Ian Jackson wrote:
> Jan Beulich writes ("Re: Radical proposal v2: Publish Amazon's verison now, 
> Citrix's version soon"):
> > There are a couple of instances of "a branch", and I'm not really
> > clear on which one that would be, yet in part my opinion depends
> > on that, as this will affect what state certain branches will be in
> > for subsequent work. As I agree with the PVH shim being the
> > better baseline for work going forward, in particular I wouldn't like
> > to see the Vixen series becoming the base of any branch going to
> > be maintained going forward.
> 
> Anthony Liguori writes ("Re: [Xen-devel] Radical proposal v2: Publish 
> Amazon's verison now, Citrix's version soon"):
> > What I would suggest is the following:
> > 1) Merge Vixen into staging
> > 2) Backport Vixen into stable-4.10 and cut a release
> 
> We do not have time any longer (if we had time to start with) to
> reconcile these divergent views.
> 
> 
> Hence George's suggestion, which bypasses the problem.  By "a branch"
> we mean some git branch on xenbits which is not any of our usual git
> branches, and which we expect to die fairly soon.
> 
> Jan, I suggest
> 
>https://xenbits.xen.org/git-http/xen.git
>  refs/heads/4.10.meltdown.vixen
>  refs/tags/4.10.meltdown.vixen.1   (signed by usual key)
> 
> If we can't agree to that[1] then I intend the following:
> 
>https://xenbits.xen.org/git-http/people/iwj/xen.git
>  refs/heads/meltdown/4.10.meltdown.vixen
>  refs/tags/4.10.meltdown.vixen.1   (signed by me personally)
> 
> [1] I am happy to accept any reasonable counterproposal for the exact
> branch and tag names.
> 
> 
> Separately, I would like to say that this branch will receive security
> support from the Xen Project Security Team, but that security support
> will be withdrawn at no less than 2 months' notice when a final
> solution is availabler.

I would add that security support will be limited to issues which
affect the security of the shim guest (ie: like being able to break
from user to kernel level or similar). IMHO a warning should be added
somewhere that this branch should not be used as a bare-metal
hypervisor.

Roger.

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

[Xen-devel] [xen-4.9-testing test] 117739: tolerable FAIL - PUSHED

[osstest service owner]

flight 117739 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117739/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-ws16-amd64 14 guest-localmigrate fail in 117710 pass 
in 117739
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 117710 
pass in 117739
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail pass in 
117710

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail in 117710 blocked in 
116619
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail in 117710 like 116619
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 116619
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 116619
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 116619
 test-amd64-amd64-xl-qemuu-ws16-amd64 18 guest-start/win.repeat fail like 116619
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 116619
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 116619
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 116619
 test-amd64-i386-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 116619
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  d6fe1860285bd4e3e3f1f6cc96f7d64200bc2138
baseline version:
 xen  0a0dcdcd20e9711cbfb08db5b21af5299ee1eb8b

Last test of basis   116619  2017-11-28 12:49:51 Z   43 days
Failing since117096  2017-12-12 14:19:03 Z   29 

Re: [Xen-devel] Radical proposal v2: Publish Amazon's verison now, Citrix's version soon [and 1 more messages]

[George Dunlap]

On 01/10/2018 04:39 PM, Ian Jackson wrote:
> Jan Beulich writes ("Re: Radical proposal v2: Publish Amazon's verison now, 
> Citrix's version soon"):
>> There are a couple of instances of "a branch", and I'm not really
>> clear on which one that would be, yet in part my opinion depends
>> on that, as this will affect what state certain branches will be in
>> for subsequent work. As I agree with the PVH shim being the
>> better baseline for work going forward, in particular I wouldn't like
>> to see the Vixen series becoming the base of any branch going to
>> be maintained going forward.
> 
> Anthony Liguori writes ("Re: [Xen-devel] Radical proposal v2: Publish 
> Amazon's verison now, Citrix's version soon"):
>> What I would suggest is the following:
>> 1) Merge Vixen into staging
>> 2) Backport Vixen into stable-4.10 and cut a release
> 
> We do not have time any longer (if we had time to start with) to
> reconcile these divergent views.
> 
> 
> Hence George's suggestion, which bypasses the problem.  By "a branch"
> we mean some git branch on xenbits which is not any of our usual git
> branches, and which we expect to die fairly soon.
> 
> Jan, I suggest
> 
>https://xenbits.xen.org/git-http/xen.git
>  refs/heads/4.10.meltdown.vixen
>  refs/tags/4.10.meltdown.vixen.1   (signed by usual key)

I would use 'shim' somewhere; and I don't think 'meltdown' is necessary,
but I'm not terribly picky.

+1 to putting it on xenbits.

 -George

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

Re: [Xen-devel] Radical proposal v2: Publish Amazon's verison now, Citrix's version soon [and 1 more messages]

[Ian Jackson]

Jan Beulich writes ("Re: Radical proposal v2: Publish Amazon's verison now, 
Citrix's version soon"):
> There are a couple of instances of "a branch", and I'm not really
> clear on which one that would be, yet in part my opinion depends
> on that, as this will affect what state certain branches will be in
> for subsequent work. As I agree with the PVH shim being the
> better baseline for work going forward, in particular I wouldn't like
> to see the Vixen series becoming the base of any branch going to
> be maintained going forward.

Anthony Liguori writes ("Re: [Xen-devel] Radical proposal v2: Publish Amazon's 
verison now, Citrix's version soon"):
> What I would suggest is the following:
> 1) Merge Vixen into staging
> 2) Backport Vixen into stable-4.10 and cut a release

We do not have time any longer (if we had time to start with) to
reconcile these divergent views.


Hence George's suggestion, which bypasses the problem.  By "a branch"
we mean some git branch on xenbits which is not any of our usual git
branches, and which we expect to die fairly soon.

Jan, I suggest

   https://xenbits.xen.org/git-http/xen.git
 refs/heads/4.10.meltdown.vixen
 refs/tags/4.10.meltdown.vixen.1   (signed by usual key)

If we can't agree to that[1] then I intend the following:

   https://xenbits.xen.org/git-http/people/iwj/xen.git
 refs/heads/meltdown/4.10.meltdown.vixen
 refs/tags/4.10.meltdown.vixen.1   (signed by me personally)

[1] I am happy to accept any reasonable counterproposal for the exact
branch and tag names.


Separately, I would like to say that this branch will receive security
support from the Xen Project Security Team, but that security support
will be withdrawn at no less than 2 months' notice when a final
solution is availabler.

If anyone objects to that then we can go ahead with sending out
information ASAP and argue about security support status later.


Ian.

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

Re: [Xen-devel] 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  TBD
> 
> 
> Instructions
> 
> 
> 1. On a suitable system (perhaps a different host)
>   git clone X TBD
>   git checkout X TBD
>    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: [Xen-devel] [PATCH RFC v1 00/74] Run PV guest in PVH container

[Wei Liu]

On Wed, Jan 10, 2018 at 04:26:07PM +, George Dunlap wrote:
> On Thu, Jan 4, 2018 at 1:05 PM, Wei Liu  wrote:
> > Hi all
> >
> > This is a patch series to run PV guest inside a PVH container. The series is
> > still in a very RFC state. We're aware that some code is not very clean yet 
> > and
> > in the process of cleaning things up.
> >
> > The series can be found at:
> >
> > https://xenbits.xen.org/git-http/people/liuw/xen.git wip.pvshim-rfc-v1
> >
> > The basic idea can be found at page 15 of the slides at [0].
> >
> > This is a mitigation against one of the CPU vulnerabilities disclosed 
> > recently.
> > This series makes it possible to continue running untrusted PV guests.  
> > Please
> > refer to XSA-254 [1] for more information.
> >
> > Given the embargo lifted and vulnerabilities disclosed we opt to develop 
> > openly
> > on xen-devel. Feedback and testing is very welcome.
> >
> > The series is split into three parts: The first part is for the host that 
> > runs
> > the shim, the second part is for the shim itself, the third part is for
> > toolstack patches (not yet fully working). See the markers in the list of
> > patches.
> >
> > Instructions on using the PV shim:
> >
> > 1. Git clone the branch and configure as one normally would.
> > 2. A xen-shim binary would be built and installed into Xen's firmware
> >directory, along side hvmloader and co.
> > 3. Use the hacky way currently provided in the first part of the series to
> >boot a PV guest inside a PVH container:
> >a. Append type='pvh' in your PV guest config file;
> >b. Export two environment variables so that libxl knows where to find
> >   the shim and what to add to the shim's command line option.
> >   # export LIBXL_PVSHIM_PATH=$PATH_TO_XEN_SHIM
> >   # export LIBXL_PVSHIM_CMDLINE="pv-shim console=xen,pv loglvl=all 
> > guest_loglvl=all apic_verbosity=debug e820-verbose sched=null"
> > 4. xl create -c guest.cfg
> >
> > You should be able to see some Xen messages first and then guest kernel
> > messages (the console= shim paramter is required).
> >
> > Known issues:
> >
> > 1. ARM build and some Clang build are broken by this series.
> > 2. The host will see a lot over-allocation messages, nothing too harmful and
> >will be fixed once toolstack is ready.
> >
> > Wei.
> >
> > [0] 
> > https://www.slideshare.net/xen_com_mgr/xpdds17-keynote-towards-a-configurable-and-slimmer-x86-hypervisor-wei-liu-citrix
> > [1] https://xenbits.xen.org/xsa/advisory-254.html
> >
> > # Patches for the host:
> >
> > 448f56a363 x86/svm: Offer CPUID Faulting to AMD HVM guests as well
> > 6a78c9ae33 x86: Common cpuid faulting support
> > 05844fec44 x86/upcall: inject a spurious event after setting upcall vector
> > fc7a48dd74 tools/libxc: initialise hvm loader elf log fd to get more logging
> > 522c9cbaf0 tools/libxc: remove extraneous newline in xc_dom_load_acpi
> > bd6b572b32 tools/libelf: fix elf notes check for PVH guest
> > 449b932b0c tools/libxc: Multi modules support
> > cc6dbdc0c1 libxl: Introduce hack to allow PVH mode to add a shim
> >
> > # Patches for the shim:
> >
> [snip]
> > 7dbc3f25f6 xen/x86: report domain id on cpuid
> 
> This is a host (L0) patch, isn't it?

Yes it is.

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

Re: [Xen-devel] [PATCH RFC v1 00/74] Run PV guest in PVH container

[George Dunlap]

On Thu, Jan 4, 2018 at 1:05 PM, Wei Liu  wrote:
> Hi all
>
> This is a patch series to run PV guest inside a PVH container. The series is
> still in a very RFC state. We're aware that some code is not very clean yet 
> and
> in the process of cleaning things up.
>
> The series can be found at:
>
> https://xenbits.xen.org/git-http/people/liuw/xen.git wip.pvshim-rfc-v1
>
> The basic idea can be found at page 15 of the slides at [0].
>
> This is a mitigation against one of the CPU vulnerabilities disclosed 
> recently.
> This series makes it possible to continue running untrusted PV guests.  Please
> refer to XSA-254 [1] for more information.
>
> Given the embargo lifted and vulnerabilities disclosed we opt to develop 
> openly
> on xen-devel. Feedback and testing is very welcome.
>
> The series is split into three parts: The first part is for the host that runs
> the shim, the second part is for the shim itself, the third part is for
> toolstack patches (not yet fully working). See the markers in the list of
> patches.
>
> Instructions on using the PV shim:
>
> 1. Git clone the branch and configure as one normally would.
> 2. A xen-shim binary would be built and installed into Xen's firmware
>directory, along side hvmloader and co.
> 3. Use the hacky way currently provided in the first part of the series to
>boot a PV guest inside a PVH container:
>a. Append type='pvh' in your PV guest config file;
>b. Export two environment variables so that libxl knows where to find
>   the shim and what to add to the shim's command line option.
>   # export LIBXL_PVSHIM_PATH=$PATH_TO_XEN_SHIM
>   # export LIBXL_PVSHIM_CMDLINE="pv-shim console=xen,pv loglvl=all 
> guest_loglvl=all apic_verbosity=debug e820-verbose sched=null"
> 4. xl create -c guest.cfg
>
> You should be able to see some Xen messages first and then guest kernel
> messages (the console= shim paramter is required).
>
> Known issues:
>
> 1. ARM build and some Clang build are broken by this series.
> 2. The host will see a lot over-allocation messages, nothing too harmful and
>will be fixed once toolstack is ready.
>
> Wei.
>
> [0] 
> https://www.slideshare.net/xen_com_mgr/xpdds17-keynote-towards-a-configurable-and-slimmer-x86-hypervisor-wei-liu-citrix
> [1] https://xenbits.xen.org/xsa/advisory-254.html
>
> # Patches for the host:
>
> 448f56a363 x86/svm: Offer CPUID Faulting to AMD HVM guests as well
> 6a78c9ae33 x86: Common cpuid faulting support
> 05844fec44 x86/upcall: inject a spurious event after setting upcall vector
> fc7a48dd74 tools/libxc: initialise hvm loader elf log fd to get more logging
> 522c9cbaf0 tools/libxc: remove extraneous newline in xc_dom_load_acpi
> bd6b572b32 tools/libelf: fix elf notes check for PVH guest
> 449b932b0c tools/libxc: Multi modules support
> cc6dbdc0c1 libxl: Introduce hack to allow PVH mode to add a shim
>
> # Patches for the shim:
>
[snip]
> 7dbc3f25f6 xen/x86: report domain id on cpuid

This is a host (L0) patch, isn't it?

 -George

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

Re: [Xen-devel] 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  TBD


Instructions


1. On a suitable system (perhaps a different host)
  git clone X TBD
  git checkout X TBD
   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: [Xen-devel] [PATCH RFC v1 66/74] xen/shim: allow DomU to have as many vcpus as available

[Roger Pau Monné]

On Tue, Jan 09, 2018 at 03:59:33AM -0700, Jan Beulich wrote:
> >>> On 04.01.18 at 14:06,  wrote:
> > From: Roger Pau Monne 
> > 
> > Since the shim VCPUOP_{up/down} hypercall is wired to the plug/unplug
> > of CPUs to the shim itself, start the shim DomU with only the BSP
> > online, and let the guest bring up other CPUs as it needs them.
> > 
> > Signed-off-by: Roger Pau Monné 
> 
> What are the ramifications of not making this change? Shouldn't
> the shim's pCPU count (pCPU as viewed from its own perspective)
> simply always match its client's vCPU count?

Yes, that's the point of this change. By default Dom0 will get a many
vCPUs as online pCPUs. ÇIn the shim case the number of online pCPUs is
always 1, and thus we need to set max_vcpus to match the number of
possible pCPUs.

> > --- a/xen/arch/x86/pv/dom0_build.c
> > +++ b/xen/arch/x86/pv/dom0_build.c
> > @@ -695,7 +695,8 @@ int __init dom0_construct_pv(struct domain *d,
> >  for ( i = 0; i < XEN_LEGACY_MAX_VCPUS; i++ )
> >  shared_info(d, vcpu_info[i].evtchn_upcall_mask) = 1;
> >  
> > -printk("Dom0 has maximum %u VCPUs\n", d->max_vcpus);
> > +printk("%s has maximum %u VCPUs\n", pv_shim ? "DomU" : "Dom0",
> 
> "Dom%c ..." perhaps?

We could even use Dom%u and d->domain_id. That would remove the
dependency on pv_shim.

Thanks, Roger.

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

Re: [Xen-devel] [Makefile] asm: handle comments when creating header file

[Jan Beulich]

>>> On 10.01.18 at 16:14,  wrote:
> In the early steps of compilation, the asm header files are created, such
> as include/asm-$(TARGET_ARCH)/asm-offsets.h. These files depend on the
> assembly file arch/$(TARGET_ARCH)/asm-offsets.s, which is generated
> before. Depending on the used assembler, there might be comments in the
> assembly files.
> 
> This commit adds handling comments in the assembler during the creation of
> the asm header files.

I have a hard time seeing how ...

> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -189,7 +189,7 @@ include/asm-$(TARGET_ARCH)/asm-offsets.h: 
> arch/$(TARGET_ARCH)/asm-offsets.s
> echo "#ifndef __ASM_OFFSETS_H__"; \
> echo "#define __ASM_OFFSETS_H__"; \
> echo ""; \
> -   sed -rne "/==>/{s:.*==>(.*)<==.*:\1:; s: [\$$#]: :; p;}"; \

... this pattern could match any comment that we currently have.
Would you mind clarifying what it is that is actually broken (and
hence wants/needs fixing)?

Jan


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

Re: [Xen-devel] [PATCH RFC v1 34/74] x86/guest: add PV console code

[Jan Beulich]

>>> On 10.01.18 at 16:33,  wrote:
> I've spoken to Sergey and he agrees that this should be solved and
> that using uart_driver seems like the right approach.
> 
> However given that we would like to merge this ASAP, do you consider
> this a blocker?

No.

Jan


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

Re: [Xen-devel] [PATCH RFC v1 34/74] x86/guest: add PV console code

[Roger Pau Monné]

On Fri, Jan 05, 2018 at 08:22:46AM -0700, Jan Beulich wrote:
> >>> On 04.01.18 at 14:05,  wrote:
> > +void __init pv_console_set_rx_handler(serial_rx_fn fn)
> > +{
> > +cons_rx_handler = fn;
> > +}
> 
> Especially this and ...
> 
> > +size_t pv_console_rx(struct cpu_user_regs *regs)
> > +{
> > +char c;
> > +XENCONS_RING_IDX cons, prod;
> > +size_t recv = 0;
> > +
> > +if ( !cons_ring )
> > +return 0;
> > +
> > +/* TODO: move this somewhere */
> > +if ( !test_bit(cons_evtchn, XEN_shared_info->evtchn_pending) )
> > +return 0;
> 
> ... the need for this and ...
> 
> > +prod = ACCESS_ONCE(cons_ring->in_prod);
> > +cons = cons_ring->in_cons;
> > +/* Get pointers before reading the ring */
> > +smp_rmb();
> > +
> > +ASSERT((prod - cons) <= sizeof(cons_ring->in));
> > +
> > +while ( cons != prod )
> > +{
> > +c = cons_ring->in[MASK_XENCONS_IDX(cons++, cons_ring->in)];
> > +if ( cons_rx_handler )
> > +cons_rx_handler(c, regs);
> > +recv++;
> > +}
> > +
> > +/* No need for a mem barrier because every character was already 
> > consumed */
> > +barrier();
> > +ACCESS_ONCE(cons_ring->in_cons) = cons;
> > +notify_daemon();
> > +
> > +clear_bit(cons_evtchn, XEN_shared_info->evtchn_pending);
> 
> ... this at this layer are very hard to judge about with all the code
> here being dead for the moment. Can't this driver be modeled like
> any other of the UART drivers, surfacing the accessors through
> struct uart_driver (and making the ad-hoc call sites in the next
> patch [mostly] unnecessary)?

I've spoken to Sergey and he agrees that this should be solved and
that using uart_driver seems like the right approach.

However given that we would like to merge this ASAP, do you consider
this a blocker? I haven't really looked at how much effort it would
take to model this code as a proper uart driver.

Thanks, Roger.

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

Re: [Xen-devel] sidecar (hvm shim) creation script

[Ian Jackson]

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.

#!/usr/bin/perl -w
#
# usage:
#   pvshim-converter [OPTIONS] OLD-CONFIG NEW-CONFIG
#
# options:
#   --sidecars-directory DIR   default is /var/lib/xen/pvshim-sidecars
#   --shim SHIMoverrides domain config file
#   --debugverbose, 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, '<' or die $!;
}
{
local $/;
$indata = ;
}
I->error and die $!;
close I;

open P, "-|", qw(python -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 = <", "$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 <", "$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"

Re: [Xen-devel] sidecar (hvm shim) creation script

[Ian Jackson]

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.

#!/usr/bin/perl -w
#
# usage:
#   pvshim-converter [OPTIONS] OLD-CONFIG NEW-CONFIG
#
# options:
#   --sidecars-directory DIR   default is /var/lib/xen/pvshim-sidecars
#   --shim SHIMoverrides domain config file
#   --debugverbose, 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, '<' or die $!;
}
{
local $/;
$indata = ;
}
I->error and die $!;
close I;

open P, "-|", qw(python -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 = <", "$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 <", "$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
;;
 

[Xen-devel] [Makefile] asm: handle comments when creating header file

[Norbert Manthey]

In the early steps of compilation, the asm header files are created, such
as include/asm-$(TARGET_ARCH)/asm-offsets.h. These files depend on the
assembly file arch/$(TARGET_ARCH)/asm-offsets.s, which is generated
before. Depending on the used assembler, there might be comments in the
assembly files.

This commit adds handling comments in the assembler during the creation of
the asm header files.

Signed-off-by: Norbert Manthey 
Signed-off-by: Michael Tautschnig 
Reviewed-by: Pawel Wieczorkiewicz 
Reviewed-by: Bjoern Doebel 
---
 xen/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/Makefile b/xen/Makefile
index 044e7c8..841a9e5 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -189,7 +189,7 @@ include/asm-$(TARGET_ARCH)/asm-offsets.h: 
arch/$(TARGET_ARCH)/asm-offsets.s
  echo "#ifndef __ASM_OFFSETS_H__"; \
  echo "#define __ASM_OFFSETS_H__"; \
  echo ""; \
- sed -rne "/==>/{s:.*==>(.*)<==.*:\1:; s: [\$$#]: :; p;}"; \
+ sed -rne "/^[^#].*==>/{s:.*==>(.*)<==.*:\1:; s: [\$$#]: :; p;}"; \
  echo ""; \
  echo "#endif") <$< >$@
 
-- 
2.7.4


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

Re: [Xen-devel] sidecar (hvm shim) creation script

[Ian Jackson]

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

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 SHIMoverrides domain config file
#   --debugverbose, 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, '<' or die $!;
}
{
local $/;
$indata = ;
}
I->error and die $!;
close I;

open P, "-|", qw(python -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 = <", "$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 <", "$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"; 

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

[Anthony Liguori]

On Wed, Jan 10, 2018 at 4:27 AM, Wei Liu  wrote:
> On Wed, Jan 10, 2018 at 08:32:24AM +, Roger Pau Monné wrote:
>> On Tue, Jan 09, 2018 at 07:43:51PM +, Wei Liu wrote:
>> > On Mon, Jan 08, 2018 at 05:45:32PM +, 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
>> 

Re: [Xen-devel] sidecar (hvm shim) creation script

[Anthony Liguori]

On Wed, Jan 10, 2018 at 5:07 AM, 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 ?

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 SHIMoverrides domain config file
> #   --debugverbose, 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, '<' or die $!;
> }
> {
> local $/;
> $indata = ;
> }
> I->error and die $!;
> close I;
>
> open P, "-|", qw(python -c), < 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 $/;
> $_ = ;
> $!=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 = < 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 < 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 

Re: [Xen-devel] [PATCH RFC v1 61/74] xen/pvshim: support vCPU hotplug

[Roger Pau Monné]

On Tue, Jan 09, 2018 at 03:16:38AM -0700, Jan Beulich wrote:
> >>> On 04.01.18 at 14:06,  wrote:
> > @@ -1303,22 +1320,20 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, 
> > XEN_GUEST_HANDLE_PARAM(void) arg)
> >  
> >  break;
> >  
> > -case VCPUOP_up: {
> > -bool_t wake = 0;
> > -domain_lock(d);
> > -if ( !v->is_initialised )
> > -rc = -EINVAL;
> 
> Shouldn't this check remain here? I realize this will complicate
> locking (luckily the domain lock is a recursive one, so it shouldn't
> be too bad), but I don't think pv_shim_cpu_up() can tolerate failing
> because of vcpu_up() failing.

I guess you mean that it's unfortunate to fail in pv_shim_cpu_up after
having brought up the physical CPU if it turns out that
!v->is_initialised. I can add a check at the top of pv_shim_cpu_up for
!v->is_initialised and change vcpu_up slightly.

Regarding the usage of long, continue_hypercall_on_cpu requires a
function that returns long, so I would rather keep things as they are
now for simplicity.

Thanks, Roger.

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

Re: [Xen-devel] Radical proposal v2: Publish Amazon's verison now, Citrix's version soon

[Anthony Liguori]

On Wed, Jan 10, 2018 at 5:50 AM, Jan Beulich  wrote:
 On 10.01.18 at 14:34,  wrote:
>> I'd like to propose a new appraoch:
>>
>> 1. Immediately release Amazon's v1 series for people who can / prefer
>> to use the HVM + sidecar option.
>> - Advisory and HOWTO should include who should use this option, and
>>   how to do it.
>> - Check the series into a branch on xenbits, and add a signed tag
>> - HOWTO-vixen, and sidecar script, to be included in the advisory.
>>
>> 2. As soon as possible, release Citrix's series for people who can /
>> prefer to use the PVH + toolstack option.
>> - Immediate work should focus on getting PVH + toolstack functionality
>>   ready to release
>> - When ready, advisory and HOWTO should include who should use this
>>   option and how
>> - Either check the series into a branch on xenbits, or into
>>   staging-4.10
>> - HOWTO-pvh to be included in the advisory.
>>
>> This should allow us to get a solution to the widest number of users
>> in the shortest amount of time; it also allows us to leverage the
>> testing efforts of both Amazon (for breadth of Xen versions) and
>> Citrix (for depth of functionality).
>>
>> That takes the pressure off us to check in one or the other version of
>> the patch series.
>>
>> Going forward, we could work towards the convergence of functionality
>> from either patch series.  But it looks superficially at least like
>> the Citrix series is closer to the convergence point, and so it seems
>> like using that as a starting point would make the most sense.
>
> There are a couple of instances of "a branch", and I'm not really
> clear on which one that would be, yet in part my opinion depends
> on that, as this will affect what state certain branches will be in
> for subsequent work. As I agree with the PVH shim being the
> better baseline for work going forward, in particular I wouldn't like
> to see the Vixen series becoming the base of any branch going to
> be maintained going forward.

What I would suggest is the following:

1) Merge Vixen into staging

2) Backport Vixen into stable-4.10 and cut a release

3) Immediately begin bringing in PVH shim into staging

4) While doing (3), avoid breaking HVM shim but take full liberty to
remove Vixen bits and replace.

5) Release 4.11 once PVH shim is ready

I think releasing something to users and then doing a totally
different implementation is going to be extremely painful.

The advantage of merging to staging is that it becomes possible to
bisect regressions.

There isn't really much of a user facing difference here so if the entirety
of Vixen was replaced under the covers for 4.11, as long as we are able
to test continuously and avoid regressions, no one would notice the
difference.

However, if you start from a different base for 4.11 and release something
that regresses from a unique Vixen branch, it's going to be painful trying
to move people off of that branch.

Regards,

Anthony Liguori

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

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

Re: [Xen-devel] Radical proposal v2: Publish Amazon's verison now, Citrix's version soon

[Lars Kurth]

> On 10 Jan 2018, at 13:51, Juergen Gross  wrote:
> 
> On 10/01/18 14:34, George Dunlap wrote:
>> * Executive summary
>> 
[snip]

>> 
>> Regardless of what we think of step 2, I think we should take step 1
>> immediately.
>> 
>> Let me know what you think.

Thank you for putting this proposal together.

> I'm absolutely in favor of that idea.

Me too. We should aim for a release tomorrow morning. Maybe getting as much as 
we need to get in place today.
It is probably to late to get all the bits and pieces done today.

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

Re: [Xen-devel] [BUG] kernel bug encountered at drivers/net/xen-netback/netback.c:430!

[Paul Durrant]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 10 January 2018 12:52
> To: 'Christoph Moench-Tegeder' 
> Cc: 'Michael Collins' ; 'Juergen Gross'
> ; Wei Liu ; 'Alex Braunegg'
> ; xen-devel@lists.xenproject.org
> Subject: Re: [Xen-devel] [BUG] kernel bug encountered at drivers/net/xen-
> netback/netback.c:430!
> 
> I have tracked down the problem to multiple calls to the zerocopy callback for
> the same ubuf_info. I am not sure exactly which patch introduced the issue
> but my suspicion is that it was one of the the MSG_ZEROCOPY series (see
> https://marc.info/?l=linux-netdev=149807997726733=2).
> I have a candidate patch to netback to make use of the ubuf_info ref count
> to handle the multiple callbacks and that certainly fixes the issue for me. 
> I'll
> post this shortly recommending a backport to stable.
> 

Actually no need... The underlying issue was really a bug and has been fixed in 
4.14.11. See 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=v4.14.13=17155ea827b2fd81330a442ed56d0edafd9969e1

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

Re: [Xen-devel] Radical proposal v2: Publish Amazon's verison now, Citrix's version soon

[Juergen Gross]

On 10/01/18 14:34, George Dunlap wrote:
> * Executive summary
> 
> - We've agreed on a "convergence" point for PV shim functionality that
>   covers as many users as possible:
>  - 'HVM' functionality: boots in HVM mode, has support for Xen 3.4
>event channels, , booted via 'sidecar'
>  - 'PVH' functionality: boots in PVH mode, booted via toolstack
>changes
> 
> - "Vixen" (the Amazon shim) and PVH shim (mostly developed by Citrix)
>   each cover some users and not others; neither one (yet) covers all
>   users
> 
> - Vixen is ready for immediate release; PVH shim still needs some
>   minor revision, and the toolstack component
> 
> - Proposal:
>  - Release "HOWTO" for Amazon shim v1 immediately (including a signed
>tag on xenbits with the requisite patches)
>  - Release "HOWTO" for PVH shim as soon as it's ready (including a
>signed tag or tags on xenbits with the requisite patches)
>  - Base future development on the PVH shim (porting over functionality
>from the Amazon series)
> 
> * Discussion
> 
> In our discussions, we've generally identified four kinds of users /
> consumers of Xen:
> 
> 1. Those for whom upgrading to a newer version of Xen is the biggest
> problem
> 
> This could be people who have local changes they can't forward-port,
> people whose SLAs forbid updating versions, or any number of other
> things that make updating to a newer version of Xen unpalatable or
> impossible.
> 
> 2. Those for whom adding a QEMU instance to all PV guests is the
> biggest problem
> 
> Many users I've talked to extremely dislike the idea of adding QEMU
> instances to all their PV guests, and would rather do upgrades and/or
> modify guest types to avoid this
> 
> 3. Those for whom modifying guest parameters is the biggest problem
> 
> Many users I've talked to are using software which severely limits the
> flexibility they have in terms of how guests are created
> 
> 4. Those for whom some subset of features (migration, ballooning, vcpu
> hotplug, ) is the biggest problem.
> 
> This includes users who rely on these features, as well as software
> providers that provide those features.
> 
> Amazon is in the first category, and have developed a "PV shim"
> series that addresses their needs.  They have also very kindly
> shared the patches publicly for the community to be able to use.
> 
> Citrix is in the fourth category, and have developed a "PV shim"
> series that addresses their needs.  This shim also satisfies category 2,
> and with some work could support category 3.
> 
> Going forward, the best solutions for new hypervisors (Xen 4.11+)
> would be to avoid needing QEMU, building the sidecar, and so on.  But
> we still want to be able to support people running the 'HVM shim with
> sidecar' version going forward.  So the "convergence point" we've all
> seemed to agree on is to have a shim capable of satisfying all groups:
> 
> - Can run in HVM mode back as far as Xen 3.4
> - Can run in PVH mode, without QEMU or "sidecar", and doesn't require
>   many toolstack changes
> - Has feature parity with PV mode (migration, ballooning, vcpu
>   migration, )
> 
> The issue has been made public for nearly a week now, so there is a
> lot of pressure to get a solution to our users as soon as possible; by
> the end of the week at absolute latest, but today if possible.
> 
> Amazon's v1 series:
> - Has support for 'legacy' event channels
> 
> - Has been tested by Amazon over a wide range of their hypervisor
>   versions and guest types (including pvgrub types) back as far as Xen
>   3.4
> 
> - Uses HVM mode, and so has the overhead and security implications of
>   running QEMU
> 
> - Requires no L0 hypervisor or toolstack changes
> 
> - Requires users to build a "boot sidecar" image for each unique guest
>   boot configuration
> 
> - Is missing many features, such as migration, memory ballooning, and
>   vcpu hotplug
> 
> - Has accurate 'stolen time' support
> 
> Citrix's series:
> - Has been extensively tested by XenServer's XenRT for Xen 4.7 (with
>   PVH backports) and 4.10
> - Uses PVH mode, and so doesn't have the overhead and security
>   implications of running QEMU
> - No need to build "boot sidecar"
> - Requires hypervisor changes for versions for versions before 4.10
>   which cannot reasonably be backported by the open-source team beyond
>   Xen 4.8
> - Requires toolstack changes in all versions
> - Has migration, memory ballooning, and vcpu hotplug (extensively
>   tested by XenRT)
> - Doesn't have accurate 'stolen time' support
> - Currently is missing a clean toolstack interface
> 
> With some tweaks, Citrix's version has been made to boot in HVM mode.
> However, this modified version:
> - Doesn't support the 'legacy' event channel mode, and so won't work
>   for versions as old as Amazon's
> - Hasn't been tested extensively on older versions
> 
> Ian suggested that we get something and check it into 4.10-staging
> as soon as possible.  But there has been a debate about whether we
> 

Re: [Xen-devel] Radical proposal v2: Publish Amazon's verison now, Citrix's version soon

[Jan Beulich]

>>> On 10.01.18 at 14:34,  wrote:
> I'd like to propose a new appraoch:
> 
> 1. Immediately release Amazon's v1 series for people who can / prefer
> to use the HVM + sidecar option.
> - Advisory and HOWTO should include who should use this option, and
>   how to do it.
> - Check the series into a branch on xenbits, and add a signed tag
> - HOWTO-vixen, and sidecar script, to be included in the advisory.
> 
> 2. As soon as possible, release Citrix's series for people who can /
> prefer to use the PVH + toolstack option.
> - Immediate work should focus on getting PVH + toolstack functionality
>   ready to release
> - When ready, advisory and HOWTO should include who should use this
>   option and how
> - Either check the series into a branch on xenbits, or into
>   staging-4.10
> - HOWTO-pvh to be included in the advisory.
> 
> This should allow us to get a solution to the widest number of users
> in the shortest amount of time; it also allows us to leverage the
> testing efforts of both Amazon (for breadth of Xen versions) and
> Citrix (for depth of functionality).
> 
> That takes the pressure off us to check in one or the other version of
> the patch series.
> 
> Going forward, we could work towards the convergence of functionality
> from either patch series.  But it looks superficially at least like
> the Citrix series is closer to the convergence point, and so it seems
> like using that as a starting point would make the most sense.

There are a couple of instances of "a branch", and I'm not really
clear on which one that would be, yet in part my opinion depends
on that, as this will affect what state certain branches will be in
for subsequent work. As I agree with the PVH shim being the
better baseline for work going forward, in particular I wouldn't like
to see the Vixen series becoming the base of any branch going to
be maintained going forward.

Jan


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

Re: [Xen-devel] [PATCH RFC v1 62/74] xen/pvshim: memory hotplug

[Jan Beulich]

>>> On 10.01.18 at 14:36,  wrote:
> On Tue, Jan 09, 2018 at 03:42:01AM -0700, Jan Beulich wrote:
>> >>> On 04.01.18 at 14:06,  wrote:
>> > @@ -1015,6 +1024,11 @@ long do_memory_op(unsigned long cmd, 
>> > XEN_GUEST_HANDLE_PARAM(void) arg)
>> >  __HYPERVISOR_memory_op, "lh",
>> >  op | (rc << MEMOP_EXTENT_SHIFT), arg);
>> >  
>> > +#ifdef CONFIG_X86
>> > +if ( pv_shim && op == XENMEM_decrease_reservation )
>> > +pv_shim_offline_memory(args.nr_extents, args.extent_order);
>> > +#endif
>> 
>> Looking at both of these changes - is it somewhere being made
>> sure that shim containers won't boot in PoD mode?
>> 
>> For the latter change - is this correct when the operation has been
>> preempted? I think you want to offline only the delta between
>> start and args.nr_done.
> 
> AFAICT this function will only be called once, even when preempted.
> On the online case it's only called when args.nr_done == 0, and in the
> offline case it's only called after the work has been completely done.

No, and that's the point of my earlier comment: You call the function
solely based on the value of op, not considering at all whether you
were preempted. Or am I overlooking anything?

Jan


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

[Xen-devel] Radical proposal v2: Publish Amazon's verison now, Citrix's version soon

[George Dunlap]

* Executive summary

- We've agreed on a "convergence" point for PV shim functionality that
  covers as many users as possible:
 - 'HVM' functionality: boots in HVM mode, has support for Xen 3.4
   event channels, , booted via 'sidecar'
 - 'PVH' functionality: boots in PVH mode, booted via toolstack
   changes

- "Vixen" (the Amazon shim) and PVH shim (mostly developed by Citrix)
  each cover some users and not others; neither one (yet) covers all
  users

- Vixen is ready for immediate release; PVH shim still needs some
  minor revision, and the toolstack component

- Proposal:
 - Release "HOWTO" for Amazon shim v1 immediately (including a signed
   tag on xenbits with the requisite patches)
 - Release "HOWTO" for PVH shim as soon as it's ready (including a
   signed tag or tags on xenbits with the requisite patches)
 - Base future development on the PVH shim (porting over functionality
   from the Amazon series)

* Discussion

In our discussions, we've generally identified four kinds of users /
consumers of Xen:

1. Those for whom upgrading to a newer version of Xen is the biggest
problem

This could be people who have local changes they can't forward-port,
people whose SLAs forbid updating versions, or any number of other
things that make updating to a newer version of Xen unpalatable or
impossible.

2. Those for whom adding a QEMU instance to all PV guests is the
biggest problem

Many users I've talked to extremely dislike the idea of adding QEMU
instances to all their PV guests, and would rather do upgrades and/or
modify guest types to avoid this

3. Those for whom modifying guest parameters is the biggest problem

Many users I've talked to are using software which severely limits the
flexibility they have in terms of how guests are created

4. Those for whom some subset of features (migration, ballooning, vcpu
hotplug, ) is the biggest problem.

This includes users who rely on these features, as well as software
providers that provide those features.

Amazon is in the first category, and have developed a "PV shim"
series that addresses their needs.  They have also very kindly
shared the patches publicly for the community to be able to use.

Citrix is in the fourth category, and have developed a "PV shim"
series that addresses their needs.  This shim also satisfies category 2,
and with some work could support category 3.

Going forward, the best solutions for new hypervisors (Xen 4.11+)
would be to avoid needing QEMU, building the sidecar, and so on.  But
we still want to be able to support people running the 'HVM shim with
sidecar' version going forward.  So the "convergence point" we've all
seemed to agree on is to have a shim capable of satisfying all groups:

- Can run in HVM mode back as far as Xen 3.4
- Can run in PVH mode, without QEMU or "sidecar", and doesn't require
  many toolstack changes
- Has feature parity with PV mode (migration, ballooning, vcpu
  migration, )

The issue has been made public for nearly a week now, so there is a
lot of pressure to get a solution to our users as soon as possible; by
the end of the week at absolute latest, but today if possible.

Amazon's v1 series:
- Has support for 'legacy' event channels

- Has been tested by Amazon over a wide range of their hypervisor
  versions and guest types (including pvgrub types) back as far as Xen
  3.4

- Uses HVM mode, and so has the overhead and security implications of
  running QEMU

- Requires no L0 hypervisor or toolstack changes

- Requires users to build a "boot sidecar" image for each unique guest
  boot configuration

- Is missing many features, such as migration, memory ballooning, and
  vcpu hotplug

- Has accurate 'stolen time' support

Citrix's series:
- Has been extensively tested by XenServer's XenRT for Xen 4.7 (with
  PVH backports) and 4.10
- Uses PVH mode, and so doesn't have the overhead and security
  implications of running QEMU
- No need to build "boot sidecar"
- Requires hypervisor changes for versions for versions before 4.10
  which cannot reasonably be backported by the open-source team beyond
  Xen 4.8
- Requires toolstack changes in all versions
- Has migration, memory ballooning, and vcpu hotplug (extensively
  tested by XenRT)
- Doesn't have accurate 'stolen time' support
- Currently is missing a clean toolstack interface

With some tweaks, Citrix's version has been made to boot in HVM mode.
However, this modified version:
- Doesn't support the 'legacy' event channel mode, and so won't work
  for versions as old as Amazon's
- Hasn't been tested extensively on older versions

Ian suggested that we get something and check it into 4.10-staging
as soon as possible.  But there has been a debate about whether we
should start with Amazon's series and add PVH support, or start with
Citrix's series and add HVM support (including legacy event channels,
and so on).

No matter what, individual users will need to decide whether to take
the 'HVM + sidecar' option or the 'PVH' option..

I'd like to propose 

Re: [Xen-devel] [PATCH RFC v1 61/74] xen/pvshim: support vCPU hotplug

[Jan Beulich]

>>> On 10.01.18 at 14:07,  wrote:
> On Tue, Jan 09, 2018 at 03:16:38AM -0700, Jan Beulich wrote:
>> >>> On 04.01.18 at 14:06,  wrote:
>> > @@ -1303,22 +1320,20 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, 
> XEN_GUEST_HANDLE_PARAM(void) arg)
>> >  
>> >  break;
>> >  
>> > -case VCPUOP_up: {
>> > -bool_t wake = 0;
>> > -domain_lock(d);
>> > -if ( !v->is_initialised )
>> > -rc = -EINVAL;
>> 
>> Shouldn't this check remain here? I realize this will complicate
>> locking (luckily the domain lock is a recursive one, so it shouldn't
>> be too bad), but I don't think pv_shim_cpu_up() can tolerate failing
>> because of vcpu_up() failing.
>> 
>> I also think that the use of "long" for return types and values isn't
>> really warranted here, and there's also no visible to me reason to
>> special case CPU0 here. But for simplicity reasons I can see why
>> you've chosen that option; otoh the locking issue above that you'll
>> need to solve might be easier to deal with if you didn't switch CPUs
>> for hypercall processing (without dropping the use of
>> continue_hypercall_on_cpu()).
> 
> Right, I'm not sure why bringing a CPU up is required to happen on
> CPU0, but that's what the current code in arch_do_sysctl does.

In the bare metal hypervisor we likely will need to do some work to
remove this CPU0 restriction.

> I'm not sure I'm following the last part of your reply, if for CPU
> bringup there's no need to switch to CPU0, why would I want to keep
> the continue_hypercall_on_cpu for in that case?

For onlining you may indeed get away without. But in the
offlining case you don't want to offline the CPU you're
running on.

Jan


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

[Xen-devel] [PATCH v3 0/2] x86/boot: Some fixes

[Daniel Kiper]

Hi,

As in subject...

Daniel

 xen/arch/x86/setup.c |   18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

Daniel Kiper (2):
  x86/setup: do not relocate Xen over current Xen image placement
  x86/setup: remap Xen image up to PFN_DOWN(__pa(_end))


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

Re: [Xen-devel] [PATCH RFC v1 61/74] xen/pvshim: support vCPU hotplug

[Roger Pau Monné]

On Tue, Jan 09, 2018 at 03:16:38AM -0700, Jan Beulich wrote:
> >>> On 04.01.18 at 14:06,  wrote:
> > @@ -1303,22 +1320,20 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, 
> > XEN_GUEST_HANDLE_PARAM(void) arg)
> >  
> >  break;
> >  
> > -case VCPUOP_up: {
> > -bool_t wake = 0;
> > -domain_lock(d);
> > -if ( !v->is_initialised )
> > -rc = -EINVAL;
> 
> Shouldn't this check remain here? I realize this will complicate
> locking (luckily the domain lock is a recursive one, so it shouldn't
> be too bad), but I don't think pv_shim_cpu_up() can tolerate failing
> because of vcpu_up() failing.
> 
> I also think that the use of "long" for return types and values isn't
> really warranted here, and there's also no visible to me reason to
> special case CPU0 here. But for simplicity reasons I can see why
> you've chosen that option; otoh the locking issue above that you'll
> need to solve might be easier to deal with if you didn't switch CPUs
> for hypercall processing (without dropping the use of
> continue_hypercall_on_cpu()).

Right, I'm not sure why bringing a CPU up is required to happen on
CPU0, but that's what the current code in arch_do_sysctl does.

I'm not sure I'm following the last part of your reply, if for CPU
bringup there's no need to switch to CPU0, why would I want to keep
the continue_hypercall_on_cpu for in that case?

Thanks, Roger.

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

Re: [Xen-devel] sidecar (hvm shim) creation script

[Wei Liu]

On Wed, Jan 10, 2018 at 01:07:33PM +, 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

[Xen-devel] sidecar (hvm shim) creation script

[Ian Jackson]

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.

#!/usr/bin/perl -w
#
# usage:
#   pvshim-converter [OPTIONS] OLD-CONFIG NEW-CONFIG
#
# options:
#   --sidecars-directory DIR   default is /var/lib/xen/pvshim-sidecars
#   --shim SHIMoverrides domain config file
#   --debugverbose, 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, '<' or die $!;
}
{
local $/;
$indata = ;
}
I->error and die $!;
close I;

open P, "-|", qw(python -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 = <", "$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 <", "$dmwrap.new" or die "$dmwrap: $!";
print Q 

[Xen-devel] [PATCH v3 1/2] x86/setup: do not relocate Xen over current Xen image placement

[Daniel Kiper]

Otherwise, due to Xen code/data changes under CPU feet, Xen may crash
silently at boot.

We were hit by the issue in OVS Xen 4.4 with my earlier version of
EFI/Multiboot2 patches. Initially its implementation allowed relocation
of Xen even if it was relocated by the bootloader. This led to the
crashes on some new Oracle machines because copy destination partially
overlapped with the end of current/initial Xen image placement.

After some discussion on Xen-devel we decided to disable Xen relocation in
my EFI/Multiboot2 upstream patches if the booloader did the work for us.
Though one case is still not covered. If Xen is not relocated by the
booloader then it tries to do that by itself. If all RAM regions above
currently occupied one are unsuitable for relocation then Xen tries to move
itself higher in it. And if (end - reloc_size + XEN_IMG_OFFSET) goes below
__pa(_end) then copy/relocation destination overlaps, at least partially,
with its source.

I can agree that this should not happen on todays machines very often.
If at all. It is rather unusual to not have usable RAM regions above
~5 MiB nowadays. Though I think that we should at least consider putting
such safety measure here. Otherwise Xen may crash mysteriously without
any stack trace. It is very confusing and impairs further debugging.

Signed-off-by: Daniel Kiper 
---
v3 - suggestions/fixes:
   - use more readable condition
 (suggested by Jan Beulich),
   - improve comment
 (suggested by Jan Beulich),
   - improve commit message.

v2 - suggestions/fixes:
   - improve comment
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/setup.c |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 2e10c6b..9f8abd9 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -962,7 +962,12 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 }
 else
 end = 0;
-if ( end > s )
+
+/*
+ * Is the region size greater than zero and does it begin
+ * at or above the end of current Xen image placement?
+ */
+if ( (end > s) && (end - reloc_size + XEN_IMG_OFFSET >= __pa(_end)) )
 {
 l4_pgentry_t *pl4e;
 l3_pgentry_t *pl3e;
-- 
1.7.10.4


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

[Xen-devel] [PATCH v3 2/2] x86/setup: remap Xen image up to PFN_DOWN(__pa(_end))

[Daniel Kiper]

Current limit, PFN_DOWN(xen_phys_start), introduced by commit b280442
(x86: make Xen early boot code relocatable) is not reliable. Potentially
its value may fall below PFN_DOWN(__pa(_end)) and then part of Xen image
may not be mapped after relocation. This will not happen in current code
thanks to "x86/setup: do not relocate over current Xen image placement"
patch. Though this safety measure may save a lot of debugging time when
somebody decide to relax existing relocation restrictions one day.
Additionally, remapping will execute a bit faster due to this change.

Signed-off-by: Daniel Kiper 
---
 xen/arch/x86/setup.c |   11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 9f8abd9..ac163e2 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -973,6 +973,11 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 l3_pgentry_t *pl3e;
 l2_pgentry_t *pl2e;
 int i, j, k;
+/*
+ * We have to calculate xen_remap_end_pfn before
+ * xen_phys_start change.
+ */
+unsigned long xen_remap_end_pfn = PFN_DOWN(__pa(_end));
 
 /* Select relocation address. */
 e = end - reloc_size;
@@ -1002,7 +1007,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 /* Not present, 1GB mapping, or already relocated? */
 if ( !(l3e_get_flags(*pl3e) & _PAGE_PRESENT) ||
  (l3e_get_flags(*pl3e) & _PAGE_PSE) ||
- (l3e_get_pfn(*pl3e) > PFN_DOWN(xen_phys_start)) )
+ (l3e_get_pfn(*pl3e) > xen_remap_end_pfn) )
 continue;
 *pl3e = l3e_from_intpte(l3e_get_intpte(*pl3e) +
 xen_phys_start);
@@ -1012,7 +1017,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 /* Not present, PSE, or already relocated? */
 if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) ||
  (l2e_get_flags(*pl2e) & _PAGE_PSE) ||
- (l2e_get_pfn(*pl2e) > PFN_DOWN(xen_phys_start)) )
+ (l2e_get_pfn(*pl2e) > xen_remap_end_pfn) )
 continue;
 *pl2e = l2e_from_intpte(l2e_get_intpte(*pl2e) +
 xen_phys_start);
@@ -1036,7 +1041,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 unsigned int flags;
 
 if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) ||
- (l2e_get_pfn(*pl2e) > PFN_DOWN(xen_phys_start)) )
+ (l2e_get_pfn(*pl2e) > xen_remap_end_pfn) )
 continue;
 
 if ( !using_2M_mapping() )
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH RFC v1 58/74] xen/pvshim: add migration support

[Roger Pau Monné]

On Tue, Jan 09, 2018 at 02:38:21AM -0700, Jan Beulich wrote:
> >>> On 04.01.18 at 14:06,  wrote:
> > +struct domain *d = current->domain;
> > +struct vcpu *v;
> > +unsigned int i;
> > +uint64_t old_store_pfn, old_console_pfn = 0, store_pfn, 
> > console_pfn;
> > +uint64_t store_evtchn, console_evtchn;
> > +
> > +BUG_ON(current->vcpu_id != 0);
> > +
> > +BUG_ON(xen_hypercall_hvm_get_param(HVM_PARAM_STORE_PFN,
> > +   _store_pfn));
> > +if ( !pv_console )
> > +BUG_ON(xen_hypercall_hvm_get_param(HVM_PARAM_CONSOLE_PFN,
> > +   _console_pfn));
> > +
> > +/* Pause the other vcpus before starting the migration. */
> > +for_each_vcpu(d, v)
> > +if ( v != current )
> > +vcpu_pause_by_systemcontroller(v);
> > +
> > +rc = xen_hypercall_shutdown(SHUTDOWN_suspend);
> > +if ( rc )
> > +{
> > +for_each_vcpu(d, v)
> > +if ( v != current )
> > +vcpu_unpause_by_systemcontroller(v);
> > +
> > +return rc;
> > +}
> > +
> > +/* Resume the shim itself first. */
> > +hypervisor_resume();
> > +
> > +/*
> > + * ATM there's nothing Xen can do if the console/store pfn changes,
> > + * because Xen won't have a page_info struct for it.
> > + */
> > +BUG_ON(xen_hypercall_hvm_get_param(HVM_PARAM_STORE_PFN,
> > +   _pfn));
> > +BUG_ON(old_store_pfn != store_pfn);
> > +if ( !pv_console )
> > +{
> > +BUG_ON(xen_hypercall_hvm_get_param(HVM_PARAM_CONSOLE_PFN,
> > +   _pfn));
> > +BUG_ON(old_console_pfn != console_pfn);
> > +}
> > +
> > +/* Update domain id. */
> > +d->domain_id = get_dom0_domid();
> > +
> > +/* Clean the iomem range. */
> > +BUG_ON(iomem_deny_access(d, 0, ~0UL));
> 
> Does this rangeset change across migration?

Likely, the allowed iomem ranges for the DomU change depending on what
hypervisor_alloc_unused_page returns. Those are mainly used to map
grant table frames.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v3 00/24] Vixen: A PV-in-HVM shim

[Wei Liu]

On Tue, Jan 09, 2018 at 04:02:34PM -0800, Anthony Liguori wrote:
> From: Anthony Liguori 
> 
> CVE-2017-5754 is problematic for paravirtualized x86 domUs because it
> appears to be very difficult to isolate the hypervisor's page tables
> from PV domUs while maintaining ABI compatibility.  Instead of trying
> to make a KPTI-like approach work for Xen PV, it seems reasonable to
> run a copy of Xen within an HVM (or PVH) domU to provide backwards
> compatibility with guests as mentioned in XSA-254 [1].
> 
> This patch series adds a new mode to Xen called Vixen (Virtualized
> Xen) which provides a PV-compatible interface while gaining
> CVE-2017-5754 protection for the host provided by hardware
> virtualization.  Vixen supports running a single unprivileged PV
> domain (a dom1) that is constructed by the dom0 domain builder.
> 
> Please note the Xen page table configuration fundamental to the
> current PV ABI makes it impossible for an operating system to mitigate
> CVE-2017-5754 through mechanisms like Kernel Page Table Isolation
> (KPTI).  In order for an operating system to mitigate CVE-2017-5754 it
> must run directly in a HVM or PVH domU.
> 
> This series is very similar to the PVH series posted by Wei and we
> have been discussing how to merge efforts.  We were hoping to have
> more time to work this out.  I am posting this because I'm fairly
> confident that this series is complete (all PV instances in EC2 are
> using this) and others might find it useful.  I also wanted to have
> more of a discussion about the best way to merge and some of the
> differences in designs.
> 

What sort of testing is done on this version? I think the cover letter
should be updated if this isn't the exact version deployed in EC2. And I
would rather have users get a well-tested and deployed version from
Amazon.

> This series is also available at:
> 
>  git clone https://github.com/aliguori/xen.git vixen-upstream-v2
> 

Should be v3 now?

Wei.

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

Re: [Xen-devel] [BUG] kernel bug encountered at drivers/net/xen-netback/netback.c:430!

[Paul Durrant]

I have tracked down the problem to multiple calls to the zerocopy callback for 
the same ubuf_info. I am not sure exactly which patch introduced the issue but 
my suspicion is that it was one of the the MSG_ZEROCOPY series (see 
https://marc.info/?l=linux-netdev=149807997726733=2).
I have a candidate patch to netback to make use of the ubuf_info ref count to 
handle the multiple callbacks and that certainly fixes the issue for me. I'll 
post this shortly recommending a backport to stable.

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

Re: [Xen-devel] [PATCH v3 04/24] x86: Don't use potentially incorrect CPUID values for topology information

[Wei Liu]

On Tue, Jan 09, 2018 at 04:02:38PM -0800, Anthony Liguori wrote:
> From: Jan H. Schönherr 
> 
> Intel says for CPUID leaf 0Bh:
> 
>   "Software must not use EBX[15:0] to enumerate processor
>topology of the system. This value in this field
>(EBX[15:0]) is only intended for display/diagnostic
>purposes. The actual number of logical processors
>available to BIOS/OS/Applications may be different from
>the value of EBX[15:0], depending on software and platform
>hardware configurations."
> 
> And yet, we're using them to derive the number cores in a package
> and the number of siblings in a core.
> 
> Derive the number of siblings and cores from EAX instead, which is
> intended for that.
> 
> Signed-off-by: Jan H. Schönherr 

This is already merged to staging.

Wei.

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

Re: [Xen-devel] [PATCH v4 01/39] arm/p2m: Introduce p2m_(switch|restore)_vttbr_and_(g|s)et_flags

[Sergej Proskurin]

Hi Julien,

please excuse me for the long delay.

On 10/09/2017 06:25 PM, Julien Grall wrote:
> Hi Sergej,
>
> On 30/08/17 19:32, Sergej Proskurin wrote:
>> This commit introduces macros for switching and restoring the vttbr
>> considering the currently set irq flags. We define these macros, as the
>> following commits will use the associated functionality multiple times
>> throughout different files.
>>
>> Signed-off-by: Sergej Proskurin 
>> ---
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>> ---
>> v4: Save the content of VTTBR_EL2 inside of the introduced macro
>>  "p2m_switch_vttbr_and_get_flags".
>>
>>  Move the introduced macros into ./xen/include/asm-arm/p2m.h, as
>> they will
>>  be used by different files in the future commits.
>
> I don't like the idea of moving such macros in p2m.h because it expose
> the underlying implementation of P2M.
>
> A better solution would be introduce a helper to translate from a
> guest VA to guest PA in p2m.c. This helper will switch to the host P2M
> if necessary.

I agree, thank you. This would eliminate the unnecessary macro
invocations in mem_access.c. I will include such wrapper in p2m.c in the
next version of the altp2m patch series.

Do you think it would make sense to submit the upper macros for saving
and restoring the VTTBR and flags as a standalone patch in form of a
cosmetic fix? This would simplify the function p2m_force_tlb_flush_sync
in p2m.c.

Thanks,
~Sergej


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

[Xen-devel] [distros-debian-squeeze test] 74195: trouble: blocked/broken

[Platform Team regression test user]

flight 74195 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74195/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvopsbroken
 build-i386   broken
 build-amd64-pvopsbroken
 build-armhf  broken
 build-amd64  broken
 build-i386-pvops broken
 build-armhf-pvops 3 syslog-serverrunning
 build-armhf   3 syslog-serverrunning

Tests which did not succeed, but are not blocking:
 test-amd64-i386-i386-squeeze-netboot-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-i386-squeeze-netboot-pygrub  1 build-check(1) blocked n/a
 test-amd64-i386-amd64-squeeze-netboot-pygrub  1 build-check(1) blocked n/a
 test-amd64-amd64-amd64-squeeze-netboot-pygrub  1 build-check(1)blocked n/a
 build-armhf   4 host-install(4)  broken like 73828
 build-armhf-pvops 4 host-install(4)  broken like 73828
 build-armhf   5 capture-logs broken like 73828
 build-armhf-pvops 5 capture-logs broken like 73828
 build-amd64   4 host-install(4)  broken like 73828
 build-i386-pvops  4 host-install(4)  broken like 73828
 build-amd64-pvops 4 host-install(4)  broken like 73828
 build-i3864 host-install(4)  broken like 73828

baseline version:
 flight   73828

jobs:
 build-amd64  broken  
 build-armhf  broken  
 build-i386   broken  
 build-amd64-pvopsbroken  
 build-armhf-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-amd64-squeeze-netboot-pygrubblocked 
 test-amd64-i386-amd64-squeeze-netboot-pygrub blocked 
 test-amd64-amd64-i386-squeeze-netboot-pygrub blocked 
 test-amd64-i386-i386-squeeze-netboot-pygrub  blocked 



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


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

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

[Wei Liu]

On Wed, Jan 10, 2018 at 08:32:24AM +, Roger Pau Monné wrote:
> On Tue, Jan 09, 2018 at 07:43:51PM +, Wei Liu wrote:
> > On Mon, Jan 08, 2018 at 05:45:32PM +, 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 

Re: [Xen-devel] [PATCH RFC v1 55/74] xen/pvshim: forward evtchn ops between L0 Xen and L2 DomU

[Roger Pau Monné]

On Tue, Jan 09, 2018 at 09:50:14AM -0800, Anthony Liguori wrote:
> On Mon, Jan 8, 2018 at 8:05 AM, Jan Beulich  wrote:
>  On 04.01.18 at 14:06,  wrote:
> >> From: Roger Pau Monne 
> >>
> >> Note that the unmask and the virq operations are handled by the shim
> >> itself, and that FIFO event channels are not exposed to the guest.
> >>
> >> Signed-off-by: Anthony Liguori 
> >> Signed-off-by: Roger Pau Monné 
> >> Signed-off-by: Sergey Dyasli 
> >
> > In RFC state this certainly doesn't matter yet, but generally I'd
> > expect From: to match the first S-o-b.
> >
> >> @@ -155,11 +156,31 @@ static void set_vcpu_id(void)
> >>  static void xen_evtchn_upcall(struct cpu_user_regs *regs)
> >>  {
> >>  struct vcpu_info *vcpu_info = this_cpu(vcpu_info);
> >> +unsigned long pending;
> >>
> >>  vcpu_info->evtchn_upcall_pending = 0;
> >> -xchg(_info->evtchn_pending_sel, 0);
> >> +pending = xchg(_info->evtchn_pending_sel, 0);
> >>
> >> -pv_console_rx(regs);
> >> +while ( pending )
> >> +{
> >> +unsigned int l1 = ffsl(pending) - 1;
> >
> > find_first_set_bit() would look to be the better match here (and
> > below), not the least because it translates (on capable hardware)
> > to TZCNT instead of BSF.
> >
> >> +unsigned long evtchn = xchg(_shared_info->evtchn_pending[l1], 
> >> 0);
> >> +
> >> +__clear_bit(l1, );
> >> +evtchn &= ~XEN_shared_info->evtchn_mask[l1];
> >> +while ( evtchn )
> >> +{
> >> +unsigned int port = ffsl(evtchn) - 1;
> >> +
> >> +__clear_bit(port, );
> >> +port += l1 * BITS_PER_LONG;
> >
> > What about a 32-bit client? If that's not intended to be supported,
> > building of such a guest should be prevented (in dom0_build.c).
> 
> Note that we discarded this approach in the Vixen series because it
> wasn't working reliably for injecting remote event channel
> notifications.

I have to admit I haven't found issues with this implementation, and
AFAICT it looks correct albeit simplistic.

The lack if issues might be because the shim only supports
HVMOP_set_evtchn_upcall_vector as the event channel injection
mechanism ATM. I guess we will revising this if required once more
event channel injection mechanisms are added.

Thanks, Roger.

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

[Xen-devel] [libvirt test] 117737: tolerable all pass - PUSHED

[osstest service owner]

flight 117737 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117737/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 117662
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 117662
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 117662
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  e3088bfd8efe0ec4a3875788aad6d69f48509c2d
baseline version:
 libvirt  2b041dc8c7b70e762d99b6bd7805daa9961740f6

Last test of basis   117662  2018-01-05 20:58:25 Z4 days
Testing same since   117737  2018-01-09 04:20:02 Z1 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Bjoern Walk 
  Chen Hanxiao 
  Michal Privoznik 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test 

Re: [Xen-devel] [PATCH RFC 4/4] xen: use per-vcpu TSS and stacks for pv domains

[Juergen Gross]

On 10/01/18 11:40, Andrew Cooper wrote:
> On 09/01/18 19:39, Juergen Gross wrote:
>> On 09/01/18 20:13, Andrew Cooper wrote:
>>> (sorry for the top-post. I'm on my phone) 
>>>
>>> I can see you are using ltr, but I don't see anywhere where where you are 
>>> changing the content on the TSS, or the top-of-stack content.
>> The per-vcpu TSS is already initialized with the correct stack
>> addresses, so it doesn't have to be modified later.
>>
>>> It is very complicated to safely switch IST stacks when you might be taking 
>>> interrupts.
>> Using LTR with a new TSS with both stack areas mapped (old and new)
>> should work, right?
> 
> The top-of-stack block has pcpu information on it, including
> smp_processor_id() and pervcpu_offset.  Switching the cr4 shadow without
> hitting an assert is tricky, and was left with a rather large RFC/TODO
> in my pre-kaiser series.
> 
> The syscall stubs contain absolute stack references in them, so at a
> minimum they also need rewriting on context switch.

Aah, okay. This is the information I was after.

So I need to look after struct cpu_info and the syscall stubs next.


Juergen

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

Re: [Xen-devel] [PATCH RFC 4/4] xen: use per-vcpu TSS and stacks for pv domains

[Andrew Cooper]

On 09/01/18 19:39, Juergen Gross wrote:
> On 09/01/18 20:13, Andrew Cooper wrote:
>> (sorry for the top-post. I'm on my phone) 
>>
>> I can see you are using ltr, but I don't see anywhere where where you are 
>> changing the content on the TSS, or the top-of-stack content.
> The per-vcpu TSS is already initialized with the correct stack
> addresses, so it doesn't have to be modified later.
>
>> It is very complicated to safely switch IST stacks when you might be taking 
>> interrupts.
> Using LTR with a new TSS with both stack areas mapped (old and new)
> should work, right?

The top-of-stack block has pcpu information on it, including
smp_processor_id() and pervcpu_offset.  Switching the cr4 shadow without
hitting an assert is tricky, and was left with a rather large RFC/TODO
in my pre-kaiser series.

The syscall stubs contain absolute stack references in them, so at a
minimum they also need rewriting on context switch.

~Andrew

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

Re: [Xen-devel] [PATCH] x86/ioemul: Account for ioemul_handle_quirk() in stub length check

[Andrew Cooper]

On 10/01/2018 09:52, Jan Beulich wrote:
 On 09.01.18 at 17:47,  wrote:
>> The opcode potentially written into ctxt->io_emul_stub[] in the case
>> that ioemul_handle_quirk() is overriding the default logic isnt
>> accounted for in the build-time check that the stubs are large enough.
>>
>> Introduce IOEMUL_QUIRK_STUB_BYTES and use for both the main and quirk
>> stub cases.  As a slim optimisation, avoid writing out the default stub
>> when we know we are going to overwrite it.
>>
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 
> with one suggestion:
>
>> --- a/xen/arch/x86/pv/emul-priv-op.c
>> +++ b/xen/arch/x86/pv/emul-priv-op.c
>> @@ -89,19 +89,24 @@ static io_emul_stub_t *io_emul_stub_setup(struct 
>> priv_op_ctxt *ctxt, u8 opcode,
>>  /* callq *%rcx */
>>  ctxt->io_emul_stub[10] = 0xff;
>>  ctxt->io_emul_stub[11] = 0xd1;
>> -/* data16 or nop */
>> -ctxt->io_emul_stub[12] = (bytes != 2) ? 0x90 : 0x66;
>> -/*  */
>> -ctxt->io_emul_stub[13] = opcode;
>> -/* imm8 or nop */
>> -ctxt->io_emul_stub[14] = !(opcode & 8) ? port : 0x90;
>> -/* ret (jumps to guest_to_host_gpr_switch) */
>> -ctxt->io_emul_stub[15] = 0xc3;
>> -BUILD_BUG_ON(STUB_BUF_SIZE / 2 < 16);
>> -
>> -if ( ioemul_handle_quirk )
>> +
>> +if ( likely(!ioemul_handle_quirk) )
>> +{
>> +/* data16 or nop */
>> +ctxt->io_emul_stub[12] = (bytes != 2) ? 0x90 : 0x66;
>> +/*  */
>> +ctxt->io_emul_stub[13] = opcode;
>> +/* imm8 or nop */
>> +ctxt->io_emul_stub[14] = !(opcode & 8) ? port : 0x90;
>> +/* ret (jumps to guest_to_host_gpr_switch) */
>> +ctxt->io_emul_stub[15] = 0xc3;
>> +}
>> +else
>>  ioemul_handle_quirk(opcode, >io_emul_stub[12], 
>> ctxt->ctxt.regs);
>>  
>> +BUILD_BUG_ON(STUB_BUF_SIZE / 2 < MAX(16, /* Regular stubs */
> Now that we have it available globally, would you mind using
> MAX_INST_LEN + 1 here instead of the literal 16?

This raw 16 is because we write 16 bytes into ctxt->io_emul_stub[], and
this jumps to 19 with the INDIRECT_THUNK work, not because it is related
to MAX_INST_LEN.

~Andrew

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

[Xen-devel] [xen-unstable-coverity test] 117768: all pass - PUSHED

[osstest service owner]

flight 117768 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117768/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  d51baf310e530659f73e714acf57bdc46303
baseline version:
 xen  2d1c82261d966735e82e5971eddb63ba3c565a37

Last test of basis   117698  2018-01-07 09:19:02 Z3 days
Testing same since   117768  2018-01-10 09:19:58 Z0 days1 attempts


People who touched revisions under test:
  Jan H. Schönherr 

jobs:
 coverity-amd64   pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   2d1c82261d..d51baf310e  d51baf310e530659f73e714acf57bdc46303 -> 
coverity-tested/smoke

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

Re: [Xen-devel] [PATCH] x86/ioemul: Account for ioemul_handle_quirk() in stub length check

[Jan Beulich]

>>> On 09.01.18 at 17:47,  wrote:
> The opcode potentially written into ctxt->io_emul_stub[] in the case
> that ioemul_handle_quirk() is overriding the default logic isnt
> accounted for in the build-time check that the stubs are large enough.
> 
> Introduce IOEMUL_QUIRK_STUB_BYTES and use for both the main and quirk
> stub cases.  As a slim optimisation, avoid writing out the default stub
> when we know we are going to overwrite it.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 
with one suggestion:

> --- a/xen/arch/x86/pv/emul-priv-op.c
> +++ b/xen/arch/x86/pv/emul-priv-op.c
> @@ -89,19 +89,24 @@ static io_emul_stub_t *io_emul_stub_setup(struct 
> priv_op_ctxt *ctxt, u8 opcode,
>  /* callq *%rcx */
>  ctxt->io_emul_stub[10] = 0xff;
>  ctxt->io_emul_stub[11] = 0xd1;
> -/* data16 or nop */
> -ctxt->io_emul_stub[12] = (bytes != 2) ? 0x90 : 0x66;
> -/*  */
> -ctxt->io_emul_stub[13] = opcode;
> -/* imm8 or nop */
> -ctxt->io_emul_stub[14] = !(opcode & 8) ? port : 0x90;
> -/* ret (jumps to guest_to_host_gpr_switch) */
> -ctxt->io_emul_stub[15] = 0xc3;
> -BUILD_BUG_ON(STUB_BUF_SIZE / 2 < 16);
> -
> -if ( ioemul_handle_quirk )
> +
> +if ( likely(!ioemul_handle_quirk) )
> +{
> +/* data16 or nop */
> +ctxt->io_emul_stub[12] = (bytes != 2) ? 0x90 : 0x66;
> +/*  */
> +ctxt->io_emul_stub[13] = opcode;
> +/* imm8 or nop */
> +ctxt->io_emul_stub[14] = !(opcode & 8) ? port : 0x90;
> +/* ret (jumps to guest_to_host_gpr_switch) */
> +ctxt->io_emul_stub[15] = 0xc3;
> +}
> +else
>  ioemul_handle_quirk(opcode, >io_emul_stub[12], 
> ctxt->ctxt.regs);
>  
> +BUILD_BUG_ON(STUB_BUF_SIZE / 2 < MAX(16, /* Regular stubs */

Now that we have it available globally, would you mind using
MAX_INST_LEN + 1 here instead of the literal 16?

Jan


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

[Xen-devel] [qemu-mainline baseline-only test] 74185: trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 74185 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74185/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64  broken
 build-i386   broken
 build-armhf-pvopsbroken
 build-i386-xsm   broken
 build-amd64-xsm  broken
 build-amd64-pvopsbroken
 build-i386-pvops broken
 build-armhf-xsm  broken
 build-armhf  broken
 build-armhf-pvops 3 syslog-serverrunning
 build-armhf   3 syslog-serverrunning
 build-armhf-xsm   3 syslog-serverrunning

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  

Re: [Xen-devel] [PATCH 2/2] xen/gntdev: Fix partial gntdev_mmap() cleanup

[Ross Lagerwall]

On 01/10/2018 01:22 AM, Boris Ostrovsky wrote:



On 01/09/2018 07:10 AM, Ross Lagerwall wrote:

When cleaning up after a partially successful gntdev_mmap(), unmap the
successfully mapped grant pages otherwise Xen will kill the domain if
in debug mode (Attempt to implicitly unmap a granted PTE) or Linux will
kill the process and emit "BUG: Bad page map in process" if Xen is in
release mode.

This is only needed when use_ptemod is true because gntdev_put_map()
will unmap grant pages itself when use_ptemod is false.

Signed-off-by: Ross Lagerwall 


Reviewed-by: Boris Ostrovsky 

although I wonder whether it may be possible to have gntdev_put_map() 
figure whether to unmap the pages if use_ptemod is set.


It was a while since I wrote this patch, but IIRC when use_ptemod is 
set, successfully mmapped pages are unmapped via the mmu_notifier 
release callback. So doing it in gntdev_put_map() isn't possible without 
further changes.


--
Ross Lagerwall

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

Re: [Xen-devel] [RFC PATCH 1/8] x86/domctl: introduce a pair of hypercall to set and get cpu topology

[Andrew Cooper]

On 09/01/2018 20:47, Chao Gao wrote:
> On Tue, Jan 09, 2018 at 11:47:54PM +, Andrew Cooper wrote:
>> On 08/01/18 04:01, Chao Gao wrote:
>>> Define interface, structures and hypercalls for toolstack to build
>>> cpu topology and for guest that will retrieve it [1].
>>> Two subop hypercalls introduced by this patch:
>>> XEN_DOMCTL_set_cpu_topology to define cpu topology information per domain
>>> and XENMEM_get_cpu_topology to retrieve cpu topology information.
>>>
>>> [1]: during guest creation, those information helps hvmloader to build ACPI.
>>>
>>> Signed-off-by: Chao Gao 
>> I'm sorry, but this going in the wrong direction.  Details like this
>> should be contained and communicated exclusively in the CPUID policy.
>>
>> Before the spectre/meltdown fire started, I had a prototype series
>> introducing a toolstack interface for getting and setting a full CPUID
>> policy at once, rather than piecewise.  I will be continuing with this
> Is the new interface able to set CPUID policy for each vCPU rather than
> current for each domain? Otherwise I couldn't see how to set APIC_ID
> for each vcpu except by introducing a new interface.

AFAIR, all APIC IDs can be uniquely and correctly derived from the
shift/count information in leaf 0xb

We've already got some CPUID information that is derived either entirely
dynamically (e.g. OSXSAVE), or when first set.  This isn't any different.

>
>> work once the dust settles.
>>
>> In particular, we should not have multiple ways of conveying the same
>> information, or duplication of the same data inside the hypervisor.
>>
>> If you rearrange your series to put the struct cpuid_policy changes
>> first, then patch 2 will become far more simple.  HVMLoader should
>> derive its topology information from the CPUID instruction, just as is
>> expected on native hardware.
> Good point. It seems that in HVMLoader BSP should boot APs in a
> broadcase fashion and then information is collected via CPUID and then
> build MADT/SRAT.

We already do that for MTRR setup, but as before, I'm fairly sure the
BSP can do this alone.

~Andrew

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